NXP LPC2366

 NXP LPC2366

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.

 RE: NXP LPC2366

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.

 RE: NXP LPC2366

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 ?

 RE: NXP LPC2366

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.

 RE: NXP LPC2366

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 ?

 RE: NXP LPC2366

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

 RE: NXP LPC2366

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.

 RE: NXP LPC2366

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.