MSPM0G3507: MCAN reset cause MCU reset

Need to confirm the reset cause.

You can read the register to get the reset cause at the begining of the application code.

Once MSPM0 is reset, you can stop M0 core and read the register.

Also, there are NMI and hardfault handler in MCAN demo code, you can try to add breakpoint in these two int handler.

Reset cause register is in here:

https://www.ti.com/lit/ug/slau846b/slau846b.pdf

2.6.36 RSTCAUSE (Offset = 1220h) [Reset = 00000000h]

Also, you can try this latest can demo: there are some bus fixed.

0385.mcan_application_LP_MSPM0G3507_nortos_ticlang.zip

HI,

I check my reset cause, it shows up 0x0000000E where there is no mention in the TRM

Best Regards,

Andy

Andy Hsu said:

I check my reset cause, it shows up 0x0000000E where there is no mention in the TRM

I need sometime to confirm this internally.

At the same time, here are two tips from my side:

1. Try new mcan demo sent you just now.

2. Try to catch MCAN module error when system reset, from these register(do not init mcan, read the register firstly)

7050h MCAN_IR MCAN Interrupt Register

7830h RIS Raw interrupt status CPU_INT

3. Also, based on 2, you can try to open MCAN error interrupt and add them into mcan_IRQ handler, try to see whether there is interrupt triggered.

Can not confirm 0x0E now, but can you help to confirm whether this is a WWDT0 reset cause?

Do you add WWDT in your project?

Helic Chi said:

Do you add WWDT in your project

Yes. I will remove it and give you feedback later.

OK

Yes, the WWDT is the cause to MCU reset. 

But why does resetting MCAN cause to NMI or HardFault handler?

1. please try to remove WWDT and help to confirm whether 0x0E reset cause will be triggered or not.

2. Reset MCAN only run in thread mode, and this won't influence the MCU interrupt, this is also related to your application code, whether MCAN reset will influence reset WWDT counter or not.

Also you can confirm NMI IIDX register in SYSCTL to confirm the detailed information.

After I removed the WWDT, the 0x0E reset cause will not be triggered.

Helic Chi said:

Also you can confirm NMI IIDX register in SYSCTL to confirm the detailed information.

When it stuck at handler, the NMI IIDX register is still nothing happen.

Also I found that if MCU being reset, the breakpoints in the CCS won't be effective. 

Please add these two function to your main.c

// Debug
void NMI_Handler(void) {
    __asm("NOP");
    __BKPT(0);
}
// Debug
void HardFault_Handler(void) {
    __asm("NOP");
    __BKPT(0);
}

Andy Hsu said:

When it stuck at handler, the NMI IIDX register is still nothing happen.

Maybe it's hardfault handler.

Usually caused by invalid CPU instruction or Memory error.

Please also try to find the relation between MCAN reset and NMI/hardfault.

Andy Hsu said:

After I removed the WWDT, the 0x0E reset cause will not be triggered.

It's may caused by WWDT, not MCAN reset.

Helic Chi said:

Maybe it's hardfault handler.

Yes, it was Hard fault.

Please try to set optimize level to 0, to test whether reset MCAN function causing hardfault.

Also, please use disassembly code of MCAN reset, to confirm which instruction causing hardfault.

I found out that the Message RAM error may be the cause to hard fault. Is there any register I can confirm it?

There are RAM DED interrupt you can enable it

21.7.89 IMASK (Offset = 7828h) [Reset = 00000000h]

Here is the example that can help you config the MCAN RAM.

Need to notice that TX event FIFO length is wrong in auto calculation, please reserve some space between Rx and TX event fifo

2744.mcan_application_LP_MSPM0G3507_nortos_ticlang.zip

I enable the DED interrupt, however it doesn't trigger the interrupt before it goes to Hard fault interrupt.

Is there any other cause to hard fault?

Need check disassembly, such as invalid address used in instruction (invalid address accessed).

In real time debug, or can communication stage:

Using a GPIO toggle in debug, to confirm whether M0 CPU can reach the code or not, wo check which part of code triggers hardfault.

Once confirm the code area that causes hardfault, we can use single step debug to check each line of code.

Or stack overflow will overwrite the RAM vairables, this will also cause CPU using invalid address.