• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 944 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: disabled LPO with active clock monitoring

Dmitry Tuykov
Expert 1196 points
Other Parts Discussed in Thread: TMS570LS0432

Hello,

I have an issue with the board which is based on TMS570LS0432 MCU. Hope somebody could help me with it.

Several days ago I accidently loaded SW to MCU which disables LPO (HF + LF) during startup. At the same time code which disables clock monitoring functionality was not available.

As result I'm not able to start debug session anymore. The following error message appears during each try:

CortexR4: Error connecting to the target: (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 7.0.100.0)

I have tried to "reanimate" the board with different approaches which have been defined at the forum, such as:

1. "Playing" with nPORST during start of the debug session

2. Trying to connect IcePick and DAP separately and swap Flash and RAM

1st approach was unsuccessfully after 2 hours with playing with it.

Also sometimes this approach leads to the following error:

CortexR4: Error connecting to the target: (Error -6305) PRSC module failed to write to a router register. (Emulation package 7.0.100.0)

Typically debug session restart helps.

2nd approach doesn't work at all, I can connect to IcePick, I can connect to DAP, but I'm not able to see neither Flashh nor RAM, only '?' marks.

Also I tried to check nRST with scope, it is permanently "HIGH".

Does anybody know some additional hint which can help me? Resoldering of the MCU is the last one what I would like to hear :(

Thanks in advance for any help!

  • 0
    TI__Guru 59540 points
    Hello Dmitri,

    If you are unable to connect via the using the traditional random nPORRST assertions during the connect sequence, the only other option would be to try lifting the VCCP pin so that the CPU is unable to read the flash; and, therefore, is unable to execute from flash. Once connected via the debugger, reconnect the pin to the 3.3V supply (using a jumper or wire and clip) to provide power to the flash pump. At this point, you should be able to erase and reprogram the flash. We have used this method and been mostly successful with it; however, there have been cases where it did not work. Also once you reprogram the device to eliminate the issue, you can carefully re-connect the pin to he board. This operation needs to be done with a lot of caution because if you over extend the pin or bend it in the wrong way loosening or re-attaching it, it could break off. If it breaks off, only a very skilled bench tech can reattach the pin if there is anything left to attach to.

    Note, since all other methods have failed, this might be the only option left. If this does not work, you may have to replace the device.
  • 0 in reply to Chuck Davenport
    Expert 1196 points
    Hello Chuck,

    thanks a lot for your fast response.
    Your proposal sounds quite complicated but probably it is the only way to fix the issue.

    By the way, I also would like to try connect OSCIN and OSCOUT to start from LPO and increase a bit my chance to catch device by debugger.
    What do you think, could it be helpful or not?

    And do you know what can be a reason that I'm not able to view/modify memory via Icepick and DAP connection (Flash-RAM swap approach to unlock MCU)?
  • 0 in reply to Dmitry Tuykov
    TI__Guru**** 193116 points
    Hi Dmitry,

    should be random nRST assertions rather nPORRST assertions.
  • 0 in reply to QJ Wang
    Expert 1196 points
    Hi QJ,

    hmm...I was sure that nPORRST is required one. Tomorrow I will try to toggle nRST.
    On our board this pin is not connected to any level. As I understand this pin is internally pulled up, isn't it?
  • 0 in reply to Dmitry Tuykov
    Expert 1196 points

    Hi,

    at last I was able to unlock device yesterday.

    @QJ : Thank you for the correction, it was really necessary to "play" with nRST pin, not nPORRST

    @Chuck: Thanks for the hint with pump power supply. Hope it will not be necessary to use such a solution, but better to know it, just in case :)

    Topic can be closed.