MSP432P401R: Unexpected WDT reset

I have some questions:

- When watchdog timeout is configured as 1sec, GPIO toggle is stopped for ~1sec then watchdog reset is triggered. (Why it will stop for 1second?)
- When watchdog timeout is configured as 16sec, GPIO toggle is stopped for ~2sec then started again. No watchdog reset is triggered. (Why it will stop for 2second?)

I think it has some problem with:

1. Low power mode. Have customer use this?

2. Clock system

3. RTOS

My advice:

1. Output ALCK, SMCLK from pin to see if the clock is good all the time.

2. Rove RTOS to see if this problem will happen

3. Check if you can recreate this problem in debug mode. It will be much easy to track the problem.

Eason

Hi Eason,

Thanks for your quick reply.
I will check with customer about your advices.
Could you explain a bit more about #2 and #3?
I guess #3 is using CCS debug build, correct?
I have no idea about #2. Please clarify about it.

BTW, customer did additional test.
They changed GPIO toggle interval from 100ms to 10ms, but the result was the same, GPIO toggle stops for ~2s.

This implies the issue is not something clock gets slower, but CPU is actually stops for ~2s.

Thanks and regards,
Koichiro Tashiro

Hi Eason,

Customer monitored ACLK and SMCLK.
Both clocks are 24MHz and 32.768kHz as expected even the issue happened.

Thanks and regards,
Koichiro Tashiro

Hi Koichiro,

Thank you. At least I can know the the clock system is good. I think it may lies on the RTOS.

1. Can customer test the functions when only running one thread?  Then they can check if it lies on the thread function. (I think it is already done. Just double check)

2. What I mean in #2 is that this is a very easy software. I think customer can develop a code without RTOS to realize these two functions, then they can check if it lies on RTOS. (It is a very important part!!!)

Eason

Hi Eason,

For #1, customer tested with only one thread(GPIO toggle). WDT is disabled in this case.
Still the issue is reproduced. The GPIO toggle is stopped for ~2sec.

Customer is checking for #2. I will let you know the result.

I have one more update. Customer confirmed the issue still occurs if BCLK source is changed to REFO.
So using ACLK source from LFXTCLK is the primary condition of the issue.

Thanks and regards,
Koichiro Tashiro

Hi Koichiro,

Nice to hear that. I think customer can try to remove the RTOS to do GPIO toggle job. It is easy to find where is the wrong code.

Eason

Hi Eason,

Customer tried followings.
a) Do not call BIOS_start() and just does GPIO toggle code. So far no issue observed.
Could you give us any idea or sample codes which customer can use to narrow down where the issue resides in RTOS code?

b) There are 4 modules which use ACLK(from LFXCLK). They are Timer A1/A2/A3 and WDT.
Customer changed all 4 modules use SMCLK or BCLK, so now no module use ACLK.
But the issue still observed.

Thanks and regards,
Koichiro Tashiro

It is quite wired to know that.

I  find an example on the SDK: C:\ti\simplelink_msp432p4_sdk_3_40_01_02\examples\rtos\MSP_EXP432P401R\drivers\gpiointerrupt

I think customer can first to realize the spread function based on our code example.

Hi Eason,

Customer modified the example in SDK and still observed the same issue.
They just modified GPIO pin assignments and clock configuration.
GPIO toggle stopped ~2sec.

Customer also tried to replace the device on the failing board.
After the device is changed, the issue is gone, so it seems the issue resides in the silicon.

Thanks and regards,
Koichiro Tashiro