TMS570LC4357: WDT handling - upon watchdog reset

Hi Deric,

Make sure your toggling time is half of the time expiration of DWD.

As you configured preload with 4095 and window size 100% right

I don't know your RTICLK but i am assuming default 75Mhz, in this case your expiration time will become 0.447Sec or 447mSec right.

So, your LED toggling time should be at least less than 200mSec approximately for one ON and OFF states of LED before DWD expiration.

--

Thanks & regards,
Jagadish.

HI Jagadish

Thanks, yes the rticlk is 75Mhz and i have refreshing  interval set about 100msec in the RTI.

When the application start up it will blink for a few seconds.

Here is my snipnet of the code.

while(ctr < 25);
rtiDisableNotification(rtiREG1, rtiNOTIFICATION_COMPARE0);

while(1);

void rtiNotification(rtiBASE_t *rtiREG, uint32 notification)
{
  ctr++;
  gioToggleBit(gioPORTB,XLP_USER_LED3);
  dwdReset(rtiREG1);
}

When the WDT is not refresh, the reset will happen. But the issue is that my application (same application) does not run normally. No more led activities is observed at the start. That is the puzzling part to me.

Hi Deric,

If i understand correctly

After application loading first time everything is fine, that means LED is blinking for few seconds and WDT reset is occurring after the time out. But once the WDT reset occurred then no more LED blinking is happening.

Is it correct?

--

Thanks & regards,
Jagadish.

you are right, this is the behaviour i faced.

Deric Ng said:

you are right, this is the behaviour i faced.

Okay Deric, I will verify and update you.

Thanks, it is working.

HI Jagadish

I have tested on the launchpad XL, it is working as expected. But on the HDK, i am still checking on it. 

If you have the HDK, can you give it a go too. Appreciated that.

That weird, my old HDK board upon WDT reset; the main application does not start to run.

Can u put up the sample example for me to run it. Thanks a lot. 

Hi Deric,

I could see the issue you are mentioning, the LED is blinking only on one iteration in HDK board so i thought it is working but after watchdog reset it is not working in HDK board.

I will analyze further and will provide an update to you.

--

Thanks & regards,
Jagadish.

sure, thanks a lot.

Hi Deric,

On my testing, i found one thing that is,

SYS_ESR register value after watchdog RESET is 0x2000, that means only 13th bit(WDRST) is setting in ESR register.

But in our code, we are verifying this 13th bit(WDRST)  only if the 3rd bit(EXTRST) is SET.

So, as this 3rd bit not SET right, so we will end up in our code at reset source as NO_RESET even though it is due to watchdog RESET

If reset source is NO_RESET, then we won't do any initializations in our code and we will directly go to the below line

So, we are not performing any initializations right so it will lead to the exception.

Now what i did is, i just added one condition at before "NO_RESET"

Here also i am verifying whether 13th bit SET or not if 13th bit got SET then i am considering it as "WATCHDOG_RESET". So after adding this condition my code worked perfectly.

I am attaching my code for your reference.

DWWD_Example_LC4357_HDK.zip

--

Thanks & regards,
Jagadish.

Hi Jagadish.

Thanks, appreciate that your help. I have tested that adding the code above. The application restart as normal when WDT reset.

Let me try to investigate on launchpad board.

It seems that the behaviour of EXTRST (BIT3) is somehow different for Launchpad and HDK. Do u have have any clue on it?

Thanks,

Hi Deric,

Deric Ng said:

It seems that the behaviour of EXTRST (BIT3) is somehow different for Launchpad and HDK. Do u have have any clue on it?

There should not be any difference in behavior if the board changed.

Can you verify the complete controllers part numbers on the both the boards i.e. launchpad and HDK, if they are different controllers then might be a chance of difference in behavior.

--

Thanks & regards,
Jagadish.

HDK - TMS570 4357bZWTQQI-YFB-66AR5IW

Launchpad  -TMS570 4357bZWTQQI-YFB-93ACZ7W

Hi Deric,

And what is the exact difference you are noticing on these two controllers with respect to the Watchdog?

--

Thanks & regards,
Jagadish.

Both will assert the WDT reset bit, but only the launchpad board will assert the EXTRST bit. 

Hi Deric,

Deric Ng said:

Both will assert the WDT reset bit, but only the launchpad board will assert the EXTRST bit. 

Understood,

Give me some time to test it and analyze it.

--

Thanks & regards,
Jagadish.

Hi jagadish

Did you manage to find out why that is happening to this bit?

Hi Deric,

Sorry i didn't get chance to verify this issue again. I will work on today and will provide you an update by monday.

--

