Connect JLink without active connection

[peacefulcarrot]

Hi nxp,

I am trying to use rtt buffers and a j-link to communicate data back and forth from an s32k144w to a pc.

For this purpose I am using pylink at the pc side.

When performing the following steps, everything works fine:

1. Start gdb server on pc

2. Connect to target using gdb server

3. Start communication on pc with Python script using pylink

The first 'weird' behaviour that I see is that when I start my Python script, the s32 breaks in the `Reset_Handler()`, I don't really understand why. When I continue in my debugging session, the script runs without a problem and I can communicate with the s32.

The problem is that when I do not connect to the gdb server, the script doesn't work. It is my gut feeling that the s32 falls in the `Reset_Handler()` and is just stuck there. Do you have any idea what the difference would be in the two situations?

For some more context, in the Python script I perform the following steps:

        jlink = pylink.JLink()

        jlink.open(ip_addr=ipaddr)

        jlink.set_tif(pylink.enums.JLinkInterfaces.SWD)

        jlink.connect("S32K144W")

        jlink.rtt_start()

        while True:

            try:

                jlink.rtt_get_num_up_buffers() <<<<< The program hangs here

                jlink.rtt_get_num_down_buffers()

                break

            except pylink.errors.JLinkRTTException:

                sleep(0.1)

        

Any pointers to why this is happening would be greatly appreciated!

[peacefulcarrot]

Raking up an old topic...

By accident I used another target when connecting through pylink ( `NRF52832_XXAA` instead of `S32K144W`) and this works! Any idea why using an nRF as target (which also has a M4) works, but specifying S32 as a target doesn't?

[danielmartynek]

Hi @peacefulcarrot,

I would recommend contacting SEGGER support.

[danielmartynek]

Hi @peacefulcarrot,

J-link / Pylink are not NXP products, I can't help you with the script.

Is the MCU going through reset when you run the script?

Do you monitor the reset_b pin?

What is the source of the reset, can you read RCM_SRS?

Regards,

Daniel

[peacefulcarrot]

Hi @danielmartynek 

Thanks for your reply :-).

Reading RCM_SRS returns 0x400, which indicates a SW reset (-> RCM_SRS[SW] bit).

This reset seems to come from the `jlink.connect(device)` command. We haven't had these issues on other targets (Nordic for example) so I was wondering why the device seems to get stuck in the `Reset_Handler()`?

[danielmartynek]

The SW reset can be called either by the application core or the debugger, there is no other way.

/*FUNCTION**********************************************************************
*
* Function Name : SystemSoftwareReset
* Description : This function is used to initiate a system reset
*
* Implements : SystemSoftwareReset_Activity
*END**************************************************************************/
void SystemSoftwareReset(void)
{
uint32_t regValue;
/* Read Application Interrupt and Reset Control Register */
regValue = S32_SCB->AIRCR;
/* Clear register key */
regValue &= ~( S32_SCB_AIRCR_VECTKEY_MASK);
/* Configure System reset request bit and Register Key */
regValue |= S32_SCB_AIRCR_VECTKEY(FEATURE_SCB_VECTKEY);
regValue |= S32_SCB_AIRCR_SYSRESETREQ(0x1u);
/* Write computed register value */
S32_SCB->AIRCR = regValue;
}

The debugger can then catch it at the reset vector.

Regards,

Daniel

[peacefulcarrot]

So if I understand correctly, only calling `SystemSoftwareReset()` can cause the `RCM_SRS[SW]` bit to be set?

When setting a breakpoint on this function (in the `system_S32K144W.c` file), this function is never reached when running my script.

Steps taken:

1. Start debugger
2. Place breakpoint on `SystemSoftwareReset()` function
3. Start the Python JLink script
4. Debugger breaks in `Reset_Handler()`
5. Continue debugger > system restarts and falls in main breakpoint
6. Read out RCM, SW reset bit is set. `SystemSoftwareReset()` is not reached.

It seems like the reset is initiated some other way?

[danielmartynek]

Hi @peacefulcarrot,

Since you are not able to attach the debugger, you don't know what reset is it while the debugger is not connected and the MCU is running stand-alone. You would need to read the RCM_SRS register in the application and send it out using another interface.

In general, the debugger can disable the WDOG, initialize SRAM ECC, enable some peripheral clocks etc, hard to tell what could be issue here.

BR, Daniel

[peacefulcarrot]

Hi Daniel,

But my issue remains the same. When the debugger is attached, I can get the system to work. If the debugger is not attached, I cannot get the system to work.

It seem that, for some reason, the reset hangs when the debugger is not connected? However, I cannot verify this, since I cannot attach the debugger...