OK, I'll re-read the documentation maybe I am wrong!
It does say synchronous in the description and I don't understand how it can
work if it is asynchronous because for Cortex the SVC argument is not
transfered to a register and the only way the exception code can access it is
by reading it
In particular table 2-16 of DUI0552A_Cortex_m3_dgug.pdf states that the
Activation of the SVC exception is Synchronous.
And after the table it states For an asynchronous exception, other than reset,
the processor can execute another instruction
between when the exception is triggered and when
ok, I'll double check that backing out the local patches doesn't make a
difference. If it still happens I will try and come up with a reduced
test case.
What do you expect to happen?
Should the SVC exception 11 run immediately?
What should happen if a clock tick interrupt is also pending at level
I have put together a test program and tried against a vanila copy of
qemu 1.1.1
The SVC wil be completely masked unless I apply patch 0002-target-arm-
Disable-priority_mask-feature.patch, which hacks arm_gic.c to initialise
the gic priority_mask to 0x100 instead of 0xf0. There doesn't appear to
I've made an interesting discovery:-
If I instrument the code to record the sequence of code/exceptions and
get a different, and apparently correct result!
If I single step by starting the simulator with the following command
line qemu-system-arm -M lm3s6965evb -cpu cortex-m3 -kernel hack.bin
I have been experimenting with Sebastian's patches mentioned earlier
(http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/lm3s69xx?id=e1ebfebf1bffe3e7731ac529409bd2576285467b)
and think I have found another major issue:-(
My reading of the ARM documentation is that the SVC opcode should perform
