Other thing that can be problematic when calling IAP is that it needs some
bytes
at base of ram 0x40000000 for working. It should be reserved.

I don't remember the exact location, but I think you should change the
target RAM base
when dealing with IAP calls.
2009/8/20 42Bastian

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

--
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo


Start a New Thread

Please explain. Are you talking about in Startup?

42Bastian wrote:
>
>
> 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@...

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

http://www.koders.com/noncode/fid96F9BDDD9E7BD89E2F155E052A80EDD542344038.aspx?s=%22Jim+Lynch%22

No, sorry, it's at the top of ram

/* | |0x40008000
*/
/* .-------->|---------------------------------|
*/
/* . | variables
and
stack |0x40007FFF
*/
/* ram_isp_high |
for Philips
boot
loader |
*/
/* . | 32 + 256 = 288 bytes
|
*/
/* . | |
*/
/* . | Do not
put
anything here
|0x40007EE0

I see this in your startup.S , but not the Stack_Top definition
LDR R0, =Stack_Top

could you check that stack_top is < 0x40007EE0 , IAP should be corrupting
your stack for sure.
2009/8/20 Miguel Angel

> Other thing that can be problematic when calling IAP is that it needs some
> bytes
> at base of ram 0x40000000 for working. It should be reserved.
>
> I don't remember the exact location, but I think you should change the
> target RAM base
> when dealing with IAP calls.
> 2009/8/20 42Bastian
>>
>> 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@...
>>
>> --
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 91 120 1798
> +34 636 52 25 69
> skype: ajoajoajo
>

--
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo


Start a New Thread

Hi:

Could you post the two .map files generated by Keil uVision? (One for the bootloader and other for the main application)

To enable the .map generation, check the Linker Listing and Memory Map checkboxes in the Listing Tab of the Project->Options for Target
menu.

Regards,

Alex

--- In l..., Sutton Mehaffey wrote:
>
> 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
> >
> > > > > > >
> > > > > sutton@...
> >
> > > >
> >
> > >
> > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > 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
> >
> > > sutton@...
> >
> > >
> > >
> >
> > --
> > 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
> sutton@...
>
Start a New Thread

--- In l..., Sutton Mehaffey wrote:
>
> 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??
It's your code, what do you think it is doing? Among other things there MUST be a complete boot.s (or whatever it's called) at 0x4000 to initialize the app memory space. Things like the .data segment. This code is also responsible for reinitializing the stacks. It makes no difference how the stacks were set by the bootloader, it isn't running.
>
> 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.
In other words, your binary load file is NOT a binary image of your application. If there are extraneous bytes it is because the image is for some kind of loader. Maybe the Keil loader massages the file.
>
> I've even tried uploading a simple app like blinking an LED on my board,
> but still doesn't work.
Since you don't know what your toolchain is doing, why are you using it? Change to a toolchain that doesn't do anything. Like GNU...

That way you will know exactly where the code is going because you put it there with the linker script. You will know that the app() memory is getting initialized in the boot.s associated with the app because you will write the boot.s. You won't be wondering why there is a pop instruction because you won't have put it there. And so on...

Sometimes you just need a bigger hammer.

Richard
Start a New Thread

I hope he's putting a .bin and not a .elf or .axd image ':D :)

I think keil can convert to .bin images.

elf2bin ?

2009/8/20 rtstofer

> --- In l... , Sutton
> Mehaffey wrote:
> >
> > 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??
>
> It's your code, what do you think it is doing? Among other things there
> MUST be a complete boot.s (or whatever it's called) at 0x4000 to initialize
> the app memory space. Things like the .data segment. This code is also
> responsible for reinitializing the stacks. It makes no difference how the
> stacks were set by the bootloader, it isn't running.
>
> >
> > 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.
>
> In other words, your binary load file is NOT a binary image of your
> application. If there are extraneous bytes it is because the image is for
> some kind of loader. Maybe the Keil loader massages the file.
>
> >
> > I've even tried uploading a simple app like blinking an LED on my board,
> > but still doesn't work.
>
> Since you don't know what your toolchain is doing, why are you using it?
> Change to a toolchain that doesn't do anything. Like GNU...
>
> That way you will know exactly where the code is going because you put it
> there with the linker script. You will know that the app() memory is getting
> initialized in the boot.s associated with the app because you will write the
> boot.s. You won't be wondering why there is a pop instruction because you
> won't have put it there. And so on...
>
> Sometimes you just need a bigger hammer.
>
> Richard
>
>
>

--
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo


Start a New Thread

If it were me, I would use a .hex, even if it is bigger, as the
format is well defined.
Quoting Miguel Angel :

> I hope he's putting a .bin and not a .elf or .axd image ':D :)
>
> I think keil can convert to .bin images.
>
> elf2bin ?
>
> 2009/8/20 rtstofer > --- In l... , Sutton
>> Mehaffey wrote:
>> >
>> > 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??
>>
>> It's your code, what do you think it is doing? Among other things there
>> MUST be a complete boot.s (or whatever it's called) at 0x4000 to initialize
>> the app memory space. Things like the .data segment. This code is also
>> responsible for reinitializing the stacks. It makes no difference how the
>> stacks were set by the bootloader, it isn't running.
>>
>> >
>> > 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.
>>
>> In other words, your binary load file is NOT a binary image of your
>> application. If there are extraneous bytes it is because the image is for
>> some kind of loader. Maybe the Keil loader massages the file.
>>
>> >
>> > I've even tried uploading a simple app like blinking an LED on my board,
>> > but still doesn't work.
>>
>> Since you don't know what your toolchain is doing, why are you using it?
>> Change to a toolchain that doesn't do anything. Like GNU...
>>
>> That way you will know exactly where the code is going because you put it
>> there with the linker script. You will know that the app() memory is getting
>> initialized in the boot.s associated with the app because you will write the
>> boot.s. You won't be wondering why there is a pop instruction because you
>> won't have put it there. And so on...
>>
>> Sometimes you just need a bigger hammer.
>>
>> Richard
>> --
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 91 120 1798
> +34 636 52 25 69
> skype: ajoajoajo
>
>
> Start a New Thread

Sutton Mehaffey schrieb:
> Please explain. Are you talking about in Startup?

Right. The code you posted (running from 0x4000) sets up RAM,PINSEL and PLL.

Did you single step through the startup code ? Be sure to disable all
initialization in the debugger !

--
42Bastian
------------------
Parts of this email are written with invisible ink.

Note: SPAM-only account, direct mail to bs42@...
Start a New Thread

I should'nt be a problem for the part he's using (214x)
At least I'm doing the same thing, (double startup) , and never
had problems appart from having to leave processor in SYS mode instead
of USR mode when leaving the first bootloader.

:-)

2009/8/21 42Bastian

> Sutton Mehaffey schrieb:
>
> > Please explain. Are you talking about in Startup?
>
> Right. The code you posted (running from 0x4000) sets up RAM,PINSEL and
> PLL.
>
> Did you single step through the startup code ? Be sure to disable all
> initialization in the debugger !
>
> --
> 42Bastian
> ------------------
> Parts of this email are written with invisible ink.
>
> Note: SPAM-only account, direct mail to bs42@...
>
>
>

--
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo


Start a New Thread

--- In l..., manton@... wrote:
>
> If it were me, I would use a .hex, even if it is bigger, as the
> format is well defined.
>

Yes - I use S-record files for my update images. I have two banks of code and two fixed sectors at the top of flash, one for each bank, that contains version/CRC/whatever for each bank, so a binary image would mean that blowing bank 'A' would destroy bank 'B' because the 'flat' image from 'A' would cover the range of 'B'. It would also be much slower because all sectors would need to be written in order to reach the sector at the top.

With S-records, (or Intel hex), it's fairly easy to only blow sectors that actually have new code written to them, leaving sectors in 'gaps' alone.

I was never happy with a flat binary image - I rejected the idea very early on. OK, it means a bit of extra code in the bootloader to interpret the records from the file, but it's hardly difficult - as you say 'well defined'.

Rgds,
Martin
Start a New Thread