Help: Rowley CrossStudio & Wiggler Problem

Started by nw_mcu April 18, 2004
I'm evaluating Rowley's CrossStudio and am having serious problems.
I'm using the Olimex 2106 demo board and the Wiggler JTAG interface.
I'm new to the LPC devices and GCC but not MCUs in general.

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. The wiggler
sometimes needs to be power cycled as well, and a few times,
CrossStudio stopped responding for good and had to be shut down with
the task manager. NOT GOOD!

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.

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!

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.

It's almost as if, even when set to use flash, CrossStudio is still
telling the GCC linker to use RAM for some of the code? The
documentation isn't very clear on the CrossStudio-to-GCC interface.
The problem with CrossStudio timing out when trying to write the
flash is especially annoying as I usually have to power cycle the
board (wiggler) and start over.

Frankly, I'm not impressed with the way code is loaded into the LPC
parts. It's a bit of mess compared to other processors that have
much more direct (and bulletproof) programming interfaces.

Does anyone have any ideas or suggestions? This is really
frustrating! CrossStudio is priced right, and I otherwise like it so
far, so I hope I'm just doing something wrong?




An Engineer's Guide to the LPC2100 Series

--- In , "nw_mcu" <nw_mcu@y...> wrote:
> I'm evaluating Rowley's CrossStudio and am having serious problems.
> I'm using the Olimex 2106 demo board and the Wiggler JTAG
interface.
> I'm new to the LPC devices and GCC but not MCUs in general.
>
> The tools and board work mostly as expected when using RAM for the
> codespace. When using FLASH, however, several unexpected things are
> happening:

[tale of woe deleted] I've not had any problems programming the flash with the Rowley
software, apart from when the supply voltage was marginal due to flat
batteries (I usually use four NiMH cells for powering my boards).
This can be puzzling because loading into RAM can work OK with a
marginal supply. Have you tried a different power supply, yours might
be noisy or something like that? Or, the regulator on the Olimex
board might be misbehaving with the additional load for programming
the flash. Ideally, you could try swapping boards, but you presumably
only have the one.

Leon



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
 
 



--- In , "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.


--- In , "leon_heller" <leon_heller@h...>
wrote:
> This can be puzzling because loading into RAM can work
> OK with a marginal supply. Have you tried a different
> power supply, yours might be noisy or something like that?
> Or, the regulator on the Olimex board might be misbehaving
> with the additional load for programming the flash.

Thanks for the reply. I'm using a regulated bench power supply to
run the Olimex board (and Wiggler). To test your theory, I put a
scope on the 1.8v and 3.3v lines on the Olimex board while attempting
to write the flash and they're rock solid. The board uses 800ma
LM1117 regulators.

I seem to be having the same problem programming the flash as
Microbit. See my previous post for more info.

The problem with the PLL and clock speed is still a mystery.



Howdy,

> 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.

There is a prescaler !

Look at PLLCFG register.
If you for example are after 14.7 MHz * 4 = 58.8 MHz,
then you would set the Multiplier(M) to 4, and the presaler (P)
could for example be 2 - thus :
Fcco = Fosc * M * 2 * P = 14.7 * 4 * 2 * 2 = 235.2 MHz.
cclk = Fosc * M = 58.8 MHz.

If you now would want the M value to be only 1, then P would have
to be 4 times higher, ie. 8 - thus :
Fcco = Fosc * M * 2 * P = 14.7 * 1 * 8 * 2 = 235.2 MHz.
But cclk now is :
14.7 MHz * M = 14.7 MHz.

It sounds like the way you have it now, your PLL is incorrectly
programmed, the CCO is not capable of that low frequency, thus
the capture in range is not possible, _thus_ the PLL doesn't/can't lock.
The ref manual specifically states that you will yield unreliable operation.

Try setting the P and M values properly, and it should work properly then.
You need to change the "mov R1, # 0x24" instruction to change the prescaler
("divider") value.
For example, 0x25 sets P to 2 instead of etc.

-- Kris



> 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.

That's what I had to do.
For some mysterious reason, having it in bootloader mode
when loader.exe is downloaded into RAM, but then letting go
of P0.14 works fine.
Maybe wire in a pushbutton, just to work around it.
I had to wire nTRST to the reset pin (ie. NOT pull it up to Vcc).

> 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.

It works a treat with the Nohau/Seehau/Hitech C environment,
so it's not Philips' fault.
I suspect it's a marginal timing issue on CrossWorks.
Maybe Paul or Michael can shed some light there.
I do recall they use the loader like this because the TAP
needs to be reset or some such. > > 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?

Nope, the building and linking is fine.
I think this is because you're not setting P properly.
I set up the PLL in my sys_init() start code in C.
It's preferable not to depart from the vendors' default startup
code, it will bite you in the bum later.

> 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?

As above.

-- Kris



You shouldn't have any problems at all.
I am using the Olimex 2106-MT board together with CrossWorks and
everything works like a charm.I have tried compiling into all
different kind of targets and they all work perfectly. Mind you, i
have not messed around with the PLL yet, but i'm getting there.

Did you remove both the DEBUG and BSL jumper ?

The only snag i found was that the control pins to the LCD pins were
located on the ETM, so i can not debug my LCD driver. Bummer ;-)

