AnsweredAssumed Answered

Debugging an anomalous RAM write on S12(X)

Question asked by utwig on Oct 10, 2018
Latest reply on Oct 14, 2018 by utwig



I have encountered a very strange bug in my software for the MC9S12XEP100. I am using an array of structs for storing pulse counting data. I observe a number of pulses, store the "timestamp" of the first and last measured pulse with the Enhanced Capture Timer and calculate the number of timer overflows. The same process is repeated to 8 external multiplexer channels connected to an ECT input in sequence. The measured data along with some status information is stored in RAM into the array of structs.


The code has been working fine and producing correct pulse counting results, until recently I discovered that something is overwriting a part of the data inside the struct. Previously, if I disconnected the test signal generator from the ECT input and performed a pulse measurement, I would get all 0 results in my structure, as expected. But now, one of the bytes in the struct gets replaced with "0x07".


If I connect the signal generator, I will get a value which is otherwise OK, but one of the bytes is replaced by "0x07" on the same multiplexer channel and byte as above. Other multiplexer channels work nominally.


If I make a slight change into the code, the anomalous byte may shift its position in the data. So it seems that it is happening with a constant offset from some address. I suspect that this anomalous write has been in the SW always, but I am seeing it only now because it has shifted to this part of memory due to modifications in code.


First, I thought that this might be stack overflow, but from the .map file I see that the stack is located in logical address 0x2000-0x20FF, whereas my array of structs is at 0x279A-0x27FA. Surely, I would see other kind of problems before the stack would overflow so far. And the anomalous write is only happening for one single byte.


Is there a way to observe where the anomalous write is originating from? I have the classic IDE and the PE micro USB Multilink debugger. The MCU is MC9S12XEP100. The ECT is operating with interrupts, so it might be hard for the debugger to follow what is happening.


Best regards,