Hi Steen
I don't know whether there is any relation but I had a strange effect recently in a project with the M5225x using CodeWarrior V7.1.1. I use this version of CW because it has never shown problems before (whereby some newer ones had some quite nasty compiler problems).
The project that was being worked on/tested seemed fine until once I realised that it was not starting correctly. It was missing a part of the SW initialisation which was being controlled by a SW timer event. When the board was in this state I could reset it and it would always behave the same (missing the part of initialisation in question and so not operate correctly). After a power cycle it would sometimes start working again (usually after removing power for a few seconds).
When in this state I could connect the debugger and see that the SW timer was correctly firing and causing the code that should react to it to be called but this code was not correctly recognising the timer event number - it was using a
switch() statement and the case in question was never matched, although the value was OK. I reported this here but, since it is an older CW version, is is more "just for the record":
https://community.freescale.com/message/307158#307158After replacing the switch with a row of
if - elses it looked OK. The next day however I had the effect again and saw that also the if statment was not recognising the event number for the same reason. Rather than doing a compare with a fixed value I put the compare value into a variable and compared with that instead and it was finally solved. In this case it became also clear that the compiler was comparing the value with the content of d5 - this register was being set with the correct compare value in assembler but the code leading up to the compare was not actually executing the register load - the code was jumping in 2 lines after the assembler location where the register was loaded and so the result was in fact quite random since the compare was with whatever value the register happend to have in it at the time.
Could it be that your code also suffers from a similar compiler problem that causes an initialisation routine to be missed in some cases?
Regards
Mark