• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 1826 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.

XDS220 ISO can't step thumb code

Robert Chen
Mastermind 9135 points

Other Parts Discussed in Thread: 66AK2H14

Recently I bought a SpectrumDigital XDS220 ISO debugger. It works fine with 32-BIS (ARM) code on DM368. But today, I try to add a 16-BIS (THUMB) function, it can't jump into the 16-BIS function. From the disassembly window, it will crash while stepping the BLX instruction.

I have also tried to set a breakpoint inside the 16-BIS function and free-run from a 32-BIS function. Again, it crashed when trying to stopped at the breakpoint.

Then, I try to do the same test with XDS100v3. Everything works well, though XDS100v3 is super slow on debugging DM368.

Please note that all I/D caches are disabled in the above test. And I am using CCS 6.1.3 on Windows 10.

Please also note that the first time I encountered this issue is when I to enable "16 bits code-state" of my project. Then the debugger can't run the main(). Then, I disabled "Auto-run to main" and step-by-step from boot.asm. I found the issue happened when stepping the following "BX R0" instruction:

ADD R0, PC, #1

BX R0

The above assembly code is used to change to THUMB mode. This is why I think it is related to THUMB mode. After that, I did the tests as described above.

It is almost confirmed that this is a bug of XDS200. I believe it can be fixed by updating driver or firmware of XDS220. Do anyone know how to fix it?

  • 0
    Guru 92251 points

    Robert Chen said:
    It is almost confirmed that this is a bug of XDS200. I believe it can be fixed by updating driver or firmware of XDS220.

    Which firmware version is in the XDS220 ISO?

    I don't the same hardware as you, but with CCS 6.1.3 a XDS2xx USB Onboard Debug Probe with firmware v1.0.0.8 and a Cortex-A15 in a 66AK2H14 I can't repeat the problem in that can successfully debug programs compiled for THUMB mode. When I disabled the "Auto-run to main" and single stepped the boot.asm confirmed that the processor changed from ARM to THUMB mode.

    Robert Chen said:
    I found the issue happened when stepping the following "BX R0" instruction:

    ADD R0, PC, #1

    BX R0

    The above assembly code is used to change to THUMB mode.

    When you step the above assembly code, can you watch the value of the CPSR Register (under Core Registers in the CCS Register view). The T bit in the CPSR Register should be set when the processor is changed from ARM to THUMB mode.

    Maybe the XDS220 ISO is somehow corrupting the CPSR register (since I have seen some debug probes modify the CPSR register when single stepping such as to disable interrupts). Also, it might be useful to capture CCS Debug Server Logging when stepping and post the log.

  • 0 in reply to Chester Gillon
    Mastermind 9135 points

    Hi Ghester,

    Thanks for your help.

    1. I have confirmed the firmware version is v1.0.0.8 by using xds2xx_conf utility.

    2. After stepping "BX R0", the T bit is set but PC jumps to an invalid address. The correct address should be something like 0x8000xxxx, but it jumps to 0x000073f4 (not fixed address, but around 0x73fx). Sure, only garbage data at 0x73fx, so it will cause data/program abort exception if I continue to run.

    3. The Debug Server Log is attached. To reduce the file size, I enable the log at "ADD R0,PC,#1" and disable it after jumping to 0x73f4.

    ccs_debug_server.log

  • 0 in reply to Robert Chen
    Guru 92251 points

    Robert Chen said:
    3. The Debug Server Log is attached.

    I had a look at the log file, but haven't been able to determine the cause.

    The last valid PC, before stepping the "BR R0" is 0x80003D6C:

    0x00001770 544846 3 ARM9 GTI R: GTI_READREG( 0x5481EEA8, 0x0000000F, *0x501EE700 = 0x80003D6C ) = 0x00000000

    At which point the CPSR has a value of 0x400000D0 meaning the T bit is clear and the processor is in ARM mode:

    0x00001770 544831 3 ARM9 GTI R: GTI_READREG( 0x5481EEA8, 0x00000010, *0x501EDA40 = 0x400000D0 ) = 0x00000000

    After stepping the "BR R0" the CPSR has a value of 0x400000F0 meaning the T bis is set and processor is in THUMB mode:

    0x00001770 545737 3 ARM9 GTI R: GTI_READREG( 0x5481EEA8, 0x00000010, *0x501EDA90 = 0x400000F0 ) = 0x00000000

    And the PC is now a corrupt value of 0x00007AF2:

    0x00001770 545768 3 ARM9 GTI R: GTI_READREG( 0x5481EEA8, 0x0000000F, *0x501EE700 = 0x00007AF2 ) = 0x00000000

    I can't tell from the log file, but what is the value of the R0 register before and after stepping "BR R0"?

    [I also performed a test with an ARM9 in a DM355, and successfully stepped the code in THUMB mode using either a XDS100v2 or Blackhawk USB560-M]

  • 0 in reply to Chester Gillon
    Mastermind 9135 points
    Hi Chester,

    R0 is 0x80003C79 before stepping and 0x78F3 after stepping. This time, it jumps to 0x7902.

    Thanks for your time to look into this issue. Due to the sale conditions provided by SpectrumDigital reseller, I have to rebate the XDS220 ISO in 7 days if it has problem. Otherwise, I can't get my money back. So, I won't be able to do more experiments after today.

    According to your test, XDS200 seems working well. So, I will buy a XDS200 to test. As I know, XDS200 and XDS220 ISO use different firmware. So, there should be good news for me to use XDS200.

    Thanks a lot for your help!
  • 0 in reply to Robert Chen
    Guru 92251 points

    Robert Chen said:
    R0 is 0x80003C79 before stepping and 0x78F3 after stepping. This time, it jumps to 0x7902.

    OK, that shows the XDS220 appears to be corrupting register R0 when changing from ARM to THUMB mode which causes the PC to change to an invalid value.

    Robert Chen said:
    According to your test, XDS200 seems working well.

    Yes, my only reservation is that I tested a XDS200 with a Cortex-A15 rather than an ARM9. It would be useful if someone from TI could repeat the test with a XDS200 and XDS220 ISO and an ARM9 to confirm which combination have the problem.