> I also have the same timeout errors with an Olimex LPC-P1 board and > the Olimex JTAG cable using CrossStudio Eval. > > I tried with different PC configuration (PII and PIII, Win2K and XP, > ECP and EPP parallel port) but I gave up and I am using the RAM > configuration for the moment. > > HAO Hi, As I had mentioned before, if you're able to briefly assert P0.14 LOW while you start the debug (ie. while loader.exe is programming), then that will solve the problem, I'm quite sure. I have NO idea why this should be. I've reported this erroneous condition to Rowley Asscs ages ago, but they weren't able to reproduce the problem I think. I run on WIN98SE, so it's good to see that the good old "it's because you're running 98SE" argument indeed is irrelevant, since the problem is observed on the _magic_ XP as well :-) In my situation I used a homebrew "wiggler" I quickly banged together on some veroboard for the test. -- Kris |
Help: Rowley CrossStudio & Wiggler Problem
Started by ●April 17, 2004
Reply by ●April 18, 20042004-04-18
Reply by ●April 18, 20042004-04-18
At 12:04 AM 4/19/04 +0000, you wrote: >--- In , "nw_mcu" <nw_mcu@y...> wrote: > >OK, I've now confirmed the PLL problem! With my 2106, I get the >following results: I thought I'd repeat the calculation for the rest of your results. >PLL OFF: 1150ns (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) I get Fcco of 235.2 MHz (in range), and cclk of 29.4 MHz >PLLCFG = 0x42 (P=2, M=2): 384ns (Should be 29.4Mhz but is 44Mhz) Fcco = 352.8 MHz (out of range), cclk 44.1 MHz >PLLCFG = 0x43 (P=2, M=3): 288ns (Should be 44Mhz but is 59Mhz) Fcco = 470.4 MHz (out of range), cclk = 58.8 MHz >PLLCFG = 0x44 (P=2, M=4): 231ns (Should be 59Mhz but is 73.5Mhz) Fcco = 588 MHz (way out of range), cclk = 73.5 MHz >PLLCFG = 0x24 (P=1, M=4): 231ns (as above) Fcco = 294 MHz (out of range), cclk = 73.5 MHz Apparently there is a fair amount of margin in the PLL specs since it still seems to work even when Fcco is >2x the max. Of course there's always the peripheral side effects to worry about. However, the expected clock frequency matches the measured frequency in all cases. Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " Kelvin Throop, III |
Reply by ●April 19, 20042004-04-19
--- In , Robert Adsett <subscriptions@a...> wrote: > >PLLCFG = 0x61 (P=3, M=1): 577ns (should be 14.7Mhz but is 29Mhz) > > Ah, I see what's happening, I should have clued in earlier > > PlLLCFG of 61 gives PSEL of 3, MSEL of 1 > > That gives a P of 8 and and M of 2 Call me embarrassed! Thanks everyone for your help on this. I totally missed the lookup tables that translate the bits for the P and M values. Things make much more sense now! The CrossWorks startup code contains these lines: /* Configure PLL Multiplier/Divider */ mov r1, #0x24 /* multipler = 4, divider = 1 */ I both assumed the values were chosen for a 14.7 Mhz crystal as this is the frequency found on most demo boards (for serial port reasons) and I also read the comment as M = 4 and P = 1. In reality, those are just the raw bit values MSEL and PSEL and they get translated into M = 5 and P = 2 by the magic tables. I and others still seem to be stuck with the flash loading problem, but at least the PLL is working right now! Progress! Thanks again to all. |
Reply by ●April 19, 20042004-04-19
Firstly, are you using the latest 1.2 RC release (http://www.rowley.co.uk/arm/arm_1_2_0.zip)? This version has improved LPC2000 support. It sounds like you are having reliability problems with the Wiggler/JTAG connection. Try the following: 1. Turn on automatic load verification (Tools | Option | Target | General | Enable Load Vericiation) so you can tell if the program in memory matches the executable file. 2. Reduce the JTAG clock frequency (increase the JTAG Clock Divider target property). 3. If your still having problems, reduce the length of your parallel port cable as much as possible (I personally always plug the Wiggler directly into the back of the PC). Regards, Jon Elliott Rowley Associates --- 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: > > 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? |
Reply by ●April 19, 20042004-04-19
If you have access to the ISP UART it's possible to download and
execute a program in RAM that turns on the secondary JTAG port. The enabling of the pins appears to survive a reset so this only has to be done on power up. Some of our customers are using this with CrossWorks to program the flash and debug without losing too many IO lines. Regards Michael > Date: Sun, 18 Apr 2004 20:20:38 -0000 > From: >Subject: 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 |
Reply by ●April 19, 20042004-04-19
> 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. Try View | Symbol Browser Regards Michael |
Reply by ●April 19, 20042004-04-19
Message: 1 Date: Mon, 19 Apr 2004 12:10:03 +1000 From: "microbit" <> Subject: Re: Re: Help: Rowley CrossStudio & Wiggler Problem Kris/HAO As Jon suggested - try the 1.2 version. We've added a lot more initialisation to the reset script to try to get something that resembles a reset on the LPC2000. Regards Michael TargetInterface.setNSRST(0); TargetInterface.setNSRST(1); TargetInterface.delay(100); TargetInterface.trst(); TargetInterface.setICEBreakerBreakpoint(0, 0x00000000, 0xFFFFFFFF, 0x00000000, 0xFFFFFFFF, 0x100, 0xF7); TargetInterface.waitForDebugState(1000); TargetInterface.getICEBreakerRegister(5); /* Clear out Debug Comms Data */ TargetInterface.pokeWord(0xE0000000, 0); /* Reset Watchdog */ TargetInterface.pokeWord(0xE0028008, 0); /* Reset IODIR */ TargetInterface.pokeWord(0xE002C000, 0); /* Reset PINSEL0 */ TargetInterface.pokeWord(0xE01FC000, 0); /* Reset MAMCR */ TargetInterface.pokeWord(0xE01FC080, 0); /* Reset PLL */ TargetInterface.pokeWord(0xE01FC08C, 0xAA); /* Feed PLL */ TargetInterface.pokeWord(0xE01FC08C, 0x55); /* Feed PLL */ TargetInterface.pokeWord(0xFFFFF014, 0xFFFFFFFF); /* Disable all interrupts */ TargetInterface.setICEBreakerBreakpoint(0, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x000, 0x00); > I also have the same timeout errors with an Olimex LPC-P1 board and > the Olimex JTAG cable using CrossStudio Eval. > > I tried with different PC configuration (PII and PIII, Win2K and XP, > ECP and EPP parallel port) but I gave up and I am using the RAM > configuration for the moment. > > HAO Hi, As I had mentioned before, if you're able to briefly assert P0.14 LOW while you start the debug (ie. while loader.exe is programming), then that will solve the problem, I'm quite sure. I have NO idea why this should be. I've reported this erroneous condition to Rowley Asscs ages ago, but they weren't able to reproduce the problem I think. I run on WIN98SE, so it's good to see that the good old "it's because you're running 98SE" argument indeed is irrelevant, since the problem is observed on the _magic_ XP as well :-) In my situation I used a homebrew "wiggler" I quickly banged together on some veroboard for the test. -- Kris |
Reply by ●April 19, 20042004-04-19
Thanks Michael. Was this around just recently ? I only saw 1.1.4 ? -- Kris ----- Original Message ----- From: "Michael Johnson" <> To: <> Sent: Tuesday, April 20, 2004 4:14 AM Subject: [lpc2000] Re: Re: Help: Rowley CrossStudio & Wiggler Problem > Message: 1 > Date: Mon, 19 Apr 2004 12:10:03 +1000 > From: "microbit" <> > Subject: Re: Re: Help: Rowley CrossStudio & Wiggler Problem > > Kris/HAO > > As Jon suggested - try the 1.2 version. We've added a lot more > initialisation to the reset script to try to get something that > resembles a reset on the LPC2000. > > Regards > Michael |
|
Reply by ●April 19, 20042004-04-19
--- In , "microbit" <microbit@c...> wrote: > Thanks Michael. > Was this around just recently ? I only saw 1.1.4 ? Scroll down the page. It's at the bottom. Leon |
Reply by ●April 19, 20042004-04-19
> --- In , "microbit" <microbit@c...> wrote: > > Thanks Michael. > > Was this around just recently ? I only saw 1.1.4 ? > > Scroll down the page. It's at the bottom. > > Leon Thanks Leon, I didn't see it - the home page only mentioned V1.1. Found it at bottom of DL page, getting hardly 0.6 Kb/s though :-) Is the server cooking ? heh. 73s Kris |