I have a firmware upload feature that works most of the time (SD card to
Serial Flash to CPU Flash). It still fails occasionally, however.
I have noticed that the binary file that is created by the ELF tool
(which is loaded onto the SD card) is NOT the same as the code loaded by
Keil uVision thru the JTAG. It differs at the very end of the code
space (up around 3BE00) for the last bit of code. About the last 150
bytes are different. If it fails, I have a compare code routine in the
bootloader that verifies that the CPU code matches the Serial Flash
code. When I reload from the JTAG, the code starts working again, but
the last 150 or so bytes of code are different, according to my compare
code routine.
I'm using the 256K version of the Keil compiler. If my code size gets
really close to this 256K boundary (say within 4000 bytes), my
bootloader hangs after a firmware upload. If there is room at the end
of the code space, it seems to work fine. However, it still says the
CPU code doesn't match the Serial Flash code after a JTAG upload.
My main question for now is why is the JTAG uploaded code different from
the binary ELF code, but only the last few bytes? That might answer the
question of why it fails when the code is close to the boundary. By the
way, the memory map shows nothing up in the area where the code is
different.
Sutton
--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
Back to the SD card uploading firmware issue - LPC2148
Started by ●October 11, 2011
Reply by ●October 11, 20112011-10-11
--- In l..., Sutton Mehaffey wrote:
>
> I have a firmware upload feature that works most of the time (SD card to
> Serial Flash to CPU Flash). It still fails occasionally, however.
>
> I have noticed that the binary file that is created by the ELF tool
> (which is loaded onto the SD card) is NOT the same as the code loaded by
> Keil uVision thru the JTAG. It differs at the very end of the code
> space (up around 3BE00) for the last bit of code. About the last 150
> bytes are different. If it fails, I have a compare code routine in the
> bootloader that verifies that the CPU code matches the Serial Flash
> code. When I reload from the JTAG, the code starts working again, but
> the last 150 or so bytes of code are different, according to my compare
> code routine.
>
> I'm using the 256K version of the Keil compiler. If my code size gets
> really close to this 256K boundary (say within 4000 bytes), my
> bootloader hangs after a firmware upload. If there is room at the end
> of the code space, it seems to work fine. However, it still says the
> CPU code doesn't match the Serial Flash code after a JTAG upload.
>
> My main question for now is why is the JTAG uploaded code different from
> the binary ELF code, but only the last few bytes? That might answer the
> question of why it fails when the code is close to the boundary. By the
> way, the memory map shows nothing up in the area where the code is
> different.
>
> Sutton
>
> --
> Sutton Mehaffey
> Lookout Portable Security
> 4040 Royal Dr.
> Kennesaw, GA 30144
> 770-514-7999, 800-207-6269
> Fax: 770-514-1285
> http://www.lookoutportablesecurity.com
> sutton@...
>
I think the values for initialized RAM are located at the far end of the flash image. Any chance the elf tool isn't including that segment of memory?
Richard
>
> I have a firmware upload feature that works most of the time (SD card to
> Serial Flash to CPU Flash). It still fails occasionally, however.
>
> I have noticed that the binary file that is created by the ELF tool
> (which is loaded onto the SD card) is NOT the same as the code loaded by
> Keil uVision thru the JTAG. It differs at the very end of the code
> space (up around 3BE00) for the last bit of code. About the last 150
> bytes are different. If it fails, I have a compare code routine in the
> bootloader that verifies that the CPU code matches the Serial Flash
> code. When I reload from the JTAG, the code starts working again, but
> the last 150 or so bytes of code are different, according to my compare
> code routine.
>
> I'm using the 256K version of the Keil compiler. If my code size gets
> really close to this 256K boundary (say within 4000 bytes), my
> bootloader hangs after a firmware upload. If there is room at the end
> of the code space, it seems to work fine. However, it still says the
> CPU code doesn't match the Serial Flash code after a JTAG upload.
>
> My main question for now is why is the JTAG uploaded code different from
> the binary ELF code, but only the last few bytes? That might answer the
> question of why it fails when the code is close to the boundary. By the
> way, the memory map shows nothing up in the area where the code is
> different.
>
> Sutton
>
> --
> Sutton Mehaffey
> Lookout Portable Security
> 4040 Royal Dr.
> Kennesaw, GA 30144
> 770-514-7999, 800-207-6269
> Fax: 770-514-1285
> http://www.lookoutportablesecurity.com
> sutton@...
>
I think the values for initialized RAM are located at the far end of the flash image. Any chance the elf tool isn't including that segment of memory?
Richard
Reply by ●October 11, 20112011-10-11
I thought RAM was up at 0x40000000. At the high end of the code space
is the remapped bootloader. Much higher than my code space. Is your
suspicion different than these?
Sutotn
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
On 10/11/2011 6:34 PM, rtstofer wrote:
>
> --- In l... ,
> Sutton Mehaffey wrote:
> >
> > I have a firmware upload feature that works most of the time (SD
> card to
> > Serial Flash to CPU Flash). It still fails occasionally, however.
> >
> > I have noticed that the binary file that is created by the ELF tool
> > (which is loaded onto the SD card) is NOT the same as the code
> loaded by
> > Keil uVision thru the JTAG. It differs at the very end of the code
> > space (up around 3BE00) for the last bit of code. About the last 150
> > bytes are different. If it fails, I have a compare code routine in the
> > bootloader that verifies that the CPU code matches the Serial Flash
> > code. When I reload from the JTAG, the code starts working again, but
> > the last 150 or so bytes of code are different, according to my compare
> > code routine.
> >
> > I'm using the 256K version of the Keil compiler. If my code size gets
> > really close to this 256K boundary (say within 4000 bytes), my
> > bootloader hangs after a firmware upload. If there is room at the end
> > of the code space, it seems to work fine. However, it still says the
> > CPU code doesn't match the Serial Flash code after a JTAG upload.
> >
> > My main question for now is why is the JTAG uploaded code different
> from
> > the binary ELF code, but only the last few bytes? That might answer the
> > question of why it fails when the code is close to the boundary. By the
> > way, the memory map shows nothing up in the area where the code is
> > different.
> >
> > Sutton
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr.
> > Kennesaw, GA 30144
> > 770-514-7999, 800-207-6269
> > Fax: 770-514-1285
> > http://www.lookoutportablesecurity.com
> > sutton@...
> > I think the values for initialized RAM are located at the far end of
> the flash image. Any chance the elf tool isn't including that segment
> of memory?
>
> Richard
is the remapped bootloader. Much higher than my code space. Is your
suspicion different than these?
Sutotn
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
On 10/11/2011 6:34 PM, rtstofer wrote:
>
> --- In l... ,
> Sutton Mehaffey wrote:
> >
> > I have a firmware upload feature that works most of the time (SD
> card to
> > Serial Flash to CPU Flash). It still fails occasionally, however.
> >
> > I have noticed that the binary file that is created by the ELF tool
> > (which is loaded onto the SD card) is NOT the same as the code
> loaded by
> > Keil uVision thru the JTAG. It differs at the very end of the code
> > space (up around 3BE00) for the last bit of code. About the last 150
> > bytes are different. If it fails, I have a compare code routine in the
> > bootloader that verifies that the CPU code matches the Serial Flash
> > code. When I reload from the JTAG, the code starts working again, but
> > the last 150 or so bytes of code are different, according to my compare
> > code routine.
> >
> > I'm using the 256K version of the Keil compiler. If my code size gets
> > really close to this 256K boundary (say within 4000 bytes), my
> > bootloader hangs after a firmware upload. If there is room at the end
> > of the code space, it seems to work fine. However, it still says the
> > CPU code doesn't match the Serial Flash code after a JTAG upload.
> >
> > My main question for now is why is the JTAG uploaded code different
> from
> > the binary ELF code, but only the last few bytes? That might answer the
> > question of why it fails when the code is close to the boundary. By the
> > way, the memory map shows nothing up in the area where the code is
> > different.
> >
> > Sutton
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr.
> > Kennesaw, GA 30144
> > 770-514-7999, 800-207-6269
> > Fax: 770-514-1285
> > http://www.lookoutportablesecurity.com
> > sutton@...
> > I think the values for initialized RAM are located at the far end of
> the flash image. Any chance the elf tool isn't including that segment
> of memory?
>
> Richard
Reply by ●October 12, 20112011-10-12
I believe he is talking about the global initialization block. If you
declare a global that is initialized, then it is put into the data
segment, and there is an initialization block for these values in
flash. This would be located outside of your code.
Mike
-----Original Message-----
From: l... [mailto:l...]On Behalf
Of Sutton Mehaffey
Sent: Tuesday, October 11, 2011 6:03 PM
To: l...
Cc: rtstofer
Subject: Re: [lpc2000] Re: Back to the SD card uploading firmware issue
- LPC2148
I thought RAM was up at 0x40000000. At the high end of the code space
is the remapped bootloader. Much higher than my code space. Is your
suspicion different than these?
Sutotn
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
On 10/11/2011 6:34 PM, rtstofer wrote:
>
> --- In l... ,
> Sutton Mehaffey wrote:
> >
> > I have a firmware upload feature that works most of the time (SD
> card to
> > Serial Flash to CPU Flash). It still fails occasionally, however.
> >
> > I have noticed that the binary file that is created by the ELF tool
> > (which is loaded onto the SD card) is NOT the same as the code
> loaded by
> > Keil uVision thru the JTAG. It differs at the very end of the code
> > space (up around 3BE00) for the last bit of code. About the last 150
> > bytes are different. If it fails, I have a compare code routine in the
> > bootloader that verifies that the CPU code matches the Serial Flash
> > code. When I reload from the JTAG, the code starts working again, but
> > the last 150 or so bytes of code are different, according to my compare
> > code routine.
> >
> > I'm using the 256K version of the Keil compiler. If my code size gets
> > really close to this 256K boundary (say within 4000 bytes), my
> > bootloader hangs after a firmware upload. If there is room at the end
> > of the code space, it seems to work fine. However, it still says the
> > CPU code doesn't match the Serial Flash code after a JTAG upload.
> >
> > My main question for now is why is the JTAG uploaded code different
> from
> > the binary ELF code, but only the last few bytes? That might answer the
> > question of why it fails when the code is close to the boundary. By the
> > way, the memory map shows nothing up in the area where the code is
> > different.
> >
> > Sutton
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr.
> > Kennesaw, GA 30144
> > 770-514-7999, 800-207-6269
> > Fax: 770-514-1285
> > http://www.lookoutportablesecurity.com
> > sutton@...
> > I think the values for initialized RAM are located at the far end of
> the flash image. Any chance the elf tool isn't including that segment
> of memory?
>
> Richard
declare a global that is initialized, then it is put into the data
segment, and there is an initialization block for these values in
flash. This would be located outside of your code.
Mike
-----Original Message-----
From: l... [mailto:l...]On Behalf
Of Sutton Mehaffey
Sent: Tuesday, October 11, 2011 6:03 PM
To: l...
Cc: rtstofer
Subject: Re: [lpc2000] Re: Back to the SD card uploading firmware issue
- LPC2148
I thought RAM was up at 0x40000000. At the high end of the code space
is the remapped bootloader. Much higher than my code space. Is your
suspicion different than these?
Sutotn
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
On 10/11/2011 6:34 PM, rtstofer wrote:
>
> --- In l... ,
> Sutton Mehaffey wrote:
> >
> > I have a firmware upload feature that works most of the time (SD
> card to
> > Serial Flash to CPU Flash). It still fails occasionally, however.
> >
> > I have noticed that the binary file that is created by the ELF tool
> > (which is loaded onto the SD card) is NOT the same as the code
> loaded by
> > Keil uVision thru the JTAG. It differs at the very end of the code
> > space (up around 3BE00) for the last bit of code. About the last 150
> > bytes are different. If it fails, I have a compare code routine in the
> > bootloader that verifies that the CPU code matches the Serial Flash
> > code. When I reload from the JTAG, the code starts working again, but
> > the last 150 or so bytes of code are different, according to my compare
> > code routine.
> >
> > I'm using the 256K version of the Keil compiler. If my code size gets
> > really close to this 256K boundary (say within 4000 bytes), my
> > bootloader hangs after a firmware upload. If there is room at the end
> > of the code space, it seems to work fine. However, it still says the
> > CPU code doesn't match the Serial Flash code after a JTAG upload.
> >
> > My main question for now is why is the JTAG uploaded code different
> from
> > the binary ELF code, but only the last few bytes? That might answer the
> > question of why it fails when the code is close to the boundary. By the
> > way, the memory map shows nothing up in the area where the code is
> > different.
> >
> > Sutton
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr.
> > Kennesaw, GA 30144
> > 770-514-7999, 800-207-6269
> > Fax: 770-514-1285
> > http://www.lookoutportablesecurity.com
> > sutton@...
> > I think the values for initialized RAM are located at the far end of
> the flash image. Any chance the elf tool isn't including that segment
> of memory?
>
> Richard
Reply by ●October 12, 20112011-10-12
Where is the initialization block located?
Here's what I'm up against. My compiled Keil code shows:
Program Size: Code!2388 RO-data%76 RW-data%36 ZI-data800
After running ELF on the AXF file, it produces a binary of size 216876
(0x34f2c). So obviously, there is a difference. If I upload the binary
file from SD card to CPU Flash, it loads exactly the 216876 bytes in the
SD card file. If I load the same code from the JTAG, the code space
ends at 0x34dcc, which is 320 bytes difference. I'm trying to figure
out why the difference and what these 320 bytes actually are. I haven't
figured it out yet. The memory map shows nothing up at this end of the
code space.
I am having issues of sometimes the uploaded code not restarting
correctly. Right now it's working fine, but if I add something
insignificant to the code, it may stop restarting correctly. So, I'm
trying to start with finding out the differences in the SD card code and
the JTAG uploaded code. Maybe, by understanding that, I can narrow it
down better.
Maybe that's a Keil question.
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
On 10/12/2011 2:32 AM, Michael Anton wrote:
>
> I believe he is talking about the global initialization block. If you
> declare a global that is initialized, then it is put into the data
> segment, and there is an initialization block for these values in
> flash. This would be located outside of your code.
>
> Mike
>
> -----Original Message-----
> From: l...
> [mailto:l... ]On
> Behalf
> Of Sutton Mehaffey
> Sent: Tuesday, October 11, 2011 6:03 PM
> To: l...
> Cc: rtstofer
> Subject: Re: [lpc2000] Re: Back to the SD card uploading firmware issue
> - LPC2148
>
> I thought RAM was up at 0x40000000. At the high end of the code space
> is the remapped bootloader. Much higher than my code space. Is your
> suspicion different than these?
>
> Sutotn
>
> 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
> On 10/11/2011 6:34 PM, rtstofer wrote:
> >
> >
> >
> > --- In l...
> ,
> > Sutton Mehaffey wrote:
> > >
> > > I have a firmware upload feature that works most of the time (SD
> > card to
> > > Serial Flash to CPU Flash). It still fails occasionally, however.
> > >
> > > I have noticed that the binary file that is created by the ELF tool
> > > (which is loaded onto the SD card) is NOT the same as the code
> > loaded by
> > > Keil uVision thru the JTAG. It differs at the very end of the code
> > > space (up around 3BE00) for the last bit of code. About the last 150
> > > bytes are different. If it fails, I have a compare code routine in the
> > > bootloader that verifies that the CPU code matches the Serial Flash
> > > code. When I reload from the JTAG, the code starts working again, but
> > > the last 150 or so bytes of code are different, according to my
> compare
> > > code routine.
> > >
> > > I'm using the 256K version of the Keil compiler. If my code size gets
> > > really close to this 256K boundary (say within 4000 bytes), my
> > > bootloader hangs after a firmware upload. If there is room at the end
> > > of the code space, it seems to work fine. However, it still says the
> > > CPU code doesn't match the Serial Flash code after a JTAG upload.
> > >
> > > My main question for now is why is the JTAG uploaded code different
> > from
> > > the binary ELF code, but only the last few bytes? That might
> answer the
> > > question of why it fails when the code is close to the boundary.
> By the
> > > way, the memory map shows nothing up in the area where the code is
> > > different.
> > >
> > > Sutton
> > >
> > > --
> > > Sutton Mehaffey
> > > Lookout Portable Security
> > > 4040 Royal Dr.
> > > Kennesaw, GA 30144
> > > 770-514-7999, 800-207-6269
> > > Fax: 770-514-1285
> > > http://www.lookoutportablesecurity.com
> > > sutton@...
> > >
> >
> > I think the values for initialized RAM are located at the far end of
> > the flash image. Any chance the elf tool isn't including that segment
> > of memory?
> >
> > Richard
> >
> >
>
>
Here's what I'm up against. My compiled Keil code shows:
Program Size: Code!2388 RO-data%76 RW-data%36 ZI-data800
After running ELF on the AXF file, it produces a binary of size 216876
(0x34f2c). So obviously, there is a difference. If I upload the binary
file from SD card to CPU Flash, it loads exactly the 216876 bytes in the
SD card file. If I load the same code from the JTAG, the code space
ends at 0x34dcc, which is 320 bytes difference. I'm trying to figure
out why the difference and what these 320 bytes actually are. I haven't
figured it out yet. The memory map shows nothing up at this end of the
code space.
I am having issues of sometimes the uploaded code not restarting
correctly. Right now it's working fine, but if I add something
insignificant to the code, it may stop restarting correctly. So, I'm
trying to start with finding out the differences in the SD card code and
the JTAG uploaded code. Maybe, by understanding that, I can narrow it
down better.
Maybe that's a Keil question.
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
On 10/12/2011 2:32 AM, Michael Anton wrote:
>
> I believe he is talking about the global initialization block. If you
> declare a global that is initialized, then it is put into the data
> segment, and there is an initialization block for these values in
> flash. This would be located outside of your code.
>
> Mike
>
> -----Original Message-----
> From: l...
> [mailto:l... ]On
> Behalf
> Of Sutton Mehaffey
> Sent: Tuesday, October 11, 2011 6:03 PM
> To: l...
> Cc: rtstofer
> Subject: Re: [lpc2000] Re: Back to the SD card uploading firmware issue
> - LPC2148
>
> I thought RAM was up at 0x40000000. At the high end of the code space
> is the remapped bootloader. Much higher than my code space. Is your
> suspicion different than these?
>
> Sutotn
>
> 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
> On 10/11/2011 6:34 PM, rtstofer wrote:
> >
> >
> >
> > --- In l...
> ,
> > Sutton Mehaffey wrote:
> > >
> > > I have a firmware upload feature that works most of the time (SD
> > card to
> > > Serial Flash to CPU Flash). It still fails occasionally, however.
> > >
> > > I have noticed that the binary file that is created by the ELF tool
> > > (which is loaded onto the SD card) is NOT the same as the code
> > loaded by
> > > Keil uVision thru the JTAG. It differs at the very end of the code
> > > space (up around 3BE00) for the last bit of code. About the last 150
> > > bytes are different. If it fails, I have a compare code routine in the
> > > bootloader that verifies that the CPU code matches the Serial Flash
> > > code. When I reload from the JTAG, the code starts working again, but
> > > the last 150 or so bytes of code are different, according to my
> compare
> > > code routine.
> > >
> > > I'm using the 256K version of the Keil compiler. If my code size gets
> > > really close to this 256K boundary (say within 4000 bytes), my
> > > bootloader hangs after a firmware upload. If there is room at the end
> > > of the code space, it seems to work fine. However, it still says the
> > > CPU code doesn't match the Serial Flash code after a JTAG upload.
> > >
> > > My main question for now is why is the JTAG uploaded code different
> > from
> > > the binary ELF code, but only the last few bytes? That might
> answer the
> > > question of why it fails when the code is close to the boundary.
> By the
> > > way, the memory map shows nothing up in the area where the code is
> > > different.
> > >
> > > Sutton
> > >
> > > --
> > > Sutton Mehaffey
> > > Lookout Portable Security
> > > 4040 Royal Dr.
> > > Kennesaw, GA 30144
> > > 770-514-7999, 800-207-6269
> > > Fax: 770-514-1285
> > > http://www.lookoutportablesecurity.com
> > > sutton@...
> > >
> >
> > I think the values for initialized RAM are located at the far end of
> > the flash image. Any chance the elf tool isn't including that segment
> > of memory?
> >
> > Richard
> >
> >
>
>
Reply by ●October 28, 20112011-10-28
I've made some progress on my DAbt_Handler exception from my SD card
firmware upgrade, but still haven't figured out the problem. Maybe one
of you assembly experts might have a clue. I think it's a stack issue
of some sort.
I've discovered that after my firmware upgrade, the bootloader does in
fact transfer control to 0x5000, which is where my app is located.
However, it loops in the startup code until there is a DAbt_Handler
exception. Apparently, it is trying to access RAM above my limit, but I
don't know why. I know this because at the time of the crash, R1 is
0x40008000. My RAM limit is 0x40000000-0x40007fff. Don't know why it
is accessing up that high, because my data space is not even close to up
there. There is a compare of R1 and R2, in which R2 is always
0x40000D98 (or somewhere close to that). R1 starts at 0x40000000 and
runs through some assembly statements (adding to R1) and comparing them
to R2. For some reason, it never compares EQUAL and keeps going up to
0x40008000.
On a good transfer, the compare happens successfully and it jumps to
main() and works. If I reload the same code via JTAG, it starts working
again. I traced the compare of R1 and R2 successfully, and it jumped to
main.
I have 2 separate startup files, one for the bootloader and one for the
app. They are essentially the same. The only difference is that the
Vectors are placed in different places. However, the startup code never
changes, but the automatic binary reflash for some reason sometimes
causes this weird behavior in the startup code. I do use the same RAM
space for both the bootloader and app, since each does not access the other.
Any ideas? I can post the startup code, if need be. I know the code in
the Keil debugger where the looping occurs until either a successful
compare or a crash, but I'm not too savvy in assembly, and haven't
figured out which part of the startup code is the culprit.
Sutton
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
On 10/11/2011 6:34 PM, rtstofer wrote:
>
> --- In l... ,
> Sutton Mehaffey wrote:
> >
> > I have a firmware upload feature that works most of the time (SD
> card to
> > Serial Flash to CPU Flash). It still fails occasionally, however.
> >
> > I have noticed that the binary file that is created by the ELF tool
> > (which is loaded onto the SD card) is NOT the same as the code
> loaded by
> > Keil uVision thru the JTAG. It differs at the very end of the code
> > space (up around 3BE00) for the last bit of code. About the last 150
> > bytes are different. If it fails, I have a compare code routine in the
> > bootloader that verifies that the CPU code matches the Serial Flash
> > code. When I reload from the JTAG, the code starts working again, but
> > the last 150 or so bytes of code are different, according to my compare
> > code routine.
> >
> > I'm using the 256K version of the Keil compiler. If my code size gets
> > really close to this 256K boundary (say within 4000 bytes), my
> > bootloader hangs after a firmware upload. If there is room at the end
> > of the code space, it seems to work fine. However, it still says the
> > CPU code doesn't match the Serial Flash code after a JTAG upload.
> >
> > My main question for now is why is the JTAG uploaded code different
> from
> > the binary ELF code, but only the last few bytes? That might answer the
> > question of why it fails when the code is close to the boundary. By the
> > way, the memory map shows nothing up in the area where the code is
> > different.
> >
> > Sutton
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr.
> > Kennesaw, GA 30144
> > 770-514-7999, 800-207-6269
> > Fax: 770-514-1285
> > http://www.lookoutportablesecurity.com
> > sutton@...
> > I think the values for initialized RAM are located at the far end of
> the flash image. Any chance the elf tool isn't including that segment
> of memory?
>
> Richard
firmware upgrade, but still haven't figured out the problem. Maybe one
of you assembly experts might have a clue. I think it's a stack issue
of some sort.
I've discovered that after my firmware upgrade, the bootloader does in
fact transfer control to 0x5000, which is where my app is located.
However, it loops in the startup code until there is a DAbt_Handler
exception. Apparently, it is trying to access RAM above my limit, but I
don't know why. I know this because at the time of the crash, R1 is
0x40008000. My RAM limit is 0x40000000-0x40007fff. Don't know why it
is accessing up that high, because my data space is not even close to up
there. There is a compare of R1 and R2, in which R2 is always
0x40000D98 (or somewhere close to that). R1 starts at 0x40000000 and
runs through some assembly statements (adding to R1) and comparing them
to R2. For some reason, it never compares EQUAL and keeps going up to
0x40008000.
On a good transfer, the compare happens successfully and it jumps to
main() and works. If I reload the same code via JTAG, it starts working
again. I traced the compare of R1 and R2 successfully, and it jumped to
main.
I have 2 separate startup files, one for the bootloader and one for the
app. They are essentially the same. The only difference is that the
Vectors are placed in different places. However, the startup code never
changes, but the automatic binary reflash for some reason sometimes
causes this weird behavior in the startup code. I do use the same RAM
space for both the bootloader and app, since each does not access the other.
Any ideas? I can post the startup code, if need be. I know the code in
the Keil debugger where the looping occurs until either a successful
compare or a crash, but I'm not too savvy in assembly, and haven't
figured out which part of the startup code is the culprit.
Sutton
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
On 10/11/2011 6:34 PM, rtstofer wrote:
>
> --- In l... ,
> Sutton Mehaffey wrote:
> >
> > I have a firmware upload feature that works most of the time (SD
> card to
> > Serial Flash to CPU Flash). It still fails occasionally, however.
> >
> > I have noticed that the binary file that is created by the ELF tool
> > (which is loaded onto the SD card) is NOT the same as the code
> loaded by
> > Keil uVision thru the JTAG. It differs at the very end of the code
> > space (up around 3BE00) for the last bit of code. About the last 150
> > bytes are different. If it fails, I have a compare code routine in the
> > bootloader that verifies that the CPU code matches the Serial Flash
> > code. When I reload from the JTAG, the code starts working again, but
> > the last 150 or so bytes of code are different, according to my compare
> > code routine.
> >
> > I'm using the 256K version of the Keil compiler. If my code size gets
> > really close to this 256K boundary (say within 4000 bytes), my
> > bootloader hangs after a firmware upload. If there is room at the end
> > of the code space, it seems to work fine. However, it still says the
> > CPU code doesn't match the Serial Flash code after a JTAG upload.
> >
> > My main question for now is why is the JTAG uploaded code different
> from
> > the binary ELF code, but only the last few bytes? That might answer the
> > question of why it fails when the code is close to the boundary. By the
> > way, the memory map shows nothing up in the area where the code is
> > different.
> >
> > Sutton
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr.
> > Kennesaw, GA 30144
> > 770-514-7999, 800-207-6269
> > Fax: 770-514-1285
> > http://www.lookoutportablesecurity.com
> > sutton@...
> > I think the values for initialized RAM are located at the far end of
> the flash image. Any chance the elf tool isn't including that segment
> of memory?
>
> Richard
