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.
And have you connect JTAG pin correctly (provide them pull-up resisters)?
Some of this is needed in some series of LPC2000.
Best Regards,
Chutiman Yongprapat
E-mail: c...@thaieasyelec.com
LPC2138/01 won't run program
Started by ●March 24, 2011
Reply by ●March 26, 20112011-03-26
Reply by ●March 26, 20112011-03-26
--- In l..., Tobias Schlegel wrote:
>
> Tell me I'm crazy but this still didn't do the trick.
> Although the LPC2000 ISP tool calculates another vector checksum
>
> I changed the c code to toggle more pins:
>
> #include <LPC213x.H> /* LPC21xx definitions */
>
> void wait (void) { /* wait function */
> volatile unsigned int d;
>
> for (d = 0; d < 1000000; d++); /* only to delay for LED
> flashes */
> }
>
> int main (void) {
>
> IODIR0 = (unsigned int) ~0;
> IODIR1 = (unsigned int) ~0; /* P1.16..23 defined
> as Outputs */
>
> while (1) { /* Loop forever */
> IOSET0 = (unsigned int) ~0;
> IOSET1 = (unsigned int) ~0; /* Turn on
> LED */
> wait (); /* call wait function */
> IOCLR0 = (unsigned int) ~0;
> IOCLR1 = (unsigned int) ~0; /* Turn off
> LED */
> wait();
> }
> }
>
> Here is my current hex file:
>
Your revised code works fine on my LPC2148 after I changed the project properties and PLL config. Here is MY .hex file
:020000040000FA
:1000000018F09FE518F09FE518F09FE518F09FE5C0
:1000100018F09FE50000A0E1F0FF1FE518F09FE554
:1000200058000000400000004400000048000000AC
:100030004C000000000000005000000054000000D0
:10004000FEFFFFEAFEFFFFEAFEFFFFEAFEFFFFEA18
:10005000FEFFFFEAFEFFFFEAAC009FE50210A0E30F
:10006000001080E5A4009FE5AA10A0E35520A0E3BE
:100070002430A0E3043080E50130A0E3003080E5C7
:100080000C1080E50C2080E5083090E5013B13E280
:10009000FCFFFF0A0330A0E3003080E50C1080E590
:1000A0000C2080E568009FE50410A0E3041080E5C3
:1000B0000210A0E3001080E558009FE5DBF021E38B
:1000C00000D0A0E1000040E2D7F021E300D0A0E1A1
:1000D000000040E2D1F021E300D0A0E1000040E2C6
:1000E000D2F021E300D0A0E1800040E2D3F021E390
:1000F00000D0A0E1080040E210F021E300D0A0E130
:1001000001AB4DE210009FE510FF2FE100C11FE0A1
:1001100080C01FE000C01FE0E80400402001000094
:10012000000000EB250000EB2C008FE2000C90E8B3
:1001300000A08AE000B08BE001704AE20B005AE1B7
:100140000000001A1D0000EB0F00BAE818E04FE2B3
:10015000010013E303F0471013FF2FE1F00100004B
:10016000000200000030B0E30040B0E30050B0E314
:100170000060B0E3102052E27800A128FCFFFF8A63
:10018000822EB0E13000A128003081451EFF2FE112
:1001900001C08FE21CFF2FE11FB500F0C9F80598E0
:1001A00086460FBC009C02B07047000001C08FE281
:1001B0001CFF2FE130B47546AE4630BC70470000DE
:1001C000330000EB0210A0E1F0FFFFEB1CC09FE545
:1001D0000FC08CE001001CE30DE08F120FE0A001C6
:1001E0001CFF2FE101C08FE21CFF2FE100F082F81D
:1001F0006C0000007847C04603002DE9EAFFFFEBE2
:100200000300BDE8430000EB0C009FE50C109FE5E8
:1002100004209FE508309FE51EFF2FE160000040AD
:1002200060040040600000400000A0E3000000EA1D
:10023000010080E248109FE5010050E1FBFFFF3A1A
:100240001EFF2FE10000E0E338109FE5080081E584
:10025000180081E5090000EA0000E0E324109FE5B2
:10026000040081E5140081E5EEFFFFEB0000E0E310
:1002700010109FE50C0081E51C0081E5E9FFFFEB14
:10028000F4FFFFEA40420F00008002E07047704731
:10029000704700000E50A0E1180000EB05E0A0E15F
:1002A0000050B0E10D10A0E10A30A0E10700C0E36A
:1002B00000D0A0E160D08DE220402DE9D1FFFFEB1E
:1002C0002040BDE80060A0E30070A0E30080A0E350
:1002D00000B0A0E30710C1E305C0A0E1C009ACE88D
:1002E000C009ACE8C009ACE8C009ACE801D0A0E1A5
:1002F0001EFF2FE10400C046C0462000FFF77AFF32
:1003000000009FE51EFF2FE10000004000009FE578
:100310001EFF2FE10400004001C08FE21CFF2FE10F
:1003200001491820ABDFFEE7260002001EFF2FE187
:100330007847C04610402DE9F3FFFFEB0010A0E323
:10034000001080E51040BDE81EFF2FE15C030000B7
:0C03500000000040E80400006401000010
:0400000500000120D6
:00000001FF
Richard
>
> Tell me I'm crazy but this still didn't do the trick.
> Although the LPC2000 ISP tool calculates another vector checksum
>
> I changed the c code to toggle more pins:
>
> #include <LPC213x.H> /* LPC21xx definitions */
>
> void wait (void) { /* wait function */
> volatile unsigned int d;
>
> for (d = 0; d < 1000000; d++); /* only to delay for LED
> flashes */
> }
>
> int main (void) {
>
> IODIR0 = (unsigned int) ~0;
> IODIR1 = (unsigned int) ~0; /* P1.16..23 defined
> as Outputs */
>
> while (1) { /* Loop forever */
> IOSET0 = (unsigned int) ~0;
> IOSET1 = (unsigned int) ~0; /* Turn on
> LED */
> wait (); /* call wait function */
> IOCLR0 = (unsigned int) ~0;
> IOCLR1 = (unsigned int) ~0; /* Turn off
> LED */
> wait();
> }
> }
>
> Here is my current hex file:
>
Your revised code works fine on my LPC2148 after I changed the project properties and PLL config. Here is MY .hex file
:020000040000FA
:1000000018F09FE518F09FE518F09FE518F09FE5C0
:1000100018F09FE50000A0E1F0FF1FE518F09FE554
:1000200058000000400000004400000048000000AC
:100030004C000000000000005000000054000000D0
:10004000FEFFFFEAFEFFFFEAFEFFFFEAFEFFFFEA18
:10005000FEFFFFEAFEFFFFEAAC009FE50210A0E30F
:10006000001080E5A4009FE5AA10A0E35520A0E3BE
:100070002430A0E3043080E50130A0E3003080E5C7
:100080000C1080E50C2080E5083090E5013B13E280
:10009000FCFFFF0A0330A0E3003080E50C1080E590
:1000A0000C2080E568009FE50410A0E3041080E5C3
:1000B0000210A0E3001080E558009FE5DBF021E38B
:1000C00000D0A0E1000040E2D7F021E300D0A0E1A1
:1000D000000040E2D1F021E300D0A0E1000040E2C6
:1000E000D2F021E300D0A0E1800040E2D3F021E390
:1000F00000D0A0E1080040E210F021E300D0A0E130
:1001000001AB4DE210009FE510FF2FE100C11FE0A1
:1001100080C01FE000C01FE0E80400402001000094
:10012000000000EB250000EB2C008FE2000C90E8B3
:1001300000A08AE000B08BE001704AE20B005AE1B7
:100140000000001A1D0000EB0F00BAE818E04FE2B3
:10015000010013E303F0471013FF2FE1F00100004B
:10016000000200000030B0E30040B0E30050B0E314
:100170000060B0E3102052E27800A128FCFFFF8A63
:10018000822EB0E13000A128003081451EFF2FE112
:1001900001C08FE21CFF2FE11FB500F0C9F80598E0
:1001A00086460FBC009C02B07047000001C08FE281
:1001B0001CFF2FE130B47546AE4630BC70470000DE
:1001C000330000EB0210A0E1F0FFFFEB1CC09FE545
:1001D0000FC08CE001001CE30DE08F120FE0A001C6
:1001E0001CFF2FE101C08FE21CFF2FE100F082F81D
:1001F0006C0000007847C04603002DE9EAFFFFEBE2
:100200000300BDE8430000EB0C009FE50C109FE5E8
:1002100004209FE508309FE51EFF2FE160000040AD
:1002200060040040600000400000A0E3000000EA1D
:10023000010080E248109FE5010050E1FBFFFF3A1A
:100240001EFF2FE10000E0E338109FE5080081E584
:10025000180081E5090000EA0000E0E324109FE5B2
:10026000040081E5140081E5EEFFFFEB0000E0E310
:1002700010109FE50C0081E51C0081E5E9FFFFEB14
:10028000F4FFFFEA40420F00008002E07047704731
:10029000704700000E50A0E1180000EB05E0A0E15F
:1002A0000050B0E10D10A0E10A30A0E10700C0E36A
:1002B00000D0A0E160D08DE220402DE9D1FFFFEB1E
:1002C0002040BDE80060A0E30070A0E30080A0E350
:1002D00000B0A0E30710C1E305C0A0E1C009ACE88D
:1002E000C009ACE8C009ACE8C009ACE801D0A0E1A5
:1002F0001EFF2FE10400C046C0462000FFF77AFF32
:1003000000009FE51EFF2FE10000004000009FE578
:100310001EFF2FE10400004001C08FE21CFF2FE10F
:1003200001491820ABDFFEE7260002001EFF2FE187
:100330007847C04610402DE9F3FFFFEB0010A0E323
:10034000001080E51040BDE81EFF2FE15C030000B7
:0C03500000000040E80400006401000010
:0400000500000120D6
:00000001FF
Richard
Reply by ●March 26, 20112011-03-26
That exactly was my thought too - that's why I inserted the checksum
manually using the LPC ISP tool (you know this LPC2000 flash tool
version 2.2.3 - thingy).
I don't trust Flash Magic to insert the checksum (correctly).
I'll try your tool right away.
_____________________________________________
www.tobias-schlegel.de
manually using the LPC ISP tool (you know this LPC2000 flash tool
version 2.2.3 - thingy).
I don't trust Flash Magic to insert the checksum (correctly).
I'll try your tool right away.
_____________________________________________
www.tobias-schlegel.de
Reply by ●March 26, 20112011-03-26
--- In l..., Tobias Schlegel wrote:
>
> 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 :)
Earlier I mentioned about that scatterfile stuff and the change to the linker options. I had EXACTLY the same problem when I started using Keil and I convinced myself that using the 'Use Memory Layout from Target Dialog' selection was the answer.
If you have to start from 0x120 instead of 0x000 then you know there is something hosed in Startup.s OR in the scatterfile routines that are just beyond the startup code and before the __main entry. That is EXACLY where my system hung and it hung in the simulator as well. In fact, since I was using ISP, the only way I found the problem is with the simulator. And I HATE simulation because it isn't hardware.
Go into Debug (for the simulator) and step through the code. See if you get hung up in something that looks a lot like 'scatterfile'.
Richard
>
> 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 :)
Earlier I mentioned about that scatterfile stuff and the change to the linker options. I had EXACTLY the same problem when I started using Keil and I convinced myself that using the 'Use Memory Layout from Target Dialog' selection was the answer.
If you have to start from 0x120 instead of 0x000 then you know there is something hosed in Startup.s OR in the scatterfile routines that are just beyond the startup code and before the __main entry. That is EXACLY where my system hung and it hung in the simulator as well. In fact, since I was using ISP, the only way I found the problem is with the simulator. And I HATE simulation because it isn't hardware.
Go into Debug (for the simulator) and step through the code. See if you get hung up in something that looks a lot like 'scatterfile'.
Richard
Reply by ●March 26, 20112011-03-26
On 25 March 2011 08:19, Tobias Schlegel wrote:
> - 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)
>
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
> - 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)
>
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
Reply by ●March 26, 20112011-03-26
> Earlier I mentioned about that scatterfile stuff
and the change to the
> linker options. I had EXACTLY the same problem when I started using
> Keil and I convinced myself that using the 'Use Memory Layout from
> Target Dialog' selection was the answer.
>
I did select this. Are there any special selections in the "Target
Dialog" to be made?
> If you have to start from 0x120 instead of 0x000 then you know there
> is something hosed in Startup.s OR in the scatterfile routines that
> are just beyond the startup code and before the __main entry. That is
> EXACLY where my system hung and it hung in the simulator as well. In
> fact, since I was using ISP, the only way I found the problem is with
> the simulator. And I HATE simulation because it isn't hardware.
>
...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?
> Go into Debug (for the simulator) and step through the code. See if
> you get hung up in something that looks a lot like 'scatterfile'.
>
I do hate simulation too, but I'm on it.
> linker options. I had EXACTLY the same problem when I started using
> Keil and I convinced myself that using the 'Use Memory Layout from
> Target Dialog' selection was the answer.
>
I did select this. Are there any special selections in the "Target
Dialog" to be made?
> If you have to start from 0x120 instead of 0x000 then you know there
> is something hosed in Startup.s OR in the scatterfile routines that
> are just beyond the startup code and before the __main entry. That is
> EXACLY where my system hung and it hung in the simulator as well. In
> fact, since I was using ISP, the only way I found the problem is with
> the simulator. And I HATE simulation because it isn't hardware.
>
...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?
> Go into Debug (for the simulator) and step through the code. See if
> you get hung up in something that looks a lot like 'scatterfile'.
>
I do hate simulation too, but I'm on it.
Reply by ●March 26, 20112011-03-26
--- 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?
>
Very likely!
Richard
>
> 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?
>
Very likely!
Richard
Reply by ●March 26, 20112011-03-26
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...
_____________________________________________
www.tobias-schlegel.de
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...
_____________________________________________
www.tobias-schlegel.de
Reply by ●March 26, 20112011-03-26
:020000040000FA
:1000000018F09FE518F09FE518F09FE518F09FE5C0
:1000100018F09FE5805F20B9F0FF1FE518F09FE51D
:1000200058000000400000004400000048000000AC
:100030004C000000000000005000000054000000D0
:10004000FEFFFFEAFEFFFFEAFEFFFFEAFEFFFFEA18
:10005000FEFFFFEAFEFFFFEAAC009FE50210A0E30F
:10006000001080E5A4009FE5AA10A0E35520A0E3BE
:100070002230A0E3043080E50130A0E3003080E5C9
:100080000C1080E50C2080E5083090E5013B13E280
:10009000FCFFFF0A0330A0E3003080E50C1080E590
:1000A0000C2080E568009FE50410A0E3041080E5C3
:1000B0000210A0E3001080E558009FE5DBF021E38B
:1000C00000D0A0E1000040E2D7F021E300D0A0E1A1
:1000D000000040E2D1F021E300D0A0E1000040E2C6
:1000E000D2F021E300D0A0E1800040E2D3F021E390
:1000F00000D0A0E1080040E210F021E300D0A0E130
:1001000001AB4DE210009FE510FF2FE100C11FE0A1
:1001100080C01FE000C01FE0E80400402001000094
:10012000000000EB250000EB2C008FE2000C90E8B3
:1001300000A08AE000B08BE001704AE20B005AE1B7
:100140000000001A1D0000EB0F00BAE818E04FE2B3
:10015000010013E303F0471013FF2FE1F00100004B
:10016000000200000030B0E30040B0E30050B0E314
:100170000060B0E3102052E27800A128FCFFFF8A63
:10018000822EB0E13000A128003081451EFF2FE112
:1001900001C08FE21CFF2FE11FB500F0C9F80598E0
:1001A00086460FBC009C02B07047000001C08FE281
:1001B0001CFF2FE130B47546AE4630BC70470000DE
:1001C000330000EB0210A0E1F0FFFFEB1CC09FE545
:1001D0000FC08CE001001CE30DE08F120FE0A001C6
:1001E0001CFF2FE101C08FE21CFF2FE100F082F81D
:1001F0006C0000007847C04603002DE9EAFFFFEBE2
:100200000300BDE8430000EB0C009FE50C109FE5E8
:1002100004209FE508309FE51EFF2FE160000040AD
:1002200060040040600000400000A0E3000000EA1D
:10023000010080E248109FE5010050E1FBFFFF3A1A
:100240001EFF2FE10000E0E338109FE5080081E584
:10025000180081E5090000EA0000E0E324109FE5B2
:10026000040081E5140081E5EEFFFFEB0000E0E310
:1002700010109FE50C0081E51C0081E5E9FFFFEB14
:10028000F4FFFFEA40420F00008002E07047704731
:10029000704700000E50A0E1180000EB05E0A0E15F
:1002A0000050B0E10D10A0E10A30A0E10700C0E36A
:1002B00000D0A0E160D08DE220402DE9D1FFFFEB1E
:1002C0002040BDE80060A0E30070A0E30080A0E350
:1002D00000B0A0E30710C1E305C0A0E1C009ACE88D
:1002E000C009ACE8C009ACE8C009ACE801D0A0E1A5
:1002F0001EFF2FE10400C046C0462000FFF77AFF32
:1003000000009FE51EFF2FE10000004000009FE578
:100310001EFF2FE10400004001C08FE21CFF2FE10F
:1003200001491820ABDFFEE7260002001EFF2FE187
:100330007847C04610402DE9F3FFFFEB0010A0E323
:10034000001080E51040BDE81EFF2FE15C030000B7
:0C03500000000040E80400006401000010
:00000001FF
:1000000018F09FE518F09FE518F09FE518F09FE5C0
:1000100018F09FE5805F20B9F0FF1FE518F09FE51D
:1000200058000000400000004400000048000000AC
:100030004C000000000000005000000054000000D0
:10004000FEFFFFEAFEFFFFEAFEFFFFEAFEFFFFEA18
:10005000FEFFFFEAFEFFFFEAAC009FE50210A0E30F
:10006000001080E5A4009FE5AA10A0E35520A0E3BE
:100070002230A0E3043080E50130A0E3003080E5C9
:100080000C1080E50C2080E5083090E5013B13E280
:10009000FCFFFF0A0330A0E3003080E50C1080E590
:1000A0000C2080E568009FE50410A0E3041080E5C3
:1000B0000210A0E3001080E558009FE5DBF021E38B
:1000C00000D0A0E1000040E2D7F021E300D0A0E1A1
:1000D000000040E2D1F021E300D0A0E1000040E2C6
:1000E000D2F021E300D0A0E1800040E2D3F021E390
:1000F00000D0A0E1080040E210F021E300D0A0E130
:1001000001AB4DE210009FE510FF2FE100C11FE0A1
:1001100080C01FE000C01FE0E80400402001000094
:10012000000000EB250000EB2C008FE2000C90E8B3
:1001300000A08AE000B08BE001704AE20B005AE1B7
:100140000000001A1D0000EB0F00BAE818E04FE2B3
:10015000010013E303F0471013FF2FE1F00100004B
:10016000000200000030B0E30040B0E30050B0E314
:100170000060B0E3102052E27800A128FCFFFF8A63
:10018000822EB0E13000A128003081451EFF2FE112
:1001900001C08FE21CFF2FE11FB500F0C9F80598E0
:1001A00086460FBC009C02B07047000001C08FE281
:1001B0001CFF2FE130B47546AE4630BC70470000DE
:1001C000330000EB0210A0E1F0FFFFEB1CC09FE545
:1001D0000FC08CE001001CE30DE08F120FE0A001C6
:1001E0001CFF2FE101C08FE21CFF2FE100F082F81D
:1001F0006C0000007847C04603002DE9EAFFFFEBE2
:100200000300BDE8430000EB0C009FE50C109FE5E8
:1002100004209FE508309FE51EFF2FE160000040AD
:1002200060040040600000400000A0E3000000EA1D
:10023000010080E248109FE5010050E1FBFFFF3A1A
:100240001EFF2FE10000E0E338109FE5080081E584
:10025000180081E5090000EA0000E0E324109FE5B2
:10026000040081E5140081E5EEFFFFEB0000E0E310
:1002700010109FE50C0081E51C0081E5E9FFFFEB14
:10028000F4FFFFEA40420F00008002E07047704731
:10029000704700000E50A0E1180000EB05E0A0E15F
:1002A0000050B0E10D10A0E10A30A0E10700C0E36A
:1002B00000D0A0E160D08DE220402DE9D1FFFFEB1E
:1002C0002040BDE80060A0E30070A0E30080A0E350
:1002D00000B0A0E30710C1E305C0A0E1C009ACE88D
:1002E000C009ACE8C009ACE8C009ACE801D0A0E1A5
:1002F0001EFF2FE10400C046C0462000FFF77AFF32
:1003000000009FE51EFF2FE10000004000009FE578
:100310001EFF2FE10400004001C08FE21CFF2FE10F
:1003200001491820ABDFFEE7260002001EFF2FE187
:100330007847C04610402DE9F3FFFFEB0010A0E323
:10034000001080E51040BDE81EFF2FE15C030000B7
:0C03500000000040E80400006401000010
:00000001FF
Reply by ●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:
PC = 8
and so:
PC,#0x0018 = absolute address (0x8 + 0x0018)
= absolute address #0x0020
Regards,
Chris Burrows
CFB Software
Astrobe v3.3: LPC2000 Oberon-07 Development System
http://www.astrobe.com
> 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:
PC = 8
and so:
PC,#0x0018 = absolute address (0x8 + 0x0018)
= absolute address #0x0020
Regards,
Chris Burrows
CFB Software
Astrobe v3.3: LPC2000 Oberon-07 Development System
http://www.astrobe.com
