TMS470 reset pin outputs 7kHz pulse

Hello Karl,

"There is a feature in the device which will trigger a CPU reset if the processor remains locked up for more than a set threshold (believe this is 256 CPU clocks).  "

Can you please tell me which document number I should read for this feature to understand?

Thank you.
Regards
Pashan

Hi Pashan,

Please reference SPNU495C, Chapter 13 (TRM for TMS470M products).  This module is unique to the Cortex M3 based products in the TMS470M family.  Can you confirm this is the TMS470 based product in question?

Best Regards,

Karl

Hello Karl,

Thank you for the infiormation. I am using TMS570LS0432 device. I thought this feature is present in Cortex-R4 also.

Looks like LRM is only for Cortex-M3 module.

Regards
Pashan

Hi Pashan,

You are probably confusing it with the Cortex R4's "LIVELOCK" signal.  An M3's LOCKUP signal is far more likely to occur (especially due to issues in software) but also has the possibility for recovery via software - thus the different approach on the M3 which gives software a chance to recover online without reset.

Regards,

Karl

Hi Karl,

I tried that but I get a time out error when I try to load a program into FLASH. It never gets to the erase step. I can stop the processor in the debugger and the lock up reset stops but as soon as I start the processor again it goes back into the lock up reset loop. Is there another way to get the processor out of lock up?

Pat F.

Hi Pat,

If you refer back to the ARM documentation, there are limited options.  Per ARM DUI0522A, "Cortex-M3 Devices Generic User Guide" Section 2.4.4:

"The processor remains in lockup state until either:

• it is reset
• an NMI occurs
• it is halted by a debugger."

The problem which usually occurs is that the lockup is due to the programmed code in the flash, so simply resetting will help only until the code which initiated the lockup is again executed.  In my experience the only effective mechanism is to halt via debugger, swap flash/SRAM chip selects, and load via debugger a dummy valid program into SRAM, and reset via debugger.  This should put the device in a stable state, which then allows a flashing tool to connect and reflash the device.

Regards,

Karl

Hi Karl,

Thanks for your reply. I tried resetting the processor and swapping the chip selects and loading a dummy program but as soon as the debugger tries to access and program the flash the processor goes into lockup reset mode. Maybe I'm not doing the swap correctly.  The debugger does halt the processor but as soon as you try to do anything else it goes back to lockup. There are two scripts in CCS available. one is for memory map setup and the other is for memory switch. I've tried all combinations of set up and switch with now success. Have you seen this before?

Thanks again for your help,

Pat.

Hi Pat,

Sorry for the delayed response, am travelling internationally.  I'm not familiar with the current tool offerings so I'm going to forward your issue to another of our engineers who is using CCS regularly.

Best Regards,

Karl

Hi Pat,

To clear your situation, I would try the following:

- Enter Debug halt to stop the CPU and LRM countdown

- Place a breakpoint at the reset vector (i.e., begining of _c_init)

- Using CCS, initiate a CPU/soft reset (note that a system reset should not be used since it will clear the break point).

After the reset, code execution should halt at the beginning of the reset vector, preventing whatever software caused the Hard Fault from being executed. At this point, you should be able to manually erase the device through CCS and get back to square one.

The key is to clear the Hard Fault signal from the CPU via the reset before trying to reprogram. As long as the Hard Fault is set the LRM will continue to count down and reset the device.

Before trying to reprogram the device and after the CPU reset, it might be prudent to try and narrow down what is generating the hard fault so this can be repaired prior to reprogramming the device.