PLL0USB LPC4337 locked on reset

[jean-marcrouxel]

Hello,

I've a LPC4337 on my board,

(My development's tool is the MDK from KEIL-ARM and I already opened a case on the ARM support, but without answer for the moment).

I compile my program with the -Ofast optimization.

I have the following problem : sometimes, in the SetClock() function in the system_LPC43xx.c file, the program stopped on the following line : while (!(LPC_CGU->PLL0USB_STAT & 1));

=> it means that the PLL is never locked

But, if i compile my program with no optimization (-O0), I don't have this problem anymore.

Any ideas ?

Regards,

Jean-Marc Rouxel

[DanielRuvalcaba]

Hello

If the application works fine when applying minimal optimizations -O0, probably the compiler is having problems optimizing the code.

What about if you use another kind of optimization that can work with your application? Or if it’s not strictly necessary, do not use any?

Sometimes, optimizations can cause weird behaviors in applications where there isn’t a proper use of the volatile qualifier, such as in functions or variables.  

I hope this helps, Daniel.

[jean-marcrouxel]

Here is the reply of my ARM Support, who succeeded to reproduce the problem :

"I can sort of reproduce this with the Blinky project for our MCB4300 with LPC4357, when pressing Reset while the program is running. It sometimes hangs then on the PLL0USB lock loop, or also ends in a hardfault.
Not sure what goes wrong there. But when it hangs, strange values appear in the PLL0USB_CTRL and/or PLL0USB_MDIV registers. When stopping the program, manually disable the PLL0 (set PLL0USB_CTRL PD bit), set values from successful runs in PLL0USB_MDIV and/or PLL0USB_CTRL and enable the PLL0 again, it locks and the program continues.
So, not sure if there are some timing constraints when accessing these registers.
Or maybe a problem is, that for this chip VECTRESET is the default, that does not reset the peripherals. And when the configuration runs it gives corner cases with what was configured at the last run.
I have no solution for this for now. I think the executed code should always be the same unless fetching instructions does not work correct or something like this.
Maybe you can also check with NXP, if they can explain that?
"