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
-n
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
b
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
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 t
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 fr
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 a
