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?
LPC2138/01 won't run program
Started by ●March 24, 2011
Reply by ●March 24, 20112011-03-24
Reply by ●March 24, 20112011-03-24
okay. Your hex file doesn't work on my circuit either.
The way I see it, we have successfully ruled out the software-branch
(thanks to you guys - you're totally awesome!)
Which makes me think about the hardware.
There are only a few weak points:
- clock - seems to be OK, I'm trying to get the specs of this SMD-crystal
I used, need to know internal capacitance and resistance to check
if they match my 39pF block caps
- some odd logic pin preventing the CPU from code execution; none of
which i'm aware of (except P0.14)
- black magic (searched for the 'more magic' position, not found yet)
> 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?
Hm. strange.
This is so ridiculously not working; in the middle-ages they'd 've buned it.
_____________________________________________
www.tobias-schlegel.de
The way I see it, we have successfully ruled out the software-branch
(thanks to you guys - you're totally awesome!)
Which makes me think about the hardware.
There are only a few weak points:
- clock - seems to be OK, I'm trying to get the specs of this SMD-crystal
I used, need to know internal capacitance and resistance to check
if they match my 39pF block caps
- some odd logic pin preventing the CPU from code execution; none of
which i'm aware of (except P0.14)
- black magic (searched for the 'more magic' position, not found yet)
> 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?
Hm. strange.
This is so ridiculously not working; in the middle-ages they'd 've buned it.
_____________________________________________
www.tobias-schlegel.de
Reply by ●March 24, 20112011-03-24
--- In l..., Tobias Schlegel wrote:
>
> 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!)
>
> Simulating to find that fraction thing...
>
What happens when you use lpc21isp?
Addr 0x20 is a constant which is the address of the reset handler. Those vectors are almost always indirect jumps through the address table just after the vectors.
Richard
>
> 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!)
>
> Simulating to find that fraction thing...
>
What happens when you use lpc21isp?
Addr 0x20 is a constant which is the address of the reset handler. Those vectors are almost always indirect jumps through the address table just after the vectors.
Richard
Reply by ●March 24, 20112011-03-24
--- In l..., Tobias Schlegel wrote:
> I did select this. Are there any special selections in the "Target
> Dialog" to be made?
Not that I know of. Only the "Report 'might fail'..." is selected. Over to the right are the starting addresses of flash and RAM but they are greyed out.
> ...Or it is the Checksum! Correct me if i'm wrong, but he checksum check
> would prevent the CPU from reset (by jumping to BL), but not from
> executing code when explicitly jumped to?
JTAG can do whatever it wants. The only difference would be that you haven't executed the PLL setup so you will be running slow.
Maybe that checksum thing is the culprit.
Richard
> I did select this. Are there any special selections in the "Target
> Dialog" to be made?
Not that I know of. Only the "Report 'might fail'..." is selected. Over to the right are the starting addresses of flash and RAM but they are greyed out.
> ...Or it is the Checksum! Correct me if i'm wrong, but he checksum check
> would prevent the CPU from reset (by jumping to BL), but not from
> executing code when explicitly jumped to?
JTAG can do whatever it wants. The only difference would be that you haven't executed the PLL setup so you will be running slow.
Maybe that checksum thing is the culprit.
Richard
Reply by ●March 24, 20112011-03-24
--- 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)
Because all of those vectors are PC relative, not absolute. The value of the PC is 8 bytes from the current instruction. So, at addr = 0x00000000, the PC is pointing at 0x00000008 which, when 0x00000018 is added results in a destination address of 0x00000020. So, we load PC with the value at PC + 0x18 where PC is 8 bytes beyond the current instruction. It's enough to drive me nuts!
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473c/Cacdbfji.html
>
> I was unable to lure yahoo into giving me the lpc2isp executable; but I
> found it
> elsewhere on the web and will test it tomorrow morning.
>
I just downloaded and executed it. Worked fine.
Richard
> 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)
Because all of those vectors are PC relative, not absolute. The value of the PC is 8 bytes from the current instruction. So, at addr = 0x00000000, the PC is pointing at 0x00000008 which, when 0x00000018 is added results in a destination address of 0x00000020. So, we load PC with the value at PC + 0x18 where PC is 8 bytes beyond the current instruction. It's enough to drive me nuts!
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473c/Cacdbfji.html
>
> I was unable to lure yahoo into giving me the lpc2isp executable; but I
> found it
> elsewhere on the web and will test it tomorrow morning.
>
I just downloaded and executed it. Worked fine.
Richard
Reply by ●March 24, 20112011-03-24
Yeah - as a matter of fact I checked the outputs using a 100MHz scope
with 5ns/div (plus trigger) ... just plain 2V of DC.
_____________________________________________
www.tobias-schlegel.de
with 5ns/div (plus trigger) ... just plain 2V of DC.
_____________________________________________
www.tobias-schlegel.de
Reply by ●March 25, 20112011-03-25
Ok.
The disassembly shows the following:
239: Vectors LDR PC, Reset_Addr
0x00000000 E59FF018 LDR PC,[PC,#0x0018]
240: LDR PC, Undef_Addr
0x00000004 E59FF018 LDR PC,[PC,#0x0018]
241: LDR PC, SWI_Addr
0x00000008 E59FF018 LDR PC,[PC,#0x0018]
242: LDR PC, PAbt_Addr
0x0000000C E59FF018 LDR PC,[PC,#0x0018]
243: LDR PC, DAbt_Addr
0x00000010 E59FF018 LDR PC,[PC,#0x0018]
244: NOP ; Reserved Vector
245: ; LDR PC, IRQ_Addr
0x00000014 E1A00000 NOP
246: LDR PC, [PC, #-0x0FF0] ; Vector from
VicVectAddr
0x00000018 E51FFFF0 LDR PC,[PC,#-0x0FF0]
247: LDR PC, FIQ_Addr
248:
249: Reset_Addr DCD Reset_Handler
250: Undef_Addr DCD Undef_Handler
251: SWI_Addr DCD SWI_Handler
252: PAbt_Addr DCD PAbt_Handler
253: DAbt_Addr DCD DAbt_Handler
254: DCD 0 ; Reserved Address
255: IRQ_Addr DCD IRQ_Handler
256: FIQ_Addr DCD FIQ_Handler
257:
0x0000001C E59FF018 LDR PC,[PC,#0x0018]
0x00000020 00000058 DD 0x00000058
0x00000024 00000040 DD 0x00000040
0x00000028 00000044 DD 0x00000044
0x0000002C 00000048 DD 0x00000048
0x00000030 0000004C DD 0x0000004C
0x00000034 00000000 DD 0x00000000
0x00000038 00000050 DD 0x00000050
0x0000003C 00000054 DD 0x00000054
258: Undef_Handler B Undef_Handler
0x00000040 EAFFFFFE B 0x00000040
259: SWI_Handler B SWI_Handler
0x00000044 EAFFFFFE B 0x00000044
260: PAbt_Handler B PAbt_Handler
0x00000048 EAFFFFFE B 0x00000048
261: DAbt_Handler B DAbt_Handler
0x0000004C EAFFFFFE B 0x0000004C
262: IRQ_Handler B IRQ_Handler
0x00000050 EAFFFFFE B 0x00000050
263: FIQ_Handler B FIQ_Handler
0x00000054 EAFFFFFE B 0x00000054
309: LDR R0, =VPBDIV
0x00000058 E59F00AC LDR R0,[PC,#0x00AC]
310: LDR R1, =VPBDIV_Val
-> Start of RESET_HANDLER
The fact that running from 0x20 didn't work is now explainable: Heck of
a lot interrupt handlers looping forever.
At 0x58 the reset handler starts, and this is why I can jump directly to
0x58 and it will work.
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)
OK. This is weird; must have something to do with this strange fraction
linker-thing you mentioned, Robert.
Ok, I'm quite tired, so I'll call it a day. I'll come back tomorrow
(jeez it is 0035h already :) !).
Maybe I'll test it with some GNU magic. Maybe that will work upon reset,
but I'm not quite ... sure.
I'm not even sure why it 'works' now.
I was unable to lure yahoo into giving me the lpc2isp executable; but I
found it
elsewhere on the web and will test it tomorrow morning.
I want to thank you all so much for your (ongoing) quick and
professional help!
The problem isn't solved yet but with your help it is a huge leap closer
to it's solution.
Thank you!
Tobi
_____________________________________________
www.tobias-schlegel.de
The disassembly shows the following:
239: Vectors LDR PC, Reset_Addr
0x00000000 E59FF018 LDR PC,[PC,#0x0018]
240: LDR PC, Undef_Addr
0x00000004 E59FF018 LDR PC,[PC,#0x0018]
241: LDR PC, SWI_Addr
0x00000008 E59FF018 LDR PC,[PC,#0x0018]
242: LDR PC, PAbt_Addr
0x0000000C E59FF018 LDR PC,[PC,#0x0018]
243: LDR PC, DAbt_Addr
0x00000010 E59FF018 LDR PC,[PC,#0x0018]
244: NOP ; Reserved Vector
245: ; LDR PC, IRQ_Addr
0x00000014 E1A00000 NOP
246: LDR PC, [PC, #-0x0FF0] ; Vector from
VicVectAddr
0x00000018 E51FFFF0 LDR PC,[PC,#-0x0FF0]
247: LDR PC, FIQ_Addr
248:
249: Reset_Addr DCD Reset_Handler
250: Undef_Addr DCD Undef_Handler
251: SWI_Addr DCD SWI_Handler
252: PAbt_Addr DCD PAbt_Handler
253: DAbt_Addr DCD DAbt_Handler
254: DCD 0 ; Reserved Address
255: IRQ_Addr DCD IRQ_Handler
256: FIQ_Addr DCD FIQ_Handler
257:
0x0000001C E59FF018 LDR PC,[PC,#0x0018]
0x00000020 00000058 DD 0x00000058
0x00000024 00000040 DD 0x00000040
0x00000028 00000044 DD 0x00000044
0x0000002C 00000048 DD 0x00000048
0x00000030 0000004C DD 0x0000004C
0x00000034 00000000 DD 0x00000000
0x00000038 00000050 DD 0x00000050
0x0000003C 00000054 DD 0x00000054
258: Undef_Handler B Undef_Handler
0x00000040 EAFFFFFE B 0x00000040
259: SWI_Handler B SWI_Handler
0x00000044 EAFFFFFE B 0x00000044
260: PAbt_Handler B PAbt_Handler
0x00000048 EAFFFFFE B 0x00000048
261: DAbt_Handler B DAbt_Handler
0x0000004C EAFFFFFE B 0x0000004C
262: IRQ_Handler B IRQ_Handler
0x00000050 EAFFFFFE B 0x00000050
263: FIQ_Handler B FIQ_Handler
0x00000054 EAFFFFFE B 0x00000054
309: LDR R0, =VPBDIV
0x00000058 E59F00AC LDR R0,[PC,#0x00AC]
310: LDR R1, =VPBDIV_Val
-> Start of RESET_HANDLER
The fact that running from 0x20 didn't work is now explainable: Heck of
a lot interrupt handlers looping forever.
At 0x58 the reset handler starts, and this is why I can jump directly to
0x58 and it will work.
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)
OK. This is weird; must have something to do with this strange fraction
linker-thing you mentioned, Robert.
Ok, I'm quite tired, so I'll call it a day. I'll come back tomorrow
(jeez it is 0035h already :) !).
Maybe I'll test it with some GNU magic. Maybe that will work upon reset,
but I'm not quite ... sure.
I'm not even sure why it 'works' now.
I was unable to lure yahoo into giving me the lpc2isp executable; but I
found it
elsewhere on the web and will test it tomorrow morning.
I want to thank you all so much for your (ongoing) quick and
professional help!
The problem isn't solved yet but with your help it is a huge leap closer
to it's solution.
Thank you!
Tobi
_____________________________________________
www.tobias-schlegel.de
Reply by ●March 25, 20112011-03-25
--- In l..., Tobias Schlegel wrote:
>
> 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)
>
> _____________________________________________
> www.tobias-schlegel.de
My bad...
I just tried a new build from an unmodified project and files - and it didn't work. Again... I thought I had unwound this change that I tried briefly but I guess it was still in effect.
You absolutely have to go into Project -> Options For Target 'Target 1' -> Linker Tab and click on 'Use Memory Layout from Target Dialog'.
This jumped up and bit my when I first started playing with Keil MDK (to assist another user, I personally use Rowley Crossworks). Apparently, Keil likes the 'scatterfile' approach and I haven't learned enough about the toolchain to understand what that means. I have, however, learned how to get around it.
Richard
>
> 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)
>
> _____________________________________________
> www.tobias-schlegel.de
My bad...
I just tried a new build from an unmodified project and files - and it didn't work. Again... I thought I had unwound this change that I tried briefly but I guess it was still in effect.
You absolutely have to go into Project -> Options For Target 'Target 1' -> Linker Tab and click on 'Use Memory Layout from Target Dialog'.
This jumped up and bit my when I first started playing with Keil MDK (to assist another user, I personally use Rowley Crossworks). Apparently, Keil likes the 'scatterfile' approach and I haven't learned enough about the toolchain to understand what that means. I have, however, learned how to get around it.
Richard
Reply by ●March 25, 20112011-03-25
Hi,
sorry! It seems like i was too tired yesterday evening; what I wrote is
total nonsense.
Sure, it is a load from a location relative to PC (which I expected to
be 0x0 btw; so much about debugging at night...)
Thinking this over:
- The (Keil related) linking-problem Robert mentioned is no longer a
point of failure because starting from 0x58 works.
- Checksum check fail might still be a problem; test with lpc2isp coming
right up. But I don't expect that to be the problem
except the LPC2000 flash utility calculates them wrong for the LPC2138/01.
To cut it short: The problem
a) lays between 0x0 and 0x58 (or vector checksum)
b) is some hardware problem (some pin that has the wrong level).
> Are you sure your MCU is not running the programming mode? You can
> check that by using Hyperterminal (or other terminal software), any
> baud rate and then send it character. In programming mode, you will
> get some response from MCU.
I normally disconnect the UART-port because this lead to jumps to the
bootloader in the past; don't know why. In the Olimex schematic there
are no external pullups/pulldowns there.
-> But it indicates that in fact, the system is not executing normally.
I'll investigate that.
> And have you connect JTAG pin correctly (provide them pull-up
> resisters)? Some of this is needed in some series of LPC2000.
Yes; they do (all) have pullups (10k) except TCK which has a pulldown
(also 10k).
RTCK also has a pulldown (to enable debug pins) but as far as I know
this doesn't interfere with program execution. (I can tie it high and
reset; program won't start)
TRST has a pullup (10k)
P0.14 has a pullup (4k7)
P0.31 has a pullup (10k)
I'll test lpc2isp now, and then I'll provide a schematic (with populated
/ unpopulated parts).
sorry! It seems like i was too tired yesterday evening; what I wrote is
total nonsense.
Sure, it is a load from a location relative to PC (which I expected to
be 0x0 btw; so much about debugging at night...)
Thinking this over:
- The (Keil related) linking-problem Robert mentioned is no longer a
point of failure because starting from 0x58 works.
- Checksum check fail might still be a problem; test with lpc2isp coming
right up. But I don't expect that to be the problem
except the LPC2000 flash utility calculates them wrong for the LPC2138/01.
To cut it short: The problem
a) lays between 0x0 and 0x58 (or vector checksum)
b) is some hardware problem (some pin that has the wrong level).
> Are you sure your MCU is not running the programming mode? You can
> check that by using Hyperterminal (or other terminal software), any
> baud rate and then send it character. In programming mode, you will
> get some response from MCU.
I normally disconnect the UART-port because this lead to jumps to the
bootloader in the past; don't know why. In the Olimex schematic there
are no external pullups/pulldowns there.
-> But it indicates that in fact, the system is not executing normally.
I'll investigate that.
> And have you connect JTAG pin correctly (provide them pull-up
> resisters)? Some of this is needed in some series of LPC2000.
Yes; they do (all) have pullups (10k) except TCK which has a pulldown
(also 10k).
RTCK also has a pulldown (to enable debug pins) but as far as I know
this doesn't interfere with program execution. (I can tie it high and
reset; program won't start)
TRST has a pullup (10k)
P0.14 has a pullup (4k7)
P0.31 has a pullup (10k)
I'll test lpc2isp now, and then I'll provide a schematic (with populated
/ unpopulated parts).
Reply by ●March 25, 20112011-03-25
Finally - problem solved.
Ok. It was a hard one. And a stupid one.
As i wrote in my last email, i populated all remaining CPU-related
pullups possible; which had no effect.
My next idea was, that there might be a short between RESET and P0.14 -
which wasn't the case.
P0.14 had straight 3,3Vs of DC - at least I thought that, because i
measured that voltage on the corresponding PCB trace.
I even checked that with my scope.
Because all solderjoints looked OK when I inspected them I had no doubt
that all pins of the LPC were connected correctly.
So I inspected the P0.14 solderjoint again and - it totally checked out.
But; as I measured P0.14 on the chip's lead there were 0V - not the 3.3V
from the trace 1mm away.
Continuity-checking did not check out.
So i greased it up, reheated it and voila it all worked.
The joint exactly looked the same as before but now it did connect.
Sorry for making so much noise about this - I'm a little embarassed ;)
I really want to thank all of you for your very helpful and professional
support!
Without you guys I would still be poking around in the startup-code.
Thanks - again!
Tobi
_____________________________________________
www.tobias-schlegel.de
Ok. It was a hard one. And a stupid one.
As i wrote in my last email, i populated all remaining CPU-related
pullups possible; which had no effect.
My next idea was, that there might be a short between RESET and P0.14 -
which wasn't the case.
P0.14 had straight 3,3Vs of DC - at least I thought that, because i
measured that voltage on the corresponding PCB trace.
I even checked that with my scope.
Because all solderjoints looked OK when I inspected them I had no doubt
that all pins of the LPC were connected correctly.
So I inspected the P0.14 solderjoint again and - it totally checked out.
But; as I measured P0.14 on the chip's lead there were 0V - not the 3.3V
from the trace 1mm away.
Continuity-checking did not check out.
So i greased it up, reheated it and voila it all worked.
The joint exactly looked the same as before but now it did connect.
Sorry for making so much noise about this - I'm a little embarassed ;)
I really want to thank all of you for your very helpful and professional
support!
Without you guys I would still be poking around in the startup-code.
Thanks - again!
Tobi
_____________________________________________
www.tobias-schlegel.de