Hi,
sorry I know the Title sounds like a really trivial problem, but I tried
everything I could find on the net, and now I'm a little clueless.
A while ago I designed a little board with a LPC2138FBD64/01; The schematic was
based upon an olimex dev board with LPC2138
(http://www.olimex.com/dev/pdf/ARM/LPC/LPC-MT-2138%20-%20schematic.pdf).
I managed to establish a JTAG-connection using the bus pirate and openOCD; with
which I was able to flash an image which was - not working at all, namly the
GPIOs were not toggling.
I then connected to UART0 and tried to connect to the ISP bootloader, which was
a success. I was able to download the hexfile both with FlashMagic and the
LPC2000 flash utility, version 2.2.3.
(I checkt for the vector checksum with the flash utility, which read back
correctly.)
I then thought it might be the code and switched from my yagarto-compiler
(arm-none-eabi) to Keil's µVision IDE / Devsuite and generated a
Project with the LPC2138/01. It compiled with no errors but the same problem
with the keil-image: It won't run at all.
I checked the following things:
- Supply voltage: Stable at 3,3V
- RESET: 10k pullup to VCC
- RTCK: 4k7 pulldown to GND, to enable debug mode (tried also reset with RTCK
high; no solution here)
- P0.14: 4k7 to VCC (GND until reset for ISP, reset with high value does not
help)
- Oscillator: Oscillating at the nominal 20MHz (checked with scope)
I don't know where the problem could be... not anymore.
Here is the VPBDIV and PLL part of the (adapted) Keil startup file:
And here the C-File:
You can find a zip of the complete Keil project in this thread:
http://www.mikrocontroller.net/topic/212861#2117483
I hope you can help me.
Thanks in advance,
Tobi
LPC2138/01 won't run program
Started by ●March 24, 2011
Reply by ●March 24, 20112011-03-24
Am 24.03.2011 20:11, schrieb Chutiman Yongprapat:
>
> So sorry,
>
> 10MHz input need M=6 and P=2 (that's PLLCFG_Val =0x23)
> Now you have 20MHz, so you need M=3
> So your PLLCFG_Val should be 0x22.
>
> Here FCCO x3x2x2$0 MHz (within range)
> CCLK$0/(2x2)` MHz
> The correct is...
> 10MHz input need M=6 and P=2 (that's PLLCFG_Val =0x25)
> Now you have 20MHz, so you need M=3
> So your PLLCFG_Val should be 0x22.
> Here FCCO x3x2x2$0 MHz (within range)
> CCLK$0/(2x2)` MHz
> Best Regards,
> Chutiman Yongprapat
> E-mail: c...@thaieasyelec.com <mailto:c...@thaieasyelec.com
I tried as you said and put into the startup-script
PLLCFG_Val EQU 0x00000022
I disconnected it; I powercycled it, I reset it manually - Nothing.
Same procedure as above, with disabled debug mode: same result.
This thing drives me crazy.
The only thing I find to be interesting is the values of the XTAL-Pins;
>-> XTAL1 : Vmax 1V, Vmin 720mV, Amplitude316,8mV
>-> XTAL2 : Vmax 1,18V, Vmin 730mV, Amplitude 440mV
Are they whithin limits? (I thereby found that my scope miscalculates
the amplitute voltage)
>
> So sorry,
>
> 10MHz input need M=6 and P=2 (that's PLLCFG_Val =0x23)
> Now you have 20MHz, so you need M=3
> So your PLLCFG_Val should be 0x22.
>
> Here FCCO x3x2x2$0 MHz (within range)
> CCLK$0/(2x2)` MHz
> The correct is...
> 10MHz input need M=6 and P=2 (that's PLLCFG_Val =0x25)
> Now you have 20MHz, so you need M=3
> So your PLLCFG_Val should be 0x22.
> Here FCCO x3x2x2$0 MHz (within range)
> CCLK$0/(2x2)` MHz
> Best Regards,
> Chutiman Yongprapat
> E-mail: c...@thaieasyelec.com <mailto:c...@thaieasyelec.com
I tried as you said and put into the startup-script
PLLCFG_Val EQU 0x00000022
I disconnected it; I powercycled it, I reset it manually - Nothing.
Same procedure as above, with disabled debug mode: same result.
This thing drives me crazy.
The only thing I find to be interesting is the values of the XTAL-Pins;
>-> XTAL1 : Vmax 1V, Vmin 720mV, Amplitude316,8mV
>-> XTAL2 : Vmax 1,18V, Vmin 730mV, Amplitude 440mV
Are they whithin limits? (I thereby found that my scope miscalculates
the amplitute voltage)
Reply by ●March 24, 20112011-03-24
So sorry,
> 10MHz input need M=6 and P=2 (that's PLLCFG_Val =0x23)
> Now you have 20MHz, so you need M=3
> So your PLLCFG_Val should be 0x22.
>
> Here FCCO x3x2x2$0 MHz (within range)
> CCLK$0/(2x2)` MHz
>
The correct is...
10MHz input need M=6 and P=2 (that's PLLCFG_Val =0x25)
Now you have 20MHz, so you need M=3
So your PLLCFG_Val should be 0x22.
Here FCCO x3x2x2$0 MHz (within range)
CCLK$0/(2x2)` MHz
Best Regards,
Chutiman Yongprapat
E-mail: c...@thaieasyelec.com
> 10MHz input need M=6 and P=2 (that's PLLCFG_Val =0x23)
> Now you have 20MHz, so you need M=3
> So your PLLCFG_Val should be 0x22.
>
> Here FCCO x3x2x2$0 MHz (within range)
> CCLK$0/(2x2)` MHz
>
The correct is...
10MHz input need M=6 and P=2 (that's PLLCFG_Val =0x25)
Now you have 20MHz, so you need M=3
So your PLLCFG_Val should be 0x22.
Here FCCO x3x2x2$0 MHz (within range)
CCLK$0/(2x2)` MHz
Best Regards,
Chutiman Yongprapat
E-mail: c...@thaieasyelec.com
Reply by ●March 24, 20112011-03-24
Maybe it's worth noting that YOUR .hex file doesn't have the next to
the last line of code that mine has:
:0400000500000120D6
That 05 record type is used to set an EIP register in the 80xxx processors and I have no idea what it is used for in the ARM context. However, the data field is 0x00000120 which is the address of __main and that IS important to know.
Are you sure you changed to project properties as I suggested?
Richard
:0400000500000120D6
That 05 record type is used to set an EIP register in the 80xxx processors and I have no idea what it is used for in the ARM context. However, the data field is 0x00000120 which is the address of __main and that IS important to know.
Are you sure you changed to project properties as I suggested?
Richard
Reply by ●March 24, 20112011-03-24
Have you check the PLLCFG_Val? Olimex's board use 14.7456MHz but as you
said
that you're using 20MHz. The frequency after the PLL may be too much and it
won't run.
Best Regards,
Chutiman Yongprapat
E-mail: c...@thaieasyelec.com
that you're using 20MHz. The frequency after the PLL may be too much and it
won't run.
Best Regards,
Chutiman Yongprapat
E-mail: c...@thaieasyelec.com
Reply by ●March 24, 20112011-03-24
--- In l..., Tobias Schlegel wrote:
>
> okay. Your hex file doesn't work on my circuit either.
>
And yet your uC is working well enough to allow it to be programmed. I have forgotten: are you using ISP or JTAG?
As JTAG provides a clock, maybe the CPU can be brain dead and still accept a program into flash. That information is above my pay grade.
For ISP, the CPU absolutely has to be working. All day I have been using ISP - another reason I want to get back to CrossWorks. JTAG is MUCH nicer.
Richard
>
> okay. Your hex file doesn't work on my circuit either.
>
And yet your uC is working well enough to allow it to be programmed. I have forgotten: are you using ISP or JTAG?
As JTAG provides a clock, maybe the CPU can be brain dead and still accept a program into flash. That information is above my pay grade.
For ISP, the CPU absolutely has to be working. All day I have been using ISP - another reason I want to get back to CrossWorks. JTAG is MUCH nicer.
Richard
Reply by ●March 24, 20112011-03-24
OK, ISP works so the CPU works, the oscillator is between 10 and 25 MHz and
autobaud works. In effect, everything works except your code.
Are you certain your ISP programming software is inserting the checksum into the vectors area? If it doesn't, the uC will ALWAYS go to the bootloader code because the image is not considered to be valid.
Some programming software have this as a selectable option, others just do it anyway. lpc21isp does it by default.
I have uploaded lpc21isp.exe to the Files folder. Put it anywhere on your computer. Then, inside uVision, go to Project->Options For Target 'Target 1'->Utilities tab and click on 'Use External Tool for Flash Programming'. Use the browse button to find the executable (Command) and add this line for 'Arguments':
"#H" \\.\COM15 38400 12000
That bizarre \\.\COM15 nonsense is only required if the COM port is > 4. If your port is <= 4, just specify it directly as COMx.
Now you can use the Download button on the IDE to do the flash programming. You can also use Flash->Download. I messed around with the IDE until I got F12 to do the same thing.
Richard
Are you certain your ISP programming software is inserting the checksum into the vectors area? If it doesn't, the uC will ALWAYS go to the bootloader code because the image is not considered to be valid.
Some programming software have this as a selectable option, others just do it anyway. lpc21isp does it by default.
I have uploaded lpc21isp.exe to the Files folder. Put it anywhere on your computer. Then, inside uVision, go to Project->Options For Target 'Target 1'->Utilities tab and click on 'Use External Tool for Flash Programming'. Use the browse button to find the executable (Command) and add this line for 'Arguments':
"#H" \\.\COM15 38400 12000
That bizarre \\.\COM15 nonsense is only required if the COM port is > 4. If your port is <= 4, just specify it directly as COMx.
Now you can use the Download button on the IDE to do the flash programming. You can also use Flash->Download. I messed around with the IDE until I got F12 to do the same thing.
Richard
Reply by ●March 24, 20112011-03-24
Okay.
I changed my caps to 20pF (layin around) and added a 10k pullup to P0.31
(which makes Revision 3 of my PCB :).
Still not working.
Then I uploaded my hexfile again and while poking around with the
LPC2000 ISP tools Flash Manager,
I saw that I was able to kickstart the system by merely starting
execution in ARM-mode from 0x120.
The LED is blinking now, but when I reset it, it is again High-Z until I
enter the ISP and start execution from 0x120.
When I start from 0x0 it doesn't work.
At least the GPIO isn't down :)
I changed my caps to 20pF (layin around) and added a 10k pullup to P0.31
(which makes Revision 3 of my PCB :).
Still not working.
Then I uploaded my hexfile again and while poking around with the
LPC2000 ISP tools Flash Manager,
I saw that I was able to kickstart the system by merely starting
execution in ARM-mode from 0x120.
The LED is blinking now, but when I reset it, it is again High-Z until I
enter the ISP and start execution from 0x120.
When I start from 0x0 it doesn't work.
At least the GPIO isn't down :)
Reply by ●March 24, 20112011-03-24
Back to spin loops! Are you certain the compiler didn't dump that delay
loop? Any decent compiler would as it does nothing.
Define the loop variable as 'volatile int d;' and see if that helps.
FWIW, I have an LPC2148 sitting in front of me already connected to Keil uVision. I'll try to run your code.
Richard
Define the loop variable as 'volatile int d;' and see if that helps.
FWIW, I have an LPC2148 sitting in front of me already connected to Keil uVision. I'll try to run your code.
Richard
Reply by ●March 24, 20112011-03-24
> And yet your uC is working well enough to allow it
to be programmed. I
> have forgotten: are you using ISP or JTAG?
ISP because JTAG was indeed working, but I was uncertain if it was doing
what i wanted it to do. ISP is working OK.
> As JTAG provides a clock, maybe the CPU can be brain dead and still
> accept a program into flash. That information is above my pay grade.
>
> For ISP, the CPU absolutely has to be working. All day I have been
> using ISP - another reason I want to get back to CrossWorks. JTAG is
> MUCH nicer.
Hm. I'm going to single step via JTAG...
So you say that in ISP mode, the CPU must be working? That would roule
out the crystal osc. wouldn't it?
I found out that with my crystal the optimal block-cap value is closer
to 18pF than to my 39pF.
> Hi Tobias,
> There's a note in the errata sheet:
> "Port pin P0.31 must not be driven low during reset." The olimex
> schematic has that pulled high through the LED at reset. Did that
> change in your circuit?
>
> Cheers,
> Clint
Indeed, no. P0.31 is an open output in my schematic, wait a minute, I
tie it to VCC via 10k.
Just kicking on my iron....
> have forgotten: are you using ISP or JTAG?
ISP because JTAG was indeed working, but I was uncertain if it was doing
what i wanted it to do. ISP is working OK.
> As JTAG provides a clock, maybe the CPU can be brain dead and still
> accept a program into flash. That information is above my pay grade.
>
> For ISP, the CPU absolutely has to be working. All day I have been
> using ISP - another reason I want to get back to CrossWorks. JTAG is
> MUCH nicer.
Hm. I'm going to single step via JTAG...
So you say that in ISP mode, the CPU must be working? That would roule
out the crystal osc. wouldn't it?
I found out that with my crystal the optimal block-cap value is closer
to 18pF than to my 39pF.
> Hi Tobias,
> There's a note in the errata sheet:
> "Port pin P0.31 must not be driven low during reset." The olimex
> schematic has that pulled high through the LED at reset. Did that
> change in your circuit?
>
> Cheers,
> Clint
Indeed, no. P0.31 is an open output in my schematic, wait a minute, I
tie it to VCC via 10k.
Just kicking on my iron....