• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 403 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.

RM57L843: Error loading code on target

Susie Gibson
Prodigy 30 points
Part Number: RM57L843

I am unable to load code onto an RM57L843BZWTT processor on our custom PCB. I am using an XDS100v2 debug probe. When I attempt to start a debug session in CCS, I receive the following errors:

CortexR5: Can’t Run Target CPU: (Error -2063 @ 0x0) Unable to reset device. Power-cycle the board. If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.1.0.00007)

CortexR5: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.1.0.00007)

CortexR5: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.1.0.00007)

I have both the RM57Lx development kit and the RM57Lx launchpad and am able to load code onto those without any issue. I am also able to load code onto the RM57Lx development kit board using our XDS100v2 debug probe plugged into the EXTJTAG port.

In the following thread it mentions that normally this kind of error is due to code loaded on the processor that basically bricks it, but I have never been able to program the processor on our PCB:

https://e2e.ti.com/support/microcontrollers/hercules/f/312/p/465986/1675676#1675676

I have tried lowering TCLK, but that did not work.

We have used a logic analyzer to compare all JTAG lines on the development kit board to those on our custom board and they look the same. The oscillator, power & reset lines all look good as well.

The “Test Connection” test (under the RM57L8xx.ccxml tab) passes.

I’m not sure where to go from here. Any advice would be much appreciated.

Thank you for your help.

Susie

  • 0
    TI__Guru**** 196276 points

    Hi Susie,

    How long are the traces of JTAG signals? The JTAG connector should be placed within 6 inches (152 mm) or less from the corresponding pins on the Microcontroller. If this is not possible, signal buffers should be added.

    The nTRST (Test Reset) pin has an internal weak pulldown. In a noisy environment, this pin can pick up a strong noise signal, putting the device in JTAG test mode. It is highly recommended to add an external pulldown resistor (1 kΩ to 10 kΩ) to offer adequate protection.

  • 0 in reply to QJ Wang
    Prodigy 30 points

    Hi QJ,

    The JTAG signals from the microcontroller to the XDS100v2 connector are roughly 2.5 inches in length, well under the suggested 6 inch max.

    We do have a 4.7k pulldown on the nTRST pin.

    I appreciate the speedy reply. We will continue to try and hunt down the issue, please let me know if you have any other thoughts.

    Thanks,

    Susie

  • 0 in reply to QJ Wang
    Prodigy 30 points

    QJ,

    I work with Susie and have been helping troubleshoot. 

    I followed this post  (despite it being for a different device) and was able to launch the target configuration without a project. From there I'm able to connect to the Icepick and DAP cores successfully and browse the memory table. From there I can connect to the processor but when I go to load a .OUT file I get the same error: "CortexR5: Error: (Error -1170 @ 0x0) Unable to access the DAP." 

    In the post, it's suggested that it could be a power related issue. So i probed the 1.2VCC rail to see what was happening when I went to load code. I found that as soon as the code tries to load and CCS throws the -1170 error, the VCC rail rises from 1.2V to 1.4V and when I disconnect the 1.2V supply, it jumps to 3.3V.

    After some more troubleshooting I found that the 1.2V rail only becomes shorted to the 3.3V rail when I try to load code via CCS. When the device is powered off or the device is powered on but not not loading code, the 1.2V rail is solid and isolated from the 3.3V rail. Not sure whats going on here with the processor. Any ideas?

    Thanks,

    Mitch

  • 0 in reply to Mitch Costa
    TI__Guru**** 196276 points

    Hello Mitch,

    What is the maximum output current of the 1.2V regulator? Are you using a stable power source? The supply voltage for the flash has to be present and stable during programming. 

    3.3V on core power supply will damage the device. The maximum core power supply is 1.43V.

    Did you see this issue on only one board? 

  • 0 in reply to QJ Wang
    Prodigy 30 points

    My first thought was that the 1.2V LDO we are using on the board may be the suspect so I removed it and have been powering the 1.2VCC from a bench top supply. I still see the same issue. We are seeing this on multiple boards. I've double checked our schematic and confirmed we did not mix up the supply to any power pins on the processor, we're supplying the clocks with the correct voltage, and our voltage supervisor circuits are correct.

  • 0 in reply to Mitch Costa
    TI__Mastermind 49120 points

    Please check the JTAG header design. Also ensure that the JTAG emulator is being plugged in correctly, as some of the JTAG header definitions do not include a "key" location.

    How is nTRST from the JTAG header connected to the MCU? Does this signal connect anywhere else on the board?

  • 0 in reply to Sunil Oak
    Prodigy 30 points

    Sunil and QJ,

    We figured out the issue. The culprit is a faulty bench power supply that was not providing a consistent 3.3V to the board. Voltage was occasionally spiking above 4.6V. We must have shorted something within the processor. I appreciate your help!

    -Mitch