• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 33 subscribers
  • Views 736 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.

Unable to connect to TMS5701225BZWTQQ1 with JTAG to halt faulty init code

Dan Wieland
Intellectual 2625 points


We have a situation where two initialization routines were swapped around in sequence, written to flash, and did not realize that the one that was originally running second required some hardware initialization which was running in the routine which was first. Having swapped them this initialization was now not happening when needed. I have swapped them back but I cannot get into the system to downloaded the fixed version. The software resides in flash and hence restarts whenever the processor is powered up or reset. I need a way to clear out the flash so there is no program in there to run and hence I should be able to get in to download one. I can connect to the DAP port but CCS (I have version 6.1.0.00104) will not allow me to look at the flash memory via the DAP port.

Is it possible to use a GEL script (or something else?) to get into the system and clear the flash ? Failing that, is there a hardware method of clearing the flash electrically ?

 

Is it possible to tell the system to run the program in RAM rather than flash so it will not run the one in flash and hence allow me to manually clear flash since the probe should then connect ?

I am using an XDS200 emulator.

Thanks in advance for your help.

Dan

  • 0
    TI__Guru 72500 points
    If you can connect with the DAP, there is one thing you can try to regain control of the part. (But it is tricky)
    1. Connect to the DAP as you did earlier, and leave the DAP connection highlighted in the Debug window.
    2. In a memory window enter the address 0x08000000 (start of RAM). The debugger will display the memory by reading it through the DAP without using the CPU.
    3. Change the value at that location to 0xEAFFFFFE (branch to self instruction)
    4. Change the memory window to address 0xFFFFFFC4. You should see 0x0000000A at this location. Change it to 0x00000005. This tells the bus matrix to switch Flash and RAM.
    5. Now write a 1 to location 0xFFFFFFCC. This causes a CPU reset.
    6. Now try to connect to the CPU in the Debug window.
  • 0 in reply to Bob Crosby
    Prodigy 100 points

    Bob,

    Thanks for the suggestion. Unfortunately, whilst I can connect to the DAP without error (the error occurs when I try to connect to the CortexR4) I cannot read any memory. It is just full of '?'s the same as if the CortexR4 is selected in the debug window.

  • 0 in reply to Andy Reeves
    TI__Guru 72500 points
    It sounds like something in the init code is causing the CPU to hang the APB bus. I suppose you have already tried holding nRST and releasing it while trying to connect. The goal is for the debugger to stop the CPU before it executes whatever instruction causes the bus to stall. Are you able to disconnect the flash supply Vccp (ball F8)? If you disconnect the flash supply and then assert nRST (not nPORRST as that will lock the AJSM), then the CPU will not be able to execute code from the flash. You might be able to connect then, and then reconnect Vccp after the CPU is halted.

    If you solve this, I sure would like to know what in the init code caused this problem.
  • 0 in reply to Bob Crosby
    Prodigy 100 points
    Oops, how embarrassing. It turns out that I only thought I was controlling the RSTn line. One of our experts set me straight and we have now successfully turned our two bricks back into working cards.

    Thank for your help with this issue.