• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 30 subscribers
  • Views 482 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.

TMS570LS0432: Cannot FLASH firmware onto TMS5700432BPZQQ1; Error -2131: @0x0

Ryan Campiz
Prodigy 10 points
Part Number: TMS570LS0432
Other Parts Discussed in Thread: UNIFLASH,

Greetings,

We've recently received 5 boards from our assembly house. These boards utilize the TMS5700432BPZQQ1 chip and have the same PCB artwork as prior boards, which have worked just fine in the past. The following are the steps that I executed to sanity-check and then produce the error.

  • I power-on the boards, and then measure the voltage rails that power the chip; they measure in spec (3.3V and 1.2V).
  • I power-off the boards, and then measure the continuity from the MCU leads to the programming header pins; they are continuous.
  • I power-on the boards, and then plug in the programming header, and then bring up the UniFlash application on my laptop.
  • I go through the process of selecting the debugger/programmer as well as the onboard chip.
  • I select the desired FW to program, and then I select "Load" to program the chip; I receive an error: Error -2131 @0x0 — Unable to access device register.

This is the same error for all five (5) boards received. Again, this is the same exact PCB artwork of prior boards that we know to not have this problem.

 

To rule out the programmer being bad, I sought to demonstrate that I could at least program boards that were ordered prior to these 5 "bad boards". The board that I selected was the same exact PCB artwork (same internal part number and revision number; i.e. no difference in the design files). Running through the same exact steps as described prior, I was able to successfully program the board with no issue. I was curious about what the programming signals were supposed to look like, so I scoped the pins and saw the following at the start-up of programming. Obviously there was more activity after start-up, but for comparison sake, I thought this was all that would be necessary to share for reference against for the "bad board", as the "bad board" failed at start-up. Below is a screenshot of the "good board" at the beginning of programming. (Note: CH1: nTRST; CH2: TCK, CH3: TDI, CH4: TDO).

Going back to the "bad board", I did the same as before and scoped some of the programming signals. Jumping ahead to the result, it looks like the TDI line (CH3) was not able to complete what it was trying to do. It also looks like there was absolutely no activity on the TDO line (CH4). Frustrated with this outcome, that I had the Functional Safety version of this chip (RM42L432BPZT) purchased, which has the same package, pin out, and ARM Cortex-R4F architecture — the only difference I could ascertain is the temperature range. I installed the chip as a substitute; same result; I was not able to program it. Below is a screenshot of the "bad board" at the beginning of programming. (Note: CH1: nTRST; CH2: TCK, CH3: TDI, CH4: TDO). 

What's more, for kicks, I decided to see what error would result if I did not have any chip soldered to the board. So I de-soldered the MCU from the board and, lo and behold, it was the same error I was getting for these new boards: Error -2131 — Unable to access the device register.  as an extra sanity check, with the chip removed, I used a multi-meter to check for continuity between the pads on the MCU footprint and the pins on the programming header. There was continuity as expected. I did the same with another board with the leads of the chip and the pins of the programming header: Continuity was there too. I used a multi-meter to verify that all of the pins were receiving power from the respective power rail: they were.

I am out of ideas.

  • What could be going wrong?
  • What should I be looking for onboard as a cause?
  • Are there batches of bad chips on Digi-Key or Mouser? Is that even a likely possibility?
  • Does TI have any samples that they could send us to try in place of these chips? 

Please let me know.

  • 0
    TI__Guru**** 197446 points

    Hi,

    Is there any error when you perform the JTAG connectivity test in CCS:

    Is RM42Lx device used on your prior board (working)? Did you solder the TMS570LS0432 (not working on your new PCB) on to your prior PCB and check if it works or not?

  • 0 in reply to QJ Wang
    TI__Guru**** 197446 points

    I am not sure if the device flash has been erased completely. Any un-working code in the flash may prevents the CPU from entering a debug state.

    Can you please this procedure to let CPU enter a debug state:

    1. Open the target configuration window, and launch the selected the configuration
    2. Switch to debug window
    3. Press the reset (nRST) button on your PCB board and hold it
    4. Click “Connect Target” immediately after you release the nRST button
    5. The board should be connected after couple tries
  • 0 in reply to QJ Wang
    Prodigy 10 points

    I ran the test connection and got the following output:

    [Start: Texas Instruments XDS2xx USB Onboard Debug Probe_0]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

