Hi Sutton
> 1. No. The bootloader is always initiated on reset.
It figures out
> whether the code is valid by looking at RAM (for 0xA5 - good, otherwise
> bad), then transfers to 0x00004000 if valid. Otherwise, it uploads from
> serial flash. If for some reason, the serial flash has a bad image and
> the RAM variable is not 0xA5, the user will have to send the unit back.
> I consider this a rare event, but will probably happen someday.
> There is no SD code in the bootloader. Done for the reason of not
> having a larger bootloader. The main app does not have a mechanism to
> jump back to 0 or call the bootload code. Doesn't need to.
I am a bit confused: Normaly the bootloader loads the "application" from
some non-volatile storage (NOR/NAND Flash, SD-Card) into RAM.
To do this, it has to initialize the RAM.
Do you expect the RAM content to be correct after a reset ?
If so, do not only check a single byte, you have to do at least a CRC32
over you code.
>
> 3. No. The bootloader still functions fine after installing off the SD
> card. I've never had to reload the bootloader after installing off the
> SD card. I've only had to reinstall the app code via JTAG for it to
> work again.
Where do you "reinstall" the application ?
> 4. The bootloader has always worked whether the app
was programmed via
> JTAG (transfer to 0x00004000 works fine) or whether the app was uploaded
> from the SD card (transfer to 0x00004000 doesn't work).
Check your (SD)RAM setup !
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
new SD code transfer to LPC2148 not quite working
Started by ●August 18, 2009
Reply by ●August 20, 20092009-08-20
Reply by ●August 20, 20092009-08-20
When I say RAM for my variable, I say it loosely, but it is confusing to
everyone. The variable I use for the valid byte is in I2C serial
eeprom, not CPU RAM. Therefore a non problem on power up.
The application copies code from SD card to SPI serial flash (not the
same as my I2C serial eeprom). The only purpose right now for the SPI
serial flash is to capture the SD card code so that I do not have to
have SD support in the bootloader. After, the code is uploaded from the
SD card into the serial flash, it is write protected. There are several
levels of WP. So, this code should remain good indefinitely. I check
byte for byte with the SD card after upload before considering the
serial flash to be valid. I, then, change the serial eeprom value to 0
and initiate a WDT reset to start the bootloader.
Upon a WDT reset (and a 0 in serial eeprom), the bootloader uploads into
CPU RAM (1024 bytes at a time) the new code from the serial flash. This
code goes into RAM to 0x00004000 via IAP.
Hope this is better clarification.
42Bastian wrote:
>
>
> Hi Sutton
>
> > 1. No. The bootloader is always initiated on reset. It figures out
> > whether the code is valid by looking at RAM (for 0xA5 - good, otherwise
> > bad), then transfers to 0x00004000 if valid. Otherwise, it uploads from
> > serial flash. If for some reason, the serial flash has a bad image and
> > the RAM variable is not 0xA5, the user will have to send the unit back.
> > I consider this a rare event, but will probably happen someday.
> > There is no SD code in the bootloader. Done for the reason of not
> > having a larger bootloader. The main app does not have a mechanism to
> > jump back to 0 or call the bootload code. Doesn't need to.
>
> I am a bit confused: Normaly the bootloader loads the "application" from
> some non-volatile storage (NOR/NAND Flash, SD-Card) into RAM.
>
> To do this, it has to initialize the RAM.
>
> Do you expect the RAM content to be correct after a reset ?
>
> If so, do not only check a single byte, you have to do at least a CRC32
> over you code.
>
> >
> > 3. No. The bootloader still functions fine after installing off the SD
> > card. I've never had to reload the bootloader after installing off the
> > SD card. I've only had to reinstall the app code via JTAG for it to
> > work again.
>
> Where do you "reinstall" the application ?
>
> > 4. The bootloader has always worked whether the app was programmed via
> > JTAG (transfer to 0x00004000 works fine) or whether the app was uploaded
> > from the SD card (transfer to 0x00004000 doesn't work).
>
> Check your (SD)RAM setup !
>
> --
> 42Bastian
> ------------------
> Parts of this email are written with invisible ink.
>
> Note: SPAM-only account, direct mail to bs42@...
--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
everyone. The variable I use for the valid byte is in I2C serial
eeprom, not CPU RAM. Therefore a non problem on power up.
The application copies code from SD card to SPI serial flash (not the
same as my I2C serial eeprom). The only purpose right now for the SPI
serial flash is to capture the SD card code so that I do not have to
have SD support in the bootloader. After, the code is uploaded from the
SD card into the serial flash, it is write protected. There are several
levels of WP. So, this code should remain good indefinitely. I check
byte for byte with the SD card after upload before considering the
serial flash to be valid. I, then, change the serial eeprom value to 0
and initiate a WDT reset to start the bootloader.
Upon a WDT reset (and a 0 in serial eeprom), the bootloader uploads into
CPU RAM (1024 bytes at a time) the new code from the serial flash. This
code goes into RAM to 0x00004000 via IAP.
Hope this is better clarification.
42Bastian wrote:
>
>
> Hi Sutton
>
> > 1. No. The bootloader is always initiated on reset. It figures out
> > whether the code is valid by looking at RAM (for 0xA5 - good, otherwise
> > bad), then transfers to 0x00004000 if valid. Otherwise, it uploads from
> > serial flash. If for some reason, the serial flash has a bad image and
> > the RAM variable is not 0xA5, the user will have to send the unit back.
> > I consider this a rare event, but will probably happen someday.
> > There is no SD code in the bootloader. Done for the reason of not
> > having a larger bootloader. The main app does not have a mechanism to
> > jump back to 0 or call the bootload code. Doesn't need to.
>
> I am a bit confused: Normaly the bootloader loads the "application" from
> some non-volatile storage (NOR/NAND Flash, SD-Card) into RAM.
>
> To do this, it has to initialize the RAM.
>
> Do you expect the RAM content to be correct after a reset ?
>
> If so, do not only check a single byte, you have to do at least a CRC32
> over you code.
>
> >
> > 3. No. The bootloader still functions fine after installing off the SD
> > card. I've never had to reload the bootloader after installing off the
> > SD card. I've only had to reinstall the app code via JTAG for it to
> > work again.
>
> Where do you "reinstall" the application ?
>
> > 4. The bootloader has always worked whether the app was programmed via
> > JTAG (transfer to 0x00004000 works fine) or whether the app was uploaded
> > from the SD card (transfer to 0x00004000 doesn't work).
>
> Check your (SD)RAM setup !
>
> --
> 42Bastian
> ------------------
> Parts of this email are written with invisible ink.
>
> Note: SPAM-only account, direct mail to bs42@...
--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
Reply by ●August 20, 20092009-08-20
2009/8/20 Sutton Mehaffey
> By the way, to answer Miguel's question. I know where the crash occurs.
> Here's what happens. In tracing thru the assembly code when executing
> 'app()' (on the bad transfer), which transfers execution to 0x00004000,
> there is a statement:
I don't understand:
The crash happens in the bootloader, just before calling your app? (0x000000
- 0x3fff)
or inside your app? (0x4000 - ....)
>
> E8BA000F LDMIA R10!,(R0-R3) that changes R3 to 0x2CB88 and 4 lines
this is a pop from stack
> down this register is used in BX R3 as a branch. This is a bogus
> location that is causing the eventual crash.
and this is a "return", I suppose
It's possible for you to post a .lst file (or .S output file) just in the
part that's crashing?
and a .map file?
>
> In the 'good transfer', this statement causes R3 to be set to 0x4158,
> which is much more reasonable. And, thus the transfer works.
>
> ;
--
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
> By the way, to answer Miguel's question. I know where the crash occurs.
> Here's what happens. In tracing thru the assembly code when executing
> 'app()' (on the bad transfer), which transfers execution to 0x00004000,
> there is a statement:
I don't understand:
The crash happens in the bootloader, just before calling your app? (0x000000
- 0x3fff)
or inside your app? (0x4000 - ....)
>
> E8BA000F LDMIA R10!,(R0-R3) that changes R3 to 0x2CB88 and 4 lines
this is a pop from stack
> down this register is used in BX R3 as a branch. This is a bogus
> location that is causing the eventual crash.
and this is a "return", I suppose
It's possible for you to post a .lst file (or .S output file) just in the
part that's crashing?
and a .map file?
>
> In the 'good transfer', this statement causes R3 to be set to 0x4158,
> which is much more reasonable. And, thus the transfer works.
>
> ;
--
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
Reply by ●August 20, 20092009-08-20
I'll post in a little bit.
The crash happens in the bootloader as it's trying to transfer control
to 0x00004000. The app code never gets started.
It's a stack problem, I'm sure. The debugger gets to 'app();', which is
a pointer to address 0x00004000 (which is the last statement in the
bootloader), but never gets to the first line in the app code. If you
follow the assembly code from 'app()', I assume that things are saved,
the stack is setup for a transfer, and that's where the crash happens.
Miguel Angel wrote:
>
>
> 2009/8/20 Sutton Mehaffey > >
> > By the way, to answer Miguel's question. I know where the crash occurs.
> > Here's what happens. In tracing thru the assembly code when executing
> > 'app()' (on the bad transfer), which transfers execution to 0x00004000,
> > there is a statement:
>
> I don't understand:
>
> The crash happens in the bootloader, just before calling your app? (0x000000
> - 0x3fff)
> or inside your app? (0x4000 - ....)
>
> >
> > E8BA000F LDMIA R10!,(R0-R3) that changes R3 to 0x2CB88 and 4 lines
>
> this is a pop from stack
>
> > down this register is used in BX R3 as a branch. This is a bogus
> > location that is causing the eventual crash.
>
> and this is a "return", I suppose
>
> It's possible for you to post a .lst file (or .S output file) just in the
> part that's crashing?
>
> and a .map file?
>
> >
> > In the 'good transfer', this statement causes R3 to be set to 0x4158,
> > which is much more reasonable. And, thus the transfer works.
> >
> > ;
>
> --
> 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
The crash happens in the bootloader as it's trying to transfer control
to 0x00004000. The app code never gets started.
It's a stack problem, I'm sure. The debugger gets to 'app();', which is
a pointer to address 0x00004000 (which is the last statement in the
bootloader), but never gets to the first line in the app code. If you
follow the assembly code from 'app()', I assume that things are saved,
the stack is setup for a transfer, and that's where the crash happens.
Miguel Angel wrote:
>
>
> 2009/8/20 Sutton Mehaffey > >
> > By the way, to answer Miguel's question. I know where the crash occurs.
> > Here's what happens. In tracing thru the assembly code when executing
> > 'app()' (on the bad transfer), which transfers execution to 0x00004000,
> > there is a statement:
>
> I don't understand:
>
> The crash happens in the bootloader, just before calling your app? (0x000000
> - 0x3fff)
> or inside your app? (0x4000 - ....)
>
> >
> > E8BA000F LDMIA R10!,(R0-R3) that changes R3 to 0x2CB88 and 4 lines
>
> this is a pop from stack
>
> > down this register is used in BX R3 as a branch. This is a bogus
> > location that is causing the eventual crash.
>
> and this is a "return", I suppose
>
> It's possible for you to post a .lst file (or .S output file) just in the
> part that's crashing?
>
> and a .map file?
>
> >
> > In the 'good transfer', this statement causes R3 to be set to 0x4158,
> > which is much more reasonable. And, thus the transfer works.
> >
> > ;
>
> --
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 91 120 1798
> +34 636 52 25 69
> skype: ajoajoajo
>
>
--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
Reply by ●August 20, 20092009-08-20
Hmmm I see,
It really looks like an stack corruption problem. What's the setup of
your stack/heap/bss ?
Do you use mallocs in your bootloader code?
May be just changing the call to 0x4000 with assembler code
would fix it, but if it's an stack problem, then it could arise at any other
time, making the bootloader crash in some other situation. It's better
to fix the problem from roots.
Try this, as a "patch", but the stack problem should be fixed:
__asm {
LDR R0,=0x4000 <--- if this one doesn't compile try MOV
R0,#0x4000
MOV LR,PC
BX R0
}
2009/8/20 Sutton Mehaffey
> I'll post in a little bit.
>
> The crash happens in the bootloader as it's trying to transfer control
> to 0x00004000. The app code never gets started.
>
> It's a stack problem, I'm sure. The debugger gets to 'app();', which is
> a pointer to address 0x00004000 (which is the last statement in the
> bootloader), but never gets to the first line in the app code. If you
> follow the assembly code from 'app()', I assume that things are saved,
> the stack is setup for a transfer, and that's where the crash happens.
> Miguel Angel wrote:
> >
> >
> > 2009/8/20 Sutton Mehaffey
> >
> >> > > By the way, to answer Miguel's question. I know where the crash occurs.
> > > Here's what happens. In tracing thru the assembly code when executing
> > > 'app()' (on the bad transfer), which transfers execution to 0x00004000,
> > > there is a statement:
> >
> > I don't understand:
> >
> > The crash happens in the bootloader, just before calling your app?
> (0x000000
> > - 0x3fff)
> > or inside your app? (0x4000 - ....)
> >
> > >
> > > E8BA000F LDMIA R10!,(R0-R3) that changes R3 to 0x2CB88 and 4 lines
> >
> > this is a pop from stack
> >
> > > down this register is used in BX R3 as a branch. This is a bogus
> > > location that is causing the eventual crash.
> >
> > and this is a "return", I suppose
> >
> > It's possible for you to post a .lst file (or .S output file) just in the
> > part that's crashing?
> >
> > and a .map file?
> >
> > >
> > > In the 'good transfer', this statement causes R3 to be set to 0x4158,
> > > which is much more reasonable. And, thus the transfer works.
> > >
> > > ;
> >
> > --
> > 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
It really looks like an stack corruption problem. What's the setup of
your stack/heap/bss ?
Do you use mallocs in your bootloader code?
May be just changing the call to 0x4000 with assembler code
would fix it, but if it's an stack problem, then it could arise at any other
time, making the bootloader crash in some other situation. It's better
to fix the problem from roots.
Try this, as a "patch", but the stack problem should be fixed:
__asm {
LDR R0,=0x4000 <--- if this one doesn't compile try MOV
R0,#0x4000
MOV LR,PC
BX R0
}
2009/8/20 Sutton Mehaffey
> I'll post in a little bit.
>
> The crash happens in the bootloader as it's trying to transfer control
> to 0x00004000. The app code never gets started.
>
> It's a stack problem, I'm sure. The debugger gets to 'app();', which is
> a pointer to address 0x00004000 (which is the last statement in the
> bootloader), but never gets to the first line in the app code. If you
> follow the assembly code from 'app()', I assume that things are saved,
> the stack is setup for a transfer, and that's where the crash happens.
> Miguel Angel wrote:
> >
> >
> > 2009/8/20 Sutton Mehaffey
> >
> >> > > By the way, to answer Miguel's question. I know where the crash occurs.
> > > Here's what happens. In tracing thru the assembly code when executing
> > > 'app()' (on the bad transfer), which transfers execution to 0x00004000,
> > > there is a statement:
> >
> > I don't understand:
> >
> > The crash happens in the bootloader, just before calling your app?
> (0x000000
> > - 0x3fff)
> > or inside your app? (0x4000 - ....)
> >
> > >
> > > E8BA000F LDMIA R10!,(R0-R3) that changes R3 to 0x2CB88 and 4 lines
> >
> > this is a pop from stack
> >
> > > down this register is used in BX R3 as a branch. This is a bogus
> > > location that is causing the eventual crash.
> >
> > and this is a "return", I suppose
> >
> > It's possible for you to post a .lst file (or .S output file) just in the
> > part that's crashing?
> >
> > and a .map file?
> >
> > >
> > > In the 'good transfer', this statement causes R3 to be set to 0x4158,
> > > which is much more reasonable. And, thus the transfer works.
> > >
> > > ;
> >
> > --
> > 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
Reply by ●August 20, 20092009-08-20
No mallocs.
See the Startup code a few posts back for the stack/heap setup. It's
whatever the default Keil setup is for the LPC2148.
The first 'Step' thru the assembly code following app() puts me at
0x00004000. So, the call is working. But, there is obviously some
setup code following 0x4000 that eventually causes the crash before it
gets to the first app() executable statement which is somewhere around
0x4158. I think that pointer to 0x2CB98 has something to do with it,
but don't know where that value is coming from. See the post a few back
to see that statement.
Miguel Angel wrote:
>
>
> Hmmm I see,
>
> It really looks like an stack corruption problem. What's the setup of
> your stack/heap/bss ?
>
> Do you use mallocs in your bootloader code?
>
> May be just changing the call to 0x4000 with assembler code
> would fix it, but if it's an stack problem, then it could arise at any other
> time, making the bootloader crash in some other situation. It's better
> to fix the problem from roots.
>
> Try this, as a "patch", but the stack problem should be fixed:
>
> __asm {
>
> LDR R0,=0x4000 <--- if this one doesn't compile try MOV
> R0,#0x4000
> MOV LR,PC
> BX R0
> }
>
> 2009/8/20 Sutton Mehaffey > > >
> >
> > I'll post in a little bit.
> >
> > The crash happens in the bootloader as it's trying to transfer control
> > to 0x00004000. The app code never gets started.
> >
> > It's a stack problem, I'm sure. The debugger gets to 'app();', which is
> > a pointer to address 0x00004000 (which is the last statement in the
> > bootloader), but never gets to the first line in the app code. If you
> > follow the assembly code from 'app()', I assume that things are saved,
> > the stack is setup for a transfer, and that's where the crash happens.
> >
> >
> > Miguel Angel wrote:
> > >
> > >
> > > 2009/8/20 Sutton Mehaffey >
> > >
>
> > >>
> >
> > > > By the way, to answer Miguel's question. I know where the crash
> occurs.
> > > > Here's what happens. In tracing thru the assembly code when executing
> > > > 'app()' (on the bad transfer), which transfers execution to
> 0x00004000,
> > > > there is a statement:
> > >
> > > I don't understand:
> > >
> > > The crash happens in the bootloader, just before calling your app?
> > (0x000000
> > > - 0x3fff)
> > > or inside your app? (0x4000 - ....)
> > >
> > > >
> > > > E8BA000F LDMIA R10!,(R0-R3) that changes R3 to 0x2CB88 and 4 lines
> > >
> > > this is a pop from stack
> > >
> > > > down this register is used in BX R3 as a branch. This is a bogus
> > > > location that is causing the eventual crash.
> > >
> > > and this is a "return", I suppose
> > >
> > > It's possible for you to post a .lst file (or .S output file) just
> in the
> > > part that's crashing?
> > >
> > > and a .map file?
> > >
> > > >
> > > > In the 'good transfer', this statement causes R3 to be set to 0x4158,
> > > > which is much more reasonable. And, thus the transfer works.
> > > >
> > > > ;
> > >
> > > --
> > > 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
See the Startup code a few posts back for the stack/heap setup. It's
whatever the default Keil setup is for the LPC2148.
The first 'Step' thru the assembly code following app() puts me at
0x00004000. So, the call is working. But, there is obviously some
setup code following 0x4000 that eventually causes the crash before it
gets to the first app() executable statement which is somewhere around
0x4158. I think that pointer to 0x2CB98 has something to do with it,
but don't know where that value is coming from. See the post a few back
to see that statement.
Miguel Angel wrote:
>
>
> Hmmm I see,
>
> It really looks like an stack corruption problem. What's the setup of
> your stack/heap/bss ?
>
> Do you use mallocs in your bootloader code?
>
> May be just changing the call to 0x4000 with assembler code
> would fix it, but if it's an stack problem, then it could arise at any other
> time, making the bootloader crash in some other situation. It's better
> to fix the problem from roots.
>
> Try this, as a "patch", but the stack problem should be fixed:
>
> __asm {
>
> LDR R0,=0x4000 <--- if this one doesn't compile try MOV
> R0,#0x4000
> MOV LR,PC
> BX R0
> }
>
> 2009/8/20 Sutton Mehaffey > > >
> >
> > I'll post in a little bit.
> >
> > The crash happens in the bootloader as it's trying to transfer control
> > to 0x00004000. The app code never gets started.
> >
> > It's a stack problem, I'm sure. The debugger gets to 'app();', which is
> > a pointer to address 0x00004000 (which is the last statement in the
> > bootloader), but never gets to the first line in the app code. If you
> > follow the assembly code from 'app()', I assume that things are saved,
> > the stack is setup for a transfer, and that's where the crash happens.
> >
> >
> > Miguel Angel wrote:
> > >
> > >
> > > 2009/8/20 Sutton Mehaffey >
> > >
>
> > >>
> >
> > > > By the way, to answer Miguel's question. I know where the crash
> occurs.
> > > > Here's what happens. In tracing thru the assembly code when executing
> > > > 'app()' (on the bad transfer), which transfers execution to
> 0x00004000,
> > > > there is a statement:
> > >
> > > I don't understand:
> > >
> > > The crash happens in the bootloader, just before calling your app?
> > (0x000000
> > > - 0x3fff)
> > > or inside your app? (0x4000 - ....)
> > >
> > > >
> > > > E8BA000F LDMIA R10!,(R0-R3) that changes R3 to 0x2CB88 and 4 lines
> > >
> > > this is a pop from stack
> > >
> > > > down this register is used in BX R3 as a branch. This is a bogus
> > > > location that is causing the eventual crash.
> > >
> > > and this is a "return", I suppose
> > >
> > > It's possible for you to post a .lst file (or .S output file) just
> in the
> > > part that's crashing?
> > >
> > > and a .map file?
> > >
> > > >
> > > > In the 'good transfer', this statement causes R3 to be set to 0x4158,
> > > > which is much more reasonable. And, thus the transfer works.
> > > >
> > > > ;
> > >
> > > --
> > > 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
Reply by ●August 20, 20092009-08-20
Sutton Mehaffey schrieb:
> No mallocs.
>
> See the Startup code a few posts back for the stack/heap setup. It's
You application should not setup things already setup by the bootloader.
Esp. messing with the RAM setup while running from RAM might be a bad idea.
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
> No mallocs.
>
> See the Startup code a few posts back for the stack/heap setup. It's
You application should not setup things already setup by the bootloader.
Esp. messing with the RAM setup while running from RAM might be a bad idea.
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
Reply by ●August 20, 20092009-08-20
2009/8/20 Sutton Mehaffey No mallocs.
>
> See the Startup code a few posts back for the stack/heap setup. It's
> whatever the default Keil setup is for the LPC2148.
>
!!!!!! Then the crash is happening at >=0x4000, not <0x4000 as you told me
some mails ago..... :
"""""
>> The crash happens in the bootloader as it's trying to transfer control
>> to 0x00004000. The app code never gets started.
"""""
Could you* please post the .lst or binary *of your app to check the first
instructions?
It's failing at startup of your binary image. If it's working when you flash
using JTAG, then I start to think that your flashing it's not working
correctly,
.....
> The first 'Step' thru the assembly code following app() puts me at
> 0x00004000. So, the call is working. But, there is obviously some
> setup code following 0x4000 that eventually causes the crash before it
> gets to the first app() executable statement which is somewhere around
> 0x4158. I think that pointer to 0x2CB98 has something to do with it,
> but don't know where that value is coming from. See the post a few back
> to see that statement.
>
> Miguel Angel wrote:
> >
> >
> > Hmmm I see,
> >
> > It really looks like an stack corruption problem. What's the setup of
> > your stack/heap/bss ?
> >
> > Do you use mallocs in your bootloader code?
> >
> > May be just changing the call to 0x4000 with assembler code
> > would fix it, but if it's an stack problem, then it could arise at any
other
> > time, making the bootloader crash in some other situation. It's better
> > to fix the problem from roots.
> >
> > Try this, as a "patch", but the stack problem should be fixed:
> >
> > __asm {
> >
> > LDR R0,=0x4000 <--- if this one doesn't compile try MOV
> > R0,#0x4000
> > MOV LR,PC
> > BX R0
> > }
> >
> > 2009/8/20 Sutton Mehaffey > >
>>
> >
> > >
> > >
> > > I'll post in a little bit.
> > >
> > > The crash happens in the bootloader as it's trying to transfer control
> > > to 0x00004000. The app code never gets started.
> > >
> > > It's a stack problem, I'm sure. The debugger gets to 'app();', which
is
> > > a pointer to address 0x00004000 (which is the last statement in the
> > > bootloader), but never gets to the first line in the app code. If you
> > > follow the assembly code from 'app()', I assume that things are saved,
> > > the stack is setup for a transfer, and that's where the crash happens.
> > >
> > >
> > > Miguel Angel wrote:
> > > >
> > > >
> > > > 2009/8/20 Sutton Mehaffey > >
>
> > > >
> >
> > > >>
> > >
> > > > > By the way, to answer Miguel's question. I know where the crash
> > occurs.
> > > > > Here's what happens. In tracing thru the assembly code when
executing
> > > > > 'app()' (on the bad transfer), which transfers execution to
> > 0x00004000,
> > > > > there is a statement:
> > > >
> > > > I don't understand:
> > > >
> > > > The crash happens in the bootloader, just before calling your app?
> > > (0x000000
> > > > - 0x3fff)
> > > > or inside your app? (0x4000 - ....)
> > > >
> > > > >
> > > > > E8BA000F LDMIA R10!,(R0-R3) that changes R3 to 0x2CB88 and 4 lines
> > > >
> > > > this is a pop from stack
> > > >
> > > > > down this register is used in BX R3 as a branch. This is a bogus
> > > > > location that is causing the eventual crash.
> > > >
> > > > and this is a "return", I suppose
> > > >
> > > > It's possible for you to post a .lst file (or .S output file) just
> > in the
> > > > part that's crashing?
> > > >
> > > > and a .map file?
> > > >
> > > > >
> > > > > In the 'good transfer', this statement causes R3 to be set to
0x4158,
> > > > > which is much more reasonable. And, thus the transfer works.
> > > > >
> > > > > ;
> > > >
> > > > --
> > > > 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
>
> See the Startup code a few posts back for the stack/heap setup. It's
> whatever the default Keil setup is for the LPC2148.
>
!!!!!! Then the crash is happening at >=0x4000, not <0x4000 as you told me
some mails ago..... :
"""""
>> The crash happens in the bootloader as it's trying to transfer control
>> to 0x00004000. The app code never gets started.
"""""
Could you* please post the .lst or binary *of your app to check the first
instructions?
It's failing at startup of your binary image. If it's working when you flash
using JTAG, then I start to think that your flashing it's not working
correctly,
.....
> The first 'Step' thru the assembly code following app() puts me at
> 0x00004000. So, the call is working. But, there is obviously some
> setup code following 0x4000 that eventually causes the crash before it
> gets to the first app() executable statement which is somewhere around
> 0x4158. I think that pointer to 0x2CB98 has something to do with it,
> but don't know where that value is coming from. See the post a few back
> to see that statement.
>
> Miguel Angel wrote:
> >
> >
> > Hmmm I see,
> >
> > It really looks like an stack corruption problem. What's the setup of
> > your stack/heap/bss ?
> >
> > Do you use mallocs in your bootloader code?
> >
> > May be just changing the call to 0x4000 with assembler code
> > would fix it, but if it's an stack problem, then it could arise at any
other
> > time, making the bootloader crash in some other situation. It's better
> > to fix the problem from roots.
> >
> > Try this, as a "patch", but the stack problem should be fixed:
> >
> > __asm {
> >
> > LDR R0,=0x4000 <--- if this one doesn't compile try MOV
> > R0,#0x4000
> > MOV LR,PC
> > BX R0
> > }
> >
> > 2009/8/20 Sutton Mehaffey > >
>>
> >
> > >
> > >
> > > I'll post in a little bit.
> > >
> > > The crash happens in the bootloader as it's trying to transfer control
> > > to 0x00004000. The app code never gets started.
> > >
> > > It's a stack problem, I'm sure. The debugger gets to 'app();', which
is
> > > a pointer to address 0x00004000 (which is the last statement in the
> > > bootloader), but never gets to the first line in the app code. If you
> > > follow the assembly code from 'app()', I assume that things are saved,
> > > the stack is setup for a transfer, and that's where the crash happens.
> > >
> > >
> > > Miguel Angel wrote:
> > > >
> > > >
> > > > 2009/8/20 Sutton Mehaffey > >
>
> > > >
> >
> > > >>
> > >
> > > > > By the way, to answer Miguel's question. I know where the crash
> > occurs.
> > > > > Here's what happens. In tracing thru the assembly code when
executing
> > > > > 'app()' (on the bad transfer), which transfers execution to
> > 0x00004000,
> > > > > there is a statement:
> > > >
> > > > I don't understand:
> > > >
> > > > The crash happens in the bootloader, just before calling your app?
> > > (0x000000
> > > > - 0x3fff)
> > > > or inside your app? (0x4000 - ....)
> > > >
> > > > >
> > > > > E8BA000F LDMIA R10!,(R0-R3) that changes R3 to 0x2CB88 and 4 lines
> > > >
> > > > this is a pop from stack
> > > >
> > > > > down this register is used in BX R3 as a branch. This is a bogus
> > > > > location that is causing the eventual crash.
> > > >
> > > > and this is a "return", I suppose
> > > >
> > > > It's possible for you to post a .lst file (or .S output file) just
> > in the
> > > > part that's crashing?
> > > >
> > > > and a .map file?
> > > >
> > > > >
> > > > > In the 'good transfer', this statement causes R3 to be set to
0x4158,
> > > > > which is much more reasonable. And, thus the transfer works.
> > > > >
> > > > > ;
> > > >
> > > > --
> > > > 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
Reply by ●August 20, 20092009-08-20
Hi Sutton
> When I say RAM for my variable, I say it loosely, but it is confusing to
> everyone. The variable I use for the valid byte is in I2C serial
> eeprom, not CPU RAM. Therefore a non problem on power up.
>
> The application copies code from SD card to SPI serial flash (not the
> same as my I2C serial eeprom). The only purpose right now for the SPI
> serial flash is to capture the SD card code so that I do not have to
> have SD support in the bootloader. After, the code is uploaded from the
> SD card into the serial flash, it is write protected. There are several
> levels of WP. So, this code should remain good indefinitely. I check
> byte for byte with the SD card after upload before considering the
> serial flash to be valid. I, then, change the serial eeprom value to 0
> and initiate a WDT reset to start the bootloader.
Hell, how complicated. Sorry I missed parts of the thread, but what CPU
is it. Is you bootrom so limited ?
> Upon a WDT reset (and a 0 in serial eeprom), the bootloader uploads into
> CPU RAM (1024 bytes at a time) the new code from the serial flash. This
> code goes into RAM to 0x00004000 via IAP.
Via IAP ? Into RAM ?
> Hope this is better clarification.
A little. But still ...
Be sure to disable all interrupts before launching the app and stay in
SVC mode in the bootloader.
Did you try booting a "hello world" ?
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
> When I say RAM for my variable, I say it loosely, but it is confusing to
> everyone. The variable I use for the valid byte is in I2C serial
> eeprom, not CPU RAM. Therefore a non problem on power up.
>
> The application copies code from SD card to SPI serial flash (not the
> same as my I2C serial eeprom). The only purpose right now for the SPI
> serial flash is to capture the SD card code so that I do not have to
> have SD support in the bootloader. After, the code is uploaded from the
> SD card into the serial flash, it is write protected. There are several
> levels of WP. So, this code should remain good indefinitely. I check
> byte for byte with the SD card after upload before considering the
> serial flash to be valid. I, then, change the serial eeprom value to 0
> and initiate a WDT reset to start the bootloader.
Hell, how complicated. Sorry I missed parts of the thread, but what CPU
is it. Is you bootrom so limited ?
> Upon a WDT reset (and a 0 in serial eeprom), the bootloader uploads into
> CPU RAM (1024 bytes at a time) the new code from the serial flash. This
> code goes into RAM to 0x00004000 via IAP.
Via IAP ? Into RAM ?
> Hope this is better clarification.
A little. But still ...
Be sure to disable all interrupts before launching the app and stay in
SVC mode in the bootloader.
Did you try booting a "hello world" ?
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
Reply by ●August 20, 20092009-08-20
My bad. It is making it to 0x4000, but not getting to the first
executable statement in app();, which is around 0x4158. OK, so what
goes on between 0x4000 and 0x4158? Vector mapping, etc??
I will post it, but not at my workstation again for a couple of hours.
Also, one omitted point (and we all love those, but I just thought of
it). The binary file has 00 00 40 00 00 00 as the first 6 bytes in the
file, which looks like a load location of 0x4000 somehow after the Keil
compile. After a load from JTAG (which runs perfect), the first 6 bytes
starting at 0x4000 are mapped to the SD card file byte number 6. Bytes
0-5, the ones listed above, are not in the code space. So, what I did
was omit those when loading and start with byte 6 in my upload to CPU
RAM (then onto CPU flash). That way the after the upload, the code
matches exactly to what the JTAG code looked like.
I've even tried uploading a simple app like blinking an LED on my board,
but still doesn't work.
Miguel Angel wrote:
>
>
> 2009/8/20 Sutton Mehaffey > >
> >
> >
> >
> > No mallocs.
> >
> > See the Startup code a few posts back for the stack/heap setup. It's
> > whatever the default Keil setup is for the LPC2148.
> > !!!!!! Then the crash is happening at >=0x4000, not <0x4000 as you told me
> some mails ago..... :
>
> """""
> >> The crash happens in the bootloader as it's trying to transfer control
> >> to 0x00004000. The app code never gets started.
> """""
>
> Could you* please post the .lst or binary *of your app to check the first
> instructions?
>
> It's failing at startup of your binary image. If it's working when you flash
> using JTAG, then I start to think that your flashing it's not working
> correctly,
> .....
>
> > The first 'Step' thru the assembly code following app() puts me at
> > 0x00004000. So, the call is working. But, there is obviously some
> > setup code following 0x4000 that eventually causes the crash before it
> > gets to the first app() executable statement which is somewhere around
> > 0x4158. I think that pointer to 0x2CB98 has something to do with it,
> > but don't know where that value is coming from. See the post a few back
> > to see that statement.
> >
> > Miguel Angel wrote:
> > >
> > >
> > > Hmmm I see,
> > >
> > > It really looks like an stack corruption problem. What's the setup of
> > > your stack/heap/bss ?
> > >
> > > Do you use mallocs in your bootloader code?
> > >
> > > May be just changing the call to 0x4000 with assembler code
> > > would fix it, but if it's an stack problem, then it could arise at any
> other
> > > time, making the bootloader crash in some other situation. It's better
> > > to fix the problem from roots.
> > >
> > > Try this, as a "patch", but the stack problem should be fixed:
> > >
> > > __asm {
> > >
> > > LDR R0,=0x4000 <--- if this one doesn't compile try MOV
> > > R0,#0x4000
> > > MOV LR,PC
> > > BX R0
> > > }
> > >
> > > 2009/8/20 Sutton Mehaffey >
> > >
>
> >>
> > >
> > > >
> > > >
> > > > I'll post in a little bit.
> > > >
> > > > The crash happens in the bootloader as it's trying to transfer
> control
> > > > to 0x00004000. The app code never gets started.
> > > >
> > > > It's a stack problem, I'm sure. The debugger gets to 'app();', which
> is
> > > > a pointer to address 0x00004000 (which is the last statement in the
> > > > bootloader), but never gets to the first line in the app code. If you
> > > > follow the assembly code from 'app()', I assume that things are
> saved,
> > > > the stack is setup for a transfer, and that's where the crash
> happens.
> > > >
> > > >
> > > > Miguel Angel wrote:
> > > > >
> > > > >
> > > > > 2009/8/20 Sutton Mehaffey >
> > >
>
> >
> > > > >
> > >
>
>
> > > > >>
> > > >
> > > > > > By the way, to answer Miguel's question. I know where the crash
> > > occurs.
> > > > > > Here's what happens. In tracing thru the assembly code when
> executing
> > > > > > 'app()' (on the bad transfer), which transfers execution to
> > > 0x00004000,
> > > > > > there is a statement:
> > > > >
> > > > > I don't understand:
> > > > >
> > > > > The crash happens in the bootloader, just before calling your app?
> > > > (0x000000
> > > > > - 0x3fff)
> > > > > or inside your app? (0x4000 - ....)
> > > > >
> > > > > >
> > > > > > E8BA000F LDMIA R10!,(R0-R3) that changes R3 to 0x2CB88 and 4
> lines
> > > > >
> > > > > this is a pop from stack
> > > > >
> > > > > > down this register is used in BX R3 as a branch. This is a bogus
> > > > > > location that is causing the eventual crash.
> > > > >
> > > > > and this is a "return", I suppose
> > > > >
> > > > > It's possible for you to post a .lst file (or .S output file) just
> > > in the
> > > > > part that's crashing?
> > > > >
> > > > > and a .map file?
> > > > >
> > > > > >
> > > > > > In the 'good transfer', this statement causes R3 to be set to
> 0x4158,
> > > > > > which is much more reasonable. And, thus the transfer works.
> > > > > >
> > > > > > ;
> > > > >
> > > > > --
> > > > > 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
>
>
--
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
executable statement in app();, which is around 0x4158. OK, so what
goes on between 0x4000 and 0x4158? Vector mapping, etc??
I will post it, but not at my workstation again for a couple of hours.
Also, one omitted point (and we all love those, but I just thought of
it). The binary file has 00 00 40 00 00 00 as the first 6 bytes in the
file, which looks like a load location of 0x4000 somehow after the Keil
compile. After a load from JTAG (which runs perfect), the first 6 bytes
starting at 0x4000 are mapped to the SD card file byte number 6. Bytes
0-5, the ones listed above, are not in the code space. So, what I did
was omit those when loading and start with byte 6 in my upload to CPU
RAM (then onto CPU flash). That way the after the upload, the code
matches exactly to what the JTAG code looked like.
I've even tried uploading a simple app like blinking an LED on my board,
but still doesn't work.
Miguel Angel wrote:
>
>
> 2009/8/20 Sutton Mehaffey > >
> >
> >
> >
> > No mallocs.
> >
> > See the Startup code a few posts back for the stack/heap setup. It's
> > whatever the default Keil setup is for the LPC2148.
> > !!!!!! Then the crash is happening at >=0x4000, not <0x4000 as you told me
> some mails ago..... :
>
> """""
> >> The crash happens in the bootloader as it's trying to transfer control
> >> to 0x00004000. The app code never gets started.
> """""
>
> Could you* please post the .lst or binary *of your app to check the first
> instructions?
>
> It's failing at startup of your binary image. If it's working when you flash
> using JTAG, then I start to think that your flashing it's not working
> correctly,
> .....
>
> > The first 'Step' thru the assembly code following app() puts me at
> > 0x00004000. So, the call is working. But, there is obviously some
> > setup code following 0x4000 that eventually causes the crash before it
> > gets to the first app() executable statement which is somewhere around
> > 0x4158. I think that pointer to 0x2CB98 has something to do with it,
> > but don't know where that value is coming from. See the post a few back
> > to see that statement.
> >
> > Miguel Angel wrote:
> > >
> > >
> > > Hmmm I see,
> > >
> > > It really looks like an stack corruption problem. What's the setup of
> > > your stack/heap/bss ?
> > >
> > > Do you use mallocs in your bootloader code?
> > >
> > > May be just changing the call to 0x4000 with assembler code
> > > would fix it, but if it's an stack problem, then it could arise at any
> other
> > > time, making the bootloader crash in some other situation. It's better
> > > to fix the problem from roots.
> > >
> > > Try this, as a "patch", but the stack problem should be fixed:
> > >
> > > __asm {
> > >
> > > LDR R0,=0x4000 <--- if this one doesn't compile try MOV
> > > R0,#0x4000
> > > MOV LR,PC
> > > BX R0
> > > }
> > >
> > > 2009/8/20 Sutton Mehaffey >
> > >
>
> >>
> > >
> > > >
> > > >
> > > > I'll post in a little bit.
> > > >
> > > > The crash happens in the bootloader as it's trying to transfer
> control
> > > > to 0x00004000. The app code never gets started.
> > > >
> > > > It's a stack problem, I'm sure. The debugger gets to 'app();', which
> is
> > > > a pointer to address 0x00004000 (which is the last statement in the
> > > > bootloader), but never gets to the first line in the app code. If you
> > > > follow the assembly code from 'app()', I assume that things are
> saved,
> > > > the stack is setup for a transfer, and that's where the crash
> happens.
> > > >
> > > >
> > > > Miguel Angel wrote:
> > > > >
> > > > >
> > > > > 2009/8/20 Sutton Mehaffey >
> > >
>
> >
> > > > >
> > >
>
>
> > > > >>
> > > >
> > > > > > By the way, to answer Miguel's question. I know where the crash
> > > occurs.
> > > > > > Here's what happens. In tracing thru the assembly code when
> executing
> > > > > > 'app()' (on the bad transfer), which transfers execution to
> > > 0x00004000,
> > > > > > there is a statement:
> > > > >
> > > > > I don't understand:
> > > > >
> > > > > The crash happens in the bootloader, just before calling your app?
> > > > (0x000000
> > > > > - 0x3fff)
> > > > > or inside your app? (0x4000 - ....)
> > > > >
> > > > > >
> > > > > > E8BA000F LDMIA R10!,(R0-R3) that changes R3 to 0x2CB88 and 4
> lines
> > > > >
> > > > > this is a pop from stack
> > > > >
> > > > > > down this register is used in BX R3 as a branch. This is a bogus
> > > > > > location that is causing the eventual crash.
> > > > >
> > > > > and this is a "return", I suppose
> > > > >
> > > > > It's possible for you to post a .lst file (or .S output file) just
> > > in the
> > > > > part that's crashing?
> > > > >
> > > > > and a .map file?
> > > > >
> > > > > >
> > > > > > In the 'good transfer', this statement causes R3 to be set to
> 0x4158,
> > > > > > which is much more reasonable. And, thus the transfer works.
> > > > > >
> > > > > > ;
> > > > >
> > > > > --
> > > > > 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
>
>
--
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
