|
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? |
|
|
Help: Rowley CrossStudio & Wiggler Problem
Started by ●April 17, 2004
Reply by ●April 17, 20042004-04-17
|
--- 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 |
|
|
Reply by ●April 18, 20042004-04-18
|
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
|
|
|
Reply by ●April 18, 20042004-04-18
|
--- 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. |
Reply by ●April 18, 20042004-04-18
|
--- 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. |
Reply by ●April 18, 20042004-04-18
|
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 |
|
|
Reply by ●April 18, 20042004-04-18
|
> 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 |
|
|
Reply by ●April 18, 20042004-04-18
|
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 |
|
|
Reply by ●April 18, 20042004-04-18
|
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 |
Reply by ●April 18, 20042004-04-18
|
--- 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. |
|
|
