Intermittent K60F15 LOCKUP in VLPR

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

Intermittent K60F15 LOCKUP in VLPR

1,671 Views
gabrielharrison
Contributor III

Hi,

I am having a lockup issue when running a K60F15 in VLPR.

It is random how long it takes to happen but usually within a couple of minutes after transitioning to VLPR. The debugger will break because a Hardfault has happened and the Stack shows that the PC has gone to 0x00000000.

The Hardfault is definitely because it is trying to execute code 0x00000000 but I cannot see why the PC goes to zero.

In SCB->ICSR there is always a pending interrupt for either Systick or LPTMR (this may be irrelevant).

I can stop the problem by:

1. Go to BLPE but not VLPR

2. Disable SysTick, switch to VLPR, reinitialize SysTick

I can also sometimes trigger the issue by doing Break then Go in the debugger even after point 2 above.

I am using MK60FX512VMD15 chip mask 3N and IAR compiler. The fault occurs both with debugger attached and detached

Any help much appreciated.

Gabriel

16 Replies

1,381 Views
gabrielharrison
Contributor III

Hi,

Just so anyone reading this thread know we have parked the plan to use VLPR so are not going to look into this further at the moment.

N.B. The reason for parking the plan is not because of this issue but it isn't quite fast enough switching from VLPR back to 48MHz run mode.

Regards,

Gabriel

0 Kudos

1,380 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Gabriel,

I think the key of this issue to figure out the root of the hardfault, and I'd like to suggest you to check this post: Debugging Hard Faults on ARM Cortex-M | MCU on Eclipse.

Hope it helps.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

1,381 Views
gabrielharrison
Contributor III

Hi, Thank you for your reply.

The Hardfault is a Precise fault (after setting ACTLR DISDEFWBUF) and the Program Counter is no longer in a valid code section. It looks like the Hardfault is a secondary issue. I have monitored the Stack too and there is not a stack overflow.

Because it is is random exactly when it occurs I was thinking maybe a low voltage issue but I still can't think why reinitialising SysTick appears to solve the issue.

Can a low voltage have random effects or will it always be caught by the PCM, if configured?

Regards,

Gabriel

0 Kudos

1,381 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Gabriel,

As you mentioned above, reinitialising SysTick or turn off the IAR optimize can eliminate the Hardfault, so I don't think the low voltage is the possible cause of this issue.

However I'm very confused with relation between reinitialising SysTick and turn off the IAR optimize, and I was wondering if you can share any updates about the issue and I'm also still working on it now.
Have a great day,

Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

1,381 Views
gabrielharrison
Contributor III

Hi,

I still don't have a root cause but here is an update based on today's investigation.

I have spent most of the day trying to isolation a function that, when optimised, was causing the issue. I may have found one but it is difficult to be sure that it is fixing the issue or just making it less likely to Hardfault.

I also investigated the Systick anomaly and found that it was the frequency of the tick that seemed to be the issue not the act of re-initialising. Ticking at 1ms seems to fix (or mask) the issue but ticking at 24ms exposes it.

Next I rechecked the effect of running at 4MHz with and without VLPR set. When just in BLPE the issue goes away and also breaking and running the debugger has has no negative affect. In VLPR breaking and running the debugger more often than not creates a hard fault when you start running again. I have tried this with both the IAR I-jet and Segger j-link Base. When testing this in BLPE I always went from PEE(24MHz) to VLPR(4MHz) as normal, then exit VLPR to BLPE(4MHz) by setting SMC_PMCTRL_RUNM.

Finally, as the error was often (but not always) reported as a Precise fault I tried altering the SIM dividers. The default config I've been using is Core = Bus = FlexBus = /2 and Flash = /4. I tried various combinations using the rules in 5.4 Clock definitions of the Reference Manual. If I set Core = /2, Bus = FlexBus = /8 and Flash = /16 the random Hardfault appears to vanish. More interestingly breaking and running the debugger did not cause a Hardfault.

There is still no firm conclusion but I will do a soak test overnight to gather more data an confidence.

Regards,

Gabriel

0 Kudos

1,381 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Gabriel,

Do you get any updated investigations of this issue?

I was wondering if you can share the demo project, then I can run the tower board for testing.

I'm looking forward to your reply.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

1,381 Views
gabrielharrison
Contributor III

Hi,

I'm still working on this but have had to work on a different project for a bit.

I no longer have a tower board but it may be reproducible with the KINETIS512_V2_SC pmc_demo project by changing the speeds to the maximum 4/4/4/1 MHz and adding in the systick timer interrupt.

I'm actually using the K60F15 which doesn't have a VLPR demo in the bare metal examples.

Gabriel

0 Kudos

1,381 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Gabriel,

Just let you now.

According to your suggestion above, I configured the MCU work in the BLPI mode at first (The external clock source 50MHz is not supported in the BLPE mode), then let the MCU enter the VLPR mode and its several clocks sources all up the maximum 4/4/4 MHz/800 kHz.

In last, enable the systick timer.

I'm still testing and the issue doesn't occur until now.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

1,381 Views
gabrielharrison
Contributor III

Hi,

I will try BLPI too and see if I can get a tower board to test my code on.

I have also now raised a support request with IAR to try to see if it is something they can reproduce with the I-Jet.

What IDE and debugger are you using?

Gabriel

0 Kudos

1,382 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Gabriel,

FYI.

I did more testing with the systick timer day.

I've set differ situations for testing, for instance, enable the systick timer before or after the MCU enters VLPR mode, change the value of the systick reload value register,etc.

The similar issue you mentioned hasn't been triggered.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

1,382 Views
gabrielharrison
Contributor III

Hi,

An update. The issue started happening in RUN mode yesterday so I started digging a bit deeper. For some reason the IAR IDE was unable to decode the stack but it looked like the firmware was always servicing the USB at the point it faulted so I turned off the USB module and the issue went away. I think the reason the IDE may not decode the stack is because a reset was being triggered, although I don't know why.

This morning I have turned on the USB again and I am still getting a hard fault but without the rest so the stack is displayed.

It seems to fault on either of these two lines:

USB0_USBTRC0 &= ~0x40;

or

USB0_USBCTRL = 0x00;

A bit of searching brought up this post:  Possibly hardware issue with USB

Could it be related?

Gabriel

0 Kudos

1,382 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Gabriel,

Thanks for sharing the update.

It's hard to jump to conclusion. I think you need to do more testing for confirming.

And I'd like to know what the board and demo your use.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

1,382 Views
gabrielharrison
Contributor III

Hi Ping,

The MCU is on a custom board powered by a regulated 3.3v supply generated from either battery or USB (controlled by a charger chip).

The configuration we use is most similar to figure "Figure 3-58. USB regulator AA cell usecase" in the Reference Manual except VDD is the output of the 3.3V regulator.

Is there an accurate version of "Figure 3-59. USB regulator Li-ion usecase" available? We could investigate using that design.

Gabriel

0 Kudos

1,382 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Gabriel,

I use the IAR and OpenSDA interface which provideS a JTAG debug interface to the K60D100.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------


Have a great day,
(my name)

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

1,382 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Gabriel,

Thanks for sharing the updating, I'm testing the pmc_demo on the TWR-K60D100 now and I'll inform you as soon as possible after I find this issue out.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

1,382 Views
gabrielharrison
Contributor III

Hi,

An update. Turing off the IAR optimiser also stops the Hardfault.

I need to do some more digging.

Gabriel

0 Kudos