S32K312EVB reset problem

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32K312EVB reset problem

3,838 Views
peterhausberger
Contributor I

I'm working on the S32K312 evaluation board and have the problem that the board resets when the debugger is not connected.

The program executes correctly for 1 second and then a reset is performed. This is repeated for exactly 10 times, afterwards execution stops completely. When I push the reset button (or power off and on the board), this whole behaviour starts again.

As mentioned, this only happens when the debugger (USB/PEMicro) is not connected. I run a very simple test program from the examples which toggles the user LED in an infinite loop. When the debugger is connected, the loop is really run infinite as expeced. So I'm quite sure that the user code is not triggering the reset.

First I was assuming that it is because of the watchdog of the SBC (FS26). But all the jumpers are set as in the default config (as described here Getting Started with the S32K312EVB-Q172 Evaluation Board for General Purpose | NXP Semiconductors), and accordingly the watchdog should be disabled by closing J1.

Maybe anyone has an idea what that could be or already run in the same problem. Thx for the help!

0 Kudos
Reply
10 Replies

2,622 Views
jigs123
Contributor I

I can get is work with 

RTD S32K3XX 2.0.3 2.0.3.202302160110

FreeRTOS S32K3 2.0.3 2.0.3.202303141032

0 Kudos
Reply

3,796 Views
VaneB
NXP TechSupport
NXP TechSupport

Hi @peterhausberger 

With the provided information, it looks like a possibility of this behavior is that when you power up the MCU immediately enters into a reset escalation, this occurs after a reset is triggered several times without any handling and the microcontroller holds in permanent reset.

Please ensure your code does not reset the microcontroller. For example, you can try to download any example included in S32 Design Studio and check if this error disappears.

Please, check the MC_RGM register to identify the cause of the reset.

Also, If you can share the code that you use to try to see if I present the same behavior as you, it would help me to better understand the problem.

 

B.R.

VaneB.

3,775 Views
peterhausberger
Contributor I

Hello @VaneB,

Thanks for your reply! I tried to create a minimal application which causes the problem, see attached.

First I created an empty project (File > New > S32DS Application Project) which just runs an infinite loop. Here the issue didn't occur. Then I added the lines for clock initialisation:

#include "Clock_Ip.h"

Clock_Ip_Init(&Clock_Ip_aClockConfig[0]);

When I then flash/debug the program, disconnect the debugger and do a manual reset (by pressing the reset button), the reset problem occurs, i.e. the board resets itself after 1 second. This can be seen by the reset LED flashing (only very short).

So it might be due to invalid clock settings? I did not change anything at the default config. The clock init is not needed in this sample code, but I need it for my projects (UART, CAN, ...). 

Unfortunately, I cannot check the MC_RGM register, since I have to disconnect the debugger to trigger the problem. 

0 Kudos
Reply

3,601 Views
atranzillo93
Contributor III

Hi,

I have the same problem and I have found the root cause:

https://community.nxp.com/t5/S32K/S32K312-uC-reset-after-1sec-from-power-on-caused-by-writing-MUX/m-...

I have seen that the reason of reset is when I try to write DIV bit of MUX_0_DC_2 register with a value different from 1.

I hope this can be useful for you.

Anna

0 Kudos
Reply

3,761 Views
VaneB
NXP TechSupport
NXP TechSupport

Hi @peterhausberger 

Sorry for the inconvenience this may cause.

There is a problem with the RTD v3.0.0 for the S32K312. The recommendation at this moment is to use the RTD v2.0.3.

Please use this version, and if there is any other problem, let me know. 

 

0 Kudos
Reply

3,737 Views
peterhausberger
Contributor I

Hi @VaneB,

thanks for the info! I tried to install v2.0.3, but only get a "Unsuitable Packages" error message, see attached. Probably I would also have to step back to DS 3.4?

0 Kudos
Reply

3,698 Views
VaneB
NXP TechSupport
NXP TechSupport

Hi @peterhausberger 

It would be the best, but if you want to install this version of RTD on S32DS v3.5 let me know so I can help you install it.

0 Kudos
Reply

3,546 Views
sai-bodhanapu
Contributor I

