MSPM0L2228: independent watchdog timer (IWDT) disturbs flash process

Update, I found a way to get my device back. I removed the BAT jumper so that the LFSS including IWDT is not supplied. After that, I'm able to flash the device.
But this did not solve my main problem. How to work with the WDT if it will hit into the Flash process?
Our target device is an MSPM0L1228 with 32 pins. This one does not have a BAT pin. Does that mean that the device is locked forever after flashing an IWDT Project?
Just to be clear, I've tried several LaunchPads, all with the same behavior.

Is that a desired behavior? The Reverence Manual is not telling something about that.

Additional question, I tried to test with a L1306 LP and syscfg told me this one does not have an IWDT. How can I figure out which devices support it?

I hope somebody can help me out.

Regards,
Timo

Hi Timo,

Sorry for late response, yes I also find when enable IWDT, the debug will not hold IWDT, so that it will make POR reset, which will break SWD connection can not connect the device. I will set up an internal thread to track this, hopefully we can get a fix in following release of the CCS.

To check which device support IWDT, we need to check the device datasheet to finalize.

In summary, MSPM0Lx22x, MSPM0Gx51x has IWDT. The upcoming device nearly all include a IWDT.

B.R.

Sal

Hi Sal,

thanks for your answer. But if I understand it right, I can't go on with the IWDT until CSS is updated. Right?
How long will it take to release a new version of CCS? And UniFlash is also producing these problems, is there a new release planed as well?

Regards,
Timo

Hi Timo,

Timo said:

But if I understand it right, I can't go on with the IWDT until CSS is updated. Right?

We provide a method to force MCU reset and not run IWDT manually:

Wait_for_debug DSSM scripts, after run this scripts manually, CCS can force MCU at high reset level and then load the firmware to device is not expected to be broken:

The steps you can also find it in Design Flow Guide - unlock MCU: MSPM0 Design Flow Guide

Timo said:

How long will it take to release a new version of CCS?

We also provide a automatically steps in the project property:

This auto step is little weaker than the manually process one, but it also worthy a try. If it doesn't work, I can file a request to do some upgrade in futher release, you can use the manual step for recently debug.

And one my suggestion is that, after you verify the IWDT behavior, you can just disable it during normal function development and test, and finally combine the IWDT together. 

IWDT triggers POR will break all the connection, if it locked by IWDT periodically reset, you need trigger POR with BSL entry (re-power on with PA18 connect to VCC, or pull down NRST larger than 1s with PA18 connect to VCC).

B.R.

Sal

Hi Sal,

unfortunately, this does not solve the problem.

If the device is "locked" by IWDT and I start the Wait_for_debug DSSM script, I get the error "Unable to access device register. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 20.0.0.3178)"

In the MSPM0 Desing Flow Guide chapter unlock MCU you have mentioned, I did not find something about WDT or WaitForDebg skript. Only EraseFlash and FactoryReset witch also does not work. 

Enable the function wait for debug in Project properties doesn't help either. I still get various error messages. Also starting MCU in BSL mode with PA18.

Any other solutions to work with WDT?

Regards,
Timo

Hi Timo,

Additional information is that, make sure your IWDT is working currently.

If you are not feed IWDT in the firmware, then you will find that IWDT trigger POR, POR occurs will destroy all the SWD conncection, and also clear the message in the DSSM mailbox. So the scripts will not work. Or you can say IWDT locked the device.

If IWDT locked the device (IWDT trigger POR periodically), then the remaining method is that, connect the PA18 to VCC, then re-power on or pull down NRST more than 1s. After POR reset, the device will reset IWDT by POR, and then enter BSL mode which will be connected correctly.

B.R.

Sal

Hi Sal,

also, if I feed the IWDT correctly, I'm running into problems. This was my first problem, which prompted me to investigate the behavior of the IWDT. Not always but sometimes I get the Error 

I would say it happens more often if I use a short IWDT period. In example, I used 93,75ms IWDT period and reset it every 50ms.

If the error occurs, I cannot flash, mass erase or factory reset the device. Also, the WaitForDebug script will not work. The before flashed SW is not running correctly anymore. A power cycle is also not sufficient. Only the disconnection of the Bat supply helps to get the Device back running. It seems that the IWDT is still running at the beginning of the Flash process, and sometimes the timing is fine to stop the IWDT before POR and sometimes not.

Is that a desired behavior?

For me, it feels like the IWDT feature is not completely finished. Could you confirm that? In that case, we would disable it, until it is fixed in CCS and UniFlash. But then the question remains, when will there be a fix?

Regards,
Timo

Hi Timo,

Thanks for information.

Timo said:

If the error occurs, I cannot flash, mass erase or factory reset the device. Also, the WaitForDebug script will not work. The before flashed SW is not running correctly anymore. A power cycle is also not sufficient. Only the disconnection of the Bat supply helps to get the Device back running. It seems that the IWDT is still running at the beginning of the Flash process, and sometimes the timing is fine to stop the IWDT before POR and sometimes not.

I aslo create the same scenario you describe here and get the same result. And yes this is under expectation.

As M0L2228 has VBAT, it requires VABT Reset in VBAT Power domain to reset IWDT. The reset generated by NRST or IWDT will not reset the VBAT power domain. So that IWDT will run background.

Any moment the MCU is halt and run DSSM command or laod firmware, the POR generated by IWDT and break the operation.

This is unique for the device who has VBAT feature.

I will add additional descriptions in the tracking thread, and check how we can take a fix. It does have the risk for user if they want to reload the firmware in mass production stage, where the device will act as locked by IWDT.

For debug activity, two operations for temporarily usage:

1. Repower the board with PA18 connected to VCC

2. Dispower the VBAT, so that IWDT will not work

Timo said:

For me, it feels like the IWDT feature is not completely finished. Could you confirm that? In that case, we would disable it, until it is fixed in CCS and UniFlash. But then the question remains, when will there be a fix?

I'll share the fix schedule when internal team finalize it.

B.R.

Sal

Hi Sal,

thanks for your confirmation. I haven't even thought about mass production yet. But you are right, that also could cause a big problem. Hopefully there is an easy fix. 
I would appreciate hearing from you, when there is a schedule for the fixing process.

Regards,
Timo

Hi Timo,

Sure, I'll keep you posted when we have fixed this issue.

Then normally the fix will take effect in next CCS release timeline. If you have any critical timeline for product, please let me aware.

B.R.

Sal