MSPM0G3507: Regarding Systick handler

There is a newer version of the SDK.

Have you tried to pause it with the debugger to see if you are in the default interrupt handler? If you are, you can add this code:

/*
* These are traps for debugging when you find that your code
* ends up in the default handler for some unknown reason.
* To keep the compiler from complaining, comment out the ones
* below if you already have a working handler for that vector.
*
*/
void NMI_Handler(void){ __BKPT(0);}
void HardFault_Handler(void){ __BKPT(0);}
void SVC_Handler(void){ __BKPT(0);}
void PendSV_Handler(void){ __BKPT(0);}
void SysTick_Handler(void){ __BKPT(0);}
void GROUP0_IRQHandler(void){ __BKPT(0);}
void GROUP1_IRQHandler(void){ __BKPT(0);}
void TIMG8_IRQHandler(void){ __BKPT(0);}
void UART3_IRQHandler(void){ __BKPT(0);}
//void ADC0_IRQHandler(void){ __BKPT(0);}
//void ADC1_IRQHandler(void){ __BKPT(0);}
void CANFD0_IRQHandler(void){ __BKPT(0);}
void DAC0_IRQHandler(void){ __BKPT(0);}
void SPI0_IRQHandler(void){ __BKPT(0);}
void SPI1_IRQHandler(void){ /*__BKPT(0);*/ return;}
void UART1_IRQHandler(void){ __BKPT(0);}
void UART2_IRQHandler(void){ __BKPT(0);}
void UART0_IRQHandler(void){ __BKPT(0);}
void TIMG0_IRQHandler(void){ __BKPT(0);}
void TIMG6_IRQHandler(void){ __BKPT(0);}
void TIMA0_IRQHandler(void){ __BKPT(0);}
void TIMA1_IRQHandler(void){ __BKPT(0);}
void TIMG7_IRQHandler(void){ __BKPT(0);}
void TIMG12_IRQHandler(void){ __BKPT(0);}
void I2C0_IRQHandler(void){ __BKPT(0);}
void I2C1_IRQHandler(void){ __BKPT(0);}
void AES_IRQHandler(void){ __BKPT(0);}
void RTC_IRQHandler(void){ __BKPT(0);}
void DMA_IRQHandler(void){ __BKPT(0);}

To see which interrupt handler you forgot.

Agreed with above, if possible can you connect to the device with the debugger and tell us what code is running on the device when it is halted/ where it is halted. This would help a lot to determine what the problem is.

Additionally, you are saying that this only occurs when you first power the device on, but subsequently when you debug it works? I am not clear on what the process is here/ what is working and what isn't.

Are you using custom hardware, or a TI Launchpad?

Hi Dylan,

yes we are using Custom hardware (embedded with MSPM0G3507 MCU ) , on that board there are some other hardware logic is implemented like PI controller using OPAMP , +12 and 12 voltage to 3.3V LDO and RC filter etc. 

basically , in short our application code is changing the duty cycle of PWM and based on that we are controlling the PI loop to increase the current flow of other hardware board by the Custom hardware but what we facing is, we are able to flow the current up to 2 -5 amp for long time but as we increase the duty cycle to increase the current (16 amp) it flow for 1 min and then MCU get halt.

and we not able to debug it just because of lot of noise, so we are just flashing and running the application code. 

Best regards,

I am not clear on how noise is preventing you from debugging the device, can you elaborate on this? Is there some way to remove the device from the noisy environment to debug? We need some indicator of the internal state of the device to start to figure out why it is halting.

One other idea that I have that may help -> Does your custom hardware hold PA18 low during startup / reset? PA18 is the default BSL invoke pin, and if it is not pulled low at startup or during reset the device will enter BSL mode. Does this sound like a potential culprit for the issue?

If you have some spare GPIO's available you can have them get set as part of all of these interrupt handlers to identify them. but it would be tedious to the extreme.

You could also use, say, 4 GPIO's and set them according to a binary code for each interrupt:

UART_0 would be 0001

UART_1 would be 0010

UART_2 would be 0011

and so on.