OK. Here are my map files for both bootloader and app (called vera1)
http://www.lookoutportablesecurity.com/sutton/bootload.map
http://www.lookoutportablesecurity.com/sutton/vera1.map
BTW, it is a hex file generated by Keil. Option is enabled. I use
hex2bin to generate the binary file.
mjames_doveridge wrote:
>
>
> --- In l... ,
> manton@... wrote:
> >
> > If it were me, I would use a .hex, even if it is bigger, as the
> > format is well defined.
> > Yes - I use S-record files for my update images. I have two banks of
> code and two fixed sectors at the top of flash, one for each bank, that
> contains version/CRC/whatever for each bank, so a binary image would
> mean that blowing bank 'A' would destroy bank 'B' because
the 'flat'
> image from 'A' would cover the range of 'B'. It would also
be much
> slower because all sectors would need to be written in order to reach
> the sector at the top.
>
> With S-records, (or Intel hex), it's fairly easy to only blow sectors
> that actually have new code written to them, leaving sectors in
'gaps'
> alone.
>
> I was never happy with a flat binary image - I rejected the idea very
> early on. OK, it means a bit of extra code in the bootloader to
> interpret the records from the file, but it's hardly difficult - as you
> say 'well defined'.
>
> Rgds,
> Martin
--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
new SD code transfer to LPC2148 not quite working
Started by ●August 18, 2009
Reply by ●August 21, 20092009-08-21
Reply by ●August 21, 20092009-08-21
Sutton Mehaffey schrieb:
> OK. Here are my map files for both bootloader and app (called vera1)
>
> http://www.lookoutportablesecurity.com/sutton/bootload.map
>
> http://www.lookoutportablesecurity.com/sutton/vera1.map
_terminateio - Undefined Weak Reference
version 0x00004000 Data
2 lookout.o(.ARM.__AT_0x00004000)
^^^^^ why/what is this at 0x4000 ?
Reset_Handler 0x0000405c ARM Code
0 startup.o(RESET)
It looks, you bootloader should jump at 0x405c !
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
> OK. Here are my map files for both bootloader and app (called vera1)
>
> http://www.lookoutportablesecurity.com/sutton/bootload.map
>
> http://www.lookoutportablesecurity.com/sutton/vera1.map
_terminateio - Undefined Weak Reference
version 0x00004000 Data
2 lookout.o(.ARM.__AT_0x00004000)
^^^^^ why/what is this at 0x4000 ?
Reset_Handler 0x0000405c ARM Code
0 startup.o(RESET)
It looks, you bootloader should jump at 0x405c !
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
Reply by ●August 21, 20092009-08-21
Hi Sutton:
It is clear from the .map files that you still haven't remap the interrupt vector table to RAM when entering your main application.
>From your previous message #44141
http://tech.groups.yahoo.com/group/lpc2000/message/44141
it is possible to see that you force the addresses of the interrupt vectors to be specific addresses after 0x4000
Vectors LDR PC, Reset_Addr
LDR PC, Undef_Addr
LDR PC, SWI_Addr
LDR PC, PAbt_Addr
LDR PC, DAbt_Addr
NOP ; Reserved Vector
; LDR PC, IRQ_Addr
LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
LDR PC, FIQ_Addr
Reset_Addr DCD Reset_Handler
Undef_Addr DCD 0x4004
SWI_Addr DCD 0x4008
PAbt_Addr DCD 0x400C
DAbt_Addr DCD 0x4010
DCD 0 ; Reserved Address
IRQ_Addr DCD 0x4014
FIQ_Addr DCD 0x401C
However, there is nothing indicating that those addresses contain the correct handler for each exception. In fact, what this code is doing is to make each interrupt vector point to itself, except for the IRQ vector.
Now, if you don't remap the interrupt vectors, the processor will use the vectors provided by the bootloader:
(see line 340 of the bootloader.map file)
Undef_Handler 0x00000040 ARM Code 4 startup.o(RESET)
SWI_Handler 0x00000044 ARM Code 4 startup.o(RESET)
PAbt_Handler 0x00000048 ARM Code 4 startup.o(RESET)
DAbt_Handler 0x0000004c ARM Code 4 startup.o(RESET)
IRQ_Handler 0x00000050 ARM Code 4 startup.o(RESET)
FIQ_Handler 0x00000054 ARM Code 4 startup.o(RESET)
These vectors probably are pointing to different interrupt handling routines.
In order to remap the vectors you have to do the following:
1. Reserve 0x40 bytes at 0x40000000 (Start of RAM)
2. At reset_handler, copy 0x40 bytes from 0x00004000 (start of your main app) to 0x40000000 (start of RAM).
3. Remap the interrupt Vector table (write correct setting to MEMMAP register)
Do you use interrupts (IRQ) in the bootloader?
Regards,
Alex
--- In l..., 42Bastian wrote:
>
> Sutton Mehaffey schrieb:
> > OK. Here are my map files for both bootloader and app (called vera1)
> >
> > http://www.lookoutportablesecurity.com/sutton/bootload.map
> >
> > http://www.lookoutportablesecurity.com/sutton/vera1.map
>
> _terminateio - Undefined Weak Reference
> version 0x00004000 Data
> 2 lookout.o(.ARM.__AT_0x00004000)
>
> ^^^^^ why/what is this at 0x4000 ?
>
> Reset_Handler 0x0000405c ARM Code
> 0 startup.o(RESET)
>
> It looks, you bootloader should jump at 0x405c !
> --
> 42Bastian
> ------------------
> Parts of this email are written with invisible ink.
>
> Note: SPAM-only account, direct mail to bs42@
>
It is clear from the .map files that you still haven't remap the interrupt vector table to RAM when entering your main application.
>From your previous message #44141
http://tech.groups.yahoo.com/group/lpc2000/message/44141
it is possible to see that you force the addresses of the interrupt vectors to be specific addresses after 0x4000
Vectors LDR PC, Reset_Addr
LDR PC, Undef_Addr
LDR PC, SWI_Addr
LDR PC, PAbt_Addr
LDR PC, DAbt_Addr
NOP ; Reserved Vector
; LDR PC, IRQ_Addr
LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
LDR PC, FIQ_Addr
Reset_Addr DCD Reset_Handler
Undef_Addr DCD 0x4004
SWI_Addr DCD 0x4008
PAbt_Addr DCD 0x400C
DAbt_Addr DCD 0x4010
DCD 0 ; Reserved Address
IRQ_Addr DCD 0x4014
FIQ_Addr DCD 0x401C
However, there is nothing indicating that those addresses contain the correct handler for each exception. In fact, what this code is doing is to make each interrupt vector point to itself, except for the IRQ vector.
Now, if you don't remap the interrupt vectors, the processor will use the vectors provided by the bootloader:
(see line 340 of the bootloader.map file)
Undef_Handler 0x00000040 ARM Code 4 startup.o(RESET)
SWI_Handler 0x00000044 ARM Code 4 startup.o(RESET)
PAbt_Handler 0x00000048 ARM Code 4 startup.o(RESET)
DAbt_Handler 0x0000004c ARM Code 4 startup.o(RESET)
IRQ_Handler 0x00000050 ARM Code 4 startup.o(RESET)
FIQ_Handler 0x00000054 ARM Code 4 startup.o(RESET)
These vectors probably are pointing to different interrupt handling routines.
In order to remap the vectors you have to do the following:
1. Reserve 0x40 bytes at 0x40000000 (Start of RAM)
2. At reset_handler, copy 0x40 bytes from 0x00004000 (start of your main app) to 0x40000000 (start of RAM).
3. Remap the interrupt Vector table (write correct setting to MEMMAP register)
Do you use interrupts (IRQ) in the bootloader?
Regards,
Alex
--- In l..., 42Bastian wrote:
>
> Sutton Mehaffey schrieb:
> > OK. Here are my map files for both bootloader and app (called vera1)
> >
> > http://www.lookoutportablesecurity.com/sutton/bootload.map
> >
> > http://www.lookoutportablesecurity.com/sutton/vera1.map
>
> _terminateio - Undefined Weak Reference
> version 0x00004000 Data
> 2 lookout.o(.ARM.__AT_0x00004000)
>
> ^^^^^ why/what is this at 0x4000 ?
>
> Reset_Handler 0x0000405c ARM Code
> 0 startup.o(RESET)
>
> It looks, you bootloader should jump at 0x405c !
> --
> 42Bastian
> ------------------
> Parts of this email are written with invisible ink.
>
> Note: SPAM-only account, direct mail to bs42@
>
Reply by ●August 21, 20092009-08-21
I'm with bastian, that lookout.o at 0x4000 shouldn't be there.
It should be startup.o, your reset vector (for app) is gone to 0x4004 ... I
suppose that the __AT 0x00004000 is your
image signature, but that's not good to be there.
Try jumping to 0x4004 instead of 0x4000, that will probably fix it, and...
.ARM.__AT_0x00004000 0x00004000 Section
2 lookout.o(.ARM.__AT_0x00004000)
RESET 0x00004004 Section
272 startup.o(RESET)
About the possible stack problems with IAP, that shouldn't happen,
your stack_top is low enough. depending on your code you may need more
stackmem that 4kB (if you're suffering of stack problems...)
Stack_Mem 0x400001a8 Data
4096 startup.o(STACK)
Stack_Top 0x40001230 Number
0 startup.o(STACK)
2009/8/21 alexander_ribero
> Hi Sutton:
>
> It is clear from the .map files that you still haven't remap the interrupt
> vector table to RAM when entering your main application.
>
> From your previous message #44141
> http://tech.groups.yahoo.com/group/lpc2000/message/44141
>
> it is possible to see that you force the addresses of the interrupt vectors
> to be specific addresses after 0x4000
> Vectors LDR PC, Reset_Addr
> LDR PC, Undef_Addr
> LDR PC, SWI_Addr
> LDR PC, PAbt_Addr
> LDR PC, DAbt_Addr
> NOP ; Reserved Vector
> ; LDR PC, IRQ_Addr
> LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> LDR PC, FIQ_Addr
>
> Reset_Addr DCD Reset_Handler
> Undef_Addr DCD 0x4004
> SWI_Addr DCD 0x4008
> PAbt_Addr DCD 0x400C
> DAbt_Addr DCD 0x4010
> DCD 0 ; Reserved Address
> IRQ_Addr DCD 0x4014
> FIQ_Addr DCD 0x401C
>
> However, there is nothing indicating that those addresses contain the
> correct handler for each exception. In fact, what this code is doing is to
> make each interrupt vector point to itself, except for the IRQ vector.
>
> Now, if you don't remap the interrupt vectors, the processor will use the
> vectors provided by the bootloader:
> (see line 340 of the bootloader.map file)
> Undef_Handler 0x00000040 ARM Code 4 startup.o(RESET)
> SWI_Handler 0x00000044 ARM Code 4 startup.o(RESET)
> PAbt_Handler 0x00000048 ARM Code 4 startup.o(RESET)
> DAbt_Handler 0x0000004c ARM Code 4 startup.o(RESET)
> IRQ_Handler 0x00000050 ARM Code 4 startup.o(RESET)
> FIQ_Handler 0x00000054 ARM Code 4 startup.o(RESET)
>
> These vectors probably are pointing to different interrupt handling
> routines.
>
> In order to remap the vectors you have to do the following:
>
> 1. Reserve 0x40 bytes at 0x40000000 (Start of RAM)
> 2. At reset_handler, copy 0x40 bytes from 0x00004000 (start of your main
> app) to 0x40000000 (start of RAM).
> 3. Remap the interrupt Vector table (write correct setting to MEMMAP
> register)
>
> Do you use interrupts (IRQ) in the bootloader?
>
> Regards,
>
> Alex
>
> --- In l... , 42Bastian
> wrote:
> >
> > Sutton Mehaffey schrieb:
> > > OK. Here are my map files for both bootloader and app (called vera1)
> > >
> > > http://www.lookoutportablesecurity.com/sutton/bootload.map
> > >
> > > http://www.lookoutportablesecurity.com/sutton/vera1.map
> >
> > _terminateio - Undefined Weak Reference
> > version 0x00004000 Data
> > 2 lookout.o(.ARM.__AT_0x00004000)
> >
> > ^^^^^ why/what is this at 0x4000 ?
> >
> > Reset_Handler 0x0000405c ARM Code
> > 0 startup.o(RESET)
> >
> > It looks, you bootloader should jump at 0x405c !
> >
> >
> > --
> > 42Bastian
> > ------------------
> > Parts of this email are written with invisible ink.
> >
> > Note: SPAM-only account, direct mail to bs42@
> >
>
--
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
It should be startup.o, your reset vector (for app) is gone to 0x4004 ... I
suppose that the __AT 0x00004000 is your
image signature, but that's not good to be there.
Try jumping to 0x4004 instead of 0x4000, that will probably fix it, and...
.ARM.__AT_0x00004000 0x00004000 Section
2 lookout.o(.ARM.__AT_0x00004000)
RESET 0x00004004 Section
272 startup.o(RESET)
About the possible stack problems with IAP, that shouldn't happen,
your stack_top is low enough. depending on your code you may need more
stackmem that 4kB (if you're suffering of stack problems...)
Stack_Mem 0x400001a8 Data
4096 startup.o(STACK)
Stack_Top 0x40001230 Number
0 startup.o(STACK)
2009/8/21 alexander_ribero
> Hi Sutton:
>
> It is clear from the .map files that you still haven't remap the interrupt
> vector table to RAM when entering your main application.
>
> From your previous message #44141
> http://tech.groups.yahoo.com/group/lpc2000/message/44141
>
> it is possible to see that you force the addresses of the interrupt vectors
> to be specific addresses after 0x4000
> Vectors LDR PC, Reset_Addr
> LDR PC, Undef_Addr
> LDR PC, SWI_Addr
> LDR PC, PAbt_Addr
> LDR PC, DAbt_Addr
> NOP ; Reserved Vector
> ; LDR PC, IRQ_Addr
> LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> LDR PC, FIQ_Addr
>
> Reset_Addr DCD Reset_Handler
> Undef_Addr DCD 0x4004
> SWI_Addr DCD 0x4008
> PAbt_Addr DCD 0x400C
> DAbt_Addr DCD 0x4010
> DCD 0 ; Reserved Address
> IRQ_Addr DCD 0x4014
> FIQ_Addr DCD 0x401C
>
> However, there is nothing indicating that those addresses contain the
> correct handler for each exception. In fact, what this code is doing is to
> make each interrupt vector point to itself, except for the IRQ vector.
>
> Now, if you don't remap the interrupt vectors, the processor will use the
> vectors provided by the bootloader:
> (see line 340 of the bootloader.map file)
> Undef_Handler 0x00000040 ARM Code 4 startup.o(RESET)
> SWI_Handler 0x00000044 ARM Code 4 startup.o(RESET)
> PAbt_Handler 0x00000048 ARM Code 4 startup.o(RESET)
> DAbt_Handler 0x0000004c ARM Code 4 startup.o(RESET)
> IRQ_Handler 0x00000050 ARM Code 4 startup.o(RESET)
> FIQ_Handler 0x00000054 ARM Code 4 startup.o(RESET)
>
> These vectors probably are pointing to different interrupt handling
> routines.
>
> In order to remap the vectors you have to do the following:
>
> 1. Reserve 0x40 bytes at 0x40000000 (Start of RAM)
> 2. At reset_handler, copy 0x40 bytes from 0x00004000 (start of your main
> app) to 0x40000000 (start of RAM).
> 3. Remap the interrupt Vector table (write correct setting to MEMMAP
> register)
>
> Do you use interrupts (IRQ) in the bootloader?
>
> Regards,
>
> Alex
>
> --- In l... , 42Bastian
> wrote:
> >
> > Sutton Mehaffey schrieb:
> > > OK. Here are my map files for both bootloader and app (called vera1)
> > >
> > > http://www.lookoutportablesecurity.com/sutton/bootload.map
> > >
> > > http://www.lookoutportablesecurity.com/sutton/vera1.map
> >
> > _terminateio - Undefined Weak Reference
> > version 0x00004000 Data
> > 2 lookout.o(.ARM.__AT_0x00004000)
> >
> > ^^^^^ why/what is this at 0x4000 ?
> >
> > Reset_Handler 0x0000405c ARM Code
> > 0 startup.o(RESET)
> >
> > It looks, you bootloader should jump at 0x405c !
> >
> >
> > --
> > 42Bastian
> > ------------------
> > Parts of this email are written with invisible ink.
> >
> > Note: SPAM-only account, direct mail to bs42@
> >
>
--
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
Reply by ●August 21, 20092009-08-21
Alex,
I see what you are saying. Let me revamp and see if I can figure things
out.
I never had applications that required loading at other locations than
0, or had any need to change any parameters in startup in the many years
of developing systems. So, I am a little rusty at how all that stuff
works in startup.
I actually thought that since each project (bootloader and app) was
compiled separately that each would have it's own physical vector space.
I thought the compiler and linker would take care of that. A little
naive, I guess.
So, when I load the bootloader and then the app from the JTAG, there
must be some remapping taking place during the app load that I don't
know about. If the bootloader is loaded at 0, can you explain what
exactly happens when you load the app at 0x4000 as far as the remapping
goes? Keil's loading procedure must be doing the same thing that I need
to do on my upload. Does the uploading of the app overwrite pointers
that the remap fixes?
Maybe when it starts working, I'll finally understand what all you guys
have been trying to explain to me for the last week. But, until then
I'll muddle through the manual again and again. I appreciate
everybody's input.
Maybe I need to ask Keil some questions. But, they have yet to answer 2
sets of questions in a 2 week period.
By the way, jumping to 0x4004 doesn't work. Still hangs. I tried
0x405C (which is the reset handler that bastian pointed out in the map)
and same thing. However, to my surprise, it still works if you load the
app from the JTAG and jump to 0x4004.
Sutton
alexander_ribero wrote:
>
>
> Hi Sutton:
>
> It is clear from the .map files that you still haven't remap the
> interrupt vector table to RAM when entering your main application.
>
> >From your previous message #44141
> http://tech.groups.yahoo.com/group/lpc2000/message/44141
> it is possible to see that you force the addresses of the interrupt
> vectors to be specific addresses after 0x4000
>
> Vectors LDR PC, Reset_Addr
> LDR PC, Undef_Addr
> LDR PC, SWI_Addr
> LDR PC, PAbt_Addr
> LDR PC, DAbt_Addr
> NOP ; Reserved Vector
> ; LDR PC, IRQ_Addr
> LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> LDR PC, FIQ_Addr
>
> Reset_Addr DCD Reset_Handler
> Undef_Addr DCD 0x4004
> SWI_Addr DCD 0x4008
> PAbt_Addr DCD 0x400C
> DAbt_Addr DCD 0x4010
> DCD 0 ; Reserved Address
> IRQ_Addr DCD 0x4014
> FIQ_Addr DCD 0x401C
>
> However, there is nothing indicating that those addresses contain the
> correct handler for each exception. In fact, what this code is doing is
> to make each interrupt vector point to itself, except for the IRQ vector.
>
> Now, if you don't remap the interrupt vectors, the processor will use
> the vectors provided by the bootloader:
> (see line 340 of the bootloader.map file)
> Undef_Handler 0x00000040 ARM Code 4 startup.o(RESET)
> SWI_Handler 0x00000044 ARM Code 4 startup.o(RESET)
> PAbt_Handler 0x00000048 ARM Code 4 startup.o(RESET)
> DAbt_Handler 0x0000004c ARM Code 4 startup.o(RESET)
> IRQ_Handler 0x00000050 ARM Code 4 startup.o(RESET)
> FIQ_Handler 0x00000054 ARM Code 4 startup.o(RESET)
>
> These vectors probably are pointing to different interrupt handling
> routines.
>
> In order to remap the vectors you have to do the following:
>
> 1. Reserve 0x40 bytes at 0x40000000 (Start of RAM)
> 2. At reset_handler, copy 0x40 bytes from 0x00004000 (start of your main
> app) to 0x40000000 (start of RAM).
> 3. Remap the interrupt Vector table (write correct setting to MEMMAP
> register)
>
> Do you use interrupts (IRQ) in the bootloader?
>
> Regards,
>
> Alex
>
> --- In l... ,
> 42Bastian wrote:
> >
> > Sutton Mehaffey schrieb:
> > > OK. Here are my map files for both bootloader and app (called vera1)
> > >
> > > http://www.lookoutportablesecurity.com/sutton/bootload.map
>
> > >
> > > http://www.lookoutportablesecurity.com/sutton/vera1.map
>
> >
> > _terminateio - Undefined Weak Reference
> > version 0x00004000 Data
> > 2 lookout.o(.ARM.__AT_0x00004000)
> >
> > ^^^^^ why/what is this at 0x4000 ?
> >
> > Reset_Handler 0x0000405c ARM Code
> > 0 startup.o(RESET)
> >
> > It looks, you bootloader should jump at 0x405c !
> >
> >
> > --
> > 42Bastian
> > ------------------
> > Parts of this email are written with invisible ink.
> >
> > Note: SPAM-only account, direct mail to bs42@
> >
--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
I see what you are saying. Let me revamp and see if I can figure things
out.
I never had applications that required loading at other locations than
0, or had any need to change any parameters in startup in the many years
of developing systems. So, I am a little rusty at how all that stuff
works in startup.
I actually thought that since each project (bootloader and app) was
compiled separately that each would have it's own physical vector space.
I thought the compiler and linker would take care of that. A little
naive, I guess.
So, when I load the bootloader and then the app from the JTAG, there
must be some remapping taking place during the app load that I don't
know about. If the bootloader is loaded at 0, can you explain what
exactly happens when you load the app at 0x4000 as far as the remapping
goes? Keil's loading procedure must be doing the same thing that I need
to do on my upload. Does the uploading of the app overwrite pointers
that the remap fixes?
Maybe when it starts working, I'll finally understand what all you guys
have been trying to explain to me for the last week. But, until then
I'll muddle through the manual again and again. I appreciate
everybody's input.
Maybe I need to ask Keil some questions. But, they have yet to answer 2
sets of questions in a 2 week period.
By the way, jumping to 0x4004 doesn't work. Still hangs. I tried
0x405C (which is the reset handler that bastian pointed out in the map)
and same thing. However, to my surprise, it still works if you load the
app from the JTAG and jump to 0x4004.
Sutton
alexander_ribero wrote:
>
>
> Hi Sutton:
>
> It is clear from the .map files that you still haven't remap the
> interrupt vector table to RAM when entering your main application.
>
> >From your previous message #44141
> http://tech.groups.yahoo.com/group/lpc2000/message/44141
> it is possible to see that you force the addresses of the interrupt
> vectors to be specific addresses after 0x4000
>
> Vectors LDR PC, Reset_Addr
> LDR PC, Undef_Addr
> LDR PC, SWI_Addr
> LDR PC, PAbt_Addr
> LDR PC, DAbt_Addr
> NOP ; Reserved Vector
> ; LDR PC, IRQ_Addr
> LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> LDR PC, FIQ_Addr
>
> Reset_Addr DCD Reset_Handler
> Undef_Addr DCD 0x4004
> SWI_Addr DCD 0x4008
> PAbt_Addr DCD 0x400C
> DAbt_Addr DCD 0x4010
> DCD 0 ; Reserved Address
> IRQ_Addr DCD 0x4014
> FIQ_Addr DCD 0x401C
>
> However, there is nothing indicating that those addresses contain the
> correct handler for each exception. In fact, what this code is doing is
> to make each interrupt vector point to itself, except for the IRQ vector.
>
> Now, if you don't remap the interrupt vectors, the processor will use
> the vectors provided by the bootloader:
> (see line 340 of the bootloader.map file)
> Undef_Handler 0x00000040 ARM Code 4 startup.o(RESET)
> SWI_Handler 0x00000044 ARM Code 4 startup.o(RESET)
> PAbt_Handler 0x00000048 ARM Code 4 startup.o(RESET)
> DAbt_Handler 0x0000004c ARM Code 4 startup.o(RESET)
> IRQ_Handler 0x00000050 ARM Code 4 startup.o(RESET)
> FIQ_Handler 0x00000054 ARM Code 4 startup.o(RESET)
>
> These vectors probably are pointing to different interrupt handling
> routines.
>
> In order to remap the vectors you have to do the following:
>
> 1. Reserve 0x40 bytes at 0x40000000 (Start of RAM)
> 2. At reset_handler, copy 0x40 bytes from 0x00004000 (start of your main
> app) to 0x40000000 (start of RAM).
> 3. Remap the interrupt Vector table (write correct setting to MEMMAP
> register)
>
> Do you use interrupts (IRQ) in the bootloader?
>
> Regards,
>
> Alex
>
> --- In l... ,
> 42Bastian wrote:
> >
> > Sutton Mehaffey schrieb:
> > > OK. Here are my map files for both bootloader and app (called vera1)
> > >
> > > http://www.lookoutportablesecurity.com/sutton/bootload.map
>
> > >
> > > http://www.lookoutportablesecurity.com/sutton/vera1.map
>
> >
> > _terminateio - Undefined Weak Reference
> > version 0x00004000 Data
> > 2 lookout.o(.ARM.__AT_0x00004000)
> >
> > ^^^^^ why/what is this at 0x4000 ?
> >
> > Reset_Handler 0x0000405c ARM Code
> > 0 startup.o(RESET)
> >
> > It looks, you bootloader should jump at 0x405c !
> >
> >
> > --
> > 42Bastian
> > ------------------
> > Parts of this email are written with invisible ink.
> >
> > Note: SPAM-only account, direct mail to bs42@
> >
--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
Reply by ●August 21, 20092009-08-21
Hi:
It seems that you are doing what needs to be done to jump correctly to the main app. I'm now wondering (as some others have done) if the data written at 0x4000 is the correct data.
It is correct in the sense that you check byte by byte all the way from the SD card to the Flash. Therefore, it is possible that the data in the SD card is not valid: that is, the binary file is incorrect.
I use the following command to generate the binary file:
c:\keil\arm\bin31\fromelf --bin --output .bin .axf
1. Could you verify that this binary file and the one generated by hex2bin matches?
2. Can you dump the memory at 0x4000 after writing data from the SD card and confirm that this data matches with the binary file generated by fromelf, and that it is indeed the main app code?
Your last comments about how the main app still fails after the jump, but not when program via JTAG, prompted the memory and files questions.
I've look at the remapping concept and for very simple applications, like yours, it might not be required, as the IRQ interrupt vector always points to the same location (VICAddress) in both the bootloader and the main appl.
Regards,
Alex
--- In l..., Sutton Mehaffey wrote:
>
> Alex,
>
> I see what you are saying. Let me revamp and see if I can figure things
> out.
>
> I never had applications that required loading at other locations than
> 0, or had any need to change any parameters in startup in the many years
> of developing systems. So, I am a little rusty at how all that stuff
> works in startup.
>
> I actually thought that since each project (bootloader and app) was
> compiled separately that each would have it's own physical vector space.
> I thought the compiler and linker would take care of that. A little
> naive, I guess.
>
> So, when I load the bootloader and then the app from the JTAG, there
> must be some remapping taking place during the app load that I don't
> know about. If the bootloader is loaded at 0, can you explain what
> exactly happens when you load the app at 0x4000 as far as the remapping
> goes? Keil's loading procedure must be doing the same thing that I need
> to do on my upload. Does the uploading of the app overwrite pointers
> that the remap fixes?
>
> Maybe when it starts working, I'll finally understand what all you guys
> have been trying to explain to me for the last week. But, until then
> I'll muddle through the manual again and again. I appreciate
> everybody's input.
>
> Maybe I need to ask Keil some questions. But, they have yet to answer 2
> sets of questions in a 2 week period.
>
> By the way, jumping to 0x4004 doesn't work. Still hangs. I tried
> 0x405C (which is the reset handler that bastian pointed out in the map)
> and same thing. However, to my surprise, it still works if you load the
> app from the JTAG and jump to 0x4004.
>
> Sutton
>
> alexander_ribero wrote:
> >
> >
> > Hi Sutton:
> >
> > It is clear from the .map files that you still haven't remap the
> > interrupt vector table to RAM when entering your main application.
> >
> > >From your previous message #44141
> > http://tech.groups.yahoo.com/group/lpc2000/message/44141
> >
> >
> > it is possible to see that you force the addresses of the interrupt
> > vectors to be specific addresses after 0x4000
> >
> > Vectors LDR PC, Reset_Addr
> > LDR PC, Undef_Addr
> > LDR PC, SWI_Addr
> > LDR PC, PAbt_Addr
> > LDR PC, DAbt_Addr
> > NOP ; Reserved Vector
> > ; LDR PC, IRQ_Addr
> > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > LDR PC, FIQ_Addr
> >
> > Reset_Addr DCD Reset_Handler
> > Undef_Addr DCD 0x4004
> > SWI_Addr DCD 0x4008
> > PAbt_Addr DCD 0x400C
> > DAbt_Addr DCD 0x4010
> > DCD 0 ; Reserved Address
> > IRQ_Addr DCD 0x4014
> > FIQ_Addr DCD 0x401C
> >
> > However, there is nothing indicating that those addresses contain the
> > correct handler for each exception. In fact, what this code is doing is
> > to make each interrupt vector point to itself, except for the IRQ vector.
> >
> > Now, if you don't remap the interrupt vectors, the processor will use
> > the vectors provided by the bootloader:
> > (see line 340 of the bootloader.map file)
> > Undef_Handler 0x00000040 ARM Code 4 startup.o(RESET)
> > SWI_Handler 0x00000044 ARM Code 4 startup.o(RESET)
> > PAbt_Handler 0x00000048 ARM Code 4 startup.o(RESET)
> > DAbt_Handler 0x0000004c ARM Code 4 startup.o(RESET)
> > IRQ_Handler 0x00000050 ARM Code 4 startup.o(RESET)
> > FIQ_Handler 0x00000054 ARM Code 4 startup.o(RESET)
> >
> > These vectors probably are pointing to different interrupt handling
> > routines.
> >
> > In order to remap the vectors you have to do the following:
> >
> > 1. Reserve 0x40 bytes at 0x40000000 (Start of RAM)
> > 2. At reset_handler, copy 0x40 bytes from 0x00004000 (start of your main
> > app) to 0x40000000 (start of RAM).
> > 3. Remap the interrupt Vector table (write correct setting to MEMMAP
> > register)
> >
> > Do you use interrupts (IRQ) in the bootloader?
> >
> > Regards,
> >
> > Alex
> >
> > --- In l... ,
> > 42Bastian wrote:
> > >
> > > Sutton Mehaffey schrieb:
> > > > OK. Here are my map files for both bootloader and app (called vera1)
> > > >
> > > > http://www.lookoutportablesecurity.com/sutton/bootload.map
> >
> > > >
> > > > http://www.lookoutportablesecurity.com/sutton/vera1.map
> >
> > >
> > > _terminateio - Undefined Weak Reference
> > > version 0x00004000 Data
> > > 2 lookout.o(.ARM.__AT_0x00004000)
> > >
> > > ^^^^^ why/what is this at 0x4000 ?
> > >
> > > Reset_Handler 0x0000405c ARM Code
> > > 0 startup.o(RESET)
> > >
> > > It looks, you bootloader should jump at 0x405c !
> > >
> > >
> > > --
> > > 42Bastian
> > > ------------------
> > > Parts of this email are written with invisible ink.
> > >
> > > Note: SPAM-only account, direct mail to bs42@
> > >
> >
> > --
> Sutton Mehaffey
> Lookout Portable Security
> 4040 Royal Dr.
> Kennesaw, GA 30144
> 770-514-7999, 800-207-6269
> Fax: 770-514-1285
> http://www.lookoutportablesecurity.com
> sutton@...
>
It seems that you are doing what needs to be done to jump correctly to the main app. I'm now wondering (as some others have done) if the data written at 0x4000 is the correct data.
It is correct in the sense that you check byte by byte all the way from the SD card to the Flash. Therefore, it is possible that the data in the SD card is not valid: that is, the binary file is incorrect.
I use the following command to generate the binary file:
c:\keil\arm\bin31\fromelf --bin --output .bin .axf
1. Could you verify that this binary file and the one generated by hex2bin matches?
2. Can you dump the memory at 0x4000 after writing data from the SD card and confirm that this data matches with the binary file generated by fromelf, and that it is indeed the main app code?
Your last comments about how the main app still fails after the jump, but not when program via JTAG, prompted the memory and files questions.
I've look at the remapping concept and for very simple applications, like yours, it might not be required, as the IRQ interrupt vector always points to the same location (VICAddress) in both the bootloader and the main appl.
Regards,
Alex
--- In l..., Sutton Mehaffey wrote:
>
> Alex,
>
> I see what you are saying. Let me revamp and see if I can figure things
> out.
>
> I never had applications that required loading at other locations than
> 0, or had any need to change any parameters in startup in the many years
> of developing systems. So, I am a little rusty at how all that stuff
> works in startup.
>
> I actually thought that since each project (bootloader and app) was
> compiled separately that each would have it's own physical vector space.
> I thought the compiler and linker would take care of that. A little
> naive, I guess.
>
> So, when I load the bootloader and then the app from the JTAG, there
> must be some remapping taking place during the app load that I don't
> know about. If the bootloader is loaded at 0, can you explain what
> exactly happens when you load the app at 0x4000 as far as the remapping
> goes? Keil's loading procedure must be doing the same thing that I need
> to do on my upload. Does the uploading of the app overwrite pointers
> that the remap fixes?
>
> Maybe when it starts working, I'll finally understand what all you guys
> have been trying to explain to me for the last week. But, until then
> I'll muddle through the manual again and again. I appreciate
> everybody's input.
>
> Maybe I need to ask Keil some questions. But, they have yet to answer 2
> sets of questions in a 2 week period.
>
> By the way, jumping to 0x4004 doesn't work. Still hangs. I tried
> 0x405C (which is the reset handler that bastian pointed out in the map)
> and same thing. However, to my surprise, it still works if you load the
> app from the JTAG and jump to 0x4004.
>
> Sutton
>
> alexander_ribero wrote:
> >
> >
> > Hi Sutton:
> >
> > It is clear from the .map files that you still haven't remap the
> > interrupt vector table to RAM when entering your main application.
> >
> > >From your previous message #44141
> > http://tech.groups.yahoo.com/group/lpc2000/message/44141
> >
> >
> > it is possible to see that you force the addresses of the interrupt
> > vectors to be specific addresses after 0x4000
> >
> > Vectors LDR PC, Reset_Addr
> > LDR PC, Undef_Addr
> > LDR PC, SWI_Addr
> > LDR PC, PAbt_Addr
> > LDR PC, DAbt_Addr
> > NOP ; Reserved Vector
> > ; LDR PC, IRQ_Addr
> > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > LDR PC, FIQ_Addr
> >
> > Reset_Addr DCD Reset_Handler
> > Undef_Addr DCD 0x4004
> > SWI_Addr DCD 0x4008
> > PAbt_Addr DCD 0x400C
> > DAbt_Addr DCD 0x4010
> > DCD 0 ; Reserved Address
> > IRQ_Addr DCD 0x4014
> > FIQ_Addr DCD 0x401C
> >
> > However, there is nothing indicating that those addresses contain the
> > correct handler for each exception. In fact, what this code is doing is
> > to make each interrupt vector point to itself, except for the IRQ vector.
> >
> > Now, if you don't remap the interrupt vectors, the processor will use
> > the vectors provided by the bootloader:
> > (see line 340 of the bootloader.map file)
> > Undef_Handler 0x00000040 ARM Code 4 startup.o(RESET)
> > SWI_Handler 0x00000044 ARM Code 4 startup.o(RESET)
> > PAbt_Handler 0x00000048 ARM Code 4 startup.o(RESET)
> > DAbt_Handler 0x0000004c ARM Code 4 startup.o(RESET)
> > IRQ_Handler 0x00000050 ARM Code 4 startup.o(RESET)
> > FIQ_Handler 0x00000054 ARM Code 4 startup.o(RESET)
> >
> > These vectors probably are pointing to different interrupt handling
> > routines.
> >
> > In order to remap the vectors you have to do the following:
> >
> > 1. Reserve 0x40 bytes at 0x40000000 (Start of RAM)
> > 2. At reset_handler, copy 0x40 bytes from 0x00004000 (start of your main
> > app) to 0x40000000 (start of RAM).
> > 3. Remap the interrupt Vector table (write correct setting to MEMMAP
> > register)
> >
> > Do you use interrupts (IRQ) in the bootloader?
> >
> > Regards,
> >
> > Alex
> >
> > --- In l... ,
> > 42Bastian wrote:
> > >
> > > Sutton Mehaffey schrieb:
> > > > OK. Here are my map files for both bootloader and app (called vera1)
> > > >
> > > > http://www.lookoutportablesecurity.com/sutton/bootload.map
> >
> > > >
> > > > http://www.lookoutportablesecurity.com/sutton/vera1.map
> >
> > >
> > > _terminateio - Undefined Weak Reference
> > > version 0x00004000 Data
> > > 2 lookout.o(.ARM.__AT_0x00004000)
> > >
> > > ^^^^^ why/what is this at 0x4000 ?
> > >
> > > Reset_Handler 0x0000405c ARM Code
> > > 0 startup.o(RESET)
> > >
> > > It looks, you bootloader should jump at 0x405c !
> > >
> > >
> > > --
> > > 42Bastian
> > > ------------------
> > > Parts of this email are written with invisible ink.
> > >
> > > Note: SPAM-only account, direct mail to bs42@
> > >
> >
> > --
> Sutton Mehaffey
> Lookout Portable Security
> 4040 Royal Dr.
> Kennesaw, GA 30144
> 770-514-7999, 800-207-6269
> Fax: 770-514-1285
> http://www.lookoutportablesecurity.com
> sutton@...
>
Reply by ●August 21, 20092009-08-21
I'm still playing with it, but that appears to have fixed the problem.
The .bin file created by Hex2Bin from the Keil .hex file has 18 other
bytes it. 6 of which were the loading address of 0x4000, which I had
compensated for, but there were 12 other bytes that I haven't figured
out what's going on there.
But, it appears that fromelf makes the proper .bin file for uploading.
And, my version definition at 0x4000 still works. The compilation must
adjust for that and start at 0x4004.
Thanks to all. I'm still trying to figure out what the problem is with
the hex2bin conversion. I'll follow up if I figure out anything.
Sutton
alexander_ribero wrote:
>
>
> Hi:
>
> It seems that you are doing what needs to be done to jump correctly to
> the main app. I'm now wondering (as some others have done) if the data
> written at 0x4000 is the correct data.
>
> It is correct in the sense that you check byte by byte all the way from
> the SD card to the Flash. Therefore, it is possible that the data in the
> SD card is not valid: that is, the binary file is incorrect.
>
> I use the following command to generate the binary file:
>
> c:\keil\arm\bin31\fromelf --bin --output .bin
> .axf
>
> 1. Could you verify that this binary file and the one generated by
> hex2bin matches?
>
> 2. Can you dump the memory at 0x4000 after writing data from the SD card
> and confirm that this data matches with the binary file generated by
> fromelf, and that it is indeed the main app code?
>
> Your last comments about how the main app still fails after the jump,
> but not when program via JTAG, prompted the memory and files questions.
>
> I've look at the remapping concept and for very simple applications,
> like yours, it might not be required, as the IRQ interrupt vector always
> points to the same location (VICAddress) in both the bootloader and the
> main appl.
>
> Regards,
>
> Alex
>
> --- In l... ,
> Sutton Mehaffey wrote:
> >
> > Alex,
> >
> > I see what you are saying. Let me revamp and see if I can figure things
> > out.
> >
> > I never had applications that required loading at other locations than
> > 0, or had any need to change any parameters in startup in the many years
> > of developing systems. So, I am a little rusty at how all that stuff
> > works in startup.
> >
> > I actually thought that since each project (bootloader and app) was
> > compiled separately that each would have it's own physical vector space.
> > I thought the compiler and linker would take care of that. A little
> > naive, I guess.
> >
> > So, when I load the bootloader and then the app from the JTAG, there
> > must be some remapping taking place during the app load that I don't
> > know about. If the bootloader is loaded at 0, can you explain what
> > exactly happens when you load the app at 0x4000 as far as the remapping
> > goes? Keil's loading procedure must be doing the same thing that I need
> > to do on my upload. Does the uploading of the app overwrite pointers
> > that the remap fixes?
> >
> > Maybe when it starts working, I'll finally understand what all you guys
> > have been trying to explain to me for the last week. But, until then
> > I'll muddle through the manual again and again. I appreciate
> > everybody's input.
> >
> > Maybe I need to ask Keil some questions. But, they have yet to answer 2
> > sets of questions in a 2 week period.
> >
> > By the way, jumping to 0x4004 doesn't work. Still hangs. I tried
> > 0x405C (which is the reset handler that bastian pointed out in the map)
> > and same thing. However, to my surprise, it still works if you load the
> > app from the JTAG and jump to 0x4004.
> >
> > Sutton
> >
> >
> >
> > alexander_ribero wrote:
> > >
> > >
> > > Hi Sutton:
> > >
> > > It is clear from the .map files that you still haven't remap the
> > > interrupt vector table to RAM when entering your main application.
> > >
> > > >From your previous message #44141
> > > http://tech.groups.yahoo.com/group/lpc2000/message/44141
>
> > > > >
> > >
> > > it is possible to see that you force the addresses of the interrupt
> > > vectors to be specific addresses after 0x4000
> > >
> > > Vectors LDR PC, Reset_Addr
> > > LDR PC, Undef_Addr
> > > LDR PC, SWI_Addr
> > > LDR PC, PAbt_Addr
> > > LDR PC, DAbt_Addr
> > > NOP ; Reserved Vector
> > > ; LDR PC, IRQ_Addr
> > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > LDR PC, FIQ_Addr
> > >
> > > Reset_Addr DCD Reset_Handler
> > > Undef_Addr DCD 0x4004
> > > SWI_Addr DCD 0x4008
> > > PAbt_Addr DCD 0x400C
> > > DAbt_Addr DCD 0x4010
> > > DCD 0 ; Reserved Address
> > > IRQ_Addr DCD 0x4014
> > > FIQ_Addr DCD 0x401C
> > >
> > > However, there is nothing indicating that those addresses contain the
> > > correct handler for each exception. In fact, what this code is
> doing is
> > > to make each interrupt vector point to itself, except for the IRQ
> vector.
> > >
> > > Now, if you don't remap the interrupt vectors, the processor will use
> > > the vectors provided by the bootloader:
> > > (see line 340 of the bootloader.map file)
> > > Undef_Handler 0x00000040 ARM Code 4 startup.o(RESET)
> > > SWI_Handler 0x00000044 ARM Code 4 startup.o(RESET)
> > > PAbt_Handler 0x00000048 ARM Code 4 startup.o(RESET)
> > > DAbt_Handler 0x0000004c ARM Code 4 startup.o(RESET)
> > > IRQ_Handler 0x00000050 ARM Code 4 startup.o(RESET)
> > > FIQ_Handler 0x00000054 ARM Code 4 startup.o(RESET)
> > >
> > > These vectors probably are pointing to different interrupt handling
> > > routines.
> > >
> > > In order to remap the vectors you have to do the following:
> > >
> > > 1. Reserve 0x40 bytes at 0x40000000 (Start of RAM)
> > > 2. At reset_handler, copy 0x40 bytes from 0x00004000 (start of your
> main
> > > app) to 0x40000000 (start of RAM).
> > > 3. Remap the interrupt Vector table (write correct setting to MEMMAP
> > > register)
> > >
> > > Do you use interrupts (IRQ) in the bootloader?
> > >
> > > Regards,
> > >
> > > Alex
> > >
> > > --- In l...
> ,
> > > 42Bastian wrote:
> > > >
> > > > Sutton Mehaffey schrieb:
> > > > > OK. Here are my map files for both bootloader and app (called
> vera1)
> > > > >
> > > > > http://www.lookoutportablesecurity.com/sutton/bootload.map
>
> > > > >
> > > > >
> > > > > http://www.lookoutportablesecurity.com/sutton/vera1.map
>
> > > > >
> > > >
> > > > _terminateio - Undefined Weak Reference
> > > > version 0x00004000 Data
> > > > 2 lookout.o(.ARM.__AT_0x00004000)
> > > >
> > > > ^^^^^ why/what is this at 0x4000 ?
> > > >
> > > > Reset_Handler 0x0000405c ARM Code
> > > > 0 startup.o(RESET)
> > > >
> > > > It looks, you bootloader should jump at 0x405c !
> > > >
> > > >
> > > > --
> > > > 42Bastian
> > > > ------------------
> > > > Parts of this email are written with invisible ink.
> > > >
> > > > Note: SPAM-only account, direct mail to bs42@
> > > >
> > >
> > >
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr.
> > Kennesaw, GA 30144
> > 770-514-7999, 800-207-6269
> > Fax: 770-514-1285
> > http://www.lookoutportablesecurity.com
>
> > sutton@...
> >
--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
The .bin file created by Hex2Bin from the Keil .hex file has 18 other
bytes it. 6 of which were the loading address of 0x4000, which I had
compensated for, but there were 12 other bytes that I haven't figured
out what's going on there.
But, it appears that fromelf makes the proper .bin file for uploading.
And, my version definition at 0x4000 still works. The compilation must
adjust for that and start at 0x4004.
Thanks to all. I'm still trying to figure out what the problem is with
the hex2bin conversion. I'll follow up if I figure out anything.
Sutton
alexander_ribero wrote:
>
>
> Hi:
>
> It seems that you are doing what needs to be done to jump correctly to
> the main app. I'm now wondering (as some others have done) if the data
> written at 0x4000 is the correct data.
>
> It is correct in the sense that you check byte by byte all the way from
> the SD card to the Flash. Therefore, it is possible that the data in the
> SD card is not valid: that is, the binary file is incorrect.
>
> I use the following command to generate the binary file:
>
> c:\keil\arm\bin31\fromelf --bin --output .bin
> .axf
>
> 1. Could you verify that this binary file and the one generated by
> hex2bin matches?
>
> 2. Can you dump the memory at 0x4000 after writing data from the SD card
> and confirm that this data matches with the binary file generated by
> fromelf, and that it is indeed the main app code?
>
> Your last comments about how the main app still fails after the jump,
> but not when program via JTAG, prompted the memory and files questions.
>
> I've look at the remapping concept and for very simple applications,
> like yours, it might not be required, as the IRQ interrupt vector always
> points to the same location (VICAddress) in both the bootloader and the
> main appl.
>
> Regards,
>
> Alex
>
> --- In l... ,
> Sutton Mehaffey wrote:
> >
> > Alex,
> >
> > I see what you are saying. Let me revamp and see if I can figure things
> > out.
> >
> > I never had applications that required loading at other locations than
> > 0, or had any need to change any parameters in startup in the many years
> > of developing systems. So, I am a little rusty at how all that stuff
> > works in startup.
> >
> > I actually thought that since each project (bootloader and app) was
> > compiled separately that each would have it's own physical vector space.
> > I thought the compiler and linker would take care of that. A little
> > naive, I guess.
> >
> > So, when I load the bootloader and then the app from the JTAG, there
> > must be some remapping taking place during the app load that I don't
> > know about. If the bootloader is loaded at 0, can you explain what
> > exactly happens when you load the app at 0x4000 as far as the remapping
> > goes? Keil's loading procedure must be doing the same thing that I need
> > to do on my upload. Does the uploading of the app overwrite pointers
> > that the remap fixes?
> >
> > Maybe when it starts working, I'll finally understand what all you guys
> > have been trying to explain to me for the last week. But, until then
> > I'll muddle through the manual again and again. I appreciate
> > everybody's input.
> >
> > Maybe I need to ask Keil some questions. But, they have yet to answer 2
> > sets of questions in a 2 week period.
> >
> > By the way, jumping to 0x4004 doesn't work. Still hangs. I tried
> > 0x405C (which is the reset handler that bastian pointed out in the map)
> > and same thing. However, to my surprise, it still works if you load the
> > app from the JTAG and jump to 0x4004.
> >
> > Sutton
> >
> >
> >
> > alexander_ribero wrote:
> > >
> > >
> > > Hi Sutton:
> > >
> > > It is clear from the .map files that you still haven't remap the
> > > interrupt vector table to RAM when entering your main application.
> > >
> > > >From your previous message #44141
> > > http://tech.groups.yahoo.com/group/lpc2000/message/44141
>
> > > > >
> > >
> > > it is possible to see that you force the addresses of the interrupt
> > > vectors to be specific addresses after 0x4000
> > >
> > > Vectors LDR PC, Reset_Addr
> > > LDR PC, Undef_Addr
> > > LDR PC, SWI_Addr
> > > LDR PC, PAbt_Addr
> > > LDR PC, DAbt_Addr
> > > NOP ; Reserved Vector
> > > ; LDR PC, IRQ_Addr
> > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > LDR PC, FIQ_Addr
> > >
> > > Reset_Addr DCD Reset_Handler
> > > Undef_Addr DCD 0x4004
> > > SWI_Addr DCD 0x4008
> > > PAbt_Addr DCD 0x400C
> > > DAbt_Addr DCD 0x4010
> > > DCD 0 ; Reserved Address
> > > IRQ_Addr DCD 0x4014
> > > FIQ_Addr DCD 0x401C
> > >
> > > However, there is nothing indicating that those addresses contain the
> > > correct handler for each exception. In fact, what this code is
> doing is
> > > to make each interrupt vector point to itself, except for the IRQ
> vector.
> > >
> > > Now, if you don't remap the interrupt vectors, the processor will use
> > > the vectors provided by the bootloader:
> > > (see line 340 of the bootloader.map file)
> > > Undef_Handler 0x00000040 ARM Code 4 startup.o(RESET)
> > > SWI_Handler 0x00000044 ARM Code 4 startup.o(RESET)
> > > PAbt_Handler 0x00000048 ARM Code 4 startup.o(RESET)
> > > DAbt_Handler 0x0000004c ARM Code 4 startup.o(RESET)
> > > IRQ_Handler 0x00000050 ARM Code 4 startup.o(RESET)
> > > FIQ_Handler 0x00000054 ARM Code 4 startup.o(RESET)
> > >
> > > These vectors probably are pointing to different interrupt handling
> > > routines.
> > >
> > > In order to remap the vectors you have to do the following:
> > >
> > > 1. Reserve 0x40 bytes at 0x40000000 (Start of RAM)
> > > 2. At reset_handler, copy 0x40 bytes from 0x00004000 (start of your
> main
> > > app) to 0x40000000 (start of RAM).
> > > 3. Remap the interrupt Vector table (write correct setting to MEMMAP
> > > register)
> > >
> > > Do you use interrupts (IRQ) in the bootloader?
> > >
> > > Regards,
> > >
> > > Alex
> > >
> > > --- In l...
> ,
> > > 42Bastian wrote:
> > > >
> > > > Sutton Mehaffey schrieb:
> > > > > OK. Here are my map files for both bootloader and app (called
> vera1)
> > > > >
> > > > > http://www.lookoutportablesecurity.com/sutton/bootload.map
>
> > > > >
> > > > >
> > > > > http://www.lookoutportablesecurity.com/sutton/vera1.map
>
> > > > >
> > > >
> > > > _terminateio - Undefined Weak Reference
> > > > version 0x00004000 Data
> > > > 2 lookout.o(.ARM.__AT_0x00004000)
> > > >
> > > > ^^^^^ why/what is this at 0x4000 ?
> > > >
> > > > Reset_Handler 0x0000405c ARM Code
> > > > 0 startup.o(RESET)
> > > >
> > > > It looks, you bootloader should jump at 0x405c !
> > > >
> > > >
> > > > --
> > > > 42Bastian
> > > > ------------------
> > > > Parts of this email are written with invisible ink.
> > > >
> > > > Note: SPAM-only account, direct mail to bs42@
> > > >
> > >
> > >
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr.
> > Kennesaw, GA 30144
> > 770-514-7999, 800-207-6269
> > Fax: 770-514-1285
> > http://www.lookoutportablesecurity.com
>
> > sutton@...
> >
--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
Reply by ●August 21, 20092009-08-21
Hi!,
Great news :-)
I wonder if hex2bin is putting some kind of IMAGE BASE + IMAGE LEN +
IMAGE CRC + ??? ... :)
2009/8/21 Sutton Mehaffey
> I'm still playing with it, but that appears to have fixed the problem.
> The .bin file created by Hex2Bin from the Keil .hex file has 18 other
> bytes it. 6 of which were the loading address of 0x4000, which I had
> compensated for, but there were 12 other bytes that I haven't figured
> out what's going on there.
>
> But, it appears that fromelf makes the proper .bin file for uploading.
> And, my version definition at 0x4000 still works. The compilation must
> adjust for that and start at 0x4004.
>
> Thanks to all. I'm still trying to figure out what the problem is with
> the hex2bin conversion. I'll follow up if I figure out anything.
>
> Sutton
>
> alexander_ribero wrote:
> >
> >
> > Hi:
> >
> > It seems that you are doing what needs to be done to jump correctly to
> > the main app. I'm now wondering (as some others have done) if the data
> > written at 0x4000 is the correct data.
> >
> > It is correct in the sense that you check byte by byte all the way from
> > the SD card to the Flash. Therefore, it is possible that the data in the
> > SD card is not valid: that is, the binary file is incorrect.
> >
> > I use the following command to generate the binary file:
> >
> > c:\keil\arm\bin31\fromelf --bin --output .bin
> > .axf
> >
> > 1. Could you verify that this binary file and the one generated by
> > hex2bin matches?
> >
> > 2. Can you dump the memory at 0x4000 after writing data from the SD card
> > and confirm that this data matches with the binary file generated by
> > fromelf, and that it is indeed the main app code?
> >
> > Your last comments about how the main app still fails after the jump,
> > but not when program via JTAG, prompted the memory and files questions.
> >
> > I've look at the remapping concept and for very simple applications,
> > like yours, it might not be required, as the IRQ interrupt vector always
> > points to the same location (VICAddress) in both the bootloader and the
> > main appl.
> >
> > Regards,
> >
> > Alex
> >
> > --- In l... > lpc2000%40yahoogroups.com >,
> > Sutton Mehaffey wrote:
> > >
> > > Alex,
> > >
> > > I see what you are saying. Let me revamp and see if I can figure things
> > > out.
> > >
> > > I never had applications that required loading at other locations than
> > > 0, or had any need to change any parameters in startup in the many
> years
> > > of developing systems. So, I am a little rusty at how all that stuff
> > > works in startup.
> > >
> > > I actually thought that since each project (bootloader and app) was
> > > compiled separately that each would have it's own physical vector
> space.
> > > I thought the compiler and linker would take care of that. A little
> > > naive, I guess.
> > >
> > > So, when I load the bootloader and then the app from the JTAG, there
> > > must be some remapping taking place during the app load that I don't
> > > know about. If the bootloader is loaded at 0, can you explain what
> > > exactly happens when you load the app at 0x4000 as far as the remapping
> > > goes? Keil's loading procedure must be doing the same thing that I need
> > > to do on my upload. Does the uploading of the app overwrite pointers
> > > that the remap fixes?
> > >
> > > Maybe when it starts working, I'll finally understand what all you guys
> > > have been trying to explain to me for the last week. But, until then
> > > I'll muddle through the manual again and again. I appreciate
> > > everybody's input.
> > >
> > > Maybe I need to ask Keil some questions. But, they have yet to answer 2
> > > sets of questions in a 2 week period.
> > >
> > > By the way, jumping to 0x4004 doesn't work. Still hangs. I tried
> > > 0x405C (which is the reset handler that bastian pointed out in the map)
> > > and same thing. However, to my surprise, it still works if you load the
> > > app from the JTAG and jump to 0x4004.
> > >
> > > Sutton
> > >
> > >
> > >
> > > alexander_ribero wrote:
> > > >
> > > >
> > > > Hi Sutton:
> > > >
> > > > It is clear from the .map files that you still haven't remap the
> > > > interrupt vector table to RAM when entering your main application.
> > > >
> > > > >From your previous message #44141
> > > > http://tech.groups.yahoo.com/group/lpc2000/message/44141
> >
> > > > > > >
> > > >
> > > > it is possible to see that you force the addresses of the interrupt
> > > > vectors to be specific addresses after 0x4000
> > > >
> > > > Vectors LDR PC, Reset_Addr
> > > > LDR PC, Undef_Addr
> > > > LDR PC, SWI_Addr
> > > > LDR PC, PAbt_Addr
> > > > LDR PC, DAbt_Addr
> > > > NOP ; Reserved Vector
> > > > ; LDR PC, IRQ_Addr
> > > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > > LDR PC, FIQ_Addr
> > > >
> > > > Reset_Addr DCD Reset_Handler
> > > > Undef_Addr DCD 0x4004
> > > > SWI_Addr DCD 0x4008
> > > > PAbt_Addr DCD 0x400C
> > > > DAbt_Addr DCD 0x4010
> > > > DCD 0 ; Reserved Address
> > > > IRQ_Addr DCD 0x4014
> > > > FIQ_Addr DCD 0x401C
> > > >
> > > > However, there is nothing indicating that those addresses contain the
> > > > correct handler for each exception. In fact, what this code is
> > doing is
> > > > to make each interrupt vector point to itself, except for the IRQ
> > vector.
> > > >
> > > > Now, if you don't remap the interrupt vectors, the processor will use
> > > > the vectors provided by the bootloader:
> > > > (see line 340 of the bootloader.map file)
> > > > Undef_Handler 0x00000040 ARM Code 4 startup.o(RESET)
> > > > SWI_Handler 0x00000044 ARM Code 4 startup.o(RESET)
> > > > PAbt_Handler 0x00000048 ARM Code 4 startup.o(RESET)
> > > > DAbt_Handler 0x0000004c ARM Code 4 startup.o(RESET)
> > > > IRQ_Handler 0x00000050 ARM Code 4 startup.o(RESET)
> > > > FIQ_Handler 0x00000054 ARM Code 4 startup.o(RESET)
> > > >
> > > > These vectors probably are pointing to different interrupt handling
> > > > routines.
> > > >
> > > > In order to remap the vectors you have to do the following:
> > > >
> > > > 1. Reserve 0x40 bytes at 0x40000000 (Start of RAM)
> > > > 2. At reset_handler, copy 0x40 bytes from 0x00004000 (start of your
> > main
> > > > app) to 0x40000000 (start of RAM).
> > > > 3. Remap the interrupt Vector table (write correct setting to MEMMAP
> > > > register)
> > > >
> > > > Do you use interrupts (IRQ) in the bootloader?
> > > >
> > > > Regards,
> > > >
> > > > Alex
> > > >
> > > > --- In l... > lpc2000%40yahoogroups.com >
> > >,
> > > > 42Bastian wrote:
> > > > >
> > > > > Sutton Mehaffey schrieb:
> > > > > > OK. Here are my map files for both bootloader and app (called
> > vera1)
> > > > > >
> > > > > > http://www.lookoutportablesecurity.com/sutton/bootload.map
> >
> > > > > > >
> > > > > >
> > > > > > http://www.lookoutportablesecurity.com/sutton/vera1.map
> >
> > > > > > >
> > > > >
> > > > > _terminateio - Undefined Weak Reference
> > > > > version 0x00004000 Data
> > > > > 2 lookout.o(.ARM.__AT_0x00004000)
> > > > >
> > > > > ^^^^^ why/what is this at 0x4000 ?
> > > > >
> > > > > Reset_Handler 0x0000405c ARM Code
> > > > > 0 startup.o(RESET)
> > > > >
> > > > > It looks, you bootloader should jump at 0x405c !
> > > > >
> > > > >
> > > > > --
> > > > > 42Bastian
> > > > > ------------------
> > > > > Parts of this email are written with invisible ink.
> > > > >
> > > > > Note: SPAM-only account, direct mail to bs42@
> > > > >
> > > >
> > > >
> > >
> > > --
> > > Sutton Mehaffey
> > > Lookout Portable Security
> > > 4040 Royal Dr.
> > > Kennesaw, GA 30144
> > > 770-514-7999, 800-207-6269
> > > Fax: 770-514-1285
> > > http://www.lookoutportablesecurity.com
> >
> > > sutton@...
> > >
> >
> > --
> Sutton Mehaffey
> Lookout Portable Security
> 4040 Royal Dr.
> Kennesaw, GA 30144
> 770-514-7999, 800-207-6269
> Fax: 770-514-1285
> http://www.lookoutportablesecurity.com
> s...@lookoutportablesecurity.com
>
--
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
Great news :-)
I wonder if hex2bin is putting some kind of IMAGE BASE + IMAGE LEN +
IMAGE CRC + ??? ... :)
2009/8/21 Sutton Mehaffey
> I'm still playing with it, but that appears to have fixed the problem.
> The .bin file created by Hex2Bin from the Keil .hex file has 18 other
> bytes it. 6 of which were the loading address of 0x4000, which I had
> compensated for, but there were 12 other bytes that I haven't figured
> out what's going on there.
>
> But, it appears that fromelf makes the proper .bin file for uploading.
> And, my version definition at 0x4000 still works. The compilation must
> adjust for that and start at 0x4004.
>
> Thanks to all. I'm still trying to figure out what the problem is with
> the hex2bin conversion. I'll follow up if I figure out anything.
>
> Sutton
>
> alexander_ribero wrote:
> >
> >
> > Hi:
> >
> > It seems that you are doing what needs to be done to jump correctly to
> > the main app. I'm now wondering (as some others have done) if the data
> > written at 0x4000 is the correct data.
> >
> > It is correct in the sense that you check byte by byte all the way from
> > the SD card to the Flash. Therefore, it is possible that the data in the
> > SD card is not valid: that is, the binary file is incorrect.
> >
> > I use the following command to generate the binary file:
> >
> > c:\keil\arm\bin31\fromelf --bin --output .bin
> > .axf
> >
> > 1. Could you verify that this binary file and the one generated by
> > hex2bin matches?
> >
> > 2. Can you dump the memory at 0x4000 after writing data from the SD card
> > and confirm that this data matches with the binary file generated by
> > fromelf, and that it is indeed the main app code?
> >
> > Your last comments about how the main app still fails after the jump,
> > but not when program via JTAG, prompted the memory and files questions.
> >
> > I've look at the remapping concept and for very simple applications,
> > like yours, it might not be required, as the IRQ interrupt vector always
> > points to the same location (VICAddress) in both the bootloader and the
> > main appl.
> >
> > Regards,
> >
> > Alex
> >
> > --- In l... > lpc2000%40yahoogroups.com >,
> > Sutton Mehaffey wrote:
> > >
> > > Alex,
> > >
> > > I see what you are saying. Let me revamp and see if I can figure things
> > > out.
> > >
> > > I never had applications that required loading at other locations than
> > > 0, or had any need to change any parameters in startup in the many
> years
> > > of developing systems. So, I am a little rusty at how all that stuff
> > > works in startup.
> > >
> > > I actually thought that since each project (bootloader and app) was
> > > compiled separately that each would have it's own physical vector
> space.
> > > I thought the compiler and linker would take care of that. A little
> > > naive, I guess.
> > >
> > > So, when I load the bootloader and then the app from the JTAG, there
> > > must be some remapping taking place during the app load that I don't
> > > know about. If the bootloader is loaded at 0, can you explain what
> > > exactly happens when you load the app at 0x4000 as far as the remapping
> > > goes? Keil's loading procedure must be doing the same thing that I need
> > > to do on my upload. Does the uploading of the app overwrite pointers
> > > that the remap fixes?
> > >
> > > Maybe when it starts working, I'll finally understand what all you guys
> > > have been trying to explain to me for the last week. But, until then
> > > I'll muddle through the manual again and again. I appreciate
> > > everybody's input.
> > >
> > > Maybe I need to ask Keil some questions. But, they have yet to answer 2
> > > sets of questions in a 2 week period.
> > >
> > > By the way, jumping to 0x4004 doesn't work. Still hangs. I tried
> > > 0x405C (which is the reset handler that bastian pointed out in the map)
> > > and same thing. However, to my surprise, it still works if you load the
> > > app from the JTAG and jump to 0x4004.
> > >
> > > Sutton
> > >
> > >
> > >
> > > alexander_ribero wrote:
> > > >
> > > >
> > > > Hi Sutton:
> > > >
> > > > It is clear from the .map files that you still haven't remap the
> > > > interrupt vector table to RAM when entering your main application.
> > > >
> > > > >From your previous message #44141
> > > > http://tech.groups.yahoo.com/group/lpc2000/message/44141
> >
> > > > > > >
> > > >
> > > > it is possible to see that you force the addresses of the interrupt
> > > > vectors to be specific addresses after 0x4000
> > > >
> > > > Vectors LDR PC, Reset_Addr
> > > > LDR PC, Undef_Addr
> > > > LDR PC, SWI_Addr
> > > > LDR PC, PAbt_Addr
> > > > LDR PC, DAbt_Addr
> > > > NOP ; Reserved Vector
> > > > ; LDR PC, IRQ_Addr
> > > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > > LDR PC, FIQ_Addr
> > > >
> > > > Reset_Addr DCD Reset_Handler
> > > > Undef_Addr DCD 0x4004
> > > > SWI_Addr DCD 0x4008
> > > > PAbt_Addr DCD 0x400C
> > > > DAbt_Addr DCD 0x4010
> > > > DCD 0 ; Reserved Address
> > > > IRQ_Addr DCD 0x4014
> > > > FIQ_Addr DCD 0x401C
> > > >
> > > > However, there is nothing indicating that those addresses contain the
> > > > correct handler for each exception. In fact, what this code is
> > doing is
> > > > to make each interrupt vector point to itself, except for the IRQ
> > vector.
> > > >
> > > > Now, if you don't remap the interrupt vectors, the processor will use
> > > > the vectors provided by the bootloader:
> > > > (see line 340 of the bootloader.map file)
> > > > Undef_Handler 0x00000040 ARM Code 4 startup.o(RESET)
> > > > SWI_Handler 0x00000044 ARM Code 4 startup.o(RESET)
> > > > PAbt_Handler 0x00000048 ARM Code 4 startup.o(RESET)
> > > > DAbt_Handler 0x0000004c ARM Code 4 startup.o(RESET)
> > > > IRQ_Handler 0x00000050 ARM Code 4 startup.o(RESET)
> > > > FIQ_Handler 0x00000054 ARM Code 4 startup.o(RESET)
> > > >
> > > > These vectors probably are pointing to different interrupt handling
> > > > routines.
> > > >
> > > > In order to remap the vectors you have to do the following:
> > > >
> > > > 1. Reserve 0x40 bytes at 0x40000000 (Start of RAM)
> > > > 2. At reset_handler, copy 0x40 bytes from 0x00004000 (start of your
> > main
> > > > app) to 0x40000000 (start of RAM).
> > > > 3. Remap the interrupt Vector table (write correct setting to MEMMAP
> > > > register)
> > > >
> > > > Do you use interrupts (IRQ) in the bootloader?
> > > >
> > > > Regards,
> > > >
> > > > Alex
> > > >
> > > > --- In l... > lpc2000%40yahoogroups.com >
> > >,
> > > > 42Bastian wrote:
> > > > >
> > > > > Sutton Mehaffey schrieb:
> > > > > > OK. Here are my map files for both bootloader and app (called
> > vera1)
> > > > > >
> > > > > > http://www.lookoutportablesecurity.com/sutton/bootload.map
> >
> > > > > > >
> > > > > >
> > > > > > http://www.lookoutportablesecurity.com/sutton/vera1.map
> >
> > > > > > >
> > > > >
> > > > > _terminateio - Undefined Weak Reference
> > > > > version 0x00004000 Data
> > > > > 2 lookout.o(.ARM.__AT_0x00004000)
> > > > >
> > > > > ^^^^^ why/what is this at 0x4000 ?
> > > > >
> > > > > Reset_Handler 0x0000405c ARM Code
> > > > > 0 startup.o(RESET)
> > > > >
> > > > > It looks, you bootloader should jump at 0x405c !
> > > > >
> > > > >
> > > > > --
> > > > > 42Bastian
> > > > > ------------------
> > > > > Parts of this email are written with invisible ink.
> > > > >
> > > > > Note: SPAM-only account, direct mail to bs42@
> > > > >
> > > >
> > > >
> > >
> > > --
> > > Sutton Mehaffey
> > > Lookout Portable Security
> > > 4040 Royal Dr.
> > > Kennesaw, GA 30144
> > > 770-514-7999, 800-207-6269
> > > Fax: 770-514-1285
> > > http://www.lookoutportablesecurity.com
> >
> > > sutton@...
> > >
> >
> > --
> Sutton Mehaffey
> Lookout Portable Security
> 4040 Royal Dr.
> Kennesaw, GA 30144
> 770-514-7999, 800-207-6269
> Fax: 770-514-1285
> http://www.lookoutportablesecurity.com
> s...@lookoutportablesecurity.com
>
--
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
Reply by ●August 21, 20092009-08-21
Don't know. It appears that the other 12 bytes are at the end of the
file, so I'm still not sure why it wouldn't run.
Miguel Angel wrote:
>
>
> Hi!,
> Great news :-)
>
> I wonder if hex2bin is putting some kind of IMAGE BASE + IMAGE LEN +
> IMAGE CRC + ??? ... :)
>
> 2009/8/21 Sutton Mehaffey > > >
> >
> > I'm still playing with it, but that appears to have fixed the problem.
> > The .bin file created by Hex2Bin from the Keil .hex file has 18 other
> > bytes it. 6 of which were the loading address of 0x4000, which I had
> > compensated for, but there were 12 other bytes that I haven't figured
> > out what's going on there.
> >
> > But, it appears that fromelf makes the proper .bin file for uploading.
> > And, my version definition at 0x4000 still works. The compilation must
> > adjust for that and start at 0x4004.
> >
> > Thanks to all. I'm still trying to figure out what the problem is with
> > the hex2bin conversion. I'll follow up if I figure out anything.
> >
> > Sutton
> >
> > alexander_ribero wrote:
> > >
> > >
> > > Hi:
> > >
> > > It seems that you are doing what needs to be done to jump correctly to
> > > the main app. I'm now wondering (as some others have done) if the data
> > > written at 0x4000 is the correct data.
> > >
> > > It is correct in the sense that you check byte by byte all the way from
> > > the SD card to the Flash. Therefore, it is possible that the data
> in the
> > > SD card is not valid: that is, the binary file is incorrect.
> > >
> > > I use the following command to generate the binary file:
> > >
> > > c:\keil\arm\bin31\fromelf --bin --output .bin
> > > .axf
> > >
> > > 1. Could you verify that this binary file and the one generated by
> > > hex2bin matches?
> > >
> > > 2. Can you dump the memory at 0x4000 after writing data from the SD
> card
> > > and confirm that this data matches with the binary file generated by
> > > fromelf, and that it is indeed the main app code?
> > >
> > > Your last comments about how the main app still fails after the jump,
> > > but not when program via JTAG, prompted the memory and files questions.
> > >
> > > I've look at the remapping concept and for very simple applications,
> > > like yours, it might not be required, as the IRQ interrupt vector
> always
> > > points to the same location (VICAddress) in both the bootloader and the
> > > main appl.
> > >
> > > Regards,
> > >
> > > Alex
> > >
> > > --- In l...
> > > lpc2000%40yahoogroups.com >,
> > > Sutton Mehaffey wrote:
> > > >
> > > > Alex,
> > > >
> > > > I see what you are saying. Let me revamp and see if I can figure
> things
> > > > out.
> > > >
> > > > I never had applications that required loading at other locations
> than
> > > > 0, or had any need to change any parameters in startup in the many
> > years
> > > > of developing systems. So, I am a little rusty at how all that stuff
> > > > works in startup.
> > > >
> > > > I actually thought that since each project (bootloader and app) was
> > > > compiled separately that each would have it's own physical vector
> > space.
> > > > I thought the compiler and linker would take care of that. A little
> > > > naive, I guess.
> > > >
> > > > So, when I load the bootloader and then the app from the JTAG, there
> > > > must be some remapping taking place during the app load that I don't
> > > > know about. If the bootloader is loaded at 0, can you explain what
> > > > exactly happens when you load the app at 0x4000 as far as the
> remapping
> > > > goes? Keil's loading procedure must be doing the same thing that
> I need
> > > > to do on my upload. Does the uploading of the app overwrite pointers
> > > > that the remap fixes?
> > > >
> > > > Maybe when it starts working, I'll finally understand what all
> you guys
> > > > have been trying to explain to me for the last week. But, until then
> > > > I'll muddle through the manual again and again. I appreciate
> > > > everybody's input.
> > > >
> > > > Maybe I need to ask Keil some questions. But, they have yet to
> answer 2
> > > > sets of questions in a 2 week period.
> > > >
> > > > By the way, jumping to 0x4004 doesn't work. Still hangs. I tried
> > > > 0x405C (which is the reset handler that bastian pointed out in
> the map)
> > > > and same thing. However, to my surprise, it still works if you
> load the
> > > > app from the JTAG and jump to 0x4004.
> > > >
> > > > Sutton
> > > >
> > > >
> > > >
> > > > alexander_ribero wrote:
> > > > >
> > > > >
> > > > > Hi Sutton:
> > > > >
> > > > > It is clear from the .map files that you still haven't remap the
> > > > > interrupt vector table to RAM when entering your main application.
> > > > >
> > > > > >From your previous message #44141
> > > > > http://tech.groups.yahoo.com/group/lpc2000/message/44141
>
> > > > >
> > > > > >
> > > > >>
> > > > >
> > > > > it is possible to see that you force the addresses of the interrupt
> > > > > vectors to be specific addresses after 0x4000
> > > > >
> > > > > Vectors LDR PC, Reset_Addr
> > > > > LDR PC, Undef_Addr
> > > > > LDR PC, SWI_Addr
> > > > > LDR PC, PAbt_Addr
> > > > > LDR PC, DAbt_Addr
> > > > > NOP ; Reserved Vector
> > > > > ; LDR PC, IRQ_Addr
> > > > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > > > LDR PC, FIQ_Addr
> > > > >
> > > > > Reset_Addr DCD Reset_Handler
> > > > > Undef_Addr DCD 0x4004
> > > > > SWI_Addr DCD 0x4008
> > > > > PAbt_Addr DCD 0x400C
> > > > > DAbt_Addr DCD 0x4010
> > > > > DCD 0 ; Reserved Address
> > > > > IRQ_Addr DCD 0x4014
> > > > > FIQ_Addr DCD 0x401C
> > > > >
> > > > > However, there is nothing indicating that those addresses
> contain the
> > > > > correct handler for each exception. In fact, what this code is
> > > doing is
> > > > > to make each interrupt vector point to itself, except for the IRQ
> > > vector.
> > > > >
> > > > > Now, if you don't remap the interrupt vectors, the processor
> will use
> > > > > the vectors provided by the bootloader:
> > > > > (see line 340 of the bootloader.map file)
> > > > > Undef_Handler 0x00000040 ARM Code 4 startup.o(RESET)
> > > > > SWI_Handler 0x00000044 ARM Code 4 startup.o(RESET)
> > > > > PAbt_Handler 0x00000048 ARM Code 4 startup.o(RESET)
> > > > > DAbt_Handler 0x0000004c ARM Code 4 startup.o(RESET)
> > > > > IRQ_Handler 0x00000050 ARM Code 4 startup.o(RESET)
> > > > > FIQ_Handler 0x00000054 ARM Code 4 startup.o(RESET)
> > > > >
> > > > > These vectors probably are pointing to different interrupt handling
> > > > > routines.
> > > > >
> > > > > In order to remap the vectors you have to do the following:
> > > > >
> > > > > 1. Reserve 0x40 bytes at 0x40000000 (Start of RAM)
> > > > > 2. At reset_handler, copy 0x40 bytes from 0x00004000 (start of your
> > > main
> > > > > app) to 0x40000000 (start of RAM).
> > > > > 3. Remap the interrupt Vector table (write correct setting to
> MEMMAP
> > > > > register)
> > > > >
> > > > > Do you use interrupts (IRQ) in the bootloader?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Alex
> > > > >
> > > > > --- In l...
> > > lpc2000%40yahoogroups.com >
> > > >,
> > > > > 42Bastian wrote:
> > > > > >
> > > > > > Sutton Mehaffey schrieb:
> > > > > > > OK. Here are my map files for both bootloader and app (called
> > > vera1)
> > > > > > >
> > > > > > > http://www.lookoutportablesecurity.com/sutton/bootload.map
>
> > > > >
> > > > > >
> > > > >>
> > > > > > >
> > > > > > > http://www.lookoutportablesecurity.com/sutton/vera1.map
>
> > > > >
> > > > > >
> > > > >>
> > > > > >
> > > > > > _terminateio - Undefined Weak Reference
> > > > > > version 0x00004000 Data
> > > > > > 2 lookout.o(.ARM.__AT_0x00004000)
> > > > > >
> > > > > > ^^^^^ why/what is this at 0x4000 ?
> > > > > >
> > > > > > Reset_Handler 0x0000405c ARM Code
> > > > > > 0 startup.o(RESET)
> > > > > >
> > > > > > It looks, you bootloader should jump at 0x405c !
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 42Bastian
> > > > > > ------------------
> > > > > > Parts of this email are written with invisible ink.
> > > > > >
> > > > > > Note: SPAM-only account, direct mail to bs42@
> > > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Sutton Mehaffey
> > > > Lookout Portable Security
> > > > 4040 Royal Dr.
> > > > Kennesaw, GA 30144
> > > > 770-514-7999, 800-207-6269
> > > > Fax: 770-514-1285
> > > > http://www.lookoutportablesecurity.com
>
> > > > >
> > > > sutton@...
> > > >
> > >
> > >
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr.
> > Kennesaw, GA 30144
> > 770-514-7999, 800-207-6269
> > Fax: 770-514-1285
> > http://www.lookoutportablesecurity.com
>
> > s...@lookoutportablesecurity.com
>
>
> >
> >
> > --
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 91 120 1798
> +34 636 52 25 69
> skype: ajoajoajo
>
>
--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
file, so I'm still not sure why it wouldn't run.
Miguel Angel wrote:
>
>
> Hi!,
> Great news :-)
>
> I wonder if hex2bin is putting some kind of IMAGE BASE + IMAGE LEN +
> IMAGE CRC + ??? ... :)
>
> 2009/8/21 Sutton Mehaffey > > >
> >
> > I'm still playing with it, but that appears to have fixed the problem.
> > The .bin file created by Hex2Bin from the Keil .hex file has 18 other
> > bytes it. 6 of which were the loading address of 0x4000, which I had
> > compensated for, but there were 12 other bytes that I haven't figured
> > out what's going on there.
> >
> > But, it appears that fromelf makes the proper .bin file for uploading.
> > And, my version definition at 0x4000 still works. The compilation must
> > adjust for that and start at 0x4004.
> >
> > Thanks to all. I'm still trying to figure out what the problem is with
> > the hex2bin conversion. I'll follow up if I figure out anything.
> >
> > Sutton
> >
> > alexander_ribero wrote:
> > >
> > >
> > > Hi:
> > >
> > > It seems that you are doing what needs to be done to jump correctly to
> > > the main app. I'm now wondering (as some others have done) if the data
> > > written at 0x4000 is the correct data.
> > >
> > > It is correct in the sense that you check byte by byte all the way from
> > > the SD card to the Flash. Therefore, it is possible that the data
> in the
> > > SD card is not valid: that is, the binary file is incorrect.
> > >
> > > I use the following command to generate the binary file:
> > >
> > > c:\keil\arm\bin31\fromelf --bin --output .bin
> > > .axf
> > >
> > > 1. Could you verify that this binary file and the one generated by
> > > hex2bin matches?
> > >
> > > 2. Can you dump the memory at 0x4000 after writing data from the SD
> card
> > > and confirm that this data matches with the binary file generated by
> > > fromelf, and that it is indeed the main app code?
> > >
> > > Your last comments about how the main app still fails after the jump,
> > > but not when program via JTAG, prompted the memory and files questions.
> > >
> > > I've look at the remapping concept and for very simple applications,
> > > like yours, it might not be required, as the IRQ interrupt vector
> always
> > > points to the same location (VICAddress) in both the bootloader and the
> > > main appl.
> > >
> > > Regards,
> > >
> > > Alex
> > >
> > > --- In l...
> > > lpc2000%40yahoogroups.com >,
> > > Sutton Mehaffey wrote:
> > > >
> > > > Alex,
> > > >
> > > > I see what you are saying. Let me revamp and see if I can figure
> things
> > > > out.
> > > >
> > > > I never had applications that required loading at other locations
> than
> > > > 0, or had any need to change any parameters in startup in the many
> > years
> > > > of developing systems. So, I am a little rusty at how all that stuff
> > > > works in startup.
> > > >
> > > > I actually thought that since each project (bootloader and app) was
> > > > compiled separately that each would have it's own physical vector
> > space.
> > > > I thought the compiler and linker would take care of that. A little
> > > > naive, I guess.
> > > >
> > > > So, when I load the bootloader and then the app from the JTAG, there
> > > > must be some remapping taking place during the app load that I don't
> > > > know about. If the bootloader is loaded at 0, can you explain what
> > > > exactly happens when you load the app at 0x4000 as far as the
> remapping
> > > > goes? Keil's loading procedure must be doing the same thing that
> I need
> > > > to do on my upload. Does the uploading of the app overwrite pointers
> > > > that the remap fixes?
> > > >
> > > > Maybe when it starts working, I'll finally understand what all
> you guys
> > > > have been trying to explain to me for the last week. But, until then
> > > > I'll muddle through the manual again and again. I appreciate
> > > > everybody's input.
> > > >
> > > > Maybe I need to ask Keil some questions. But, they have yet to
> answer 2
> > > > sets of questions in a 2 week period.
> > > >
> > > > By the way, jumping to 0x4004 doesn't work. Still hangs. I tried
> > > > 0x405C (which is the reset handler that bastian pointed out in
> the map)
> > > > and same thing. However, to my surprise, it still works if you
> load the
> > > > app from the JTAG and jump to 0x4004.
> > > >
> > > > Sutton
> > > >
> > > >
> > > >
> > > > alexander_ribero wrote:
> > > > >
> > > > >
> > > > > Hi Sutton:
> > > > >
> > > > > It is clear from the .map files that you still haven't remap the
> > > > > interrupt vector table to RAM when entering your main application.
> > > > >
> > > > > >From your previous message #44141
> > > > > http://tech.groups.yahoo.com/group/lpc2000/message/44141
>
> > > > >
> > > > > >
> > > > >>
> > > > >
> > > > > it is possible to see that you force the addresses of the interrupt
> > > > > vectors to be specific addresses after 0x4000
> > > > >
> > > > > Vectors LDR PC, Reset_Addr
> > > > > LDR PC, Undef_Addr
> > > > > LDR PC, SWI_Addr
> > > > > LDR PC, PAbt_Addr
> > > > > LDR PC, DAbt_Addr
> > > > > NOP ; Reserved Vector
> > > > > ; LDR PC, IRQ_Addr
> > > > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > > > LDR PC, FIQ_Addr
> > > > >
> > > > > Reset_Addr DCD Reset_Handler
> > > > > Undef_Addr DCD 0x4004
> > > > > SWI_Addr DCD 0x4008
> > > > > PAbt_Addr DCD 0x400C
> > > > > DAbt_Addr DCD 0x4010
> > > > > DCD 0 ; Reserved Address
> > > > > IRQ_Addr DCD 0x4014
> > > > > FIQ_Addr DCD 0x401C
> > > > >
> > > > > However, there is nothing indicating that those addresses
> contain the
> > > > > correct handler for each exception. In fact, what this code is
> > > doing is
> > > > > to make each interrupt vector point to itself, except for the IRQ
> > > vector.
> > > > >
> > > > > Now, if you don't remap the interrupt vectors, the processor
> will use
> > > > > the vectors provided by the bootloader:
> > > > > (see line 340 of the bootloader.map file)
> > > > > Undef_Handler 0x00000040 ARM Code 4 startup.o(RESET)
> > > > > SWI_Handler 0x00000044 ARM Code 4 startup.o(RESET)
> > > > > PAbt_Handler 0x00000048 ARM Code 4 startup.o(RESET)
> > > > > DAbt_Handler 0x0000004c ARM Code 4 startup.o(RESET)
> > > > > IRQ_Handler 0x00000050 ARM Code 4 startup.o(RESET)
> > > > > FIQ_Handler 0x00000054 ARM Code 4 startup.o(RESET)
> > > > >
> > > > > These vectors probably are pointing to different interrupt handling
> > > > > routines.
> > > > >
> > > > > In order to remap the vectors you have to do the following:
> > > > >
> > > > > 1. Reserve 0x40 bytes at 0x40000000 (Start of RAM)
> > > > > 2. At reset_handler, copy 0x40 bytes from 0x00004000 (start of your
> > > main
> > > > > app) to 0x40000000 (start of RAM).
> > > > > 3. Remap the interrupt Vector table (write correct setting to
> MEMMAP
> > > > > register)
> > > > >
> > > > > Do you use interrupts (IRQ) in the bootloader?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Alex
> > > > >
> > > > > --- In l...
> > > lpc2000%40yahoogroups.com >
> > > >,
> > > > > 42Bastian wrote:
> > > > > >
> > > > > > Sutton Mehaffey schrieb:
> > > > > > > OK. Here are my map files for both bootloader and app (called
> > > vera1)
> > > > > > >
> > > > > > > http://www.lookoutportablesecurity.com/sutton/bootload.map
>
> > > > >
> > > > > >
> > > > >>
> > > > > > >
> > > > > > > http://www.lookoutportablesecurity.com/sutton/vera1.map
>
> > > > >
> > > > > >
> > > > >>
> > > > > >
> > > > > > _terminateio - Undefined Weak Reference
> > > > > > version 0x00004000 Data
> > > > > > 2 lookout.o(.ARM.__AT_0x00004000)
> > > > > >
> > > > > > ^^^^^ why/what is this at 0x4000 ?
> > > > > >
> > > > > > Reset_Handler 0x0000405c ARM Code
> > > > > > 0 startup.o(RESET)
> > > > > >
> > > > > > It looks, you bootloader should jump at 0x405c !
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 42Bastian
> > > > > > ------------------
> > > > > > Parts of this email are written with invisible ink.
> > > > > >
> > > > > > Note: SPAM-only account, direct mail to bs42@
> > > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Sutton Mehaffey
> > > > Lookout Portable Security
> > > > 4040 Royal Dr.
> > > > Kennesaw, GA 30144
> > > > 770-514-7999, 800-207-6269
> > > > Fax: 770-514-1285
> > > > http://www.lookoutportablesecurity.com
>
> > > > >
> > > > sutton@...
> > > >
> > >
> > >
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr.
> > Kennesaw, GA 30144
> > 770-514-7999, 800-207-6269
> > Fax: 770-514-1285
> > http://www.lookoutportablesecurity.com
>
> > s...@lookoutportablesecurity.com
>
>
> >
> >
> > --
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 91 120 1798
> +34 636 52 25 69
> skype: ajoajoajo
>
>
--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
Reply by ●August 21, 20092009-08-21
Probably it was breaking some other part in the middle of the bin.
2009/8/21 Sutton Mehaffey
> Don't know. It appears that the other 12 bytes are at the end of the
> file, so I'm still not sure why it wouldn't run.
> Miguel Angel wrote:
> >
> >
> > Hi!,
> > Great news :-)
> >
> > I wonder if hex2bin is putting some kind of IMAGE BASE + IMAGE LEN +
> > IMAGE CRC + ??? ... :)
> >
> > 2009/8/21 Sutton Mehaffey
> >
> >> >
> > >
> > >
> > > I'm still playing with it, but that appears to have fixed the problem.
> > > The .bin file created by Hex2Bin from the Keil .hex file has 18 other
> > > bytes it. 6 of which were the loading address of 0x4000, which I had
> > > compensated for, but there were 12 other bytes that I haven't figured
> > > out what's going on there.
> > >
> > > But, it appears that fromelf makes the proper .bin file for uploading.
> > > And, my version definition at 0x4000 still works. The compilation must
> > > adjust for that and start at 0x4004.
> > >
> > > Thanks to all. I'm still trying to figure out what the problem is with
> > > the hex2bin conversion. I'll follow up if I figure out anything.
> > >
> > > Sutton
> > >
> > > alexander_ribero wrote:
> > > >
> > > >
> > > > Hi:
> > > >
> > > > It seems that you are doing what needs to be done to jump correctly
> to
> > > > the main app. I'm now wondering (as some others have done) if the
> data
> > > > written at 0x4000 is the correct data.
> > > >
> > > > It is correct in the sense that you check byte by byte all the way
> from
> > > > the SD card to the Flash. Therefore, it is possible that the data
> > in the
> > > > SD card is not valid: that is, the binary file is incorrect.
> > > >
> > > > I use the following command to generate the binary file:
> > > >
> > > > c:\keil\arm\bin31\fromelf --bin --output .bin
> > > > .axf
> > > >
> > > > 1. Could you verify that this binary file and the one generated by
> > > > hex2bin matches?
> > > >
> > > > 2. Can you dump the memory at 0x4000 after writing data from the SD
> > card
> > > > and confirm that this data matches with the binary file generated by
> > > > fromelf, and that it is indeed the main app code?
> > > >
> > > > Your last comments about how the main app still fails after the jump,
> > > > but not when program via JTAG, prompted the memory and files
> questions.
> > > >
> > > > I've look at the remapping concept and for very simple applications,
> > > > like yours, it might not be required, as the IRQ interrupt vector
> > always
> > > > points to the same location (VICAddress) in both the bootloader and
> the
> > > > main appl.
> > > >
> > > > Regards,
> > > >
> > > > Alex
> > > >
> > > > --- In l... > lpc2000%40yahoogroups.com >
> > > > > lpc2000%40yahoogroups.com >,
>
> > > > Sutton Mehaffey wrote:
> > > > >
> > > > > Alex,
> > > > >
> > > > > I see what you are saying. Let me revamp and see if I can figure
> > things
> > > > > out.
> > > > >
> > > > > I never had applications that required loading at other locations
> > than
> > > > > 0, or had any need to change any parameters in startup in the many
> > > years
> > > > > of developing systems. So, I am a little rusty at how all that
> stuff
> > > > > works in startup.
> > > > >
> > > > > I actually thought that since each project (bootloader and app) was
> > > > > compiled separately that each would have it's own physical vector
> > > space.
> > > > > I thought the compiler and linker would take care of that. A little
> > > > > naive, I guess.
> > > > >
> > > > > So, when I load the bootloader and then the app from the JTAG,
> there
> > > > > must be some remapping taking place during the app load that I
> don't
> > > > > know about. If the bootloader is loaded at 0, can you explain what
> > > > > exactly happens when you load the app at 0x4000 as far as the
> > remapping
> > > > > goes? Keil's loading procedure must be doing the same thing that
> > I need
> > > > > to do on my upload. Does the uploading of the app overwrite
> pointers
> > > > > that the remap fixes?
> > > > >
> > > > > Maybe when it starts working, I'll finally understand what all
> > you guys
> > > > > have been trying to explain to me for the last week. But, until
> then
> > > > > I'll muddle through the manual again and again. I appreciate
> > > > > everybody's input.
> > > > >
> > > > > Maybe I need to ask Keil some questions. But, they have yet to
> > answer 2
> > > > > sets of questions in a 2 week period.
> > > > >
> > > > > By the way, jumping to 0x4004 doesn't work. Still hangs. I tried
> > > > > 0x405C (which is the reset handler that bastian pointed out in
> > the map)
> > > > > and same thing. However, to my surprise, it still works if you
> > load the
> > > > > app from the JTAG and jump to 0x4004.
> > > > >
> > > > > Sutton
> > > > >
> > > > >
> > > > >
> > > > > alexander_ribero wrote:
> > > > > >
> > > > > >
> > > > > > Hi Sutton:
> > > > > >
> > > > > > It is clear from the .map files that you still haven't remap the
> > > > > > interrupt vector table to RAM when entering your main
> application.
> > > > > >
> > > > > > >From your previous message #44141
> > > > > > http://tech.groups.yahoo.com/group/lpc2000/message/44141
> >
> > > > > > >
> > > > > > > >
> > > > > > >>
> > > > > >
> > > > > > it is possible to see that you force the addresses of the
> interrupt
> > > > > > vectors to be specific addresses after 0x4000
> > > > > >
> > > > > > Vectors LDR PC, Reset_Addr
> > > > > > LDR PC, Undef_Addr
> > > > > > LDR PC, SWI_Addr
> > > > > > LDR PC, PAbt_Addr
> > > > > > LDR PC, DAbt_Addr
> > > > > > NOP ; Reserved Vector
> > > > > > ; LDR PC, IRQ_Addr
> > > > > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > > > > LDR PC, FIQ_Addr
> > > > > >
> > > > > > Reset_Addr DCD Reset_Handler
> > > > > > Undef_Addr DCD 0x4004
> > > > > > SWI_Addr DCD 0x4008
> > > > > > PAbt_Addr DCD 0x400C
> > > > > > DAbt_Addr DCD 0x4010
> > > > > > DCD 0 ; Reserved Address
> > > > > > IRQ_Addr DCD 0x4014
> > > > > > FIQ_Addr DCD 0x401C
> > > > > >
> > > > > > However, there is nothing indicating that those addresses
> > contain the
> > > > > > correct handler for each exception. In fact, what this code is
> > > > doing is
> > > > > > to make each interrupt vector point to itself, except for the IRQ
> > > > vector.
> > > > > >
> > > > > > Now, if you don't remap the interrupt vectors, the processor
> > will use
> > > > > > the vectors provided by the bootloader:
> > > > > > (see line 340 of the bootloader.map file)
> > > > > > Undef_Handler 0x00000040 ARM Code 4 startup.o(RESET)
> > > > > > SWI_Handler 0x00000044 ARM Code 4 startup.o(RESET)
> > > > > > PAbt_Handler 0x00000048 ARM Code 4 startup.o(RESET)
> > > > > > DAbt_Handler 0x0000004c ARM Code 4 startup.o(RESET)
> > > > > > IRQ_Handler 0x00000050 ARM Code 4 startup.o(RESET)
> > > > > > FIQ_Handler 0x00000054 ARM Code 4 startup.o(RESET)
> > > > > >
> > > > > > These vectors probably are pointing to different interrupt
> handling
> > > > > > routines.
> > > > > >
> > > > > > In order to remap the vectors you have to do the following:
> > > > > >
> > > > > > 1. Reserve 0x40 bytes at 0x40000000 (Start of RAM)
> > > > > > 2. At reset_handler, copy 0x40 bytes from 0x00004000 (start of
> your
> > > > main
> > > > > > app) to 0x40000000 (start of RAM).
> > > > > > 3. Remap the interrupt Vector table (write correct setting to
> > MEMMAP
> > > > > > register)
> > > > > >
> > > > > > Do you use interrupts (IRQ) in the bootloader?
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Alex
> > > > > >
> > > > > > --- In l...
> > >
> > > > lpc2000%40yahoogroups.com >
> > > > > 2540yahoogroups.com>>,
>
> > > > > > 42Bastian wrote:
> > > > > > >
> > > > > > > Sutton Mehaffey schrieb:
> > > > > > > > OK. Here are my map files for both bootloader and app (called
> > > > vera1)
> > > > > > > >
> > > > > > > > http://www.lookoutportablesecurity.com/sutton/bootload.map
> >
> > > > > > >
> > > > > > > >
> > > > > > >>
> > > > > > > >
> > > > > > > > http://www.lookoutportablesecurity.com/sutton/vera1.map
> >
> > > > > > >
> > > > > > > >
> > > > > > >>
> > > > > > >
> > > > > > > _terminateio - Undefined Weak Reference
> > > > > > > version 0x00004000 Data
> > > > > > > 2 lookout.o(.ARM.__AT_0x00004000)
> > > > > > >
> > > > > > > ^^^^^ why/what is this at 0x4000 ?
> > > > > > >
> > > > > > > Reset_Handler 0x0000405c ARM Code
> > > > > > > 0 startup.o(RESET)
> > > > > > >
> > > > > > > It looks, you bootloader should jump at 0x405c !
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > 42Bastian
> > > > > > > ------------------
> > > > > > > Parts of this email are written with invisible ink.
> > > > > > >
> > > > > > > Note: SPAM-only account, direct mail to bs42@
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Sutton Mehaffey
> > > > > Lookout Portable Security
> > > > > 4040 Royal Dr.
> > > > > Kennesaw, GA 30144
> > > > > 770-514-7999, 800-207-6269
> > > > > Fax: 770-514-1285
> > > > > http://www.lookoutportablesecurity.com
> >
> > > > > > >
> > > > > sutton@...
> > > > >
> > > >
> > > >
> > >
> > > --
> > > Sutton Mehaffey
> > > Lookout Portable Security
> > > 4040 Royal Dr.
> > > Kennesaw, GA 30144
> > > 770-514-7999, 800-207-6269
> > > Fax: 770-514-1285
> > > http://www.lookoutportablesecurity.com
> >
> > > s...@lookoutportablesecurity.com
> > > >
> > >
> > >
> > >
> >
> > --
> > Miguel Angel Ajo Pelayo
> > http://www.nbee.es
> > +34 91 120 1798
> > +34 636 52 25 69
> > skype: ajoajoajo
> >
> >
> >
> > --
> Sutton Mehaffey
> Lookout Portable Security
> 4040 Royal Dr.
> Kennesaw, GA 30144
> 770-514-7999, 800-207-6269
> Fax: 770-514-1285
> http://www.lookoutportablesecurity.com
> s...@lookoutportablesecurity.com
>
--
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
2009/8/21 Sutton Mehaffey
> Don't know. It appears that the other 12 bytes are at the end of the
> file, so I'm still not sure why it wouldn't run.
> Miguel Angel wrote:
> >
> >
> > Hi!,
> > Great news :-)
> >
> > I wonder if hex2bin is putting some kind of IMAGE BASE + IMAGE LEN +
> > IMAGE CRC + ??? ... :)
> >
> > 2009/8/21 Sutton Mehaffey
> >
> >> >
> > >
> > >
> > > I'm still playing with it, but that appears to have fixed the problem.
> > > The .bin file created by Hex2Bin from the Keil .hex file has 18 other
> > > bytes it. 6 of which were the loading address of 0x4000, which I had
> > > compensated for, but there were 12 other bytes that I haven't figured
> > > out what's going on there.
> > >
> > > But, it appears that fromelf makes the proper .bin file for uploading.
> > > And, my version definition at 0x4000 still works. The compilation must
> > > adjust for that and start at 0x4004.
> > >
> > > Thanks to all. I'm still trying to figure out what the problem is with
> > > the hex2bin conversion. I'll follow up if I figure out anything.
> > >
> > > Sutton
> > >
> > > alexander_ribero wrote:
> > > >
> > > >
> > > > Hi:
> > > >
> > > > It seems that you are doing what needs to be done to jump correctly
> to
> > > > the main app. I'm now wondering (as some others have done) if the
> data
> > > > written at 0x4000 is the correct data.
> > > >
> > > > It is correct in the sense that you check byte by byte all the way
> from
> > > > the SD card to the Flash. Therefore, it is possible that the data
> > in the
> > > > SD card is not valid: that is, the binary file is incorrect.
> > > >
> > > > I use the following command to generate the binary file:
> > > >
> > > > c:\keil\arm\bin31\fromelf --bin --output .bin
> > > > .axf
> > > >
> > > > 1. Could you verify that this binary file and the one generated by
> > > > hex2bin matches?
> > > >
> > > > 2. Can you dump the memory at 0x4000 after writing data from the SD
> > card
> > > > and confirm that this data matches with the binary file generated by
> > > > fromelf, and that it is indeed the main app code?
> > > >
> > > > Your last comments about how the main app still fails after the jump,
> > > > but not when program via JTAG, prompted the memory and files
> questions.
> > > >
> > > > I've look at the remapping concept and for very simple applications,
> > > > like yours, it might not be required, as the IRQ interrupt vector
> > always
> > > > points to the same location (VICAddress) in both the bootloader and
> the
> > > > main appl.
> > > >
> > > > Regards,
> > > >
> > > > Alex
> > > >
> > > > --- In l... > lpc2000%40yahoogroups.com >
> > > > > lpc2000%40yahoogroups.com >,
>
> > > > Sutton Mehaffey wrote:
> > > > >
> > > > > Alex,
> > > > >
> > > > > I see what you are saying. Let me revamp and see if I can figure
> > things
> > > > > out.
> > > > >
> > > > > I never had applications that required loading at other locations
> > than
> > > > > 0, or had any need to change any parameters in startup in the many
> > > years
> > > > > of developing systems. So, I am a little rusty at how all that
> stuff
> > > > > works in startup.
> > > > >
> > > > > I actually thought that since each project (bootloader and app) was
> > > > > compiled separately that each would have it's own physical vector
> > > space.
> > > > > I thought the compiler and linker would take care of that. A little
> > > > > naive, I guess.
> > > > >
> > > > > So, when I load the bootloader and then the app from the JTAG,
> there
> > > > > must be some remapping taking place during the app load that I
> don't
> > > > > know about. If the bootloader is loaded at 0, can you explain what
> > > > > exactly happens when you load the app at 0x4000 as far as the
> > remapping
> > > > > goes? Keil's loading procedure must be doing the same thing that
> > I need
> > > > > to do on my upload. Does the uploading of the app overwrite
> pointers
> > > > > that the remap fixes?
> > > > >
> > > > > Maybe when it starts working, I'll finally understand what all
> > you guys
> > > > > have been trying to explain to me for the last week. But, until
> then
> > > > > I'll muddle through the manual again and again. I appreciate
> > > > > everybody's input.
> > > > >
> > > > > Maybe I need to ask Keil some questions. But, they have yet to
> > answer 2
> > > > > sets of questions in a 2 week period.
> > > > >
> > > > > By the way, jumping to 0x4004 doesn't work. Still hangs. I tried
> > > > > 0x405C (which is the reset handler that bastian pointed out in
> > the map)
> > > > > and same thing. However, to my surprise, it still works if you
> > load the
> > > > > app from the JTAG and jump to 0x4004.
> > > > >
> > > > > Sutton
> > > > >
> > > > >
> > > > >
> > > > > alexander_ribero wrote:
> > > > > >
> > > > > >
> > > > > > Hi Sutton:
> > > > > >
> > > > > > It is clear from the .map files that you still haven't remap the
> > > > > > interrupt vector table to RAM when entering your main
> application.
> > > > > >
> > > > > > >From your previous message #44141
> > > > > > http://tech.groups.yahoo.com/group/lpc2000/message/44141
> >
> > > > > > >
> > > > > > > >
> > > > > > >>
> > > > > >
> > > > > > it is possible to see that you force the addresses of the
> interrupt
> > > > > > vectors to be specific addresses after 0x4000
> > > > > >
> > > > > > Vectors LDR PC, Reset_Addr
> > > > > > LDR PC, Undef_Addr
> > > > > > LDR PC, SWI_Addr
> > > > > > LDR PC, PAbt_Addr
> > > > > > LDR PC, DAbt_Addr
> > > > > > NOP ; Reserved Vector
> > > > > > ; LDR PC, IRQ_Addr
> > > > > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > > > > LDR PC, FIQ_Addr
> > > > > >
> > > > > > Reset_Addr DCD Reset_Handler
> > > > > > Undef_Addr DCD 0x4004
> > > > > > SWI_Addr DCD 0x4008
> > > > > > PAbt_Addr DCD 0x400C
> > > > > > DAbt_Addr DCD 0x4010
> > > > > > DCD 0 ; Reserved Address
> > > > > > IRQ_Addr DCD 0x4014
> > > > > > FIQ_Addr DCD 0x401C
> > > > > >
> > > > > > However, there is nothing indicating that those addresses
> > contain the
> > > > > > correct handler for each exception. In fact, what this code is
> > > > doing is
> > > > > > to make each interrupt vector point to itself, except for the IRQ
> > > > vector.
> > > > > >
> > > > > > Now, if you don't remap the interrupt vectors, the processor
> > will use
> > > > > > the vectors provided by the bootloader:
> > > > > > (see line 340 of the bootloader.map file)
> > > > > > Undef_Handler 0x00000040 ARM Code 4 startup.o(RESET)
> > > > > > SWI_Handler 0x00000044 ARM Code 4 startup.o(RESET)
> > > > > > PAbt_Handler 0x00000048 ARM Code 4 startup.o(RESET)
> > > > > > DAbt_Handler 0x0000004c ARM Code 4 startup.o(RESET)
> > > > > > IRQ_Handler 0x00000050 ARM Code 4 startup.o(RESET)
> > > > > > FIQ_Handler 0x00000054 ARM Code 4 startup.o(RESET)
> > > > > >
> > > > > > These vectors probably are pointing to different interrupt
> handling
> > > > > > routines.
> > > > > >
> > > > > > In order to remap the vectors you have to do the following:
> > > > > >
> > > > > > 1. Reserve 0x40 bytes at 0x40000000 (Start of RAM)
> > > > > > 2. At reset_handler, copy 0x40 bytes from 0x00004000 (start of
> your
> > > > main
> > > > > > app) to 0x40000000 (start of RAM).
> > > > > > 3. Remap the interrupt Vector table (write correct setting to
> > MEMMAP
> > > > > > register)
> > > > > >
> > > > > > Do you use interrupts (IRQ) in the bootloader?
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Alex
> > > > > >
> > > > > > --- In l...
> > >
> > > > lpc2000%40yahoogroups.com >
> > > > > 2540yahoogroups.com>>,
>
> > > > > > 42Bastian wrote:
> > > > > > >
> > > > > > > Sutton Mehaffey schrieb:
> > > > > > > > OK. Here are my map files for both bootloader and app (called
> > > > vera1)
> > > > > > > >
> > > > > > > > http://www.lookoutportablesecurity.com/sutton/bootload.map
> >
> > > > > > >
> > > > > > > >
> > > > > > >>
> > > > > > > >
> > > > > > > > http://www.lookoutportablesecurity.com/sutton/vera1.map
> >
> > > > > > >
> > > > > > > >
> > > > > > >>
> > > > > > >
> > > > > > > _terminateio - Undefined Weak Reference
> > > > > > > version 0x00004000 Data
> > > > > > > 2 lookout.o(.ARM.__AT_0x00004000)
> > > > > > >
> > > > > > > ^^^^^ why/what is this at 0x4000 ?
> > > > > > >
> > > > > > > Reset_Handler 0x0000405c ARM Code
> > > > > > > 0 startup.o(RESET)
> > > > > > >
> > > > > > > It looks, you bootloader should jump at 0x405c !
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > 42Bastian
> > > > > > > ------------------
> > > > > > > Parts of this email are written with invisible ink.
> > > > > > >
> > > > > > > Note: SPAM-only account, direct mail to bs42@
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Sutton Mehaffey
> > > > > Lookout Portable Security
> > > > > 4040 Royal Dr.
> > > > > Kennesaw, GA 30144
> > > > > 770-514-7999, 800-207-6269
> > > > > Fax: 770-514-1285
> > > > > http://www.lookoutportablesecurity.com
> >
> > > > > > >
> > > > > sutton@...
> > > > >
> > > >
> > > >
> > >
> > > --
> > > Sutton Mehaffey
> > > Lookout Portable Security
> > > 4040 Royal Dr.
> > > Kennesaw, GA 30144
> > > 770-514-7999, 800-207-6269
> > > Fax: 770-514-1285
> > > http://www.lookoutportablesecurity.com
> >
> > > s...@lookoutportablesecurity.com
> > > >
> > >
> > >
> > >
> >
> > --
> > Miguel Angel Ajo Pelayo
> > http://www.nbee.es
> > +34 91 120 1798
> > +34 636 52 25 69
> > skype: ajoajoajo
> >
> >
> >
> > --
> Sutton Mehaffey
> Lookout Portable Security
> 4040 Royal Dr.
> Kennesaw, GA 30144
> 770-514-7999, 800-207-6269
> Fax: 770-514-1285
> http://www.lookoutportablesecurity.com
> s...@lookoutportablesecurity.com
>
--
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
