Lpc2000

--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> 
> First of all, what are you doing with nTRST ?

nTRST is connected to the 20 pin JTAG header on the Olimex 
board. I have no idea what the Wiggler does with it as I 
don't have a schematic for the Wiggler.  CrossStudio does 
have the option of performing a reset through the JTAG 
interface.  

 
> ( I did this is with a Nohau tester board)
> Provide for a button that selects bootloader mode on reset
> (ie. P0.14 must be pulled LOW on reset).
>
> When you start the debug - PRESS the bootloader button while 
> the loader code is being downlloaded. (ie. hold P0.14 LOW)
> Then release the button (P0.14 high again) BEFORE the actual 
> Flash app code is downloaded. You should find your Flash 
> download works everytime.
> I have NO idea why this has to be like that

That would be hard to do with CrossStudio because it writes 
the loader and code back-to-back.  To make things more 
difficult, the Olimex board has a jumper rather than a switch 
for that function.

If that's really the way the chip works, Philips should be 
ashamed of themselves!  As I said in my previous message, 
I'm NOT impressed with the way the LPC parts are programmed.  
It's a poor design especially for debugging and high-speed 
production programming.

 
> Do you maybe disable the PLL here after recompiling ?
> Most likely the Flash download "looks" succesful, but it's not.

That's what I suspect is going on.  That part of the code is 
still living in RAM even after you tell it to use FLASH.  
This seems to be a bug in the way CrossStudio is building the 
make (and/or other) file(s) for the linker?


> Keep in mind that to disable the PLL (or change multiplier),
> when your last succesful download enabled it - you must ALSO 
> use the password sequence to _actually_ DISable the PLL.

Yes, the startup code executes the magic sequence after 
establishing the PLL settings.  The PLL should be properly 
initialized EVERY time the chip is reset.  I don't understand 
how the startup code is only executed sometimes, or perhaps 
there are two different copies of it (one in RAM and one in 
FLASH)?  Again, this seems like a bug in how the code is built?


> Finally, if you set the PLL for 1X, chances are that the CCO isn't 
> within its proper specified freq range anymore !

This I don't understand.  The spec says:

"The input frequency is multiplied up into the range 
of 10 MHz to 60 MHz with a Current Controlled Oscillator 
(CCO). The multiplier can be an integer value from 1 to 32 
(in practice, the multiplier value cannot be higher than 6 
on the LPC2106/2105/2104 due to the upper frequency limit 
of the CPU). The CCO operates in the range of 156 MHz to 
320 MHz, so there is an additional divider in the loop to 
keep the CCO within its frequency range while the PLL is 
providing the desired output frequency."

If you mean that 14.7Mhz * 1 is less than 156 Mhz, you're 
correct.  But so is 14.7Mhz * 4!  How are you supposed to 
get to 156Mhz if the multiplier cannot be greater than 6 
(see above)?  14.7Mhz * 1 is in the range of 10Mhz to 60Mhz.


> I initially got EXACTLY the same results. The only time you 
> will find that the loader/app code Flash programming will 
> work is with a blank LPC2106....
> ...The reason for it, I'll be buggered if I know.

You're correct.  If I erase the part with the Philips ISP 
utility it always will load correctly from CrossStudio.  
Interestingly, selecting the "erase all" function in 
CrossStudio doesn't seem to solve the problem although it 
does seem to help in some cases.

Is this REALLY the only way the chip works?  Or is there 
something wrong with the CrossStudio/Wiggler/Olimex 
implementation?

The final target LPC2XXX for this application will not have 
a lot of RAM and the code will have to reside in FLASH.  If 
it's going to be a big hassle to debug the application in 
FLASH, I think I'll start looking at other ARM7 parts (like 
STM and OKI) or at least better tools for the Philips parts.