Regards
/Pontus --- In , "microbit" <microbit@c...> wrote:
> > 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.
>
> That's what I had to do.
> For some mysterious reason, having it in bootloader mode
> when loader.exe is downloaded into RAM, but then letting go
> of P0.14 works fine.
> Maybe wire in a pushbutton, just to work around it.
> I had to wire nTRST to the reset pin (ie. NOT pull it up to Vcc).
>
> > 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.
>
> It works a treat with the Nohau/Seehau/Hitech C environment,
> so it's not Philips' fault.
> I suspect it's a marginal timing issue on CrossWorks.
> Maybe Paul or Michael can shed some light there.
> I do recall they use the loader like this because the TAP
> needs to be reset or some such. > > > 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?
>
> Nope, the building and linking is fine.
> I think this is because you're not setting P properly.
> I set up the PLL in my sys_init() start code in C.
> It's preferable not to depart from the vendors' default startup
> code, it will bite you in the bum later.
>
> > 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?
>
> As above.
>
> -- Kris





It's a marginal issue that shows on some machines I think.
I don't know whether it's the OS, or I/F or what, but I get the EXACT
same misbehaviours as nw_mcu gets.
For me, briefly holding P0.14 LOW when starting debug fixed it.

Of course the DBGSEL is set properly, it wouldn't work at all
otherwise !

-- Kris
----- Original Message -----
From: <>
To: <>
Sent: Monday, April 19, 2004 6:20 AM
Subject: [lpc2000] Re: Help: Rowley CrossStudio & Wiggler Problem > You shouldn't have any problems at all.
> I am using the Olimex 2106-MT board together with CrossWorks and
> everything works like a charm.I have tried compiling into all
> different kind of targets and they all work perfectly. Mind you, i
> have not messed around with the PLL yet, but i'm getting there.
>
> Did you remove both the DEBUG and BSL jumper ?
>
> The only snag i found was that the control pins to the LCD pins were
> located on the ETM, so i can not debug my LCD driver. Bummer ;-)
>
> Regards
> /Pontus > --- In , "microbit" <microbit@c...> wrote:
> > > 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.
> >
> > That's what I had to do.
> > For some mysterious reason, having it in bootloader mode
> > when loader.exe is downloaded into RAM, but then letting go
> > of P0.14 works fine.
> > Maybe wire in a pushbutton, just to work around it.
> > I had to wire nTRST to the reset pin (ie. NOT pull it up to Vcc).
> >
> > > 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.
> >
> > It works a treat with the Nohau/Seehau/Hitech C environment,
> > so it's not Philips' fault.
> > I suspect it's a marginal timing issue on CrossWorks.
> > Maybe Paul or Michael can shed some light there.
> > I do recall they use the loader like this because the TAP
> > needs to be reset or some such.
> >
> >
> > > > 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?
> >
> > Nope, the building and linking is fine.
> > I think this is because you're not setting P properly.
> > I set up the PLL in my sys_init() start code in C.
> > It's preferable not to depart from the vendors' default startup
> > code, it will bite you in the bum later.
> >
> > > 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?
> >
> > As above.
> >
> > -- Kris >
> --
------
> Yahoo! Groups Links
>
> a.. To




--- In , "microbit" <microbit@c...> wrote:

> Look at PLLCFG register.
> If you for example are after 14.7 MHz * 4 = 58.8 MHz,
> then you would set the Multiplier(M) to 4, and the presaler (P)
> could for example be 2 - thus :
> Fcco = Fosc * M * 2 * P = 14.7 * 4 * 2 * 2 = 235.2 MHz.
> cclk = Fosc * M = 58.8 MHz.

The demo code supplied by Rowley has P set to 1 and M set to 4
(PLLCFG = 0x24) in their example giving 59Mhz with a 14.7Mhz
crystal. This gives a Fcco of 117Mhz which should be illegal.

Second, the data sheet shows "P" is a 2 bit value (bits 5 and 6 of
PLLCFG) , yet it talks about values for P in the range of 2 - 16!
Which is it Philips?

Third, Toggling an I/O pin in a while(1) loop I get periods of:

PLL OFF: 1150ns (should be 14.7Mhz)
PLLCFG = 0x61 (P=3, M=1): 577ns (should be 14.7Mhz but is 29Mhz?)
PLLCFG = 0x21 (P=1, M=1): 577ns (as above)
PLLCFG = 0x42 (P=2, M=2): 384ns (Should be 29.4Mhz but is 44Mhz?)
PLLCFG = 0x43 (P=2, M=3): 288ns (Should be 44Mhz but is 59Mhz?)
PLLCFG = 0x44 (P=2, M=4): 231ns (Should be 59Mhz but is 73.5Mhz?)
PLLCFG = 0x23 (P=1, M=4): 231ns (as above)

The above numbers are running from RAM with VPBDIV = 1 (full speed
peripherals). Because of the way I/O works on the Philips parts, you
don't get a 1:1 correlation between clock rate and I/O speed but the
above still show something is wrong? What's going on here? > You need to change the "mov R1, # 0x24" instruction to
> change the prescaler ("divider") value.
> For example, 0x25 sets P to 2 instead of etc.

Not as I read the User Manual. 0x24 is P=1, M=4. 0x25 would be P=1,
M=5.