S32K116LA vs S32K116LF differ after reset?

[jernst]

I'm observing a strange behaviour of S32K116LA vs S32K116LF. After reset chips are commanded to enter the debug mode. In a loop the status register is polled to check if reset has finished. Between the poll the program waits for 1 ms. The problem is that with the S32K116LA the reset finishes after a couple (1..5) polls. But with the S32K116LF sometimes it finishes and sometimes even 150 polls do not see the flag.
Does anyone have an idea what the reason could be for this behaviour?
Do the chips have different setup procedures?

Here is a snippet of the code to give you an impression:

    uint16 retryCounter = 25 ;
    uint32 status;
    // S32K116: EnterDebugMode
    do
    {
        WaitFor_ms ( 1 ) ;
        status = ReadMDM ( MDM_Bank::STAT_CTRL , MDM_Register::Status ) ;
        if ( (status & MDM_AP_StatusRegister_SystemReset) != 0 )
            break;
        retryCounter --;
    }
    while ( retryCounter > 0 ) ;

[danielmartynek]

Hello Juergen,

Is there any HW difference in the PCBs?
Could you scope the reset_b pin (PTA5)?

Is it possible that the MCU is held in reset externally?
For example, by charging a capacitor on the reset_b pin.
Can you read the MDM-AP Status Flash memory ready bit as well while reading the system reset bit?

Thank you,

BR, Daniel

[jernst]

- Is there any HW difference in the PCBs?

      Customer did not know of any change in the PCBs.

- Could you scope the reset_b pin (PTA5)?

      reset_b pin is okay.

- Is it possible that the MCU is held in reset externally?

      There is only this MCU.

- For example, by charging a capacitor on the reset_b pin.

      There is an RC combination for this pin. pullup R=4k7 and C=1nF.

      C should be pretty fast charged up. Is later pulled low by programmer.

- Can you read the MDM-AP Status Flash memory ready bit as well while reading the system reset bit?

      This flag is read later to check if Flash is okay. But in that loop? Maybe I did once. If I remember correctly there was no change, meaning reset came first and flash flag is ready much later.

Meanwhile I did some more tests.

I think there is no difference between these MCU variants because now I can reproduce the behaviour with them both.

Now it depending on whether the Flash was erased before or not.

If erased then the loop waiting for reset flag is always stuck.

But if programmed before then there was this random behaviour with 25% stuck but 75% okay.

[danielmartynek]

When the flash is blank, the MCU is periodically resetting itself due to core lock-ups. 

The MCU is out of reset only for a few micro seconds before it is reset again.

You should see that on the reset_b pin.

Based on that, I think it is normal that you read MDM-AP_Status[3] == 0.

BR, Daniel