• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 301 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.

RM48L952/952 suddenly hangs

Michael Enggaard Pedersen
Intellectual 295 points
Other Parts Discussed in Thread: RM48L950

Hello,

Please we are in desperate need for a hint!
We have "killed" 3 boards with RM48L950/952 by accident.

Two of them (1 was a Hercules HDK-card), we dont know what has happend, suddenly we cannot make our IAR debugger work with the cards!

Now we have just "killed" a card more, after we have programmed it to run with an external-2 clock of 32kHz.

Now I  have changed the configuration back to run with oscillator of 20MHz, but when I try to download the program in the MCU, the debugger says it cannot get status from the MCU and the debug-session is terminated.

I have tried to get the JTag interface to connect to the MCU and get the MCU ID. This works!!!

My question is: Is it possible to get the MCU in a deadlock where the JTag works but it cannot flash the code into it?

If your answer is yes, my next question is of course, how do I get it out of this?

Best regards

   Michael c".)

  • 0
    TI__Mastermind 22375 points

    Michael,

    If the problem is related to a specific code running out of flash and forcing the device in a weird mode, here is a technique you can try.
    This work-through  assume the usage of CCS as debugger. I’m not sure if this will work with other debugger.
     
    1] When starting the target in CCS, display all cores to see the Icepick, DAP and Cortex R4.
    2] Connect Icepick  and see if connection is ok (It should)
    3] Connect DAP and see if connection is ok. If yes than it is now possible to open a memory window and display the SYSTEM Register.
    4] Perform a reset via the system module. (Write 0x0000_0000 at address 0xFFFFFFE0. This is the System Exception Register) This should reset the whole device without affecting the debug logic.
    5] Connect the Cortex R4. If connection is done, than erase the flash from CCS.
    6] The part is now back to normal state. It is now time to debug what the code is doing…. This is another story.

    As per my knowledge, I never faced a situation where a customer code will "brick" a device.

    I will be interested if you can share your out file to understand what is going on.