/* TEXT BELOW IS USED AS SETTING FOR TOOLS *************************************
!!Configuration
name: ClockConfig0
outputs:
- {id: ADC0_CLK.outFreq, value: 120 MHz}
- {id: ADC1_CLK.outFreq, value: 120 MHz}
- {id: AIPS_PLAT_CLK.outFreq, value: 60 MHz}
- {id: AIPS_SLOW_CLK.outFreq, value: 30 MHz}
- {id: BCTU0_CLK.outFreq, value: 120 MHz}
- {id: CLKOUT_RUN_CLK.outFreq, value: 3 MHz}
- {id: CLKOUT_STANDBY_CLK.outFreq, value: 24 MHz}
- {id: CMP0_CLK.outFreq, value: 30 MHz}
- {id: CMP1_CLK.outFreq, value: 30 MHz}
- {id: CORE_CLK.outFreq, value: 120 MHz}
- {id: CRC0_CLK.outFreq, value: 60 MHz}
- {id: DCM0_CLK.outFreq, value: 30 MHz}
- {id: DCM_CLK.outFreq, value: 30 MHz}
- {id: DMAMUX0_CLK.outFreq, value: 120 MHz}
- {id: DMAMUX1_CLK.outFreq, value: 120 MHz}
- {id: EDMA0_CLK.outFreq, value: 120 MHz}
- {id: EDMA0_TCD0_CLK.outFreq, value: 120 MHz}
- {id: EDMA0_TCD10_CLK.outFreq, value: 120 MHz}
- {id: EDMA0_TCD11_CLK.outFreq, value: 120 MHz}
- {id: EDMA0_TCD1_CLK.outFreq, value: 120 MHz}
- {id: EDMA0_TCD2_CLK.outFreq, value: 120 MHz}
- {id: EDMA0_TCD3_CLK.outFreq, value: 120 MHz}
- {id: EDMA0_TCD4_CLK.outFreq, value: 120 MHz}
- {id: EDMA0_TCD5_CLK.outFreq, value: 120 MHz}
- {id: EDMA0_TCD6_CLK.outFreq, value: 120 MHz}
- {id: EDMA0_TCD7_CLK.outFreq, value: 120 MHz}
- {id: EDMA0_TCD8_CLK.outFreq, value: 120 MHz}
- {id: EDMA0_TCD9_CLK.outFreq, value: 120 MHz}
- {id: EIM0_CLK.outFreq, value: 60 MHz}
- {id: EMIOS0_CLK.outFreq, value: 120 MHz}
- {id: EMIOS1_CLK.outFreq, value: 120 MHz}
- {id: ERM0_CLK.outFreq, value: 30 MHz}
- {id: FIRCOUT.outFreq, value: 48 MHz}
- {id: FLASH0_CLK.outFreq, value: 30 MHz}
- {id: FLEXCAN0_CLK.outFreq, value: 24 MHz}
- {id: FLEXCAN1_CLK.outFreq, value: 24 MHz}
- {id: FLEXCAN2_CLK.outFreq, value: 24 MHz}
- {id: FLEXCAN3_CLK.outFreq, value: 24 MHz}
- {id: FLEXCAN4_CLK.outFreq, value: 24 MHz}
- {id: FLEXCAN5_CLK.outFreq, value: 24 MHz}
- {id: FLEXCANA_CLK.outFreq, value: 24 MHz}
- {id: FLEXCANB_CLK.outFreq, value: 24 MHz}
- {id: FLEXIO0_CLK.outFreq, value: 60 MHz}
- {id: FXOSCOUT.outFreq, value: 16 MHz}
- {id: HSE_CLK.outFreq, value: 60 MHz}
- {id: INTM_CLK.outFreq, value: 60 MHz}
- {id: LCU0_CLK.outFreq, value: 120 MHz}
- {id: LCU1_CLK.outFreq, value: 120 MHz}
- {id: LPI2C0_CLK.outFreq, value: 30 MHz}
- {id: LPI2C1_CLK.outFreq, value: 30 MHz}
- {id: LPSPI0_CLK.outFreq, value: 60 MHz}
- {id: LPSPI1_CLK.outFreq, value: 30 MHz}
- {id: LPSPI2_CLK.outFreq, value: 30 MHz}
- {id: LPSPI3_CLK.outFreq, value: 30 MHz}
- {id: LPUART0_CLK.outFreq, value: 60 MHz}
- {id: LPUART1_CLK.outFreq, value: 30 MHz}
- {id: LPUART2_CLK.outFreq, value: 30 MHz}
- {id: LPUART3_CLK.outFreq, value: 30 MHz}
- {id: LPUART4_CLK.outFreq, value: 30 MHz}
- {id: LPUART5_CLK.outFreq, value: 30 MHz}
- {id: LPUART6_CLK.outFreq, value: 30 MHz}
- {id: LPUART7_CLK.outFreq, value: 30 MHz}
- {id: MSCM_CLK.outFreq, value: 60 MHz}
- {id: PIT0_CLK.outFreq, value: 30 MHz}
- {id: PIT1_CLK.outFreq, value: 30 MHz}
- {id: PLL_PHI0.outFreq, value: 120 MHz}
- {id: PLL_PHI1.outFreq, value: 48 MHz}
- {id: RTC0_CLK.outFreq, value: 32 kHz}
- {id: RTC_CLK.outFreq, value: 32 kHz}
- {id: SCS_CLK.outFreq, value: 120 MHz}
- {id: SIRCOUT.outFreq, value: 32 kHz}
- {id: SIUL2_CLK.outFreq, value: 30 MHz}
- {id: STCU0_CLK.outFreq, value: 30 MHz}
- {id: STM0_CLK.outFreq, value: 48 MHz}
- {id: STMA_CLK.outFreq, value: 48 MHz}
- {id: SWT0_CLK.outFreq, value: 32 kHz}
- {id: SXOSCOUT.outFreq, value: 32.768 kHz}
- {id: TEMPSENSE_CLK.outFreq, value: 120 MHz}
- {id: TRACE_CLK.outFreq, value: 48 MHz}
- {id: TRGMUX0_CLK.outFreq, value: 30 MHz}
- {id: TSENSE0_CLK.outFreq, value: 30 MHz}
- {id: WKPU0_CLK.outFreq, value: 30 MHz}
settings:
- {id: CORE_MFD.scale, value: '120', locked: true}
- {id: CORE_PLLODIV_0_DE, value: Enabled}
- {id: CORE_PLLODIV_1_DE, value: Enabled}
- {id: CORE_PLL_PD, value: Power_up}
- {id: FXOSC_PM, value: Crystal_mode}
- {id: MC_CGM_MUX_0.sel, value: PHI0}
- {id: MC_CGM_MUX_0_DIV0.scale, value: '1', locked: true}
- {id: MC_CGM_MUX_0_DIV0_Trigger, value: Common}
- {id: MC_CGM_MUX_0_DIV1.scale, value: '2', locked: true}
- {id: MC_CGM_MUX_0_DIV1_Trigger, value: Common}
- {id: MC_CGM_MUX_0_DIV2.scale, value: '4', locked: true}
- {id: MC_CGM_MUX_0_DIV2_Trigger, value: Common}
- {id: MC_CGM_MUX_0_DIV3.scale, value: '2', locked: true}
- {id: MC_CGM_MUX_0_DIV3_Trigger, value: Common}
- {id: MC_CGM_MUX_0_DIV4.scale, value: '4', locked: true}
- {id: MC_CGM_MUX_0_DIV4_Trigger, value: Common}
- {id: MC_CGM_MUX_6.sel, value: MC_CGM_MUX_0_DIV0}
- {id: MC_CGM_MUX_6_DE0, value: Enabled}
- {id: MC_CGM_MUX_6_DIV0.scale, value: '40', locked: true}
- {id: MODULE_CLOCKS.MC_CGM_AUX3_DIV0.scale, value: '2', locked: true}
- {id: MODULE_CLOCKS.MC_CGM_AUX4_DIV0.scale, value: '2', locked: true}
- {id: MODULE_CLOCKS.RTC_MUX.sel, value: SIRC_CLK}
- {id: PHI0.scale, value: '2', locked: true}
- {id: PHI1.scale, value: '5', locked: true}
- {id: PLL_PREDIV.scale, value: '2', locked: true}
- {id: POSTDIV.scale, value: '4', locked: true}
- {id: SXOSC_PM, value: Crystal_mode}
sources:
- {id: FXOSC_CLK.FXOSC_CLK.outFreq, value: 16 MHz, enabled: true}
- {id: SXOSC_CLK.SXOSC_CLK.outFreq, value: 32.768 kHz, enabled: true}
* BE CAREFUL MODIFYING THIS COMMENT - IT IS YAML SETTINGS FOR TOOLS **********/

 

 

 

try with this clock settings, it worked for me.

Regards,

Sai Praveen.

0 Kudos
Reply

1,530 Views
baris_celikcapr
Contributor I

I had the same issue and I only change MC_CGM_MUX_0_DIV3 from "1" to "2" and it solved my issue.

baris_celikcapr_0-1715172801555.png

 

0 Kudos
Reply

1,525 Views
bryan_brauchler
NXP Employee
NXP Employee

Hello @peterhausberger 

Couple things,

1. 60MHz should be the default HSE_CLK due to HSE Gasket defaults. If you wish to run the HSE at 120MHz you will need to configure the gasket in the DCF Record area. See S32K3xx_DCF_clients.xlsx attached to the reference manual for details.

2. You can check the reported reset reason using the ERM - this will indicate either an external reset or indicate the internal reset source

3. Please make sure that all cores have entered WFI before calling the clock switch:

(32.11 in the RM)

bryan_brauchler_0-1715173879648.png

This can be a common cause of the described behavior, as the debugger will delay clock initialization enough for the SBAF to park the HSE core. Changing this clock before the HSE core is parked will cause lockup on the HSE core triggering HSE WDG reset.

Best,

Bryan

0 Kudos
Reply