[Result]


-----[Print the board config pathname(s)]------------------------------------

C:\Users\rcampiz\AppData\Local\TEXASI~1\
    CCS\ccs1120\0\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 560/2xx-class product.
This utility will load the program 'xds2xxu.out'.
The library build date was 'Mar 17 2022'.
The library build time was '19:20:23'.
The library package version is '9.7.0.00213'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '13' (0x0000000d).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.

-----[Print the reset-command hardware log-file]-----------------------------

This emulator does not create a reset log-file.

-----[An error has occurred and this utility has aborted]--------------------

This error is generated by TI's USCIF driver or utilities.

The value is '-233' (0xffffff17).
The title is 'SC_ERR_PATH_BROKEN'.

The explanation is:
The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.
An attempt to scan the JTAG scan-path has failed.
The target's JTAG scan-path appears to be broken
with a stuck-at-ones or stuck-at-zero fault.

[End: Texas Instruments XDS2xx USB Onboard Debug Probe_0]

  • 0 in reply to Ryan Campiz
    TI__Guru**** 197446 points

    Hi Ryan,

    Can you solder the "non-working" silicon to the prior PCB and check if it works or not?

  • 0 in reply to QJ Wang
    Prodigy 10 points

    No. The "bad board" can still be salvaged, as it just has a bad CAN XCVR chip. If I dismounted the TMS570LS0432 chip from the "bad board", I run the risk of damaging it, as it is an MSL-3 component and very likely has moisture ingress. What's more, we don't have an oven at this site, so I cannot exercise the option to bake out the moisture.

    I am very puzzled by this, and am beginning to pull off auxiliary components, in the off chance that one of them is bad (because they may have been purchased from resellers) and causing the TMS570LS0432 top behave wonky.

  • 0 in reply to Ryan Campiz
    Prodigy 10 points

    Sorry, my last reply may have been confusing. In that last reply, by "bad board" I meant the older, identical board, which happens to have an unrelated issue with the CAN XCVR (which is why I called it the "bad board"). The Hercules chip still worked on what I called in my last reply the "bad board". I mixed up the "bad board" and "good board" in my last response. Apologies about the confusion. As I said prior, this older board has a bad CAN XCVR chip that we just need to order to replace. I don't want to risk ruining the board altogether because of this experiment.

    Nevertheless, what I said still stands. The I don't want to swap chips because they are MSL-3 rated, and both boards have definitely been in factory environments for more than 168 hours. We do not have an oven at this site to bake out moisture.

    With that said, my experiment of removing the auxiliary chips did not work. Same error. The JTAG IR and DR scan-paths cannot circulate bits, even with all of the auxiliary chips removed.

  • 0 in reply to Ryan Campiz
    TI__Guru**** 197446 points

    Hi Ryan,

    I am sorry for coming back late. Have you solved your JTAG issue? If not, can you show me the circuitry of JTAG signals on your board? I am wondering any short between TDO and other signals or GND

  • +1 in reply to QJ Wang
    Prodigy 10 points

    Yes. Apologies for not getting back you earlier. The issue stemmed from a prior designer not implementing schematic symbols correctly. Essentially, the previous designer copied/pasted resistor symbol and changed only the value of the resistor and not the underlying part number, rather than following the proper steps of creating a new entry in the library for the new resistor.

    This resistor was a pull-up resistor on the reset line (nPORRST) that was too weak (499kΩ instead of the intended 4.99kΩ), so essentially the TMS570LS0432 chip stayed in a reset state, never being pulled up to 3V3 on that pin, which disabled the chip from being programmed.

    I was not happy.