LPC1313 locks up waiting for SYSPLL (IAR/J-Link toolchain)

[Hankers]

[SOLVED] LPC1313 locks up waiting for SYSPLL (IAR/J-Link toolchain)

I am hoping that someone finds this problem familiar.

During startup and using an unmodified SystemInit() function in system_LPC13xx.c ...

#if (SYSPLL_SETUP) /* System PLL Setup */
LPC_SYSCON->SYSPLLCTRL = SYSPLLCTRL_Val;
LPC_SYSCON->PDRUNCFG &= ~(1 << 7); /* Power-up SYSPLL */
while (!(LPC_SYSCON->SYSPLLSTAT & 0x01)); /* Wait Until PLL Locked */
#endif

My program is stuck on the instructions while (!(LPC_SYSCON->SYSPLLSTAT & 0x01))
Checking the assembly code and addresses, doesn't show anything incorrect. The PLL just doesn't indicate Sync'd and Locked.

History:

Both the software and hardware previously worked, but not after I had some tool chain upgrades. The problem also occurs with the IAR/CMSIS example projects for the LPC13xx. The problem is transferred to hardware units not involved in the segger/olimex battle.

This all worked under IAR 5.3x running an Olimex JTAG-USB-EW and the Olimex version of dll.
Problems started when I upgraded IAR to 6.20, and tried to upgrade the Olimex. This eventually only worked 'sort-of' at IAR v6.10

I eventually ended up getting a Segger J-Link EDU programmer, and re-installing IAR 6.20.
Which is where I am now. IAR-6.20 ide and Segger J-Link EDU with the latest firmware and dll.
(I also tried IAR-5.50 + Segger J-LINK, no difference)

At this time I suspect IDE, library initialization, nxp1313 bootloader or configuration bit issues, or J-Link issues.

Other problems addressed and considered :
- IAR would lose Target Processor Variant (among other things) when switching backwards from v6.20 to v5.50
- Address ranges as defined for the linker (generic_cortex.ICF) for cortex didn't match the lpc1313, this prevents the linker from detecting address allocation errors.
- Same file has the stack and heap sizes. Changing these didn't make a difference, but then again, 'C'/'C++' hasn't started up either so I don't think either of the stack or heap is valid yet.

The program runs from on-board flash. The SystemInit() function is the first function called from Reset_Handler

I added code to turn off one of my LEDS before the instruction and another one after the instruction. The LEDs operated properly, so I know I am looking at the right code. The code behaves identically using connected JTAG power and unconnected battery power, so the problem is programmed into the part.

Does anyone have an idea where to look next?

 

[Hankers]

One of the delivered settings in System_LPC13xx.c is to start up the System Oscillator. On the board there is no crystal attached so the system oscillator likely was doing something bad which affected the SYSPLL.

My solution is pull out the code I need to my own file (that won't get stomped on in an upgrade) and not power SYSOSC.

 

[bigdogguru]

Check your #defines in "system_LPC13xx.c".:

//#define SYSPLLCLKSEL_Val 0x00000001 // This sets to use external crystal for clock source for PLL
#define SYSPLLCLKSEL_Val 0x00000000 // Set PLL input to internal RC oscillator

You need to make the appropriate #define depending on whether you are using an external crystal or the internal RC OSC.

BigDog

 

[Hankers]

Thanks man. That's what I ended up doing to find and fix the problem.

The file seems to belong to the NXP CodeRed group and the risk is that every time I upgrade I inherit settings that work for somebody else.

My final solution is to move the code onto my board.c file and leave it there. .

---------- Post added at 10:16 ---------- Previous post was at 10:13 ----------

BTW there is a bug in the CMSIS file. The code has SYSPLL options nested inside the SYSOSC section. It needs to be separated out.

---------- Post added at 10:17 ---------- Previous post was at 10:16 ----------

BTW there is a bug in the CMSIS file. The code has SYSPLL options nested inside the SYSOSC section. It needs to be separated out.