Debugging an anomalous RAM write on S12(X)

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Debugging an anomalous RAM write on S12(X)

ソリューションへジャンプ
833件の閲覧回数
utwig
Contributor III

Hi,

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,

Timo

ラベル(1)
タグ(2)
1 解決策
705件の閲覧回数
utwig
Contributor III

Yes, I have used #pragma align.

I found out the source of the bug, and it was totally unrelated to the structure with the buggy byte. My code was trying to access another array that was allocated into a higher memory address than the structs with the bug. However, there was a subtraction operation inside index field of the array (e.g. array[0x01 - 0xA0]), causing the code to actually write to a lower address than allocated for it during compiling.

Too bad that the C compiler does not catch bugs like this...

元の投稿で解決策を見る

3 返答(返信)
705件の閲覧回数
utwig
Contributor III

Update: I monitored the memory area containing the affected structure with the debugger periodical (100 ms interval) monitoring mode. By just watching the values in real time, it looks that the anomalous byte is updated to match the index variable value simultaneously as the index variable is updated from 0->1->2->...->7.

So it looks like the index variable is somehow copied to a seemingly random location inside the measurement data struct. Both the index variable and the struct are defined 'volatile'. And the struct typedef defines the each member of the struct as 'volatile'.

In the .map file I can see that the index variable and the measurement data struct array are correctly allocated on their own memory areas.

Is it possible that the compiler optimizer is misbehaving and copying the index variable over the struct data, even though I have 'volatile' keywords in place?

PS. I also monitored the stack memory area with debugger. Only a small portion of it gets filled during the pulse measurement operation.

0 件の賞賛
705件の閲覧回数
danielmartynek
NXP TechSupport
NXP TechSupport

Hi,

How did you declare the structures?

Have you aligned the structures and variables?

#pragma align on
struct {
 char ch; /* offset: 0 */
 int i; /* offset: 2 */
} s_aligned;

#pragma align off
struct {
 char ch; /* offset: 0 */
 int i; /* offset: 1 */
} s;

Regards,

Daniel

0 件の賞賛
706件の閲覧回数
utwig
Contributor III

Yes, I have used #pragma align.

I found out the source of the bug, and it was totally unrelated to the structure with the buggy byte. My code was trying to access another array that was allocated into a higher memory address than the structs with the bug. However, there was a subtraction operation inside index field of the array (e.g. array[0x01 - 0xA0]), causing the code to actually write to a lower address than allocated for it during compiling.

Too bad that the C compiler does not catch bugs like this...