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.
Hello Stephane Ibazizene,
1) The Clock settings work fine on my Keil MCB2300 with the Blinky Project.
2) To step through LPC2300.s during debug session open Options for Target - Debug and uncheck Run to main()
Best Regards, Martin Guenther
The Keil tools will produce a correct checksum of the interrupt vector table.
Your program will not start, unless there is a correct checksum - the sum of the full interrupt vector table should be zero. There is one unused entry in the table, and the Keil tools will fill this unused entry with the required value.
Contact the national NXP support center or call through the company where you buy the chips.
If the date code matters, then that is a strong suggestion that there may be a problem with the RC oscillator in some batches. Definitely contact NXP!
How to test the 4MHz oscillator? Create a trivial program that runs without the PLL and sets up a timer to control an output pin. Measure the output frequency. If you configure the chip to produce a 1Hz signal, and you measure 0.9Hz or 1.1Hz on the output, then you know that something is wrong with the RC oscillator. I don't know exactly how much frequency errors that are expected, but at least not so much that the PLL doesn't work as expected.
If you measure 2Hz, then it is more likely that the error is in your code :)
And if you have a "good" and a "bad" board - compare the generated frequencies from both boards. And _please_ report back with the result. It is likely that more people may be affected by this problem. For me, I have just seen indications that 5-10% of some batches can't work with some high-speed serial software download settings.
We have generated a new µVision project and the controller is able to execute the user code. At the beginning, we thought that the problem comes from the LPC2300.s file. The start-up file generated by the new project is different compared to the old one. But, if we replace the new LPC2300.s file by the old one into the new project environment, the program starts. We don't understand this behaviour, could you assist us to determine what is the real problem ? Thanks.