I found out that my LPC4357 based device (which uses LPCopen 2.12 and no OS) sometimes ends-up in hard fault after reset. Once it runs, it runs fine and does not crash.
The reset is requested by an external device via communication. Communication is handled by the M0 core which resets the whole MCU using Chip_RGU_TriggerReset(RGU_CORE_RST)
It takes randomly from several to hundreds of restarts to replicate the issue.
The M4 core ends up in hard fault. The problem happens during setting of clock.
When I repeatedly reset from the user application and connect through JTAG after the crash, I can't get any relevant information from the VECTPC register. If I reset it through the LPCXpresso "Restart" button in an active debug session over JTAG, it shows where the hard fault handler was called.
For this reason I used the restart from LPCXpresso, although I am not 100% sure the behavior is identical.
At the beginning I traced it to the call of Chip_Clock_SetupMainPLLMult():
I thought that the PLL needed more time to stabilize, so I increased the delay.
It actually helped, but eventually it crashed again.
This time it was in the call of Chip_Clock_GetMainPLLHz()
I normally debug at the code level and do not have experience at the instruction level.
Does anybody have any idea how to solve this problem?
I found a thread which describes a similar problem, just with the M0 core...
Hello Sabina,
thank you for your reply.
I would call the behavior rather consistent.
When I reset from within the application by calling Chip_RGU_TriggerReset(RGU_CORE_RST) and connect to the MCU after it stops resetting itself, it is sometimes in the NMI_Handler() and sometimes in the HardFault_Handler().
In this situation I do not see where the handler was called.
When I reset using the GUI restart button (repeated clicking using a click script tool), it consistently happens on the line 257 of clock_18xx_43xx.c
My version of the Chip_Clock_SetupMainPLLMult from LPCopen 2.12:
/* Directly set the PLL multipler */
uint32_t Chip_Clock_SetupMainPLLMult(CHIP_CGU_CLKIN_T Input, uint32_t mult)
{
volatile uint32_t delay = 250;
uint32_t freq = Chip_Clock_GetClockInputHz(Input);
uint32_t msel = 0, nsel = 0, psel = 0, pval = 1;
uint32_t PLLReg = LPC_CGU->PLL1_CTRL;
freq *= mult;
msel = mult - 1;
PLLReg &= ~(0x1F << 24);/* clear input source bits */
PLLReg |= Input << 24; /* set input source bits to parameter */
/* Clear other PLL input bits */
PLLReg &= ~((1 << 6) | /* FBSEL */
(1 << 1) | /* BYPASS */
(1 << 7) | /* DIRECT */
(0x03 << 8) | (0xFF << 16) | (0x03 << 12)); /* PSEL, MSEL, NSEL- divider ratios */
if (freq < 156000000) {
/* psel is encoded such that 0=1, 1=2, 2=4, 3=8 */
while ((2 * (pval) * freq) < 156000000) {
psel++;
pval *= 2;
}
PLLReg |= (msel << 16) | (nsel << 12) | (psel << 8) | (1 << 6); /* dividers + FBSEL */
}
else if (freq < 320000000) {
PLLReg |= (msel << 16) | (nsel << 12) | (psel << 8) | (1 << 7) | (1 << 6); /* dividers + DIRECT + FBSEL */
}
else {
Chip_Clock_DisableMainPLL();
return 0;
}
LPC_CGU->PLL1_CTRL = PLLReg & ~(1 << 0);
/* Wait for 50uSec */
while(delay--) {}
return freq;
}When I change the value of delay from 250 to 1000 it starts to happen (less frequently) at a call of
Chip_Clock_GetClockInputHz()
which is called within Chip_Clock_SetupMainPLLMult() and Chip_Clock_SetupMainPLLHz().
It can happen in either of these.
I assume that if I did not change the delay, it could still happen at the call of Chip_Clock_GetClockInputHz(). It is just more probable that it happens on line 257, so it happens there first.
I do not really understand why the debugger shows that the problem happens during the delay countdown. I would expect that it should happen after the delay decrements to 0 and the following instruction is processed.
- Calling the Chip_RGU_TriggerReset(RGU_CREG_RST) unfortunately did not change the behavior it still crashes at about the same rate.
Of course I can test that only when I call the reset from the application, not from GUI - How shall I disable the PLL without crashing the MCU? It provides clock for the core and all peripherals. When I call Chip_Clock_DisableMainPLL(), it crashes.
Hello Sabina,
thank you for the reply and I also apologize for the delay.
So far I made following tests:
- The value of the "delay" variable which starts at the value 250 is usually 244 after the crash (5 tests, 4 times it ended up 244 and once it was 240). I decreased the value to 220 and it also counted down only by 6 before the MCU ended in hard fault. The same when I increased the starting value to 260.
What is really strange is that when I increase the initial value to 300, The program does not crash on this line any more.
This is a mystery to me. Why should increasing of the value help? It counts down only by 6 or 10 before the crash so the actual value should not matter as long as it is larger than 10... - I got rid of interrupt sources on the M4 and disable interrupts using "__disable_irq();" on the M0 immediately before the M0 executes the reset. Unfortunately that did not help.
- I tried switching the clock source of the M4 and M0 cores from PLL1 to the IRC using:
LPC_CGU->BASE_CLK[CLK_BASE_MX] = CLKIN_IRC;
LPC_CGU->BASE_CLK[CLK_BASE_PERIPH] = CLKIN_IRC;
executed by the M0.
(The user guide describes the steps for switching of the clock source to high frequency PLL1. If I understand it right, switching back to IRC should be simple, no waiting for a lock, no clock dividers)
Unfortunately when I stop the controller after executing that and look into the CGU registers, the core and peripherial clocks are still set to PLL1.
When I change all the BASE-XXX-CLK which have PLL1 in them to IRC through LPCXpresso while the MCU is on breakpoint, the MCU crashes when I restart it and I loose the JTAG connection.
