we all have learned that the cause always precedes the effect. When A causes B, A is earlier than B.
When I use the debugger, I sometimes have the impression that it is the other way round.
I work on a part of code, start the debugger and get an error or malfunction in a different part of code which is executed much earlier than the part of code I am working on.
For example, there is the routine which copies code from flash to RAM. It is standard in all our projects.
Then a routine which does some initialization, and then I added a line to calculate a CRC.
Start the debugger, get a core bus fault.
Single-step to find out where it happened, it happened when calling the initialization routine mentioned above.
Looked at the disassembly code, I do not see a "bl" statement which branches to the initialization routine.
Found out that the machine code in RAM is not identical to the code in flash, two bytes are not copied.
Luckily it happened in the beginning of the section, so I saw it in the memory browser on the first glance.
Restart the debugger, single-step to the routine which copies code from flash to RAM.
The first bytes are copied OK, but two bytes are not copied.
I correct them manually in the memory browser and the program runs as before.
I preset the region of memory in RAM to 0xAA, these two bytes are still 0xAA after copying.
Try a different board, maybe there is a memory problem. No.
Add code to compare each byte after copying, single-step it, the values I read back are the ones I tried to write.
But still the memory browser shows wrong values, the code wouldn't execute, neither with debugger nor stand-alone without debugger.
It took me long to find out what I had done wrong:
The clock for the crypto unit was not enabled in the SIM module before I tried to calculate a CRC.
Added a line to enable it, all is fine.
So, why can code which is executed much later affect code which is executed earlier?
Can I use it to travel to the past? There are a few things in my life which I should have done differently.
Greetings from the future,
Let me just toss out a couple items:
Debug-window contents are often 'cached' by tools to cut down link-traffic.
Some 'older' Kinetis silicon had errata against the hardware cache. This may be affecting your copy operation.
Thank you for answering.
Yes, I suspected caching. So it looks as if I do not see the real process but kind of a "movie" of things which have happened long before.
And maybe, when the processor gets corrupted too much, an error is reported at a totally misleading line number.
We use an up-to-date K70 (mask 3 and mask 4).
The error you mention might be happening because of the compiler optimizations, you can find information about these optimizations in the document "CodeWarrior Development Studio for Microcontrollers V10.x Kinetis Freescale Build Tools Reference Manual" (C:\Freescale\CW MCU v10.6\MCU\Help\PDF\MCU_Kinetis_Compiler.pdf).
If you want you can upload an example project where the behavior you mention is happening and we can review if it is because of the compiler optimizations.