0
\$\begingroup\$

I am playing with the debug interface on the TI CC2541. It seems to be working fine, seeing correct chip ID etc.

The interface has a DEBUG_INSTR command that lets you submit and execute an instruction to the 8051 core; it then returns the accumulator after execution.

So I decided to try with the simplest opcode 0x24 which is ADD with immediate.

But it is behaving very strangely. The behavior seems to be depending on immediate value.

If I successively execute the instruction "0x24 0x02" (i.e. increment by 2) multiple times I get the expected accumulator values (1 appears be the initial value):

3
5
7
9
.
.

On the other hand, if I use "0x24 0x01" I get strange behavior:

1
4
4
6
6
7

I.e. as if it is only every other instruction execution that works but that this then adds two instead of 1.

With 2 as the immediate things work as expected again:

3
5
7
...

But with 3 I get:

3
7
9
13

I.e. it seems to be adding only two half the time but then 4 the other time (so after an even number of iterations it becomes correct because 6 is added in total)?!

Again 4 works as expected but 5 yields:

5
11
15
21
...

Again every other iteration is one too low and the other one too high, so it balances out. But this only happens for odd immediate operands?!

I am at a loss to explain this:

Seems the least significant bit is somehow treated specially and is added to some internal register/carry flags which then gets added on the next round. But it doesn't seem from the documentation the ADD instruction would behave like this. It's not even the add-with-carry instruction.

Wondering if there's some more fundamental thing wrong in my setup, such as my use interaction with debugger interface that means that the instruction bytes or its result are incorrectly delivered.

But still, the interface doesn't seem completely broken because I can execute commands and get expected results (checking status bits, chip ID etc.) and in this case, it does seem that at least something resembling an ADD instruction gets executed, and for even immediates, everything works correctly.

\$\endgroup\$
  • 1
    \$\begingroup\$ Is it possible that you're reading the result incorrectly? \$\endgroup\$ – immibis Jul 30 at 22:51
  • \$\begingroup\$ Yes you are right. Trouble was what was returned was effectively always OR'ed with 1. Turns out the accumulator started internally at zero. When adding 1 at a time I would get: 1,3,3,5,5. Adding even numbers seemed to work but where actually offset by 1 (3,5,7,... instead of 2,4,6,...) due to the OR'ing-by- one issue. \$\endgroup\$ – Morty Aug 4 at 11:44
0
\$\begingroup\$

Trouble was what was returned was effectively always OR'ed with 1. Turns out the accumulator started internally at zero. When adding 1 at a time I would get: 1,3,3,5,5. Adding even numbers seemed to work but where actually offset by 1 (3,5,7,... instead of 2,4,6,...) due to the OR'ing-by- one issue.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.