Thanks & regards,
Jagadish.

Hi Deric,

I found one old thread, where they explained why the external reset bit will get SET when watchdog timeout occurred.

(+) WDRST Bit and EXTRST Bit are set together in SYSESR Register - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

According to this thread when watchdog timeout occurred, then it will also make the nRST pin as low and as this pin is an I/O pin, so after readback the pin it will also set the external reset pin.

But we can see a different circuits at nRST pin for launchpad and HDK

HDK nRST circuit:

Launchpad nRST circuit:

If controller makes the nRST pin as low then 

sinking current on this pin in HDK = 0.33mA

And sinking current on this pin in Launchpad = 1.5mA

I am suspecting may be this difference affecting the behavior, i don't have any practical proof yet. Give me some time to analyze further and provide an update.

--

Thanks & regards,
Jagadish.

Thanks, for going into the deep details to find the root cause. This is rather useful and required in hardware design.

Hi Deric,

I changed the 10K pullup in HDK board to the 2.2K pullup for reset circuit but still the behavior is same. Give me some more time to analyze further and update you.

--

Thanks & regards,
Jagadish.

Thanks, keep me posted.

Hi Jaga

Did you manage to get more information or testing to round up this behaviour? I wish to pass the information to my team.

Deric

Hi Deric,

Deric Ng said:

Did you manage to get more information or testing to round up this behaviour? I wish to pass the information to my team.

Apologies for the delay, I was stuck with other issues this week, i will try to resolve your issue on next week.

--

Thaks & regards,
Jagadish.

Hi Jaga

Did you manage to do more testing on this issue? Look forward to get more insight from you. Thanks.

Hi Jaga. Hope to hear from you soon on this. Thanks.

Hi Jaga

Almost a month, any findings on the state of this EXTRST bit behavior under this WDT condition?

Hi Deric,

My sincere apologies for the delay!

I am still struggling to get the response from internal team.

I hope you will understand this and be patient.

--

Thanks & regards,
Jagadish.

Hi Deric,

I am kept on pinging for support but don't get any positive feedback yet.

--

Thanks & regards,
Jagadish.

Thanks for the feedback, and please continue to ping them.

Hi Deric,

Still i didn't get proper update from internal team, and i hope that this is not a blocker for your application development?

--

Thanks & regards,
Jagadish.

It is important as we are dealing with the safety related application and need to understand and make sure that the system is always predictable. For now, I will follow the Launchpad as it is newer board from TI. Please ping the internal to resolve it, end of the month Oct 23. Thanks a lot.

Hi Deric,

I got the reply from my senior expert, 

He is saying the issue is due to the silicon revision. That is the revA silicon of TMS570 has several hw bugs. The HDK was designed for RevA silicon, and its PCB layout is not changed for later rev silicon.

And we are doing the testing to confirm the same and will provide you an update .

--

Thanks & regards,
Jagadish.

Thanks a lot for following up closely on this thread.

Can I say that I should follow the schematic based on the launchpad.

Hi Deric,

For Your Information!

We did tests on HDK with RevA and RevB silicons of TMS570LC4357 and RM58L843, the EXTRST flag is not set by a watchdog reset. We monitored the nRST pin (bidirectional reset signal), the nRST pin on HDK is not pulled LOW by watchdog reset, but the nRST pin on Launchpad is pulled LOW by watchdog reset.

On HDK, the nRST is driven by a push button as well as the reset signal from ETM MIPI, XDS100V2 CPLD, ARM 20pin JTAG header, RTP header, and the nRST signal is also routed to the ethernet PHY. The pull-up resistors on all those traces makes a strong pull-up on nRST pin, so the internal reset signal from WDD is not able to pull the pin down, and EXTRST flag is not set by WDD reset. On Launchpad, the nRST pin is only connected to a push button.

We just did another test, which verified my assumption (strong pull-up on nRST).

We removed the pull-up resistors on RST signals from ETM MIPI header, ARM 20-pin JTAG header, RTP header, XDS100V2 CPLD, but leave one pull-up resistor on the RST signal from warm-reset push button. The EXTRST flag can be set by Watchdog reset.

Bit 3 (EXTRST) of ESR register is set.

and the nRST signal is pulled LOW by watchdog reset:

--
Thanks & regards,
Jagadish.

Hi Jaga

Very comprehensive to the root cause of the different outcome for nRST pin (EXTRST flag) on the launchpad and HDK. Thanks for providing the detailed test coverage. I truly appreciate your help. Cheers

Hi Deric,

Deric Ng said:

I truly appreciate your help.

It's our pleasure!

--

Thanks & regards,
Jagadish.