We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
We are using NXP LPC2366 (100 Pins) microprocessor in a project. The version of uVision is 3.60.
We have received new boards implementing the LPC2366 but we are not able to start the boards. A break point in the start up file (LPC2300.s) is never reached.
The power connections look good and we think we have a clock problem.
1)We decided to use the internal RC clock source (4.0 MHz) but the program never exits the following loop (PLL is not locked)
; Wait until PLL Locked PLL_Loop LDR R3, [R0, #PLLSTAT_OFS] ANDS R3, R3, #PLLSTAT_PLOCK BEQ PLL_Loop
The LPC2300.s file is configured with the following parameters :
CLOCK_SETUP EQU 1 SCS_Val EQU 0x00000000 ; no main osc CLKSRCSEL_Val EQU 0x00000000 PLLCFG_Val EQU 0x00000023 ; N=1 M=35 CCLKCFG_Val EQU 0x00000004 USBCLKCFG_Val EQU 0x00000005 PCLKSEL0_Val EQU 0x00001000 PCLKSEL1_Val EQU 0x00000000
Any suggestion would be appreciated.
2) We are working on the boot process flowchart of the NXP component. We would like to understand why the Ulink2 debugger can't stop in the LPC2300.s file. Could you describe us the steps performed by the controller before the startup process ? How can we check that ?
Thanks for your assistance.
Are these two threads related?
http://www.keil.com/forum/docs/thread13623.asp
Most of the controller actions before reaching the startup file are not documented. They happen in the boot loader written by NXP.
They will check-sum the interrupt vector table to see if any application has been downloaded.
If not, they will wait for an application on the serial interface.
If an application is found, they will check the current protection mode, and if it is allowed to manually request it to enter the software download mode, or if it should start the found application.
The actual detals will require that you contact NXP.
If this thread is related to the linked thread, then I would suggest that you try to synchronize your requests.
Yes, we are working on the same development project.
To reply to your questions, we are using configuration wizard to set the MSEL and NSEL values only. The clock divider is set to 5 (CCLKCFG_Val), the main oscillator is disabled (SCS_Val) and the source clock selected is Internal RC (CLKSRC) as described below :
CLOCK_SETUP EQU 1 SCS_Val EQU 0x00000000 CLKSRCSEL_Val EQU 0x00000000 PLLCFG_Val EQU 0x00000023 ; M=35 N=1 CCLKCFG_Val EQU 0x00000004 ; clock divider USBCLKCFG_Val EQU 0x00000005 PCLKSEL0_Val EQU 0x00001000 PCLKSEL1_Val EQU 0x00000000
Do you know why the PLLC and PLOCK bit of PLL status register is not set ? Have you ever heard a problem like this ?
Alas, I have too little time to look closer at the above values, or test them myself.
The most common reasons for a PLL to fail to lock are: - missing input clock, or clock frequency outside supported range. The internal RC should be within supported range. - input clock is drifting too fast for the PLL to lock or track. - configured PLL multiply/divide outside range, resulting in a frequency outside the PLL operating range. In this case, your parameters should be within range.
In this case, the RC oscillator really must work, or the processor would not be able to run the startup file. But it is hard to verify if it is stable.
There seems to be one known issue somehwere with the internal RC oscillator and the built-in boot loader. Some chips fails to perform firmware download, claiming to fail auto-baud. But when manually sending the auto-baud character, the processor do respond.
NXP claims that a newer firmware will fix this issue. But NXP has not informed about exactly what the problem is. It might be that the RC oscillator on some chips have too large frequency error, so their auto-baud produces a baudrate that they reject in the boot-loader software.
Do you have any other board to test with? Or you may possibly try to run with the PLL turned off and emit a pulse on a processor pin and verify with a frequency counter or a bettery oscilloscope if the RC oscillator may be too much off from 4MHz.
Hi,
You wrote : They will check-sum the interrupt vector table to see if any application has been downloaded.
How can we check the result of the interrupt vector table checksum ? we want to verify that the code is valid or considered as valid in the user flash. We don't change the software code and this software is running correctly on previous boards.
The actual details will require that you contact NXP.
Could you give us a direct contact ?
Do you have any other board to test with? Or you may possibly try to run ... or a better oscilloscope if the RC oscillator may be too much off from 4MHz.
Yes, the components with date code 08 07 B work but components with Date code 07 41 BY and 08 25B fail !
For us, we can't measure the 4MHz internal frequency. Can we? How ?