S32K146 RCM_SRS Register value for SWD reset

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

S32K146 RCM_SRS Register value for SWD reset

Jump to solution
2,070 Views
adria
Contributor I

Hello,

When I perform a software reset by calling "SystemSoftwareReset()" I read SW (bit 10) as reset cause int the RCM_SRS register. That is perfect.

But when I perform a reset through SWD from the IDE (S32 Design Studio) I am getting the same reset cause.

Is that the correct behaviour?

I can see there is a bit field in the RCM_SRS register for a reset caused by JTAG, shouldn't this be the one active when the reset is caused by SWD?

Thanks in advance!

Best regards,

Adria

Tags (1)
0 Kudos
1 Solution
1,873 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi Adria,

Yes, it makes sense.

Please refer to J-Link / J-Trace User Guide

https://www.segger.com/downloads/jlink/UM08001 

7.10    Reset strategies

7.10.2    Strategies for Cortex-M devices

Thanks,

BR, Daniel

View solution in original post

0 Kudos
4 Replies
1,873 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hello Adria,

What debugger are you using?

Have you tried resetting the MCU while running an empty project?

The JTAG flag is set only if the debugger selects a certain IR codes.

pastedImage_1.png

pastedImage_2.png

But the debugger can reset the MCU using external reset pin as well.

BR, Daniel

0 Kudos
1,873 Views
adria
Contributor I

Hi Daniel,

I am using Segger J-Link. When I perform the reset through the IDE (S32 Design Studio) I get a Software reset, and this bit says:

"Software
Indicates a reset has been caused by software setting of SYSRESETREQ bit in Application Interrupt and
Reset Control Register in the Arm core.
0 Reset not caused by software setting of SYSRESETREQ bit
1 Reset caused by software setting of SYSRESETREQ bit"

Instead, when I use PE Micro Multilink Universal as debugger, I get External Reset Pin, and this bit says:

"External Reset Pin
Indicates a reset has been caused by an active-low level on the external RESET (RESET_b) pin.
0 Reset not caused by external reset pin
1 Reset caused by external reset pin"

This last one (with Multilink debugger) makes more sense for me because the debugger can write on the MCU reset pin and so cause a reset through that pin. But in the case of the J-Link debugger, it just felt weird that a reset cause by a user through the debugger triggers a Software reset, which normally is done programmatically from the code.

The only thing I would like to know if it all makes sense?

Best regards,

Adria

0 Kudos
1,874 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi Adria,

Yes, it makes sense.

Please refer to J-Link / J-Trace User Guide

https://www.segger.com/downloads/jlink/UM08001 

7.10    Reset strategies

7.10.2    Strategies for Cortex-M devices

Thanks,

BR, Daniel

0 Kudos
1,873 Views
adria
Contributor I

Hi Daniel,

Thanks!

Best regards,

Adria

0 Kudos