Hi,

 

At one stage I had problems with the Seehau environment and

UART circular buffers, and I ran a sanity check with CrossStudio.

Some of the problems you are seeing were experienced by me as well :

 

First of all, what are you doing with nTRST ?

 

> The tools and board work mostly as expected when using RAM for the
> codespace. When using FLASH, however, several unexpected things are
> happening:
>
> 1 - CrossStudio always successfully writes the Loader and erases the
> flash but usually fails with various timeout errors when it tries to
> write the code to the erased flash.  Once in a while it will work. 
> I've tried both ECP and EPP settings for the parallel port and
> various settings in CrossStudio with no change.  The 2106 is also
> hung up when this happens and needs to be reset.

 

( 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, but this way it worked for me

every time in Flash.

RAM wasn't a problem.

 

> 2 - When I can manage to write the code to flash, the startup code
> doesn't seem to be linked correctly. I can change the PLLCFG
> multiplier from 0x24 (4X) to 0x21 (1X) and the chip still runs at 59
> Mhz.  I'm importing the assembly startup file into CrossStudio as
> specified in the docs, and it assembles just fine.  I'm new to this
> toolchain so I'm not sure where to look?  I can't even figure out how
> to tell the linker to generate a list file in CrossStudio?  This
> happens with the demo projects and when I start a new project from
> scratch.

Do you maybe disable the PLL here after recompiling ?

Most likely the Flash download "looks" succesful, but it's not.

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.

If the LPC2106 has not been completely powered down, RAM still holds

the PLL enabled mult settings, and you won't be able to leave the 59 MHz clock,

unless your - now new linked code - *explicitly* uses the password sequence

and turns the PLL *OFF* (or changes 4X to 1 X).

Finally, if you set the PLL for 1X, chances are that the CCO isn't within its proper

specified freq range anymore !

 

> 3 - Things get even more strange. When I can write to flash, my code
> runs at 59mhz as outlined above (no matter what I set the PLL to). 
> If I disconnect the wiggler and reset the board, the clock rate drops
> down to 1X (14.7 Mhz)!  Again, this is true no matter what the PLL is
> actually set to in the startup file!

Similar reason to above, the Flash download is being screwed up.

 
> I've verified the above problems are not related to the memory
> accelerator (which is disabled in all cases) or MAMTIM (flash wait
> states).  Those things work normally when I change them in the main
> code.

Yes, have nothing to do with it.

 

I'm not sure if the above will help, but when I tried similar things to

what you are doing, 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.

Fiddling with the bootloader signature in the vector table from the startup code didn't seem to

help either.....

To verify you have the same problem, use the Philips ISP utility first, erase the part,

and then do your Flash download thru JTAG.

Do this sequence a couple of times, and if you find that the Flash programming always works,

you have the same issue that I had.

The reason for it, I'lll be buggered if I know.

 

-- Kris

 

 

> As I said earlier, it's possible I somehow have a bad part, so if
> someone else could confirm this, that would be helpful?  If what I've
> measured is generally true, the Philips data is wrong and that's
> really disturbing for such a critical parameter.  The power
> consumption listed is also wrong (30ma at 60Mhz is really 44ma but
> that's already been discussed).  At 75Mhz, my 2106 draws 58ma.

The Philips data is correct, I've used the timers enough with different

PLL settings, and the figures were always correct.

As Robert pointed out, at that phase of testing you most likely had

your Fcco out of its range.

 

Think of the cco as a VCO in a PLL.

The VCO has a particular range, and if you eg. divide the VCO output

by 10, and feed that into a phase comparator, with eg a 10 MHz reference

then - if VCO is capable of that - the PLL will phase lock it to 100 MHz.

(This is presuming that the loopfilter is correct, damping factor, VCO gain,

phase margin etc are all appropriate of coyrse).

If you were to set the divider in this example for 20, and the VCO can only

tune up to, say, 130 MHz, then the PLL will remain unlocked, and the VCO will

be free running at around ~ 130 MHz.

 

Something similar to that is happening on the LPC2106, but I suspect that the

high integration of cco and PLL + dividers causes it to go apeshit when you incorrectly

program it, which is a fair equation.

 

B rgds

Kris