Hi,
I am facing a strange behavior of my code. If I write new code or add code to existing classes etc. the programm may cause an B-Trap IR. The TFR then says ILLOPA or UNDOPC. If I then add more code, the error disappears but it pops up again if I add even more and so on. If tried to identify the code line where the error happen, but the stack doesn't contain any valid flash address when I break the programm inside the Trap-IF function. The CSP is 0 and IP is something like 0x06 or 0x0A. Flashcode starts at 0xC00000.
I tried to debug the code to find the place where the error happens. Disassembly shows an write operation to the PSW register. The purpose is to do a IR-lock. But what is strange again, if I set some breapoints around this place of code, the B-Trap won't trigger! I have to run the code from the start or set the breakpoint far away to trigger the error.
I also checked the user stack by filling the stack with a pattern so see how much of the stack is used. But there is plenty of space left.
Does someone have an idea or hint about this?
Several years ago I had similar problems with ST10F269. In my case, the root of this problem was incorrect operation of the PC software, that was used for the flash download. It was not ST10 flasher from the STM. Then I have read back flash memory, using ST10 flasher utility, and compared it with the original hex-file. 1-byte difference on the address 0x4000 was detected. The firmware behaviour was depended on, which value was located there.
Thank you for your answer. Unfortunately, this was no the source of the Problem.
I figured out, that sometimes that there are two points inside the code the error is triggered. First at an icall-instruction where R4 and R5 are loaded with zero address. So naturally the call goes to address 0x0 and continues to run. At 0x06 there is a instruction that uses an odd address. While I still don't know why there is any code, the cause of ILLOPA is clear.
The second point is, when I trigger an external IR-Routine several times. If I check the SP, the code address of the cause is always different but all instructions are something like:
mov Rn,[R0+]
so something might be wrong with the stack. Trying to increase user or system stack does not solve the problem.
I feel like that there are some race conditions or something is going on. Maybe some atomics are not real atomics?