--- In l..., "rtstofer" wrote: >
> 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
>
Final try: I programmed my LPC2148 with YOUR .hex file and it works fine. I
guess the 05 record isn't all that important.
I don't know what PLL values you used when you built that .hex file but
they seem to be fine for me.
If your crystal is 20MHz you should use PLLCFG_VAL 0x22
to have Fcco 240MHz and CCLK 60MHz
Alex
Reply by Tobias Schlegel●March 26, 20112011-03-26
Am 24.03.2011 18:58, schrieb Chutiman Yongprapat: > 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
Yes; I used the keil-startup-dialog to set the multiplier to 12 (which
makes 240MHz for the CCO) and the divider to 4 which results in 60MHz Fclk.
I attempted a divider value of 8 (30MHz), did a manual reset... nothing.
It's so frustrating... (I fight with this circuit for 2 weeks now...)
I disconnected the UART0 Port (which turned out to be loading the
ISP-loader earlier) powercycled (nothing there)
and then conducted a manual reset (RESET pulled LOW) but it didn't help,
still 2V on all outputs...
Thanks for your really quick replies :)
Reply by Alex●March 26, 20112011-03-26
If you are using LPC2138 I think you should include LPC213x.Hand notLPC21xx.H
Alex
Reply by cfbsoftware1●March 26, 20112011-03-26
--- In l..., Tobias Schlegel wrote: > The big question now is, why is instruction 0x0
the way it is:
>
> 239: Vectors LDR PC, Reset_Addr
> 0x00000000 E59FF018 LDR PC,[PC,#0x0018]
> and not
> LDR PC,[PC,#0x0020]
> (0x20 has the value 0x58 - the address of Reset_Handler)
>
'PC,#0x0018' denotes the *relative* address offset from the current
value of the PC NOT the *absolute* address #0x0018.
In ARM code the PC is always 2 words ahead of the instruction currently being
executed.
So if the address of the instruction being executed is 0 then:
Hm you do have a point with that PLL.
When I jump exactly into the init-script....
Ok, jumping to 0x58 (according to the map file this is the location of
"Reset_Handler") does make it happy(!!).
AND the LED is flashing much faster now; -> PLL is working and set up
correctly.
I jumped to 0x20 (next intruction after the vector table (?) ) which did
NOT work.
So the way I see it there are 2 possible explanations:
1) Something between 0x0 and 0x58 (or 0x20 .. 0x58) is interfering
2) Vector checksum check fails (I wouldn't know why - I put that sum
into the image myself!)
--- In l..., Tobias Schlegel wrote: >
> The fact that I can run code from 0x0 and still be able to connect to
> the bootloader
> (but not the other way round, when i execute from 0x120) would indicate
> that the checksum check fails... wouldn't it?
>
