TMS570LC4357: nERROR pin reset behaviour

Hello Gael,

I apologize for this one slipping through the cracks. We will need to continue discussion under this post as I am unable to unlock the other threads since they were locked by the system.

As a matter of ease of access and context, I am copying the original post content here:

"Hello,

We observed an unepected behavior of the ESM nERROR pin upon Warm Reset.

Initial conditions are illustrated on top of attached figures.

Code executing on target is generating an NMPU - DMA Port A MPU Error EMS1.69 by generating an incorerct DMA request on purpose. ESM1.69 is triggered as expected,  nERROR pin and low level interrupt handler activated accordingly to ESMIEPCR7 and ESMILSR7 registers configuration. We leave some time to the handler to log some engineering data and clear the ESMSR7 register.

From this state, as described in attached diagram:  

5141.nERROR.pdf

(a) requesting a reset of the nError pin is immediately successfull as LTCR reached zero.

but after a warm reset (b)

(c) requesting a reset of the nError pin as no effect

(d) forcing the nerror is succesfull (while we would expect the request to be rejected as the nerror pin is already active, as per TRM §16.2.3-1 'The ESM module cannot be switched into the error forcing mode if a failure has already been detected in functional mode. The application command to switch to error forcing mode is ignored'

(e) From this accepted enforced mode, requesting a switch back to normal mode is actually clearing the nError pin, despite no actual reset request was sent; so original error context is lost.

(f) From the accepted enforced mode, requesting a reset of the nerror pin is accepted but state remains in reset request mode in ESMEKR while an automatic switch back to normal mode is expected as per TRM §16.2 "(Once the ERROR pin outputs low, a power on reset or a write of 0x5 to ESMEKR is required to release the ESM error pin back to normal state)", andnormal mode is only reached if actually requested by CPU by writing 0x0 in ESMEKR.

Can you please help understand why (c) is not sufficient to reset the nError pin after the warm reset ?

Can you please clarify the discrepencies vs what we understand from the TRM for transition (d), (e) and (f).

Problem is fully deterministic."

In order to dig deeper into this I will need to recreate the scenarios in a test case on my bench. If you have already a simple project that demonstrates the above behavior that you could provide, it could help in getting to an explanation more quickly.

Hi Chuck,

Thank you. Unfortunately, I can't provide you with sample project since my experiments were only performed via registers modifications directly through the debugger (WinIdea). I noticed exactly the same behaviour as documented by Franck Wartel in its original post.

I hop you could bring light on this!

Best regards,

Gael

Hi Chuck,
Any news on this topic?
Thanks,
Gael

Hi Gael
This is an old post - I see that we were not able to provide further guidance on this. Is this issue still open for you?
regards
Mukul

Hi,

Yes this is an old post and yes this is still an issue for me. I need you to confirm the problem and update the documentation in the next release of the TRM.

Thank you

Gael

Hello Gael,

When nERROR occurs, and the device gets system reset before the nERROR is cleared, writing 0x5 to ESMEKR after reset is not able to clear the nERROR.

If there is a system reset, the ESM state machine is also reset. It lost the fact that an error event had just happened. So if you now try to reset the nERROR pin by writing 0x5 it will not work. The way to clear the nERROR pin is either through a power on reset or by putting the nERROR pin in diagnostic mode by writing 0xA to the ESMEKR register followed by any non 0xA values to reset the nERROR pin.

We have added this to the latest errata.

Hello QJ,

Thank you for the information. I think this errata can explain the problem identified as "c)" in the original post.
Have you investigated the other issues described in the original post?
Thanks
Gael