I have 'successfully' uploaded new code from my SD card to CPU flash
through my intermediate flash. I have my secondary bootloader at 0x00000000 and
my app at 0x00004000. Everything uploads and verifies correctly to 0x00004000.
However, after the WDT trips, the transfer to 0x00004000 doesn't work like
it did before. I erased sectors 4-23 on the CPU leaving the bootloader and the
vector table. What else did I forget to do?
I followed the assembly code and it looks like there is a transfer to
'never never land', which doesn't happen if I load the file thru
Keil's JTAG. If I reload thru the JTAG to 0x00004000, the transfer problem
is fixed and it works fine. But, I don't know what problem it fixed. Do I
need to save the status of certain registers before uploading new code?
new SD code transfer to LPC2148 not quite working
Started by ●August 18, 2009
Reply by ●August 18, 20092009-08-18
Sutton Mehaffey wrote:
> I have 'successfully' uploaded new code from my SD card to CPU flash through my intermediate flash. I have my secondary bootloader at 0x00000000 and my app at 0x00004000. Everything uploads and verifies correctly to 0x00004000. However, after the WDT trips, the transfer to 0x00004000 doesn't work like it did before. I erased sectors 4-23 on the CPU leaving the bootloader and the vector table. What else did I forget to do?
>
> I followed the assembly code and it looks like there is a transfer to 'never never land', which doesn't happen if I load the file thru Keil's JTAG. If I reload thru the JTAG to 0x00004000, the transfer problem is fixed and it works fine. But, I don't know what problem it fixed. Do I need to save the status of certain registers before uploading new code?
CRP?
regards,
Charles
> I have 'successfully' uploaded new code from my SD card to CPU flash through my intermediate flash. I have my secondary bootloader at 0x00000000 and my app at 0x00004000. Everything uploads and verifies correctly to 0x00004000. However, after the WDT trips, the transfer to 0x00004000 doesn't work like it did before. I erased sectors 4-23 on the CPU leaving the bootloader and the vector table. What else did I forget to do?
>
> I followed the assembly code and it looks like there is a transfer to 'never never land', which doesn't happen if I load the file thru Keil's JTAG. If I reload thru the JTAG to 0x00004000, the transfer problem is fixed and it works fine. But, I don't know what problem it fixed. Do I need to save the status of certain registers before uploading new code?
CRP?
regards,
Charles
Reply by ●August 18, 20092009-08-18
Hi:
There are couple things to look for:
1. Are you remapping the interrupt vectors to RAM in the main application? From the right Flash memory location to the correct RAM location?
2. Are you using different stack sizes between your secondary bootloader and the main application? Data abort problems are a symtom of this issue. One probable cause is that the secondary bootloader changes the ARM Mode to "User", and then runs and jumps to the main application. However, some of the code at the startup of the main application (specifically the pieces that write to the CPSR register) won't operate in User Mode. It needs to be in Supervisory Mode.
Best solution to this issue is to change the mode to system or supervisory before leaving the bootloader, or change it when entering the Main Application.
Regards,
Alex
--- In l..., "Sutton Mehaffey" wrote:
>
> I have 'successfully' uploaded new code from my SD card to CPU flash through my intermediate flash. I have my secondary bootloader at 0x00000000 and my app at 0x00004000. Everything uploads and verifies correctly to 0x00004000. However, after the WDT trips, the transfer to 0x00004000 doesn't work like it did before. I erased sectors 4-23 on the CPU leaving the bootloader and the vector table. What else did I forget to do?
>
> I followed the assembly code and it looks like there is a transfer to 'never never land', which doesn't happen if I load the file thru Keil's JTAG. If I reload thru the JTAG to 0x00004000, the transfer problem is fixed and it works fine. But, I don't know what problem it fixed. Do I need to save the status of certain registers before uploading new code?
>
There are couple things to look for:
1. Are you remapping the interrupt vectors to RAM in the main application? From the right Flash memory location to the correct RAM location?
2. Are you using different stack sizes between your secondary bootloader and the main application? Data abort problems are a symtom of this issue. One probable cause is that the secondary bootloader changes the ARM Mode to "User", and then runs and jumps to the main application. However, some of the code at the startup of the main application (specifically the pieces that write to the CPSR register) won't operate in User Mode. It needs to be in Supervisory Mode.
Best solution to this issue is to change the mode to system or supervisory before leaving the bootloader, or change it when entering the Main Application.
Regards,
Alex
--- In l..., "Sutton Mehaffey" wrote:
>
> I have 'successfully' uploaded new code from my SD card to CPU flash through my intermediate flash. I have my secondary bootloader at 0x00000000 and my app at 0x00004000. Everything uploads and verifies correctly to 0x00004000. However, after the WDT trips, the transfer to 0x00004000 doesn't work like it did before. I erased sectors 4-23 on the CPU leaving the bootloader and the vector table. What else did I forget to do?
>
> I followed the assembly code and it looks like there is a transfer to 'never never land', which doesn't happen if I load the file thru Keil's JTAG. If I reload thru the JTAG to 0x00004000, the transfer problem is fixed and it works fine. But, I don't know what problem it fixed. Do I need to save the status of certain registers before uploading new code?
>
Reply by ●August 18, 20092009-08-18
I don't do anything with CRP, so I assume it's still disabled.
Charles R. Grenz wrote:
>
> Sutton Mehaffey wrote:
> > I have 'successfully' uploaded new code from my SD card to CPU flash
> through my intermediate flash. I have my secondary bootloader at
> 0x00000000 and my app at 0x00004000. Everything uploads and verifies
> correctly to 0x00004000. However, after the WDT trips, the transfer to
> 0x00004000 doesn't work like it did before. I erased sectors 4-23 on the
> CPU leaving the bootloader and the vector table. What else did I forget
> to do?
> >
> > I followed the assembly code and it looks like there is a transfer to
> 'never never land', which doesn't happen if I load the file thru Keil's
> JTAG. If I reload thru the JTAG to 0x00004000, the transfer problem is
> fixed and it works fine. But, I don't know what problem it fixed. Do I
> need to save the status of certain registers before uploading new code?
> >
> > CRP?
>
> regards,
> Charles
--
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
Charles R. Grenz wrote:
>
> Sutton Mehaffey wrote:
> > I have 'successfully' uploaded new code from my SD card to CPU flash
> through my intermediate flash. I have my secondary bootloader at
> 0x00000000 and my app at 0x00004000. Everything uploads and verifies
> correctly to 0x00004000. However, after the WDT trips, the transfer to
> 0x00004000 doesn't work like it did before. I erased sectors 4-23 on the
> CPU leaving the bootloader and the vector table. What else did I forget
> to do?
> >
> > I followed the assembly code and it looks like there is a transfer to
> 'never never land', which doesn't happen if I load the file thru Keil's
> JTAG. If I reload thru the JTAG to 0x00004000, the transfer problem is
> fixed and it works fine. But, I don't know what problem it fixed. Do I
> need to save the status of certain registers before uploading new code?
> >
> > CRP?
>
> regards,
> Charles
--
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 18, 20092009-08-18
Interrupts seem to work fine. I didn't erase sectors 24-26. Therefore,
I didn't think I needed to do anything with the interrupts.
I use the same startup file in both applications (bootloader and app).
Compiled separately, of course. Any problem with that?
Alex Ribero wrote:
>
>
> Hi:
>
> There are couple things to look for:
>
> 1. Are you remapping the interrupt vectors to RAM in the main
> application? From the right Flash memory location to the correct RAM
> location?
>
> 2. Are you using different stack sizes between your secondary bootloader
> and the main application? Data abort problems are a symtom of this
> issue. One probable cause is that the secondary bootloader changes the
> ARM Mode to "User", and then runs and jumps to the main application.
> However, some of the code at the startup of the main application
> (specifically the pieces that write to the CPSR register) won't operate
> in User Mode. It needs to be in Supervisory Mode.
>
> Best solution to this issue is to change the mode to system or
> supervisory before leaving the bootloader, or change it when entering
> the Main Application.
>
> Regards,
>
> Alex
>
> --- In l... ,
> "Sutton Mehaffey" wrote:
> >
> > I have 'successfully' uploaded new code from my SD card to CPU flash
> through my intermediate flash. I have my secondary bootloader at
> 0x00000000 and my app at 0x00004000. Everything uploads and verifies
> correctly to 0x00004000. However, after the WDT trips, the transfer to
> 0x00004000 doesn't work like it did before. I erased sectors 4-23 on the
> CPU leaving the bootloader and the vector table. What else did I forget
> to do?
> >
> > I followed the assembly code and it looks like there is a transfer to
> 'never never land', which doesn't happen if I load the file thru Keil's
> JTAG. If I reload thru the JTAG to 0x00004000, the transfer problem is
> fixed and it works fine. But, I don't know what problem it fixed. Do I
> need to save the status of certain registers before uploading new code?
> >
--
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 didn't think I needed to do anything with the interrupts.
I use the same startup file in both applications (bootloader and app).
Compiled separately, of course. Any problem with that?
Alex Ribero wrote:
>
>
> Hi:
>
> There are couple things to look for:
>
> 1. Are you remapping the interrupt vectors to RAM in the main
> application? From the right Flash memory location to the correct RAM
> location?
>
> 2. Are you using different stack sizes between your secondary bootloader
> and the main application? Data abort problems are a symtom of this
> issue. One probable cause is that the secondary bootloader changes the
> ARM Mode to "User", and then runs and jumps to the main application.
> However, some of the code at the startup of the main application
> (specifically the pieces that write to the CPSR register) won't operate
> in User Mode. It needs to be in Supervisory Mode.
>
> Best solution to this issue is to change the mode to system or
> supervisory before leaving the bootloader, or change it when entering
> the Main Application.
>
> Regards,
>
> Alex
>
> --- In l... ,
> "Sutton Mehaffey" wrote:
> >
> > I have 'successfully' uploaded new code from my SD card to CPU flash
> through my intermediate flash. I have my secondary bootloader at
> 0x00000000 and my app at 0x00004000. Everything uploads and verifies
> correctly to 0x00004000. However, after the WDT trips, the transfer to
> 0x00004000 doesn't work like it did before. I erased sectors 4-23 on the
> CPU leaving the bootloader and the vector table. What else did I forget
> to do?
> >
> > I followed the assembly code and it looks like there is a transfer to
> 'never never land', which doesn't happen if I load the file thru Keil's
> JTAG. If I reload thru the JTAG to 0x00004000, the transfer problem is
> fixed and it works fine. But, I don't know what problem it fixed. Do I
> need to save the status of certain registers before uploading new code?
> >
--
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 19, 20092009-08-19
Hi:
The startup code should be different between the bootloader and the main application, because, when you remap the interrupt vectors to RAM, the source of the interrupt vector addresses is different (as for the bootloader, are located at 0x00000000, while for the main application they are located at 0x00004000).
Note that the ARM processor will use the interrupt vector table located at 0x00000000 (even when you jump to 0x00004000 to run your application), unless the vector table is remapped at 0x40000000 (RAM).
This requires two steps: copy the correct vector table to 0x40000000 and tell the processor to use the vector table from 0x40000000.
See section 2.2.2 and 3.7.1 of the LPC2148 user Manual
We have done this for the LPC2366 and it works without problem.
Regards,
Alex
--- In l..., Sutton Mehaffey wrote:
>
> Interrupts seem to work fine. I didn't erase sectors 24-26. Therefore,
> I didn't think I needed to do anything with the interrupts.
>
> I use the same startup file in both applications (bootloader and app).
> Compiled separately, of course. Any problem with that?
>
> Alex Ribero wrote:
> >
> >
> > Hi:
> >
> > There are couple things to look for:
> >
> > 1. Are you remapping the interrupt vectors to RAM in the main
> > application? From the right Flash memory location to the correct RAM
> > location?
> >
> > 2. Are you using different stack sizes between your secondary bootloader
> > and the main application? Data abort problems are a symtom of this
> > issue. One probable cause is that the secondary bootloader changes the
> > ARM Mode to "User", and then runs and jumps to the main application.
> > However, some of the code at the startup of the main application
> > (specifically the pieces that write to the CPSR register) won't operate
> > in User Mode. It needs to be in Supervisory Mode.
> >
> > Best solution to this issue is to change the mode to system or
> > supervisory before leaving the bootloader, or change it when entering
> > the Main Application.
> >
> > Regards,
> >
> > Alex
> >
> > --- In l... ,
> > "Sutton Mehaffey" wrote:
> > >
> > > I have 'successfully' uploaded new code from my SD card to CPU flash
> > through my intermediate flash. I have my secondary bootloader at
> > 0x00000000 and my app at 0x00004000. Everything uploads and verifies
> > correctly to 0x00004000. However, after the WDT trips, the transfer to
> > 0x00004000 doesn't work like it did before. I erased sectors 4-23 on the
> > CPU leaving the bootloader and the vector table. What else did I forget
> > to do?
> > >
> > > I followed the assembly code and it looks like there is a transfer to
> > 'never never land', which doesn't happen if I load the file thru Keil's
> > JTAG. If I reload thru the JTAG to 0x00004000, the transfer problem is
> > fixed and it works fine. But, I don't know what problem it fixed. Do I
> > need to save the status of certain registers before uploading new code?
> > >
> >
> > --
> 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@...
>
The startup code should be different between the bootloader and the main application, because, when you remap the interrupt vectors to RAM, the source of the interrupt vector addresses is different (as for the bootloader, are located at 0x00000000, while for the main application they are located at 0x00004000).
Note that the ARM processor will use the interrupt vector table located at 0x00000000 (even when you jump to 0x00004000 to run your application), unless the vector table is remapped at 0x40000000 (RAM).
This requires two steps: copy the correct vector table to 0x40000000 and tell the processor to use the vector table from 0x40000000.
See section 2.2.2 and 3.7.1 of the LPC2148 user Manual
We have done this for the LPC2366 and it works without problem.
Regards,
Alex
--- In l..., Sutton Mehaffey wrote:
>
> Interrupts seem to work fine. I didn't erase sectors 24-26. Therefore,
> I didn't think I needed to do anything with the interrupts.
>
> I use the same startup file in both applications (bootloader and app).
> Compiled separately, of course. Any problem with that?
>
> Alex Ribero wrote:
> >
> >
> > Hi:
> >
> > There are couple things to look for:
> >
> > 1. Are you remapping the interrupt vectors to RAM in the main
> > application? From the right Flash memory location to the correct RAM
> > location?
> >
> > 2. Are you using different stack sizes between your secondary bootloader
> > and the main application? Data abort problems are a symtom of this
> > issue. One probable cause is that the secondary bootloader changes the
> > ARM Mode to "User", and then runs and jumps to the main application.
> > However, some of the code at the startup of the main application
> > (specifically the pieces that write to the CPSR register) won't operate
> > in User Mode. It needs to be in Supervisory Mode.
> >
> > Best solution to this issue is to change the mode to system or
> > supervisory before leaving the bootloader, or change it when entering
> > the Main Application.
> >
> > Regards,
> >
> > Alex
> >
> > --- In l... ,
> > "Sutton Mehaffey" wrote:
> > >
> > > I have 'successfully' uploaded new code from my SD card to CPU flash
> > through my intermediate flash. I have my secondary bootloader at
> > 0x00000000 and my app at 0x00004000. Everything uploads and verifies
> > correctly to 0x00004000. However, after the WDT trips, the transfer to
> > 0x00004000 doesn't work like it did before. I erased sectors 4-23 on the
> > CPU leaving the bootloader and the vector table. What else did I forget
> > to do?
> > >
> > > I followed the assembly code and it looks like there is a transfer to
> > 'never never land', which doesn't happen if I load the file thru Keil's
> > JTAG. If I reload thru the JTAG to 0x00004000, the transfer problem is
> > fixed and it works fine. But, I don't know what problem it fixed. Do I
> > need to save the status of certain registers before uploading new code?
> > >
> >
> > --
> 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 19, 20092009-08-19
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
--- In l..., "Alex Ribero" wrote:
>
> Hi:
>
> The startup code should be different between the bootloader and the main application, because, when you remap the interrupt vectors to RAM, the source of the interrupt vector addresses is different (as for the bootloader, are located at 0x00000000, while for the main application they are located at 0x00004000).
>
> Note that the ARM processor will use the interrupt vector table located at 0x00000000 (even when you jump to 0x00004000 to run your application), unless the vector table is remapped at 0x40000000 (RAM).
> This requires two steps: copy the correct vector table to 0x40000000 and tell the processor to use the vector table from 0x40000000.
>
> See section 2.2.2 and 3.7.1 of the LPC2148 user Manual
>
> We have done this for the LPC2366 and it works without problem.
>
> Regards,
>
> Alex
>
> --- In l..., Sutton Mehaffey wrote:
> >
> > Interrupts seem to work fine. I didn't erase sectors 24-26. Therefore,
> > I didn't think I needed to do anything with the interrupts.
> >
> > I use the same startup file in both applications (bootloader and app).
> > Compiled separately, of course. Any problem with that?
> >
> >
> >
> > Alex Ribero wrote:
> > >
> > >
> > > Hi:
> > >
> > > There are couple things to look for:
> > >
> > > 1. Are you remapping the interrupt vectors to RAM in the main
> > > application? From the right Flash memory location to the correct RAM
> > > location?
> > >
> > > 2. Are you using different stack sizes between your secondary bootloader
> > > and the main application? Data abort problems are a symtom of this
> > > issue. One probable cause is that the secondary bootloader changes the
> > > ARM Mode to "User", and then runs and jumps to the main application.
> > > However, some of the code at the startup of the main application
> > > (specifically the pieces that write to the CPSR register) won't operate
> > > in User Mode. It needs to be in Supervisory Mode.
> > >
> > > Best solution to this issue is to change the mode to system or
> > > supervisory before leaving the bootloader, or change it when entering
> > > the Main Application.
> > >
> > > Regards,
> > >
> > > Alex
> > >
> > > --- In l... ,
> > > "Sutton Mehaffey" wrote:
> > > >
> > > > I have 'successfully' uploaded new code from my SD card to CPU flash
> > > through my intermediate flash. I have my secondary bootloader at
> > > 0x00000000 and my app at 0x00004000. Everything uploads and verifies
> > > correctly to 0x00004000. However, after the WDT trips, the transfer to
> > > 0x00004000 doesn't work like it did before. I erased sectors 4-23 on the
> > > CPU leaving the bootloader and the vector table. What else did I forget
> > > to do?
> > > >
> > > > I followed the assembly code and it looks like there is a transfer to
> > > 'never never land', which doesn't happen if I load the file thru Keil's
> > > JTAG. If I reload thru the JTAG to 0x00004000, the transfer problem is
> > > fixed and it works fine. But, I don't know what problem it fixed. Do I
> > > need to save the status of certain registers before uploading new code?
> > > >
> > >
> > >
> >
> > --
> > 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
--- In l..., "Alex Ribero" wrote:
>
> Hi:
>
> The startup code should be different between the bootloader and the main application, because, when you remap the interrupt vectors to RAM, the source of the interrupt vector addresses is different (as for the bootloader, are located at 0x00000000, while for the main application they are located at 0x00004000).
>
> Note that the ARM processor will use the interrupt vector table located at 0x00000000 (even when you jump to 0x00004000 to run your application), unless the vector table is remapped at 0x40000000 (RAM).
> This requires two steps: copy the correct vector table to 0x40000000 and tell the processor to use the vector table from 0x40000000.
>
> See section 2.2.2 and 3.7.1 of the LPC2148 user Manual
>
> We have done this for the LPC2366 and it works without problem.
>
> Regards,
>
> Alex
>
> --- In l..., Sutton Mehaffey wrote:
> >
> > Interrupts seem to work fine. I didn't erase sectors 24-26. Therefore,
> > I didn't think I needed to do anything with the interrupts.
> >
> > I use the same startup file in both applications (bootloader and app).
> > Compiled separately, of course. Any problem with that?
> >
> >
> >
> > Alex Ribero wrote:
> > >
> > >
> > > Hi:
> > >
> > > There are couple things to look for:
> > >
> > > 1. Are you remapping the interrupt vectors to RAM in the main
> > > application? From the right Flash memory location to the correct RAM
> > > location?
> > >
> > > 2. Are you using different stack sizes between your secondary bootloader
> > > and the main application? Data abort problems are a symtom of this
> > > issue. One probable cause is that the secondary bootloader changes the
> > > ARM Mode to "User", and then runs and jumps to the main application.
> > > However, some of the code at the startup of the main application
> > > (specifically the pieces that write to the CPSR register) won't operate
> > > in User Mode. It needs to be in Supervisory Mode.
> > >
> > > Best solution to this issue is to change the mode to system or
> > > supervisory before leaving the bootloader, or change it when entering
> > > the Main Application.
> > >
> > > Regards,
> > >
> > > Alex
> > >
> > > --- In l... ,
> > > "Sutton Mehaffey" wrote:
> > > >
> > > > I have 'successfully' uploaded new code from my SD card to CPU flash
> > > through my intermediate flash. I have my secondary bootloader at
> > > 0x00000000 and my app at 0x00004000. Everything uploads and verifies
> > > correctly to 0x00004000. However, after the WDT trips, the transfer to
> > > 0x00004000 doesn't work like it did before. I erased sectors 4-23 on the
> > > CPU leaving the bootloader and the vector table. What else did I forget
> > > to do?
> > > >
> > > > I followed the assembly code and it looks like there is a transfer to
> > > 'never never land', which doesn't happen if I load the file thru Keil's
> > > JTAG. If I reload thru the JTAG to 0x00004000, the transfer problem is
> > > fixed and it works fine. But, I don't know what problem it fixed. Do I
> > > need to save the status of certain registers before uploading new code?
> > > >
> > >
> > >
> >
> > --
> > 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 19, 20092009-08-19
--- 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
>
> 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
Reply by ●August 19, 20092009-08-19
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
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
Reply by ●August 19, 20092009-08-19
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
>
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
>
