- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Tool/software:
Consider a function like the following in debug
where a counter is incremented over a set of enums. The assembly code is more or less what you can expect, after the call the variable is incremented and tested.
(I took screenshots with CCS 20.0.2, but the issue is the same with CCS 12.8.1, in a different and more realistic project)
In fact, after the first run, I find
and that's fine (my enum started at 0, next is 1).
When the loop wraps up I get the surprise
1. variable in memory is 1
2. a MOV has loaded it in AL
3. however, AL is 0 - and this is confirmed running the code
If I continue running the loop it never evaluates to something different, and the called function sees its parameter always at zero.
Note that a few collateral things are making it happen, and it's been a bit hard to replicate it in a short example (I had to add some weird code).
The lines in the example marked with comments //** are the triggers: if you remove/change them, the results are different. As an example, moving line 148 after line 156, the problem disappears, and all runs as expected.
I didn't check it on a different site (PC, programmer, board, etc.). Then I'd like to know if someone can replicate it first, or if it's just something unusual happening to me.
I tried to describe the issue quickly, but clearly, I failed to describe it at all.
The following is the same code above, in the compiler listing, which still retains all the name references that are lost in the disassembly view of the debugger:
This excerpt is around the loop in the function main_core_tests(), around the call to STA_CoreTest() - the latter isn't directly involved in the issue, it just receives a wrong parameter, as I describe below.
Note: The fact that test_item is static isn't needed by the code, is just functional for bug exploitation (could be global, with the same effect). Much of the code is there for things to happen as described here.
a. The variable test_item is set to 0 before entering the loop (in the lines above this screenshot). The fetch at offset +0x1c loads 0 in AL, and so it is passed on to STA_CoreTest as a parameter
b. Then it is incremented on each run at offset +0x23
c. At offset +0x26 the loop returns to label $C$L1. On the first run, the value of test_item in memory is correctly 1
d. When loading again AL at offset +0x1c I would expect it to be 1, but to my surprise, it still yields 0, and so it does for every repetition in the loop
I don't know whether there's a pipeline contention with instruction at offset +0x1b, which uses ACC.
The lines from +0x14 to +0x1b are produced from C source by macro DEBUG_MARK2_TOGGLE(): if I move/remove that line, the problem disappears.
Let me insist on this: I wouldn't believe this claim myself, if I didn't see it happening all the time, with the debugger running on two different projects.
Here's why I asked for someone else to test the code (the whole test project is attached to the original message).
