I have a variable in serial eeprom that indicates 'app code good' or
not. I use an intermediate serial flash to hold the file from the SD
card. I compare byte for byte the code on the SD card to the serial
flash. When valid, I change the serial eeprom value to 0. I initiate a
WDT reset and the bootloader at 0 sees that the eeprom value is 0 and
starts the upload from the serial flash to the CPU flash (via IAP). I
compare byte for byte the upload to 0x00004000 and when valid, I change
the serial eeprom value to 'good code (0xA5). I initiate another WDT
reset, which works, but the transfer to 0x00004000 doesn't work.

This update is to be done in the field by customers without JTAG.

From the previous posts, I guess I'm trying to figure out how the
interrupt vectors are affected by all of this. They are stored at 0.
I'm guessing by Richard's post that depending on what application I
loaded last by JTAG (bootloader or app), the interrupt vectors are
correct, but not for the first loaded code. The code 0x00-0x1C on the
SD card (which is Keil's compiled code converted to binary) looks
exactly like the code at 0x00-0x1C at 0x00000000. It is put at
0x00004000, which I thought was sufficient. Still trying to figure it out.

Sutton

m...@compusmart.ab.ca wrote:
>
>
> What criteria do you use to determine if control can be passed from
> your bootloader to the main application? Do you use a CRC or verify
> it to make sure
> it was written correctly?
>
> Could you use your bootloader to write the main app, and then do a
> verify via JTAG to see if they are the same?
>
> Mike
>
> Quoting Sutton Mehaffey > >:
>
> > OK. So, what is happening in Keil's uVision when I use the JTAG to load
> > the bootloader at 0x00000000 and then the app at 0x00004000? Is the
> > one I load last is the one that has the correct interrupt vector
> > pointers? It doesn't seem to matter which one I load first and last,
> > the interrupts in both sets of code seem to work just fine and the
> > bootloader transfers correctly to the app.
> >
> > Sutton
> >
> >
> >
> > rtstofer wrote:
> >>
> >>
> >> --- In l...
> ,
> >> "Sutton Mehaffey" wrote:
> >> >
> >> > Because I'm not clear on why, why do I need to remap the interrupt
> >> vector when my bootloader code at 0x00000000 never changes? I'm not
> >> copying my SD code to location 0x00000000.
> >> >
> >> > Sutton
> >>
> >> So the vectors point to the functions in the code that is actually
> >> running.
> >>
> >> Now, if you ignore every vector except IRG and you do the VIC trick of
> >> using the vector to get the address from the VIC, then you don't have
> >> to do anything.
> >>
> >> The IRQ interrupt vector should have code like:
> >>
> >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> >>
> >> However, none of the other interrupt vectors will point to your
> >> downloaded code. They will only point to entries in your boot code.
> >>
> >> That might be good enough.
> >>
> >> Richard
> >>
> >>
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr. #100
> > Kennesaw, GA 30144
> > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > s...@lookoutportablesecurity.com
>
> >

--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr. #100
Kennesaw, GA 30144
800-207-6269, 770-514-7999, 770-514-1285 FAX
s...@lookoutportablesecurity.com

Start a New Thread

How does your bootloader handle revectoring all of the interrupts?
I don't understand why the vectors located at 0x0004000 would be the
same as those at 0x00000000, since they are for different applications.

Am I to understand that the code on the SD card begins at 0? If so that
is not correct, as it should be located at 0x00004000. It wouldn't make
sense to have the vectors in the main application loaded at zero, unless
they would be executed from there. Also, given that the startup code
usually contains the vectors and the startup routines, they certainly
shouldn't be located at 0.

How do you jump to the main app from your bootloader?

This would all me much easier for us to figure out if we had the
relevant bits of code.

Mike
> -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of Sutton Mehaffey
> Sent: Wednesday, August 19, 2009 5:57 PM
> To: l...
> Subject: Re: [lpc2000] Re: new SD code transfer to LPC2148 not quite
> working
> I have a variable in serial eeprom that indicates 'app code good' or
> not. I use an intermediate serial flash to hold the file from the SD
> card. I compare byte for byte the code on the SD card to the serial
> flash. When valid, I change the serial eeprom value to 0. I
> initiate a
> WDT reset and the bootloader at 0 sees that the eeprom value is 0 and
> starts the upload from the serial flash to the CPU flash (via
> IAP). I
> compare byte for byte the upload to 0x00004000 and when
> valid, I change
> the serial eeprom value to 'good code (0xA5). I initiate another WDT
> reset, which works, but the transfer to 0x00004000 doesn't work.
>
> This update is to be done in the field by customers without JTAG.
>
> From the previous posts, I guess I'm trying to figure out how the
> interrupt vectors are affected by all of this. They are
> stored at 0.
> I'm guessing by Richard's post that depending on what application I
> loaded last by JTAG (bootloader or app), the interrupt vectors are
> correct, but not for the first loaded code. The code
> 0x00-0x1C on the
> SD card (which is Keil's compiled code converted to binary) looks
> exactly like the code at 0x00-0x1C at 0x00000000. It is put at
> 0x00004000, which I thought was sufficient. Still trying to
> figure it out.
>
> Sutton
>
> m...@compusmart.ab.ca wrote:
> >
> >
> > What criteria do you use to determine if control can be passed from
> > your bootloader to the main application? Do you use a CRC or verify
> > it to make sure
> > it was written correctly?
> >
> > Could you use your bootloader to write the main app, and then do a
> > verify via JTAG to see if they are the same?
> >
> > Mike
> >
> > Quoting Sutton Mehaffey > > >:
> >
> > > OK. So, what is happening in Keil's uVision when I use
> the JTAG to load
> > > the bootloader at 0x00000000 and then the app at
> 0x00004000? Is the
> > > one I load last is the one that has the correct interrupt vector
> > > pointers? It doesn't seem to matter which one I load
> first and last,
> > > the interrupts in both sets of code seem to work just fine and the
> > > bootloader transfers correctly to the app.
> > >
> > > Sutton
> > >
> > >
> > >
> > > rtstofer wrote:
> > >>
> > >>
> > >> --- In l...
>
> > ,
> > >> "Sutton Mehaffey" wrote:
> > >> >
> > >> > Because I'm not clear on why, why do I need to remap
> the interrupt
> > >> vector when my bootloader code at 0x00000000 never
> changes? I'm not
> > >> copying my SD code to location 0x00000000.
> > >> >
> > >> > Sutton
> > >>
> > >> So the vectors point to the functions in the code that
> is actually
> > >> running.
> > >>
> > >> Now, if you ignore every vector except IRG and you do
> the VIC trick of
> > >> using the vector to get the address from the VIC, then
> you don't have
> > >> to do anything.
> > >>
> > >> The IRQ interrupt vector should have code like:
> > >>
> > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > >>
> > >> However, none of the other interrupt vectors will point to your
> > >> downloaded code. They will only point to entries in your
> boot code.
> > >>
> > >> That might be good enough.
> > >>
> > >> Richard
> > >>
> > >>
> > >
> > > --
> > > Sutton Mehaffey
> > > Lookout Portable Security
> > > 4040 Royal Dr. #100
> > > Kennesaw, GA 30144
> > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > s...@lookoutportablesecurity.com
> >
> > >
> >
> > --
> Sutton Mehaffey
> Lookout Portable Security
> 4040 Royal Dr. #100
> Kennesaw, GA 30144
> 800-207-6269, 770-514-7999, 770-514-1285 FAX
> s...@lookoutportablesecurity.com
>

Start a New Thread

The code is compiled at 0x00004000, converted to binary and loaded on
the SD card. The application always runs at 0x00004000. The bootloader
is never changed in the field and always runs at 0. The first 6 bytes
of the compiled file hold the 0x00004000. I assume that's how Keil
knows to locate it at 0x00004000 thru the JTAG.

Where in the startup code do I specify that the vectors starts at
0x00004000?

typedef void (*APP)(void);
APP app = (APP)0x00004000;

app();

Michael Anton wrote:
>
>
> How does your bootloader handle revectoring all of the interrupts?
> I don't understand why the vectors located at 0x0004000 would be the
> same as those at 0x00000000, since they are for different applications.
>
> Am I to understand that the code on the SD card begins at 0? If so that
> is not correct, as it should be located at 0x00004000. It wouldn't make
> sense to have the vectors in the main application loaded at zero, unless
> they would be executed from there. Also, given that the startup code
> usually contains the vectors and the startup routines, they certainly
> shouldn't be located at 0.
>
> How do you jump to the main app from your bootloader?
>
> This would all me much easier for us to figure out if we had the
> relevant bits of code.
>
> Mike
>
> > -----Original Message-----
> > From: l...
> > [mailto:l... ]On
> Behalf
> > Of Sutton Mehaffey
> > Sent: Wednesday, August 19, 2009 5:57 PM
> > To: l...
> > Subject: Re: [lpc2000] Re: new SD code transfer to LPC2148 not quite
> > working
> >
> >
> > I have a variable in serial eeprom that indicates 'app code good' or
> > not. I use an intermediate serial flash to hold the file from the SD
> > card. I compare byte for byte the code on the SD card to the serial
> > flash. When valid, I change the serial eeprom value to 0. I
> > initiate a
> > WDT reset and the bootloader at 0 sees that the eeprom value is 0 and
> > starts the upload from the serial flash to the CPU flash (via
> > IAP). I
> > compare byte for byte the upload to 0x00004000 and when
> > valid, I change
> > the serial eeprom value to 'good code (0xA5). I initiate another WDT
> > reset, which works, but the transfer to 0x00004000 doesn't work.
> >
> > This update is to be done in the field by customers without JTAG.
> >
> > From the previous posts, I guess I'm trying to figure out how the
> > interrupt vectors are affected by all of this. They are
> > stored at 0.
> > I'm guessing by Richard's post that depending on what application I
> > loaded last by JTAG (bootloader or app), the interrupt vectors are
> > correct, but not for the first loaded code. The code
> > 0x00-0x1C on the
> > SD card (which is Keil's compiled code converted to binary) looks
> > exactly like the code at 0x00-0x1C at 0x00000000. It is put at
> > 0x00004000, which I thought was sufficient. Still trying to
> > figure it out.
> >
> > Sutton
> >
> >
> >
> >
> >
> > m...@compusmart.ab.ca wrote:
> > >
> > >
> > > What criteria do you use to determine if control can be passed from
> > > your bootloader to the main application? Do you use a CRC or verify
> > > it to make sure
> > > it was written correctly?
> > >
> > > Could you use your bootloader to write the main app, and then do a
> > > verify via JTAG to see if they are the same?
> > >
> > > Mike
> > >
> > > Quoting Sutton Mehaffey >
> > > >:
> > >
> > > > OK. So, what is happening in Keil's uVision when I use
> > the JTAG to load
> > > > the bootloader at 0x00000000 and then the app at
> > 0x00004000? Is the
> > > > one I load last is the one that has the correct interrupt vector
> > > > pointers? It doesn't seem to matter which one I load
> > first and last,
> > > > the interrupts in both sets of code seem to work just fine and the
> > > > bootloader transfers correctly to the app.
> > > >
> > > > Sutton
> > > >
> > > >
> > > >
> > > > rtstofer wrote:
> > > >>
> > > >>
> > > >> --- In l...
> >
> > > ,
> > > >> "Sutton Mehaffey" wrote:
> > > >> >
> > > >> > Because I'm not clear on why, why do I need to remap
> > the interrupt
> > > >> vector when my bootloader code at 0x00000000 never
> > changes? I'm not
> > > >> copying my SD code to location 0x00000000.
> > > >> >
> > > >> > Sutton
> > > >>
> > > >> So the vectors point to the functions in the code that
> > is actually
> > > >> running.
> > > >>
> > > >> Now, if you ignore every vector except IRG and you do
> > the VIC trick of
> > > >> using the vector to get the address from the VIC, then
> > you don't have
> > > >> to do anything.
> > > >>
> > > >> The IRQ interrupt vector should have code like:
> > > >>
> > > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > > >>
> > > >> However, none of the other interrupt vectors will point to your
> > > >> downloaded code. They will only point to entries in your
> > boot code.
> > > >>
> > > >> That might be good enough.
> > > >>
> > > >> Richard
> > > >>
> > > >>
> > > >
> > > > --
> > > > Sutton Mehaffey
> > > > Lookout Portable Security
> > > > 4040 Royal Dr. #100
> > > > Kennesaw, GA 30144
> > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > s...@lookoutportablesecurity.com
>
> > >
> > > >
> > >
> > >
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr. #100
> > Kennesaw, GA 30144
> > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > s...@lookoutportablesecurity.com
>
> >

--
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

Start a New Thread

Copy & Paste, I already told you (some weeks ago) a way of doing it :)

This is an example of IRQ pass-thru from my usual bootloader to the
application
(that starts at 0x2000): (ARM Assembler format for a 214x/213x device)
Modify your Startup.s to put the vectors this way:

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, [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
0x2014
FIQ_Addr DCD 0x401C

And something important too, is to end the Startup initialization with:

MSR CPSR_c, #Mode_SYS (instead of
MSR CPSR_c, #Mode_USR)

so your app startup can change processor mode again and setup all the mode's
stacks, according
to your app configuration.

2009/8/20 Sutton Mehaffey

> The code is compiled at 0x00004000, converted to binary and loaded on
> the SD card. The application always runs at 0x00004000. The bootloader
> is never changed in the field and always runs at 0. The first 6 bytes
> of the compiled file hold the 0x00004000. I assume that's how Keil
> knows to locate it at 0x00004000 thru the JTAG.
>
> Where in the startup code do I specify that the vectors starts at
> 0x00004000?
>
> typedef void (*APP)(void);
> APP app = (APP)0x00004000;
>
> app();
> Michael Anton wrote:
> >
> >
> > How does your bootloader handle revectoring all of the interrupts?
> > I don't understand why the vectors located at 0x0004000 would be the
> > same as those at 0x00000000, since they are for different applications.
> >
> > Am I to understand that the code on the SD card begins at 0? If so that
> > is not correct, as it should be located at 0x00004000. It wouldn't make
> > sense to have the vectors in the main application loaded at zero, unless
> > they would be executed from there. Also, given that the startup code
> > usually contains the vectors and the startup routines, they certainly
> > shouldn't be located at 0.
> >
> > How do you jump to the main app from your bootloader?
> >
> > This would all me much easier for us to figure out if we had the
> > relevant bits of code.
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: l... > lpc2000%40yahoogroups.com >
> > > [mailto:l... > lpc2000%40yahoogroups.com >]On
> > Behalf
> > > Of Sutton Mehaffey
> > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > To: l... > lpc2000%40yahoogroups.com >
> > > Subject: Re: [lpc2000] Re: new SD code transfer to LPC2148 not quite
> > > working
> > >
> > >
> > > I have a variable in serial eeprom that indicates 'app code good' or
> > > not. I use an intermediate serial flash to hold the file from the SD
> > > card. I compare byte for byte the code on the SD card to the serial
> > > flash. When valid, I change the serial eeprom value to 0. I
> > > initiate a
> > > WDT reset and the bootloader at 0 sees that the eeprom value is 0 and
> > > starts the upload from the serial flash to the CPU flash (via
> > > IAP). I
> > > compare byte for byte the upload to 0x00004000 and when
> > > valid, I change
> > > the serial eeprom value to 'good code (0xA5). I initiate another WDT
> > > reset, which works, but the transfer to 0x00004000 doesn't work.
> > >
> > > This update is to be done in the field by customers without JTAG.
> > >
> > > From the previous posts, I guess I'm trying to figure out how the
> > > interrupt vectors are affected by all of this. They are
> > > stored at 0.
> > > I'm guessing by Richard's post that depending on what application I
> > > loaded last by JTAG (bootloader or app), the interrupt vectors are
> > > correct, but not for the first loaded code. The code
> > > 0x00-0x1C on the
> > > SD card (which is Keil's compiled code converted to binary) looks
> > > exactly like the code at 0x00-0x1C at 0x00000000. It is put at
> > > 0x00004000, which I thought was sufficient. Still trying to
> > > figure it out.
> > >
> > > Sutton
> > >
> > >
> > >
> > >
> > >
> > > m...@compusmart.ab.ca > manton%40compusmart.ab.ca > wrote:
> > > >
> > > >
> > > > What criteria do you use to determine if control can be passed from
> > > > your bootloader to the main application? Do you use a CRC or verify
> > > > it to make sure
> > > > it was written correctly?
> > > >
> > > > Could you use your bootloader to write the main app, and then do a
> > > > verify via JTAG to see if they are the same?
> > > >
> > > > Mike
> > > >
> > > > Quoting Sutton Mehaffey
> >
> >
> > > >
> >>:
> > > >
> > > > > OK. So, what is happening in Keil's uVision when I use
> > > the JTAG to load
> > > > > the bootloader at 0x00000000 and then the app at
> > > 0x00004000? Is the
> > > > > one I load last is the one that has the correct interrupt vector
> > > > > pointers? It doesn't seem to matter which one I load
> > > first and last,
> > > > > the interrupts in both sets of code seem to work just fine and the
> > > > > bootloader transfers correctly to the app.
> > > > >
> > > > > Sutton
> > > > >
> > > > >
> > > > >
> > > > > rtstofer wrote:
> > > > >>
> > > > >>
> > > > >> --- In l... > lpc2000%40yahoogroups.com >
> > > >
> > > > >,
> > > > >> "Sutton Mehaffey" wrote:
> > > > >> >
> > > > >> > Because I'm not clear on why, why do I need to remap
> > > the interrupt
> > > > >> vector when my bootloader code at 0x00000000 never
> > > changes? I'm not
> > > > >> copying my SD code to location 0x00000000.
> > > > >> >
> > > > >> > Sutton
> > > > >>
> > > > >> So the vectors point to the functions in the code that
> > > is actually
> > > > >> running.
> > > > >>
> > > > >> Now, if you ignore every vector except IRG and you do
> > > the VIC trick of
> > > > >> using the vector to get the address from the VIC, then
> > > you don't have
> > > > >> to do anything.
> > > > >>
> > > > >> The IRQ interrupt vector should have code like:
> > > > >>
> > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > > > >>
> > > > >> However, none of the other interrupt vectors will point to your
> > > > >> downloaded code. They will only point to entries in your
> > > boot code.
> > > > >>
> > > > >> That might be good enough.
> > > > >>
> > > > >> Richard
> > > > >>
> > > > >>
> > > > >
> > > > > --
> > > > > Sutton Mehaffey
> > > > > Lookout Portable Security
> > > > > 4040 Royal Dr. #100
> > > > > Kennesaw, GA 30144
> > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
> > > > >
> > > >
> > > >
> > >
> > > --
> > > Sutton Mehaffey
> > > Lookout Portable Security
> > > 4040 Royal Dr. #100
> > > Kennesaw, GA 30144
> > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > s...@lookoutportablesecurity.com
> >
> >
> > >
> >
> > --
> 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


Start a New Thread

Hi Sutton:

Keil uVision has the option to use a scatter file to link the different sections to specific memory locations.

In our project, we have two targets for the main application: one is the Debug target to use independently of a bootloader. The other one is the Release target, to be used when the bootloader is programmed in the MCU.

We use, therefore, two scatter files: one for the Debug target and other for the Release Target.

Basically, the scatter file indicates where the sections go.

For the Debug Target, we place the RESET section (named in the startup.s file) at 0x00000000, and the rest of the code at the target address (in your case 0x00004000)

For the Release Target, we place the RESET section AND the rest of the code at the target address (in your case 0x00004000). This means that if we load the Release binary (with the JTAG) it won't run, as nothing is placed at 0x00000000, where is expected by the ARM processor.

If you are not using scatter files, most likely you are using the "Memory Layout from Target Dialog" option, which would not let you correctly generate an application to be loaded by the bootloader.

Regards,

Alex
--- In l..., Miguel Angel wrote:
>
> Copy & Paste, I already told you (some weeks ago) a way of doing it :)
>
> This is an example of IRQ pass-thru from my usual bootloader to the
> application
> (that starts at 0x2000): (ARM Assembler format for a 214x/213x device)
> Modify your Startup.s to put the vectors this way:
>
> 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, [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
> 0x2014
> FIQ_Addr DCD 0x401C
>
> And something important too, is to end the Startup initialization with:
>
> MSR CPSR_c, #Mode_SYS (instead of
> MSR CPSR_c, #Mode_USR)
>
> so your app startup can change processor mode again and setup all the mode's
> stacks, according
> to your app configuration.
>
> 2009/8/20 Sutton Mehaffey >
> >
> > The code is compiled at 0x00004000, converted to binary and loaded on
> > the SD card. The application always runs at 0x00004000. The bootloader
> > is never changed in the field and always runs at 0. The first 6 bytes
> > of the compiled file hold the 0x00004000. I assume that's how Keil
> > knows to locate it at 0x00004000 thru the JTAG.
> >
> > Where in the startup code do I specify that the vectors starts at
> > 0x00004000?
> >
> > typedef void (*APP)(void);
> > APP app = (APP)0x00004000;
> >
> > app();
> >
> >
> > Michael Anton wrote:
> > >
> > >
> > > How does your bootloader handle revectoring all of the interrupts?
> > > I don't understand why the vectors located at 0x0004000 would be the
> > > same as those at 0x00000000, since they are for different applications.
> > >
> > > Am I to understand that the code on the SD card begins at 0? If so that
> > > is not correct, as it should be located at 0x00004000. It wouldn't make
> > > sense to have the vectors in the main application loaded at zero, unless
> > > they would be executed from there. Also, given that the startup code
> > > usually contains the vectors and the startup routines, they certainly
> > > shouldn't be located at 0.
> > >
> > > How do you jump to the main app from your bootloader?
> > >
> > > This would all me much easier for us to figure out if we had the
> > > relevant bits of code.
> > >
> > > Mike
> > >
> > > > -----Original Message-----
> > > > From: l... > > lpc2000%40yahoogroups.com >
> > > > [mailto:l... > > lpc2000%40yahoogroups.com >]On
> > > Behalf
> > > > Of Sutton Mehaffey
> > > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > > To: l... > > lpc2000%40yahoogroups.com >
> > > > Subject: Re: [lpc2000] Re: new SD code transfer to LPC2148 not quite
> > > > working
> > > >
> > > >
> > > > I have a variable in serial eeprom that indicates 'app code good' or
> > > > not. I use an intermediate serial flash to hold the file from the SD
> > > > card. I compare byte for byte the code on the SD card to the serial
> > > > flash. When valid, I change the serial eeprom value to 0. I
> > > > initiate a
> > > > WDT reset and the bootloader at 0 sees that the eeprom value is 0 and
> > > > starts the upload from the serial flash to the CPU flash (via
> > > > IAP). I
> > > > compare byte for byte the upload to 0x00004000 and when
> > > > valid, I change
> > > > the serial eeprom value to 'good code (0xA5). I initiate another WDT
> > > > reset, which works, but the transfer to 0x00004000 doesn't work.
> > > >
> > > > This update is to be done in the field by customers without JTAG.
> > > >
> > > > From the previous posts, I guess I'm trying to figure out how the
> > > > interrupt vectors are affected by all of this. They are
> > > > stored at 0.
> > > > I'm guessing by Richard's post that depending on what application I
> > > > loaded last by JTAG (bootloader or app), the interrupt vectors are
> > > > correct, but not for the first loaded code. The code
> > > > 0x00-0x1C on the
> > > > SD card (which is Keil's compiled code converted to binary) looks
> > > > exactly like the code at 0x00-0x1C at 0x00000000. It is put at
> > > > 0x00004000, which I thought was sufficient. Still trying to
> > > > figure it out.
> > > >
> > > > Sutton
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > manton@... > > manton%40compusmart.ab.ca > wrote:
> > > > >
> > > > >
> > > > > What criteria do you use to determine if control can be passed from
> > > > > your bootloader to the main application? Do you use a CRC or verify
> > > > > it to make sure
> > > > > it was written correctly?
> > > > >
> > > > > Could you use your bootloader to write the main app, and then do a
> > > > > verify via JTAG to see if they are the same?
> > > > >
> > > > > Mike
> > > > >
> > > > > Quoting Sutton Mehaffey
> > >
> > >
> > > > >
> > >>:
> > > > >
> > > > > > OK. So, what is happening in Keil's uVision when I use
> > > > the JTAG to load
> > > > > > the bootloader at 0x00000000 and then the app at
> > > > 0x00004000? Is the
> > > > > > one I load last is the one that has the correct interrupt vector
> > > > > > pointers? It doesn't seem to matter which one I load
> > > > first and last,
> > > > > > the interrupts in both sets of code seem to work just fine and the
> > > > > > bootloader transfers correctly to the app.
> > > > > >
> > > > > > Sutton
> > > > > >
> > > > > >
> > > > > >
> > > > > > rtstofer wrote:
> > > > > >>
> > > > > >>
> > > > > >> --- In l... > > lpc2000%40yahoogroups.com >
> > > > >
> > > > > >,
> > > > > >> "Sutton Mehaffey" wrote:
> > > > > >> >
> > > > > >> > Because I'm not clear on why, why do I need to remap
> > > > the interrupt
> > > > > >> vector when my bootloader code at 0x00000000 never
> > > > changes? I'm not
> > > > > >> copying my SD code to location 0x00000000.
> > > > > >> >
> > > > > >> > Sutton
> > > > > >>
> > > > > >> So the vectors point to the functions in the code that
> > > > is actually
> > > > > >> running.
> > > > > >>
> > > > > >> Now, if you ignore every vector except IRG and you do
> > > > the VIC trick of
> > > > > >> using the vector to get the address from the VIC, then
> > > > you don't have
> > > > > >> to do anything.
> > > > > >>
> > > > > >> The IRQ interrupt vector should have code like:
> > > > > >>
> > > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > > > > >>
> > > > > >> However, none of the other interrupt vectors will point to your
> > > > > >> downloaded code. They will only point to entries in your
> > > > boot code.
> > > > > >>
> > > > > >> That might be good enough.
> > > > > >>
> > > > > >> Richard
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > --
> > > > > > Sutton Mehaffey
> > > > > > Lookout Portable Security
> > > > > > 4040 Royal Dr. #100
> > > > > > Kennesaw, GA 30144
> > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > sutton@...
> > >
> > >
> > > > >
> > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Sutton Mehaffey
> > > > Lookout Portable Security
> > > > 4040 Royal Dr. #100
> > > > Kennesaw, GA 30144
> > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > 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
> > sutton@...
> >
> >
> > --
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 91 120 1798
> +34 636 52 25 69
> skype: ajoajoajo
>
>
Start a New Thread

I must have missed that post. I don't see it in my folder.

Anyway, I just tried changing the startup file as per your request
(Miguel), and it still doesn't transfer to 0x4000 correctly. It hangs
after a successful upload, just like before.

I do use "Memory Layout from Target Dialog", so maybe Alex's comment has
some merit. Maybe I need to learn and use the scatter files.

Sutton

Miguel Angel wrote:
>
>
> Copy & Paste, I already told you (some weeks ago) a way of doing it :)
>
> This is an example of IRQ pass-thru from my usual bootloader to the
> application
> (that starts at 0x2000): (ARM Assembler format for a 214x/213x device)
> Modify your Startup.s to put the vectors this way:
>
> 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, [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
> 0x2014
> FIQ_Addr DCD 0x401C
>
> And something important too, is to end the Startup initialization with:
>
> MSR CPSR_c, #Mode_SYS (instead of
> MSR CPSR_c, #Mode_USR)
>
> so your app startup can change processor mode again and setup all the mode's
> stacks, according
> to your app configuration.
>
> 2009/8/20 Sutton Mehaffey > > >
> >
> > The code is compiled at 0x00004000, converted to binary and loaded on
> > the SD card. The application always runs at 0x00004000. The bootloader
> > is never changed in the field and always runs at 0. The first 6 bytes
> > of the compiled file hold the 0x00004000. I assume that's how Keil
> > knows to locate it at 0x00004000 thru the JTAG.
> >
> > Where in the startup code do I specify that the vectors starts at
> > 0x00004000?
> >
> > typedef void (*APP)(void);
> > APP app = (APP)0x00004000;
> >
> > app();
> >
> >
> > Michael Anton wrote:
> > >
> > >
> > > How does your bootloader handle revectoring all of the interrupts?
> > > I don't understand why the vectors located at 0x0004000 would be the
> > > same as those at 0x00000000, since they are for different applications.
> > >
> > > Am I to understand that the code on the SD card begins at 0? If so that
> > > is not correct, as it should be located at 0x00004000. It wouldn't make
> > > sense to have the vectors in the main application loaded at zero,
> unless
> > > they would be executed from there. Also, given that the startup code
> > > usually contains the vectors and the startup routines, they certainly
> > > shouldn't be located at 0.
> > >
> > > How do you jump to the main app from your bootloader?
> > >
> > > This would all me much easier for us to figure out if we had the
> > > relevant bits of code.
> > >
> > > Mike
> > >
> > > > -----Original Message-----
> > > > From: l...
> > > lpc2000%40yahoogroups.com >
> > > > [mailto:l...
> > > lpc2000%40yahoogroups.com >]On
> > > Behalf
> > > > Of Sutton Mehaffey
> > > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > > To: l...
> > > lpc2000%40yahoogroups.com >
> > > > Subject: Re: [lpc2000] Re: new SD code transfer to LPC2148 not quite
> > > > working
> > > >
> > > >
> > > > I have a variable in serial eeprom that indicates 'app code good' or
> > > > not. I use an intermediate serial flash to hold the file from the SD
> > > > card. I compare byte for byte the code on the SD card to the serial
> > > > flash. When valid, I change the serial eeprom value to 0. I
> > > > initiate a
> > > > WDT reset and the bootloader at 0 sees that the eeprom value is 0 and
> > > > starts the upload from the serial flash to the CPU flash (via
> > > > IAP). I
> > > > compare byte for byte the upload to 0x00004000 and when
> > > > valid, I change
> > > > the serial eeprom value to 'good code (0xA5). I initiate another WDT
> > > > reset, which works, but the transfer to 0x00004000 doesn't work.
> > > >
> > > > This update is to be done in the field by customers without JTAG.
> > > >
> > > > From the previous posts, I guess I'm trying to figure out how the
> > > > interrupt vectors are affected by all of this. They are
> > > > stored at 0.
> > > > I'm guessing by Richard's post that depending on what application I
> > > > loaded last by JTAG (bootloader or app), the interrupt vectors are
> > > > correct, but not for the first loaded code. The code
> > > > 0x00-0x1C on the
> > > > SD card (which is Keil's compiled code converted to binary) looks
> > > > exactly like the code at 0x00-0x1C at 0x00000000. It is put at
> > > > 0x00004000, which I thought was sufficient. Still trying to
> > > > figure it out.
> > > >
> > > > Sutton
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > m...@compusmart.ab.ca
> > > manton%40compusmart.ab.ca > wrote:
> > > > >
> > > > >
> > > > > What criteria do you use to determine if control can be passed from
> > > > > your bootloader to the main application? Do you use a CRC or verify
> > > > > it to make sure
> > > > > it was written correctly?
> > > > >
> > > > > Could you use your bootloader to write the main app, and then do a
> > > > > verify via JTAG to see if they are the same?
> > > > >
> > > > > Mike
> > > > >
> > > > > Quoting Sutton Mehaffey >
> > >
>
> > >
> > > > >
>
> > >>:
> > > > >
> > > > > > OK. So, what is happening in Keil's uVision when I use
> > > > the JTAG to load
> > > > > > the bootloader at 0x00000000 and then the app at
> > > > 0x00004000? Is the
> > > > > > one I load last is the one that has the correct interrupt vector
> > > > > > pointers? It doesn't seem to matter which one I load
> > > > first and last,
> > > > > > the interrupts in both sets of code seem to work just fine
> and the
> > > > > > bootloader transfers correctly to the app.
> > > > > >
> > > > > > Sutton
> > > > > >
> > > > > >
> > > > > >
> > > > > > rtstofer wrote:
> > > > > >>
> > > > > >>
> > > > > >> --- In l...
> > > lpc2000%40yahoogroups.com >
> > > > >
> > > > > >,
> > > > > >> "Sutton Mehaffey" wrote:
> > > > > >> >
> > > > > >> > Because I'm not clear on why, why do I need to remap
> > > > the interrupt
> > > > > >> vector when my bootloader code at 0x00000000 never
> > > > changes? I'm not
> > > > > >> copying my SD code to location 0x00000000.
> > > > > >> >
> > > > > >> > Sutton
> > > > > >>
> > > > > >> So the vectors point to the functions in the code that
> > > > is actually
> > > > > >> running.
> > > > > >>
> > > > > >> Now, if you ignore every vector except IRG and you do
> > > > the VIC trick of
> > > > > >> using the vector to get the address from the VIC, then
> > > > you don't have
> > > > > >> to do anything.
> > > > > >>
> > > > > >> The IRQ interrupt vector should have code like:
> > > > > >>
> > > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > > > > >>
> > > > > >> However, none of the other interrupt vectors will point to your
> > > > > >> downloaded code. They will only point to entries in your
> > > > boot code.
> > > > > >>
> > > > > >> That might be good enough.
> > > > > >>
> > > > > >> Richard
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > --
> > > > > > Sutton Mehaffey
> > > > > > Lookout Portable Security
> > > > > > 4040 Royal Dr. #100
> > > > > > Kennesaw, GA 30144
> > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
>
> > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Sutton Mehaffey
> > > > Lookout Portable Security
> > > > 4040 Royal Dr. #100
> > > > Kennesaw, GA 30144
> > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > >
> > >
> > >
> >
> > --
> > 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

Start a New Thread

Yes, my code will only help if you're using FIQs or SWIs,

For the application binary, alex's comment is quite important, you
should really set the application code base address to 0x4000 or
some jump/calls will get bad addresses.

2009/8/20 Sutton Mehaffey

> I must have missed that post. I don't see it in my folder.
>
> Anyway, I just tried changing the startup file as per your request
> (Miguel), and it still doesn't transfer to 0x4000 correctly. It hangs
> after a successful upload, just like before.
>
>
> I do use "Memory Layout from Target Dialog", so maybe Alex's comment has
> some merit. Maybe I need to learn and use the scatter files.
>
> Sutton
> Miguel Angel wrote:
> >
> >
> > Copy & Paste, I already told you (some weeks ago) a way of doing it :)
> >
> > This is an example of IRQ pass-thru from my usual bootloader to the
> > application
> > (that starts at 0x2000): (ARM Assembler format for a 214x/213x device)
> > Modify your Startup.s to put the vectors this way:
> >
> > 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, [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
> > 0x2014
> > FIQ_Addr DCD 0x401C
> >
> > And something important too, is to end the Startup initialization with:
> >
> > MSR CPSR_c, #Mode_SYS (instead of
> > MSR CPSR_c, #Mode_USR)
> >
> > so your app startup can change processor mode again and setup all the
> mode's
> > stacks, according
> > to your app configuration.
> >
> > 2009/8/20 Sutton Mehaffey
> >
> >> >
> > >
> > >
> > > The code is compiled at 0x00004000, converted to binary and loaded on
> > > the SD card. The application always runs at 0x00004000. The bootloader
> > > is never changed in the field and always runs at 0. The first 6 bytes
> > > of the compiled file hold the 0x00004000. I assume that's how Keil
> > > knows to locate it at 0x00004000 thru the JTAG.
> > >
> > > Where in the startup code do I specify that the vectors starts at
> > > 0x00004000?
> > >
> > > typedef void (*APP)(void);
> > > APP app = (APP)0x00004000;
> > >
> > > app();
> > >
> > >
> > > Michael Anton wrote:
> > > >
> > > >
> > > > How does your bootloader handle revectoring all of the interrupts?
> > > > I don't understand why the vectors located at 0x0004000 would be the
> > > > same as those at 0x00000000, since they are for different
> applications.
> > > >
> > > > Am I to understand that the code on the SD card begins at 0? If so
> that
> > > > is not correct, as it should be located at 0x00004000. It wouldn't
> make
> > > > sense to have the vectors in the main application loaded at zero,
> > unless
> > > > they would be executed from there. Also, given that the startup code
> > > > usually contains the vectors and the startup routines, they certainly
> > > > shouldn't be located at 0.
> > > >
> > > > How do you jump to the main app from your bootloader?
> > > >
> > > > This would all me much easier for us to figure out if we had the
> > > > relevant bits of code.
> > > >
> > > > Mike
> > > >
> > > > > -----Original Message-----
> > > > > From: l... > lpc2000%40yahoogroups.com >
> > > > > lpc2000%40yahoogroups.com >
> > > > > [mailto:l...
> > >
> > > > lpc2000%40yahoogroups.com >]On
> > > > Behalf
> > > > > Of Sutton Mehaffey
> > > > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > > > To: l... > lpc2000%40yahoogroups.com >
> > > > > lpc2000%40yahoogroups.com > > > > > Subject: Re: [lpc2000] Re: new SD code transfer to LPC2148 not
> quite
> > > > > working
> > > > >
> > > > >
> > > > > I have a variable in serial eeprom that indicates 'app code good'
> or
> > > > > not. I use an intermediate serial flash to hold the file from the
> SD
> > > > > card. I compare byte for byte the code on the SD card to the serial
> > > > > flash. When valid, I change the serial eeprom value to 0. I
> > > > > initiate a
> > > > > WDT reset and the bootloader at 0 sees that the eeprom value is 0
> and
> > > > > starts the upload from the serial flash to the CPU flash (via
> > > > > IAP). I
> > > > > compare byte for byte the upload to 0x00004000 and when
> > > > > valid, I change
> > > > > the serial eeprom value to 'good code (0xA5). I initiate another
> WDT
> > > > > reset, which works, but the transfer to 0x00004000 doesn't work.
> > > > >
> > > > > This update is to be done in the field by customers without JTAG.
> > > > >
> > > > > From the previous posts, I guess I'm trying to figure out how the
> > > > > interrupt vectors are affected by all of this. They are
> > > > > stored at 0.
> > > > > I'm guessing by Richard's post that depending on what application I
> > > > > loaded last by JTAG (bootloader or app), the interrupt vectors are
> > > > > correct, but not for the first loaded code. The code
> > > > > 0x00-0x1C on the
> > > > > SD card (which is Keil's compiled code converted to binary) looks
> > > > > exactly like the code at 0x00-0x1C at 0x00000000. It is put at
> > > > > 0x00004000, which I thought was sufficient. Still trying to
> > > > > figure it out.
> > > > >
> > > > > Sutton
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > m...@compusmart.ab.ca > manton%40compusmart.ab.ca >
> > > > > manton%40compusmart.ab.ca > wrote:
> > > > > >
> > > > > >
> > > > > > What criteria do you use to determine if control can be passed
> from
> > > > > > your bootloader to the main application? Do you use a CRC or
> verify
> > > > > > it to make sure
> > > > > > it was written correctly?
> > > > > >
> > > > > > Could you use your bootloader to write the main app, and then do
> a
> > > > > > verify via JTAG to see if they are the same?
> > > > > >
> > > > > > Mike
> > > > > >
> > > > > > Quoting Sutton Mehaffey
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> >
>
> > > >>:
> > > > > >
> > > > > > > OK. So, what is happening in Keil's uVision when I use
> > > > > the JTAG to load
> > > > > > > the bootloader at 0x00000000 and then the app at
> > > > > 0x00004000? Is the
> > > > > > > one I load last is the one that has the correct interrupt
> vector
> > > > > > > pointers? It doesn't seem to matter which one I load
> > > > > first and last,
> > > > > > > the interrupts in both sets of code seem to work just fine
> > and the
> > > > > > > bootloader transfers correctly to the app.
> > > > > > >
> > > > > > > Sutton
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > rtstofer wrote:
> > > > > > >>
> > > > > > >>
> > > > > > >> --- In l...
> > >
> > > > lpc2000%40yahoogroups.com >
> > > > > > 2540yahoogroups.com>>
> > > > > > > 2540yahoogroups.com>>,
>
> > > > > > >> "Sutton Mehaffey" wrote:
> > > > > > >> >
> > > > > > >> > Because I'm not clear on why, why do I need to remap
> > > > > the interrupt
> > > > > > >> vector when my bootloader code at 0x00000000 never
> > > > > changes? I'm not
> > > > > > >> copying my SD code to location 0x00000000.
> > > > > > >> >
> > > > > > >> > Sutton
> > > > > > >>
> > > > > > >> So the vectors point to the functions in the code that
> > > > > is actually
> > > > > > >> running.
> > > > > > >>
> > > > > > >> Now, if you ignore every vector except IRG and you do
> > > > > the VIC trick of
> > > > > > >> using the vector to get the address from the VIC, then
> > > > > you don't have
> > > > > > >> to do anything.
> > > > > > >>
> > > > > > >> The IRQ interrupt vector should have code like:
> > > > > > >>
> > > > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > > > > > >>
> > > > > > >> However, none of the other interrupt vectors will point to
> your
> > > > > > >> downloaded code. They will only point to entries in your
> > > > > boot code.
> > > > > > >>
> > > > > > >> That might be good enough.
> > > > > > >>
> > > > > > >> Richard
> > > > > > >>
> > > > > > >>
> > > > > > >
> > > > > > > --
> > > > > > > Sutton Mehaffey
> > > > > > > Lookout Portable Security
> > > > > > > 4040 Royal Dr. #100
> > > > > > > Kennesaw, GA 30144
> > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> >
>
> > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Sutton Mehaffey
> > > > > Lookout Portable Security
> > > > > 4040 Royal Dr. #100
> > > > > Kennesaw, GA 30144
> > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > >
> > > >
> > > >
> > >
> > > --
> > > 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


Start a New Thread

I actually do in the 'Target' link put my base address at 0x00004000.
That's how the code initially gets transferred from the bootloader to
app correctly. The bootloader (located at 0) transfers execution
perfectly to 0x00004000 before the SD card upload. But, that is loading
the 2 sections of code via Keil's JTAG.

The problem is that the Keil JTAG does some other programming (that I
haven't figured out) that my upload from SD card doesn't do.

If when the code hangs after my SD card upload (the WDT causes a reset,
the bootloader finds that the RAM value is back to 0xA5, meaning valid
code at 0x00004000, and tries to transfer to execution to 0x00004000), I
load the same code thru Keil's JTAG, the transfer works perfectly again.

Miguel Angel wrote:
>
>
> Yes, my code will only help if you're using FIQs or SWIs,
>
> For the application binary, alex's comment is quite important, you
> should really set the application code base address to 0x4000 or
> some jump/calls will get bad addresses.
>
> 2009/8/20 Sutton Mehaffey > > >
> >
> > I must have missed that post. I don't see it in my folder.
> >
> > Anyway, I just tried changing the startup file as per your request
> > (Miguel), and it still doesn't transfer to 0x4000 correctly. It hangs
> > after a successful upload, just like before.
> > >
> > I do use "Memory Layout from Target Dialog", so maybe Alex's comment has
> > some merit. Maybe I need to learn and use the scatter files.
> >
> > Sutton
> >
> >
> > Miguel Angel wrote:
> > >
> > >
> > > Copy & Paste, I already told you (some weeks ago) a way of doing it :)
> > >
> > > This is an example of IRQ pass-thru from my usual bootloader to the
> > > application
> > > (that starts at 0x2000): (ARM Assembler format for a 214x/213x device)
> > > Modify your Startup.s to put the vectors this way:
> > >
> > > 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, [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
> > > 0x2014
> > > FIQ_Addr DCD 0x401C
> > >
> > > And something important too, is to end the Startup initialization with:
> > >
> > > MSR CPSR_c, #Mode_SYS (instead of
> > > MSR CPSR_c, #Mode_USR)
> > >
> > > so your app startup can change processor mode again and setup all the
> > mode's
> > > stacks, according
> > > to your app configuration.
> > >
> > > 2009/8/20 Sutton Mehaffey >
> > >
>
> > >>
> >
> > >
> > > >
> > > >
> > > > The code is compiled at 0x00004000, converted to binary and loaded on
> > > > the SD card. The application always runs at 0x00004000. The
> bootloader
> > > > is never changed in the field and always runs at 0. The first 6 bytes
> > > > of the compiled file hold the 0x00004000. I assume that's how Keil
> > > > knows to locate it at 0x00004000 thru the JTAG.
> > > >
> > > > Where in the startup code do I specify that the vectors starts at
> > > > 0x00004000?
> > > >
> > > > typedef void (*APP)(void);
> > > > APP app = (APP)0x00004000;
> > > >
> > > > app();
> > > >
> > > >
> > > > Michael Anton wrote:
> > > > >
> > > > >
> > > > > How does your bootloader handle revectoring all of the interrupts?
> > > > > I don't understand why the vectors located at 0x0004000 would
> be the
> > > > > same as those at 0x00000000, since they are for different
> > applications.
> > > > >
> > > > > Am I to understand that the code on the SD card begins at 0? If so
> > that
> > > > > is not correct, as it should be located at 0x00004000. It wouldn't
> > make
> > > > > sense to have the vectors in the main application loaded at zero,
> > > unless
> > > > > they would be executed from there. Also, given that the startup
> code
> > > > > usually contains the vectors and the startup routines, they
> certainly
> > > > > shouldn't be located at 0.
> > > > >
> > > > > How do you jump to the main app from your bootloader?
> > > > >
> > > > > This would all me much easier for us to figure out if we had the
> > > > > relevant bits of code.
> > > > >
> > > > > Mike
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: l...
> > > lpc2000%40yahoogroups.com >
> > > > > > > lpc2000%40yahoogroups.com >
> > > > > > [mailto:l...
>
> > > >
> > > > > > lpc2000%40yahoogroups.com >]On
> > > > > Behalf
> > > > > > Of Sutton Mehaffey
> > > > > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > > > > To: l...
> > > lpc2000%40yahoogroups.com >
> > > > > > > lpc2000%40yahoogroups.com >
> >
> > > > > > Subject: Re: [lpc2000] Re: new SD code transfer to LPC2148 not
> > quite
> > > > > > working
> > > > > >
> > > > > >
> > > > > > I have a variable in serial eeprom that indicates 'app code good'
> > or
> > > > > > not. I use an intermediate serial flash to hold the file from the
> > SD
> > > > > > card. I compare byte for byte the code on the SD card to the
> serial
> > > > > > flash. When valid, I change the serial eeprom value to 0. I
> > > > > > initiate a
> > > > > > WDT reset and the bootloader at 0 sees that the eeprom value is 0
> > and
> > > > > > starts the upload from the serial flash to the CPU flash (via
> > > > > > IAP). I
> > > > > > compare byte for byte the upload to 0x00004000 and when
> > > > > > valid, I change
> > > > > > the serial eeprom value to 'good code (0xA5). I initiate another
> > WDT
> > > > > > reset, which works, but the transfer to 0x00004000 doesn't work.
> > > > > >
> > > > > > This update is to be done in the field by customers without JTAG.
> > > > > >
> > > > > > From the previous posts, I guess I'm trying to figure out how the
> > > > > > interrupt vectors are affected by all of this. They are
> > > > > > stored at 0.
> > > > > > I'm guessing by Richard's post that depending on what
> application I
> > > > > > loaded last by JTAG (bootloader or app), the interrupt
> vectors are
> > > > > > correct, but not for the first loaded code. The code
> > > > > > 0x00-0x1C on the
> > > > > > SD card (which is Keil's compiled code converted to binary) looks
> > > > > > exactly like the code at 0x00-0x1C at 0x00000000. It is put at
> > > > > > 0x00004000, which I thought was sufficient. Still trying to
> > > > > > figure it out.
> > > > > >
> > > > > > Sutton
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > m...@compusmart.ab.ca
> > > manton%40compusmart.ab.ca >
> > > > > > > manton%40compusmart.ab.ca > wrote:
> > > > > > >
> > > > > > >
> > > > > > > What criteria do you use to determine if control can be passed
> > from
> > > > > > > your bootloader to the main application? Do you use a CRC or
> > verify
> > > > > > > it to make sure
> > > > > > > it was written correctly?
> > > > > > >
> > > > > > > Could you use your bootloader to write the main app, and
> then do
> > a
> > > > > > > verify via JTAG to see if they are the same?
> > > > > > >
> > > > > > > Mike
> > > > > > >
> > > > > > > Quoting Sutton Mehaffey >
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > >
>
> >
> > > > >>:
> > > > > > >
> > > > > > > > OK. So, what is happening in Keil's uVision when I use
> > > > > > the JTAG to load
> > > > > > > > the bootloader at 0x00000000 and then the app at
> > > > > > 0x00004000? Is the
> > > > > > > > one I load last is the one that has the correct interrupt
> > vector
> > > > > > > > pointers? It doesn't seem to matter which one I load
> > > > > > first and last,
> > > > > > > > the interrupts in both sets of code seem to work just fine
> > > and the
> > > > > > > > bootloader transfers correctly to the app.
> > > > > > > >
> > > > > > > > Sutton
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > rtstofer wrote:
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> --- In l...
>
> > > >
> > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > 2540yahoogroups.com>>,
> >
> > > > > > > >> "Sutton Mehaffey" wrote:
> > > > > > > >> >
> > > > > > > >> > Because I'm not clear on why, why do I need to remap
> > > > > > the interrupt
> > > > > > > >> vector when my bootloader code at 0x00000000 never
> > > > > > changes? I'm not
> > > > > > > >> copying my SD code to location 0x00000000.
> > > > > > > >> >
> > > > > > > >> > Sutton
> > > > > > > >>
> > > > > > > >> So the vectors point to the functions in the code that
> > > > > > is actually
> > > > > > > >> running.
> > > > > > > >>
> > > > > > > >> Now, if you ignore every vector except IRG and you do
> > > > > > the VIC trick of
> > > > > > > >> using the vector to get the address from the VIC, then
> > > > > > you don't have
> > > > > > > >> to do anything.
> > > > > > > >>
> > > > > > > >> The IRQ interrupt vector should have code like:
> > > > > > > >>
> > > > > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > > > > > > >>
> > > > > > > >> However, none of the other interrupt vectors will point to
> > your
> > > > > > > >> downloaded code. They will only point to entries in your
> > > > > > boot code.
> > > > > > > >>
> > > > > > > >> That might be good enough.
> > > > > > > >>
> > > > > > > >> Richard
> > > > > > > >>
> > > > > > > >>
> > > > > > > >
> > > > > > > > --
> > > > > > > > Sutton Mehaffey
> > > > > > > > Lookout Portable Security
> > > > > > > > 4040 Royal Dr. #100
> > > > > > > > Kennesaw, GA 30144
> > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > >
>
> >
> > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Sutton Mehaffey
> > > > > > Lookout Portable Security
> > > > > > 4040 Royal Dr. #100
> > > > > > Kennesaw, GA 30144
> > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > 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
>
>

--
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

Start a New Thread

And, by the way, I don't use FIQs. I have some timers running in both
applications. Not sure if that is considered a SWI.

Miguel Angel wrote:
>
>
> Yes, my code will only help if you're using FIQs or SWIs,
>
> For the application binary, alex's comment is quite important, you
> should really set the application code base address to 0x4000 or
> some jump/calls will get bad addresses.
>
> 2009/8/20 Sutton Mehaffey > > >
> >
> > I must have missed that post. I don't see it in my folder.
> >
> > Anyway, I just tried changing the startup file as per your request
> > (Miguel), and it still doesn't transfer to 0x4000 correctly. It hangs
> > after a successful upload, just like before.
> > >
> > I do use "Memory Layout from Target Dialog", so maybe Alex's comment has
> > some merit. Maybe I need to learn and use the scatter files.
> >
> > Sutton
> >
> >
> > Miguel Angel wrote:
> > >
> > >
> > > Copy & Paste, I already told you (some weeks ago) a way of doing it :)
> > >
> > > This is an example of IRQ pass-thru from my usual bootloader to the
> > > application
> > > (that starts at 0x2000): (ARM Assembler format for a 214x/213x device)
> > > Modify your Startup.s to put the vectors this way:
> > >
> > > 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, [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
> > > 0x2014
> > > FIQ_Addr DCD 0x401C
> > >
> > > And something important too, is to end the Startup initialization with:
> > >
> > > MSR CPSR_c, #Mode_SYS (instead of
> > > MSR CPSR_c, #Mode_USR)
> > >
> > > so your app startup can change processor mode again and setup all the
> > mode's
> > > stacks, according
> > > to your app configuration.
> > >
> > > 2009/8/20 Sutton Mehaffey >
> > >
>
> > >>
> >
> > >
> > > >
> > > >
> > > > The code is compiled at 0x00004000, converted to binary and loaded on
> > > > the SD card. The application always runs at 0x00004000. The
> bootloader
> > > > is never changed in the field and always runs at 0. The first 6 bytes
> > > > of the compiled file hold the 0x00004000. I assume that's how Keil
> > > > knows to locate it at 0x00004000 thru the JTAG.
> > > >
> > > > Where in the startup code do I specify that the vectors starts at
> > > > 0x00004000?
> > > >
> > > > typedef void (*APP)(void);
> > > > APP app = (APP)0x00004000;
> > > >
> > > > app();
> > > >
> > > >
> > > > Michael Anton wrote:
> > > > >
> > > > >
> > > > > How does your bootloader handle revectoring all of the interrupts?
> > > > > I don't understand why the vectors located at 0x0004000 would
> be the
> > > > > same as those at 0x00000000, since they are for different
> > applications.
> > > > >
> > > > > Am I to understand that the code on the SD card begins at 0? If so
> > that
> > > > > is not correct, as it should be located at 0x00004000. It wouldn't
> > make
> > > > > sense to have the vectors in the main application loaded at zero,
> > > unless
> > > > > they would be executed from there. Also, given that the startup
> code
> > > > > usually contains the vectors and the startup routines, they
> certainly
> > > > > shouldn't be located at 0.
> > > > >
> > > > > How do you jump to the main app from your bootloader?
> > > > >
> > > > > This would all me much easier for us to figure out if we had the
> > > > > relevant bits of code.
> > > > >
> > > > > Mike
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: l...
> > > lpc2000%40yahoogroups.com >
> > > > > > > lpc2000%40yahoogroups.com >
> > > > > > [mailto:l...
>
> > > >
> > > > > > lpc2000%40yahoogroups.com >]On
> > > > > Behalf
> > > > > > Of Sutton Mehaffey
> > > > > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > > > > To: l...
> > > lpc2000%40yahoogroups.com >
> > > > > > > lpc2000%40yahoogroups.com >
> >
> > > > > > Subject: Re: [lpc2000] Re: new SD code transfer to LPC2148 not
> > quite
> > > > > > working
> > > > > >
> > > > > >
> > > > > > I have a variable in serial eeprom that indicates 'app code good'
> > or
> > > > > > not. I use an intermediate serial flash to hold the file from the
> > SD
> > > > > > card. I compare byte for byte the code on the SD card to the
> serial
> > > > > > flash. When valid, I change the serial eeprom value to 0. I
> > > > > > initiate a
> > > > > > WDT reset and the bootloader at 0 sees that the eeprom value is 0
> > and
> > > > > > starts the upload from the serial flash to the CPU flash (via
> > > > > > IAP). I
> > > > > > compare byte for byte the upload to 0x00004000 and when
> > > > > > valid, I change
> > > > > > the serial eeprom value to 'good code (0xA5). I initiate another
> > WDT
> > > > > > reset, which works, but the transfer to 0x00004000 doesn't work.
> > > > > >
> > > > > > This update is to be done in the field by customers without JTAG.
> > > > > >
> > > > > > From the previous posts, I guess I'm trying to figure out how the
> > > > > > interrupt vectors are affected by all of this. They are
> > > > > > stored at 0.
> > > > > > I'm guessing by Richard's post that depending on what
> application I
> > > > > > loaded last by JTAG (bootloader or app), the interrupt
> vectors are
> > > > > > correct, but not for the first loaded code. The code
> > > > > > 0x00-0x1C on the
> > > > > > SD card (which is Keil's compiled code converted to binary) looks
> > > > > > exactly like the code at 0x00-0x1C at 0x00000000. It is put at
> > > > > > 0x00004000, which I thought was sufficient. Still trying to
> > > > > > figure it out.
> > > > > >
> > > > > > Sutton
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > m...@compusmart.ab.ca
> > > manton%40compusmart.ab.ca >
> > > > > > > manton%40compusmart.ab.ca > wrote:
> > > > > > >
> > > > > > >
> > > > > > > What criteria do you use to determine if control can be passed
> > from
> > > > > > > your bootloader to the main application? Do you use a CRC or
> > verify
> > > > > > > it to make sure
> > > > > > > it was written correctly?
> > > > > > >
> > > > > > > Could you use your bootloader to write the main app, and
> then do
> > a
> > > > > > > verify via JTAG to see if they are the same?
> > > > > > >
> > > > > > > Mike
> > > > > > >
> > > > > > > Quoting Sutton Mehaffey >
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > >
>
> >
> > > > >>:
> > > > > > >
> > > > > > > > OK. So, what is happening in Keil's uVision when I use
> > > > > > the JTAG to load
> > > > > > > > the bootloader at 0x00000000 and then the app at
> > > > > > 0x00004000? Is the
> > > > > > > > one I load last is the one that has the correct interrupt
> > vector
> > > > > > > > pointers? It doesn't seem to matter which one I load
> > > > > > first and last,
> > > > > > > > the interrupts in both sets of code seem to work just fine
> > > and the
> > > > > > > > bootloader transfers correctly to the app.
> > > > > > > >
> > > > > > > > Sutton
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > rtstofer wrote:
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> --- In l...
>
> > > >
> > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > 2540yahoogroups.com>>,
> >
> > > > > > > >> "Sutton Mehaffey" wrote:
> > > > > > > >> >
> > > > > > > >> > Because I'm not clear on why, why do I need to remap
> > > > > > the interrupt
> > > > > > > >> vector when my bootloader code at 0x00000000 never
> > > > > > changes? I'm not
> > > > > > > >> copying my SD code to location 0x00000000.
> > > > > > > >> >
> > > > > > > >> > Sutton
> > > > > > > >>
> > > > > > > >> So the vectors point to the functions in the code that
> > > > > > is actually
> > > > > > > >> running.
> > > > > > > >>
> > > > > > > >> Now, if you ignore every vector except IRG and you do
> > > > > > the VIC trick of
> > > > > > > >> using the vector to get the address from the VIC, then
> > > > > > you don't have
> > > > > > > >> to do anything.
> > > > > > > >>
> > > > > > > >> The IRQ interrupt vector should have code like:
> > > > > > > >>
> > > > > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > > > > > > >>
> > > > > > > >> However, none of the other interrupt vectors will point to
> > your
> > > > > > > >> downloaded code. They will only point to entries in your
> > > > > > boot code.
> > > > > > > >>
> > > > > > > >> That might be good enough.
> > > > > > > >>
> > > > > > > >> Richard
> > > > > > > >>
> > > > > > > >>
> > > > > > > >
> > > > > > > > --
> > > > > > > > Sutton Mehaffey
> > > > > > > > Lookout Portable Security
> > > > > > > > 4040 Royal Dr. #100
> > > > > > > > Kennesaw, GA 30144
> > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > >
>
> >
> > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Sutton Mehaffey
> > > > > > Lookout Portable Security
> > > > > > 4040 Royal Dr. #100
> > > > > > Kennesaw, GA 30144
> > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > 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
>
>

--
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

Start a New Thread

Hmmm,

I think the only way you could fix incomplete image uploads is to
put more fields on the image "header" inside your startup.s, and, just
after compiling the target app, and building the binary use a program
in the PC to fill those fields that could be:

1) Image length
2) Image CRC or checksum

with those two fields at startup in your bootloader you could
check the whole image length for CRC match before jumping into the app,
if it doesn't match, then jump into (for example) "wait for SD to get
inserted
to load a new app, and blink leds"
2009/8/20 Sutton Mehaffey

> I actually do in the 'Target' link put my base address at 0x00004000.
> That's how the code initially gets transferred from the bootloader to
> app correctly. The bootloader (located at 0) transfers execution
> perfectly to 0x00004000 before the SD card upload. But, that is loading
> the 2 sections of code via Keil's JTAG.
>
> The problem is that the Keil JTAG does some other programming (that I
> haven't figured out) that my upload from SD card doesn't do.
>
> If when the code hangs after my SD card upload (the WDT causes a reset,
> the bootloader finds that the RAM value is back to 0xA5, meaning valid
> code at 0x00004000, and tries to transfer to execution to 0x00004000), I
> load the same code thru Keil's JTAG, the transfer works perfectly again.
> Miguel Angel wrote:
> >
> >
> > Yes, my code will only help if you're using FIQs or SWIs,
> >
> > For the application binary, alex's comment is quite important, you
> > should really set the application code base address to 0x4000 or
> > some jump/calls will get bad addresses.
> >
> > 2009/8/20 Sutton Mehaffey
> >
> >> >
> > >
> > >
> > > I must have missed that post. I don't see it in my folder.
> > >
> > > Anyway, I just tried changing the startup file as per your request
> > > (Miguel), and it still doesn't transfer to 0x4000 correctly. It hangs
> > > after a successful upload, just like before.
> > >
> >
> > >
> > > I do use "Memory Layout from Target Dialog", so maybe Alex's comment
> has
> > > some merit. Maybe I need to learn and use the scatter files.
> > >
> > > Sutton
> > >
> > >
> > > Miguel Angel wrote:
> > > >
> > > >
> > > > Copy & Paste, I already told you (some weeks ago) a way of doing it
> :)
> > > >
> > > > This is an example of IRQ pass-thru from my usual bootloader to the
> > > > application
> > > > (that starts at 0x2000): (ARM Assembler format for a 214x/213x
> device)
> > > > Modify your Startup.s to put the vectors this way:
> > > >
> > > > 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, [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
> > > > 0x2014
> > > > FIQ_Addr DCD 0x401C
> > > >
> > > > And something important too, is to end the Startup initialization
> with:
> > > >
> > > > MSR CPSR_c, #Mode_SYS (instead of
> > > > MSR CPSR_c, #Mode_USR)
> > > >
> > > > so your app startup can change processor mode again and setup all the
> > > mode's
> > > > stacks, according
> > > > to your app configuration.
> > > >
> > > > 2009/8/20 Sutton Mehaffey
> >
> >
> > > >
> >
>
> > > >>
> > >
> > > >
> > > > >
> > > > >
> > > > > The code is compiled at 0x00004000, converted to binary and loaded
> on
> > > > > the SD card. The application always runs at 0x00004000. The
> > bootloader
> > > > > is never changed in the field and always runs at 0. The first 6
> bytes
> > > > > of the compiled file hold the 0x00004000. I assume that's how Keil
> > > > > knows to locate it at 0x00004000 thru the JTAG.
> > > > >
> > > > > Where in the startup code do I specify that the vectors starts at
> > > > > 0x00004000?
> > > > >
> > > > > typedef void (*APP)(void);
> > > > > APP app = (APP)0x00004000;
> > > > >
> > > > > app();
> > > > >
> > > > >
> > > > > Michael Anton wrote:
> > > > > >
> > > > > >
> > > > > > How does your bootloader handle revectoring all of the
> interrupts?
> > > > > > I don't understand why the vectors located at 0x0004000 would
> > be the
> > > > > > same as those at 0x00000000, since they are for different
> > > applications.
> > > > > >
> > > > > > Am I to understand that the code on the SD card begins at 0? If
> so
> > > that
> > > > > > is not correct, as it should be located at 0x00004000. It
> wouldn't
> > > make
> > > > > > sense to have the vectors in the main application loaded at zero,
> > > > unless
> > > > > > they would be executed from there. Also, given that the startup
> > code
> > > > > > usually contains the vectors and the startup routines, they
> > certainly
> > > > > > shouldn't be located at 0.
> > > > > >
> > > > > > How do you jump to the main app from your bootloader?
> > > > > >
> > > > > > This would all me much easier for us to figure out if we had the
> > > > > > relevant bits of code.
> > > > > >
> > > > > > Mike
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: l...
> > >
> > > > lpc2000%40yahoogroups.com >
> > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > [mailto:l...
> > >
>
> > > > > 2540yahoogroups.com>>
> > > > > > > > lpc2000%40yahoogroups.com >]On
> > > > > > Behalf
> > > > > > > Of Sutton Mehaffey
> > > > > > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > > > > > To: l...
> > >
> > > > lpc2000%40yahoogroups.com >
> > > > > > > > > lpc2000%40yahoogroups.com >
> > >
> > > > > > > Subject: Re: [lpc2000] Re: new SD code transfer to LPC2148 not
> > > quite
> > > > > > > working
> > > > > > >
> > > > > > >
> > > > > > > I have a variable in serial eeprom that indicates 'app code
> good'
> > > or
> > > > > > > not. I use an intermediate serial flash to hold the file from
> the
> > > SD
> > > > > > > card. I compare byte for byte the code on the SD card to the
> > serial
> > > > > > > flash. When valid, I change the serial eeprom value to 0. I
> > > > > > > initiate a
> > > > > > > WDT reset and the bootloader at 0 sees that the eeprom value is
> 0
> > > and
> > > > > > > starts the upload from the serial flash to the CPU flash (via
> > > > > > > IAP). I
> > > > > > > compare byte for byte the upload to 0x00004000 and when
> > > > > > > valid, I change
> > > > > > > the serial eeprom value to 'good code (0xA5). I initiate
> another
> > > WDT
> > > > > > > reset, which works, but the transfer to 0x00004000 doesn't
> work.
> > > > > > >
> > > > > > > This update is to be done in the field by customers without
> JTAG.
> > > > > > >
> > > > > > > From the previous posts, I guess I'm trying to figure out how
> the
> > > > > > > interrupt vectors are affected by all of this. They are
> > > > > > > stored at 0.
> > > > > > > I'm guessing by Richard's post that depending on what
> > application I
> > > > > > > loaded last by JTAG (bootloader or app), the interrupt
> > vectors are
> > > > > > > correct, but not for the first loaded code. The code
> > > > > > > 0x00-0x1C on the
> > > > > > > SD card (which is Keil's compiled code converted to binary)
> looks
> > > > > > > exactly like the code at 0x00-0x1C at 0x00000000. It is put at
> > > > > > > 0x00004000, which I thought was sufficient. Still trying to
> > > > > > > figure it out.
> > > > > > >
> > > > > > > Sutton
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > m...@compusmart.ab.ca > manton%40compusmart.ab.ca >
> > > > > manton%40compusmart.ab.ca >
> > > > > > > > > manton%40compusmart.ab.ca > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > What criteria do you use to determine if control can be
> passed
> > > from
> > > > > > > > your bootloader to the main application? Do you use a CRC or
> > > verify
> > > > > > > > it to make sure
> > > > > > > > it was written correctly?
> > > > > > > >
> > > > > > > > Could you use your bootloader to write the main app, and
> > then do
> > > a
> > > > > > > > verify via JTAG to see if they are the same?
> > > > > > > >
> > > > > > > > Mike
> > > > > > > >
> > > > > > > > Quoting Sutton Mehaffey
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > >
> >
>
> > >
> > > > > >>:
> > > > > > > >
> > > > > > > > > OK. So, what is happening in Keil's uVision when I use
> > > > > > > the JTAG to load
> > > > > > > > > the bootloader at 0x00000000 and then the app at
> > > > > > > 0x00004000? Is the
> > > > > > > > > one I load last is the one that has the correct interrupt
> > > vector
> > > > > > > > > pointers? It doesn't seem to matter which one I load
> > > > > > > first and last,
> > > > > > > > > the interrupts in both sets of code seem to work just fine
> > > > and the
> > > > > > > > > bootloader transfers correctly to the app.
> > > > > > > > >
> > > > > > > > > Sutton
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > rtstofer wrote:
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> --- In l...
> > >
>
> > > > > 2540yahoogroups.com>>
> > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > >
> > > > > 2540yahoogroups.com>>
> > > > > > > >
> > >
> > > 2540yahoogroups.com>>,
> > >
> > > > > > > > >> "Sutton Mehaffey" wrote:
> > > > > > > > >> >
> > > > > > > > >> > Because I'm not clear on why, why do I need to remap
> > > > > > > the interrupt
> > > > > > > > >> vector when my bootloader code at 0x00000000 never
> > > > > > > changes? I'm not
> > > > > > > > >> copying my SD code to location 0x00000000.
> > > > > > > > >> >
> > > > > > > > >> > Sutton
> > > > > > > > >>
> > > > > > > > >> So the vectors point to the functions in the code that
> > > > > > > is actually
> > > > > > > > >> running.
> > > > > > > > >>
> > > > > > > > >> Now, if you ignore every vector except IRG and you do
> > > > > > > the VIC trick of
> > > > > > > > >> using the vector to get the address from the VIC, then
> > > > > > > you don't have
> > > > > > > > >> to do anything.
> > > > > > > > >>
> > > > > > > > >> The IRQ interrupt vector should have code like:
> > > > > > > > >>
> > > > > > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > > > > > > > >>
> > > > > > > > >> However, none of the other interrupt vectors will point to
> > > your
> > > > > > > > >> downloaded code. They will only point to entries in your
> > > > > > > boot code.
> > > > > > > > >>
> > > > > > > > >> That might be good enough.
> > > > > > > > >>
> > > > > > > > >> Richard
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Sutton Mehaffey
> > > > > > > > > Lookout Portable Security
> > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Sutton Mehaffey
> > > > > > > Lookout Portable Security
> > > > > > > 4040 Royal Dr. #100
> > > > > > > Kennesaw, GA 30144
> > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > 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
> >
> >
> >
> > --
> 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


Start a New Thread