I was trying to write a register context saving/restoring when I came across a weird behaviour.
My code (sorry, tried to format tens of times, but the editor WANTS to make asm a table):
When the exception is returned from, the calling function:
msg = "returned from SVC\r\n";
serial_io.put_string(msg, util_str_len(msg)+1);
asm volatile (
);
msg = "cpsr = ";
util_word_to_hex(scratchpad, tmp1);
serial_io.put_string(scratchpad, 9);
serial_io.put_string("\r\n", 3);
outputs "returned from SVC" and "cpsr = 60000013".
Why the "00000002"? the barriers don't seem to have any effect.
Hello turboscrew,
do you wonder why "00000002" was read as SPSR?
If it would be correct, I think "msr cpsr_fsxc, r2" would affect it.
By changing CSPR, the execution mode was changed.
After that, the SPSR would be read from the new execution mode.
Probably it would be unknown value.
I guess you did recover CPSR to SVC mode after reading SPSR.
Therefore, the correct CPSR was read in the main function.
Best regards,
Yasuhiko Koumoto.
But after "msr cpsr_fsxc, r2" I do "msr spsr_fsxc, r3" before reading "mrs r3, spsr".
The setting and reading spsr should happen in the same mode.
I'm sorry and I misunderstood the program sequence.
By the way, why do the delimiters exit in the previous inline assembly ocdes?
If you put delimiter for each assembly line, dose the problem still occur?
I think
"@isb" "msr spsr_fsxc, r3" - set value
"@isb"
"msr spsr_fsxc, r3" - set value
did not change the SPSR.
The funny thing was, the CPSR was right after return, so "msr spsr_fsxc, r3" did change the value - later.
The code works even if the printed value was wrong.