• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 334 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C55 simulator parallelism problems

Reine Johansson
Prodigy 130 points
Other Parts Discussed in Thread: CCSTUDIO

First some info about my setup:

C55xx Rev2.x CPU Cycle Accurate Simulator
C:\CCSTUDIO_V3.3/drivers/tisimc55x.dvr
CCS 3.3.81.11
Integrated Development 5.98.0.393
CGT v4.3.6

I have a problem with the following instruction(s) using the simulator:

AR1 = #0x0 || bit (ST1, #0x6) = #1

The contents of AR1 (and memory location 0x11 - which you know is the MMR for AR1) is always #0x6 after this operation, no matter what number I'm trying to move to AR1. If I remove the parallel manipulation of ST1, the problem dissappears and AR1 is loaded with the correct value.

If I run this code on the actual C55x CPU, AR1 is modified as expected. I've tried to find any documentation about known limitations or bugs in the simulator, but havn't found any mentions about this behaviour. Suggestions?

  • 0
    Prodigy 130 points

    Doesn't anyone have any idea what's causing this behaviour? It's starting to get really annoying, and makes the simulator kind of useless. Here are some more information about the problem:

     

    AR1 = #0x22 || T2 = T2 + #0xB

     

    When running the instruction(s)  above in the simulator, AR1 contains #0xB after execution. It seems like the first instruction (MOV) takes it operand from the second instruction (ADD). The second instruction does exactly what it should.

    Like I said in my first post, the parallel instructions works as expected when it's being executed on the c55x chip itself. This problem is only present on the simulator.

  • 0 in reply to Reine Johansson
    Prodigy 130 points

    I've found the problem! The code had been compiled using the -vcpu:3.3 option, and I was running it on a Rev2.x simulator. When I changed to the v3.0 simulator, everything started to work as expected.