TMS470M system reset issue

Hi Stefano,

The ARM SYSRESETREQ is not supported on TMS470M products.  You can reset the device via software by using the software reset in the System module (SYSECR register) or while under debug by using the ICEPICK advanced system reset feature in CCS.

Regards,

Karl

Hello Karl,

thank for your answer.

I want to put the micorcontroller in a state which allows the downloading of a microkernel in RAM.  With your information I changed the above procedure as follows:

1. setting of C_DEBUGEN, C_HALT  and C_MASKINTS in the Debug Halting Control and Status Register

2. waiting for the S_HALT bit to be set

3. enter debug state on reset, setting VC_CORERESET in the Debug Exception and Monitor Control Register

4. set RESET in SYSECR 

5. waiting for the S_HALT bit to be set

6. disable the vector catching writing 0 to DEMCR register

Is this procedure correct?

Just another question: after having set the the SYSECR to 0xC000, a global system reset will occur, according to the reference manual. Is this reset state permanent, and if so how can I release that state?

Thank your for your kind support

Br

Stefano

Hi Stefano,

I believe that the sequence you are suggesting would be workable, but I have never tried such.

The reset from SYSECR is the device warm reset, which has the same effect as pulsing the nRST pin at device level.  All logic should be reset excluding debug logic and a few elements in the SYSTEM and ESM blocks.  These blocks are reset only by nPORRST (power-on/cold reset).

Best Regards,

Karl

Hi Karl,

I'm still facing an issue with the reset and the debug state of this microcontroller.

After setting the reset_1 bit in the sysecr register,  I check that a transition of the S_RESET_ST bit in the DHCSR of 0-1-0 has taken place, so I'm confident that the reset was ok.

After this operation the value of SYSECR  is 0x00004000 and the value of DHCSR is 0x3000B, that is the S_RESET_ST bit is 0. I'm still in halt mode.

I download my ukernel.

Then  to exit from the halt mode I set the C_MASKINTS and C_DEBUGEN bits in the DHCSR, in order to run the ukernel code.

But when I read the DHCSR register I obtain the value 0x02010009, that is the S_RESET_ST bit is set.

So it seems that the micro is held in reset still. The external RST line is in high state.

What I expected was a value of 1010009. 

Any idea about this strange behaviour?

Thanks in advance for your prompt reply.

Br

Stefano

Hi Stefano,

We're in a bit of unfamiliar territory so it may take some time to find a solution.

I'm afraid I don't have a lot of experience in debugging issues using the DHCSR register.  Instead I'll focus on the system module and device level reset behavior - hopefully this will help.

When the SYSECR is used to create a software reset, it generates a reset pulse (not level).  Externally if monitoring the nRST pin you should see it transition from high --> low--> high as the reset pulse propagates thorough the internal logic.  If you read the SYSESR register, it should note the state of the last reset as well.

We may also want to consider performing only a CPU reset instead of a system reset - please reference the MPMENA bit in the MMUGCR register of the system module. 

Regards,

Karl

Hi Karl, thanks for you answer.

During my debugging sessions, going more in deep, I found a strange behaviour of the RST pin.

In my previous mail I said incorrectly that the RST pin was high. This is not true, because I saw that it stays high for about 110 us then goes to zero for about 1.5 us then returns high, determining a square wave form.

It seem that the micro resets periodically. The micro flash memory is completely blank. The reset starts this behaviour when the micro is powered. Then, when in halt condition, the RST line stays completely high.

After releasing the microcontroller from the halt condition the reset line starts again to have this square behaviour.

Analyzing the system registers, I found that  the SYSESR register indicates that there has been a power on reset, a SW reset, and the WDRST bit is set.

I thougth that the behaviour of the reset pin could depend from the digital watchdog, but reading the RTIDWDCTRL I found that the value was 0x5312ACED, so the counter is disabled.

I noticed insted that using the XDS100V2 JTAG emulator and NowFlash at the power up the reset line has the same square trend, but during the flash operation the dubugger is able to mantain the reset line high.

Is there something else inside the microcontroller that could determin this behaviour of the reset line?Is there something to shut down in order to avoid this square trend of the reset line?

Thanks in advance for your prompt reply.

Br

Stefano

Hello Stefano,

I believe what you are seeing is that the device is going into a LOCKUP state due to repeated HARD FAULT conditions.  The 470M has a block on board known as LRM (lockup recovery module) which kicks off a timeout counter whenever the part enters lockup.  If SW is unable to resolve the lockup state when the counter times out, the device will kick a reset internally (warm system reset).  Please see P. 716 of the device TRM for more details.

Regards,

Karl

Hi Karl,

as stated by you, the behaviour of my board seems to be consitent with the explanation of this lock up state and the relative reset condition.

This lock up condition stops when I enter the debug state, according to the ARM v7-M Architecture Reference Manual, but when I restart the core it still remains. 

Could be something wrong with my ukernel, at entry point?

Could be this problem related to the Vector table allocation? In my ukerne I put it at the beginnig of the RAM.

Is it necessary at entry point a recovery routine to exit this lock up state also in running mode?

Any  other idea about the way to stop this repeating reset?

Thanks.

Br

Stefano

Hi Stefano,

To get out of LOCKUP, you need to clear the issue which is causing you to enter the faulted state.  Try putting a hardware breakpoint on your Hard Fault and NMI handlers and then inspect the stack/registers to see if you can trace the point of entry.

Most of the LOCKUP issues I have debugged were due to a bad vector table.  You need to ensure that you have at least populated the first four entries of the table before resetting the CPU.  In addition, you must remember that the low bit of each vector table entry needs to be "1" to indicate entry to a Thumb routine - this has caught me more than once.

Regards,

Karl