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
Sorry sutton, I misunderstood your phrase:
"""
If when the code hangs after my SD card upload (the WDT causes a reset,
the bootloader finds that the RAM value is back to 0xA5, meaning valid
code at 0x00004000, and tries to transfer to execution to 0x00004000), I
load the same code thru Keil's JTAG, the transfer works perfectly again.
"""
2009/8/20 Sutton Mehaffey
> Why do you think the image is incomplete? The SD card code matches
> exactly the intermediate serial flash code which matches exactly the CPU
> code at 0x00004000. I have the image length, which is the size of the
> SD card code. I'm not using a checksum, because I check each and every
> byte on 2 occasions to verify. I would think that is enough.
> Miguel Angel wrote:
> >
> >
> > Hmmm,
> >
> > I think the only way you could fix incomplete image uploads is to
> > put more fields on the image "header" inside your startup.s, and, just
> > after compiling the target app, and building the binary use a program
> > in the PC to fill those fields that could be:
> >
> > 1) Image length
> > 2) Image CRC or checksum
> >
> > with those two fields at startup in your bootloader you could
> > check the whole image length for CRC match before jumping into the app,
> > if it doesn't match, then jump into (for example) "wait for SD to get
> > inserted
> > to load a new app, and blink leds"
> >
> > 2009/8/20 Sutton Mehaffey
> >
> >>
> >
> > >
> > >
> > > I actually do in the 'Target' link put my base address at 0x00004000.
> > > That's how the code initially gets transferred from the bootloader to
> > > app correctly. The bootloader (located at 0) transfers execution
> > > perfectly to 0x00004000 before the SD card upload. But, that is loading
> > > the 2 sections of code via Keil's JTAG.
> > >
> > > The problem is that the Keil JTAG does some other programming (that I
> > > haven't figured out) that my upload from SD card doesn't do.
> > >
> > > If when the code hangs after my SD card upload (the WDT causes a reset,
> > > the bootloader finds that the RAM value is back to 0xA5, meaning valid
> > > code at 0x00004000, and tries to transfer to execution to 0x00004000),
> I
> > > load the same code thru Keil's JTAG, the transfer works perfectly
> again.
> > >
> > >
> > > Miguel Angel wrote:
> > > >
> > > >
> > > > Yes, my code will only help if you're using FIQs or SWIs,
> > > >
> > > > For the application binary, alex's comment is quite important, you
> > > > should really set the application code base address to 0x4000 or
> > > > some jump/calls will get bad addresses.
> > > >
> > > > 2009/8/20 Sutton Mehaffey
> >
> >
> > > >
> >
>
> > > >>
> > >
> > > >
> > > > >
> > > > >
> > > > > I must have missed that post. I don't see it in my folder.
> > > > >
> > > > > Anyway, I just tried changing the startup file as per your request
> > > > > (Miguel), and it still doesn't transfer to 0x4000 correctly. It
> hangs
> > > > > after a successful upload, just like before.
> > > > >
> > > >
> > > > >
> > > > > I do use "Memory Layout from Target Dialog", so maybe Alex's
> comment
> > > has
> > > > > some merit. Maybe I need to learn and use the scatter files.
> > > > >
> > > > > Sutton
> > > > >
> > > > >
> > > > > Miguel Angel wrote:
> > > > > >
> > > > > >
> > > > > > Copy & Paste, I already told you (some weeks ago) a way of doing
> it
> > > :)
> > > > > >
> > > > > > This is an example of IRQ pass-thru from my usual bootloader to
> the
> > > > > > application
> > > > > > (that starts at 0x2000): (ARM Assembler format for a 214x/213x
> > > device)
> > > > > > Modify your Startup.s to put the vectors this way:
> > > > > >
> > > > > > Vectors LDR PC, Reset_Addr
> > > > > > LDR PC, Undef_Addr
> > > > > > LDR PC, SWI_Addr
> > > > > > LDR PC, PAbt_Addr
> > > > > > LDR PC, DAbt_Addr
> > > > > > NOP ; Reserved Vector
> > > > > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > > > > LDR PC, FIQ_Addr
> > > > > >
> > > > > > Reset_Addr DCD Reset_Handler
> > > > > > Undef_Addr DCD 0x4004
> > > > > > SWI_Addr DCD 0x4008
> > > > > > PAbt_Addr DCD 0x400C
> > > > > > DAbt_Addr DCD 0x4010
> > > > > > DCD 0 ; Reserved Address
> > > > > > 0x2014
> > > > > > FIQ_Addr DCD 0x401C
> > > > > >
> > > > > > And something important too, is to end the Startup initialization
> > > with:
> > > > > >
> > > > > > MSR CPSR_c, #Mode_SYS (instead of
> > > > > > MSR CPSR_c, #Mode_USR)
> > > > > >
> > > > > > so your app startup can change processor mode again and setup
> > all the
> > > > > mode's
> > > > > > stacks, according
> > > > > > to your app configuration.
> > > > > >
> > > > > > 2009/8/20 Sutton Mehaffey
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >>
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > The code is compiled at 0x00004000, converted to binary and
> > loaded
> > > on
> > > > > > > the SD card. The application always runs at 0x00004000. The
> > > > bootloader
> > > > > > > is never changed in the field and always runs at 0. The first 6
> > > bytes
> > > > > > > of the compiled file hold the 0x00004000. I assume that's how
> > Keil
> > > > > > > knows to locate it at 0x00004000 thru the JTAG.
> > > > > > >
> > > > > > > Where in the startup code do I specify that the vectors starts
> at
> > > > > > > 0x00004000?
> > > > > > >
> > > > > > > typedef void (*APP)(void);
> > > > > > > APP app = (APP)0x00004000;
> > > > > > >
> > > > > > > app();
> > > > > > >
> > > > > > >
> > > > > > > Michael Anton wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > How does your bootloader handle revectoring all of the
> > > interrupts?
> > > > > > > > I don't understand why the vectors located at 0x0004000 would
> > > > be the
> > > > > > > > same as those at 0x00000000, since they are for different
> > > > > applications.
> > > > > > > >
> > > > > > > > Am I to understand that the code on the SD card begins at 0?
> If
> > > so
> > > > > that
> > > > > > > > is not correct, as it should be located at 0x00004000. It
> > > wouldn't
> > > > > make
> > > > > > > > sense to have the vectors in the main application loaded at
> > zero,
> > > > > > unless
> > > > > > > > they would be executed from there. Also, given that the
> startup
> > > > code
> > > > > > > > usually contains the vectors and the startup routines, they
> > > > certainly
> > > > > > > > shouldn't be located at 0.
> > > > > > > >
> > > > > > > > How do you jump to the main app from your bootloader?
> > > > > > > >
> > > > > > > > This would all me much easier for us to figure out if we
> > had the
> > > > > > > > relevant bits of code.
> > > > > > > >
> > > > > > > > Mike
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: l...
> > >
>
> > > > > 2540yahoogroups.com>>
> > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > [mailto:l...
> > >
>
> > > > > 2540yahoogroups.com>>
> > >
> > > > > >
> > >
> > > 2540yahoogroups.com>>
> > > > > > > > > > > > lpc2000%40yahoogroups.com >]On
> > > > > > > > Behalf
> > > > > > > > > Of Sutton Mehaffey
> > > > > > > > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > > > > > > > To: l...
> > >
>
> > > > > 2540yahoogroups.com>>
> > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > >
> > > > > > > > > Subject: Re: [lpc2000] Re: new SD code transfer to
> > LPC2148 not
> > > > > quite
> > > > > > > > > working
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I have a variable in serial eeprom that indicates 'app code
> > > good'
> > > > > or
> > > > > > > > > not. I use an intermediate serial flash to hold the file
> from
> > > the
> > > > > SD
> > > > > > > > > card. I compare byte for byte the code on the SD card to
> the
> > > > serial
> > > > > > > > > flash. When valid, I change the serial eeprom value to 0. I
> > > > > > > > > initiate a
> > > > > > > > > WDT reset and the bootloader at 0 sees that the eeprom
> > value is
> > > 0
> > > > > and
> > > > > > > > > starts the upload from the serial flash to the CPU flash
> (via
> > > > > > > > > IAP). I
> > > > > > > > > compare byte for byte the upload to 0x00004000 and when
> > > > > > > > > valid, I change
> > > > > > > > > the serial eeprom value to 'good code (0xA5). I initiate
> > > another
> > > > > WDT
> > > > > > > > > reset, which works, but the transfer to 0x00004000 doesn't
> > > work.
> > > > > > > > >
> > > > > > > > > This update is to be done in the field by customers without
> > > JTAG.
> > > > > > > > >
> > > > > > > > > From the previous posts, I guess I'm trying to figure out
> how
> > > the
> > > > > > > > > interrupt vectors are affected by all of this. They are
> > > > > > > > > stored at 0.
> > > > > > > > > I'm guessing by Richard's post that depending on what
> > > > application I
> > > > > > > > > loaded last by JTAG (bootloader or app), the interrupt
> > > > vectors are
> > > > > > > > > correct, but not for the first loaded code. The code
> > > > > > > > > 0x00-0x1C on the
> > > > > > > > > SD card (which is Keil's compiled code converted to binary)
> > > looks
> > > > > > > > > exactly like the code at 0x00-0x1C at 0x00000000. It is
> > put at
> > > > > > > > > 0x00004000, which I thought was sufficient. Still trying to
> > > > > > > > > figure it out.
> > > > > > > > >
> > > > > > > > > Sutton
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > m...@compusmart.ab.ca
> > >
> > > > manton%40compusmart.ab.ca >
> > > > > > > > > manton%40compusmart.ab.ca >
> > > > > > > > > > > > > manton%40compusmart.ab.ca >
> wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > What criteria do you use to determine if control can be
> > > passed
> > > > > from
> > > > > > > > > > your bootloader to the main application? Do you use a
> > CRC or
> > > > > verify
> > > > > > > > > > it to make sure
> > > > > > > > > > it was written correctly?
> > > > > > > > > >
> > > > > > > > > > Could you use your bootloader to write the main app, and
> > > > then do
> > > > > a
> > > > > > > > > > verify via JTAG to see if they are the same?
> > > > > > > > > >
> > > > > > > > > > Mike
> > > > > > > > > >
> > > > > > > > > > Quoting Sutton Mehaffey
> >
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >>:
> > > > > > > > > >
> > > > > > > > > > > OK. So, what is happening in Keil's uVision when I use
> > > > > > > > > the JTAG to load
> > > > > > > > > > > the bootloader at 0x00000000 and then the app at
> > > > > > > > > 0x00004000? Is the
> > > > > > > > > > > one I load last is the one that has the correct
> interrupt
> > > > > vector
> > > > > > > > > > > pointers? It doesn't seem to matter which one I load
> > > > > > > > > first and last,
> > > > > > > > > > > the interrupts in both sets of code seem to work just
> > fine
> > > > > > and the
> > > > > > > > > > > bootloader transfers correctly to the app.
> > > > > > > > > > >
> > > > > > > > > > > Sutton
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > rtstofer wrote:
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> --- In l...
> >
> >
> > > > > 2540yahoogroups.com>>
> > >
> > > > > >
> > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > >
> > > 2540yahoogroups.com>
> > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > >
> > > 2540yahoogroups.com>
> > > > > > >
> > > > > 2540yahoogroups.com>>,
> > > > >
> > > > > > > > > > >> "Sutton Mehaffey" wrote:
> > > > > > > > > > >> >
> > > > > > > > > > >> > Because I'm not clear on why, why do I need to remap
> > > > > > > > > the interrupt
> > > > > > > > > > >> vector when my bootloader code at 0x00000000 never
> > > > > > > > > changes? I'm not
> > > > > > > > > > >> copying my SD code to location 0x00000000.
> > > > > > > > > > >> >
> > > > > > > > > > >> > Sutton
> > > > > > > > > > >>
> > > > > > > > > > >> So the vectors point to the functions in the code that
> > > > > > > > > is actually
> > > > > > > > > > >> running.
> > > > > > > > > > >>
> > > > > > > > > > >> Now, if you ignore every vector except IRG and you do
> > > > > > > > > the VIC trick of
> > > > > > > > > > >> using the vector to get the address from the VIC, then
> > > > > > > > > you don't have
> > > > > > > > > > >> to do anything.
> > > > > > > > > > >>
> > > > > > > > > > >> The IRQ interrupt vector should have code like:
> > > > > > > > > > >>
> > > > > > > > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > > > > > > > > > >>
> > > > > > > > > > >> However, none of the other interrupt vectors will
> > point to
> > > > > your
> > > > > > > > > > >> downloaded code. They will only point to entries in
> your
> > > > > > > > > boot code.
> > > > > > > > > > >>
> > > > > > > > > > >> That might be good enough.
> > > > > > > > > > >>
> > > > > > > > > > >> Richard
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Sutton Mehaffey
> > > > > > > > > > > Lookout Portable Security
> > > > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Sutton Mehaffey
> > > > > > > > > Lookout Portable Security
> > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Sutton Mehaffey
> > > > > > > Lookout Portable Security
> > > > > > > 4040 Royal Dr.
> > > > > > > Kennesaw, GA 30144
> > > > > > > 770-514-7999, 800-207-6269
> > > > > > > Fax: 770-514-1285
> > > > > > > http://www.lookoutportablesecurity.com
> >
> > > > > > >
> > > > > > > >
> > > > > > >>
> > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Miguel Angel Ajo Pelayo
> > > > > > http://www.nbee.es > > > > > > >>
> > > > > > +34 91 120 1798
> > > > > > +34 636 52 25 69
> > > > > > skype: ajoajoajo
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Sutton Mehaffey
> > > > > Lookout Portable Security
> > > > > 4040 Royal Dr.
> > > > > Kennesaw, GA 30144
> > > > > 770-514-7999, 800-207-6269
> > > > > Fax: 770-514-1285
> > > > > http://www.lookoutportablesecurity.com
> >
> > > > > > >
> > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
> >
> > >
> > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Miguel Angel Ajo Pelayo
> > > > http://www.nbee.es > > >
> > > > +34 91 120 1798
> > > > +34 636 52 25 69
> > > > skype: ajoajoajo
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Sutton Mehaffey
> > > Lookout Portable Security
> > > 4040 Royal Dr.
> > > Kennesaw, GA 30144
> > > 770-514-7999, 800-207-6269
> > > Fax: 770-514-1285
> > > http://www.lookoutportablesecurity.com
> >
> > > s...@lookoutportablesecurity.com
> > > >
> > >
> > >
> > >
> >
> > --
> > Miguel Angel Ajo Pelayo
> > http://www.nbee.es
> > +34 91 120 1798
> > +34 636 52 25 69
> > skype: ajoajoajo
> >
> >
> >
> > --
> 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
"""
If when the code hangs after my SD card upload (the WDT causes a reset,
the bootloader finds that the RAM value is back to 0xA5, meaning valid
code at 0x00004000, and tries to transfer to execution to 0x00004000), I
load the same code thru Keil's JTAG, the transfer works perfectly again.
"""
2009/8/20 Sutton Mehaffey
> Why do you think the image is incomplete? The SD card code matches
> exactly the intermediate serial flash code which matches exactly the CPU
> code at 0x00004000. I have the image length, which is the size of the
> SD card code. I'm not using a checksum, because I check each and every
> byte on 2 occasions to verify. I would think that is enough.
> Miguel Angel wrote:
> >
> >
> > Hmmm,
> >
> > I think the only way you could fix incomplete image uploads is to
> > put more fields on the image "header" inside your startup.s, and, just
> > after compiling the target app, and building the binary use a program
> > in the PC to fill those fields that could be:
> >
> > 1) Image length
> > 2) Image CRC or checksum
> >
> > with those two fields at startup in your bootloader you could
> > check the whole image length for CRC match before jumping into the app,
> > if it doesn't match, then jump into (for example) "wait for SD to get
> > inserted
> > to load a new app, and blink leds"
> >
> > 2009/8/20 Sutton Mehaffey
> >
> >>
> >
> > >
> > >
> > > I actually do in the 'Target' link put my base address at 0x00004000.
> > > That's how the code initially gets transferred from the bootloader to
> > > app correctly. The bootloader (located at 0) transfers execution
> > > perfectly to 0x00004000 before the SD card upload. But, that is loading
> > > the 2 sections of code via Keil's JTAG.
> > >
> > > The problem is that the Keil JTAG does some other programming (that I
> > > haven't figured out) that my upload from SD card doesn't do.
> > >
> > > If when the code hangs after my SD card upload (the WDT causes a reset,
> > > the bootloader finds that the RAM value is back to 0xA5, meaning valid
> > > code at 0x00004000, and tries to transfer to execution to 0x00004000),
> I
> > > load the same code thru Keil's JTAG, the transfer works perfectly
> again.
> > >
> > >
> > > Miguel Angel wrote:
> > > >
> > > >
> > > > Yes, my code will only help if you're using FIQs or SWIs,
> > > >
> > > > For the application binary, alex's comment is quite important, you
> > > > should really set the application code base address to 0x4000 or
> > > > some jump/calls will get bad addresses.
> > > >
> > > > 2009/8/20 Sutton Mehaffey
> >
> >
> > > >
> >
>
> > > >>
> > >
> > > >
> > > > >
> > > > >
> > > > > I must have missed that post. I don't see it in my folder.
> > > > >
> > > > > Anyway, I just tried changing the startup file as per your request
> > > > > (Miguel), and it still doesn't transfer to 0x4000 correctly. It
> hangs
> > > > > after a successful upload, just like before.
> > > > >
> > > >
> > > > >
> > > > > I do use "Memory Layout from Target Dialog", so maybe Alex's
> comment
> > > has
> > > > > some merit. Maybe I need to learn and use the scatter files.
> > > > >
> > > > > Sutton
> > > > >
> > > > >
> > > > > Miguel Angel wrote:
> > > > > >
> > > > > >
> > > > > > Copy & Paste, I already told you (some weeks ago) a way of doing
> it
> > > :)
> > > > > >
> > > > > > This is an example of IRQ pass-thru from my usual bootloader to
> the
> > > > > > application
> > > > > > (that starts at 0x2000): (ARM Assembler format for a 214x/213x
> > > device)
> > > > > > Modify your Startup.s to put the vectors this way:
> > > > > >
> > > > > > Vectors LDR PC, Reset_Addr
> > > > > > LDR PC, Undef_Addr
> > > > > > LDR PC, SWI_Addr
> > > > > > LDR PC, PAbt_Addr
> > > > > > LDR PC, DAbt_Addr
> > > > > > NOP ; Reserved Vector
> > > > > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > > > > LDR PC, FIQ_Addr
> > > > > >
> > > > > > Reset_Addr DCD Reset_Handler
> > > > > > Undef_Addr DCD 0x4004
> > > > > > SWI_Addr DCD 0x4008
> > > > > > PAbt_Addr DCD 0x400C
> > > > > > DAbt_Addr DCD 0x4010
> > > > > > DCD 0 ; Reserved Address
> > > > > > 0x2014
> > > > > > FIQ_Addr DCD 0x401C
> > > > > >
> > > > > > And something important too, is to end the Startup initialization
> > > with:
> > > > > >
> > > > > > MSR CPSR_c, #Mode_SYS (instead of
> > > > > > MSR CPSR_c, #Mode_USR)
> > > > > >
> > > > > > so your app startup can change processor mode again and setup
> > all the
> > > > > mode's
> > > > > > stacks, according
> > > > > > to your app configuration.
> > > > > >
> > > > > > 2009/8/20 Sutton Mehaffey
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >>
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > The code is compiled at 0x00004000, converted to binary and
> > loaded
> > > on
> > > > > > > the SD card. The application always runs at 0x00004000. The
> > > > bootloader
> > > > > > > is never changed in the field and always runs at 0. The first 6
> > > bytes
> > > > > > > of the compiled file hold the 0x00004000. I assume that's how
> > Keil
> > > > > > > knows to locate it at 0x00004000 thru the JTAG.
> > > > > > >
> > > > > > > Where in the startup code do I specify that the vectors starts
> at
> > > > > > > 0x00004000?
> > > > > > >
> > > > > > > typedef void (*APP)(void);
> > > > > > > APP app = (APP)0x00004000;
> > > > > > >
> > > > > > > app();
> > > > > > >
> > > > > > >
> > > > > > > Michael Anton wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > How does your bootloader handle revectoring all of the
> > > interrupts?
> > > > > > > > I don't understand why the vectors located at 0x0004000 would
> > > > be the
> > > > > > > > same as those at 0x00000000, since they are for different
> > > > > applications.
> > > > > > > >
> > > > > > > > Am I to understand that the code on the SD card begins at 0?
> If
> > > so
> > > > > that
> > > > > > > > is not correct, as it should be located at 0x00004000. It
> > > wouldn't
> > > > > make
> > > > > > > > sense to have the vectors in the main application loaded at
> > zero,
> > > > > > unless
> > > > > > > > they would be executed from there. Also, given that the
> startup
> > > > code
> > > > > > > > usually contains the vectors and the startup routines, they
> > > > certainly
> > > > > > > > shouldn't be located at 0.
> > > > > > > >
> > > > > > > > How do you jump to the main app from your bootloader?
> > > > > > > >
> > > > > > > > This would all me much easier for us to figure out if we
> > had the
> > > > > > > > relevant bits of code.
> > > > > > > >
> > > > > > > > Mike
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: l...
> > >
>
> > > > > 2540yahoogroups.com>>
> > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > [mailto:l...
> > >
>
> > > > > 2540yahoogroups.com>>
> > >
> > > > > >
> > >
> > > 2540yahoogroups.com>>
> > > > > > > > > > > > lpc2000%40yahoogroups.com >]On
> > > > > > > > Behalf
> > > > > > > > > Of Sutton Mehaffey
> > > > > > > > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > > > > > > > To: l...
> > >
>
> > > > > 2540yahoogroups.com>>
> > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > >
> > > > > > > > > Subject: Re: [lpc2000] Re: new SD code transfer to
> > LPC2148 not
> > > > > quite
> > > > > > > > > working
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I have a variable in serial eeprom that indicates 'app code
> > > good'
> > > > > or
> > > > > > > > > not. I use an intermediate serial flash to hold the file
> from
> > > the
> > > > > SD
> > > > > > > > > card. I compare byte for byte the code on the SD card to
> the
> > > > serial
> > > > > > > > > flash. When valid, I change the serial eeprom value to 0. I
> > > > > > > > > initiate a
> > > > > > > > > WDT reset and the bootloader at 0 sees that the eeprom
> > value is
> > > 0
> > > > > and
> > > > > > > > > starts the upload from the serial flash to the CPU flash
> (via
> > > > > > > > > IAP). I
> > > > > > > > > compare byte for byte the upload to 0x00004000 and when
> > > > > > > > > valid, I change
> > > > > > > > > the serial eeprom value to 'good code (0xA5). I initiate
> > > another
> > > > > WDT
> > > > > > > > > reset, which works, but the transfer to 0x00004000 doesn't
> > > work.
> > > > > > > > >
> > > > > > > > > This update is to be done in the field by customers without
> > > JTAG.
> > > > > > > > >
> > > > > > > > > From the previous posts, I guess I'm trying to figure out
> how
> > > the
> > > > > > > > > interrupt vectors are affected by all of this. They are
> > > > > > > > > stored at 0.
> > > > > > > > > I'm guessing by Richard's post that depending on what
> > > > application I
> > > > > > > > > loaded last by JTAG (bootloader or app), the interrupt
> > > > vectors are
> > > > > > > > > correct, but not for the first loaded code. The code
> > > > > > > > > 0x00-0x1C on the
> > > > > > > > > SD card (which is Keil's compiled code converted to binary)
> > > looks
> > > > > > > > > exactly like the code at 0x00-0x1C at 0x00000000. It is
> > put at
> > > > > > > > > 0x00004000, which I thought was sufficient. Still trying to
> > > > > > > > > figure it out.
> > > > > > > > >
> > > > > > > > > Sutton
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > m...@compusmart.ab.ca
> > >
> > > > manton%40compusmart.ab.ca >
> > > > > > > > > manton%40compusmart.ab.ca >
> > > > > > > > > > > > > manton%40compusmart.ab.ca >
> wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > What criteria do you use to determine if control can be
> > > passed
> > > > > from
> > > > > > > > > > your bootloader to the main application? Do you use a
> > CRC or
> > > > > verify
> > > > > > > > > > it to make sure
> > > > > > > > > > it was written correctly?
> > > > > > > > > >
> > > > > > > > > > Could you use your bootloader to write the main app, and
> > > > then do
> > > > > a
> > > > > > > > > > verify via JTAG to see if they are the same?
> > > > > > > > > >
> > > > > > > > > > Mike
> > > > > > > > > >
> > > > > > > > > > Quoting Sutton Mehaffey
> >
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >>:
> > > > > > > > > >
> > > > > > > > > > > OK. So, what is happening in Keil's uVision when I use
> > > > > > > > > the JTAG to load
> > > > > > > > > > > the bootloader at 0x00000000 and then the app at
> > > > > > > > > 0x00004000? Is the
> > > > > > > > > > > one I load last is the one that has the correct
> interrupt
> > > > > vector
> > > > > > > > > > > pointers? It doesn't seem to matter which one I load
> > > > > > > > > first and last,
> > > > > > > > > > > the interrupts in both sets of code seem to work just
> > fine
> > > > > > and the
> > > > > > > > > > > bootloader transfers correctly to the app.
> > > > > > > > > > >
> > > > > > > > > > > Sutton
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > rtstofer wrote:
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> --- In l...
> >
> >
> > > > > 2540yahoogroups.com>>
> > >
> > > > > >
> > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > >
> > > 2540yahoogroups.com>
> > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > >
> > > 2540yahoogroups.com>
> > > > > > >
> > > > > 2540yahoogroups.com>>,
> > > > >
> > > > > > > > > > >> "Sutton Mehaffey" wrote:
> > > > > > > > > > >> >
> > > > > > > > > > >> > Because I'm not clear on why, why do I need to remap
> > > > > > > > > the interrupt
> > > > > > > > > > >> vector when my bootloader code at 0x00000000 never
> > > > > > > > > changes? I'm not
> > > > > > > > > > >> copying my SD code to location 0x00000000.
> > > > > > > > > > >> >
> > > > > > > > > > >> > Sutton
> > > > > > > > > > >>
> > > > > > > > > > >> So the vectors point to the functions in the code that
> > > > > > > > > is actually
> > > > > > > > > > >> running.
> > > > > > > > > > >>
> > > > > > > > > > >> Now, if you ignore every vector except IRG and you do
> > > > > > > > > the VIC trick of
> > > > > > > > > > >> using the vector to get the address from the VIC, then
> > > > > > > > > you don't have
> > > > > > > > > > >> to do anything.
> > > > > > > > > > >>
> > > > > > > > > > >> The IRQ interrupt vector should have code like:
> > > > > > > > > > >>
> > > > > > > > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > > > > > > > > > >>
> > > > > > > > > > >> However, none of the other interrupt vectors will
> > point to
> > > > > your
> > > > > > > > > > >> downloaded code. They will only point to entries in
> your
> > > > > > > > > boot code.
> > > > > > > > > > >>
> > > > > > > > > > >> That might be good enough.
> > > > > > > > > > >>
> > > > > > > > > > >> Richard
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Sutton Mehaffey
> > > > > > > > > > > Lookout Portable Security
> > > > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Sutton Mehaffey
> > > > > > > > > Lookout Portable Security
> > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Sutton Mehaffey
> > > > > > > Lookout Portable Security
> > > > > > > 4040 Royal Dr.
> > > > > > > Kennesaw, GA 30144
> > > > > > > 770-514-7999, 800-207-6269
> > > > > > > Fax: 770-514-1285
> > > > > > > http://www.lookoutportablesecurity.com
> >
> > > > > > >
> > > > > > > >
> > > > > > >>
> > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Miguel Angel Ajo Pelayo
> > > > > > http://www.nbee.es > > > > > > >>
> > > > > > +34 91 120 1798
> > > > > > +34 636 52 25 69
> > > > > > skype: ajoajoajo
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Sutton Mehaffey
> > > > > Lookout Portable Security
> > > > > 4040 Royal Dr.
> > > > > Kennesaw, GA 30144
> > > > > 770-514-7999, 800-207-6269
> > > > > Fax: 770-514-1285
> > > > > http://www.lookoutportablesecurity.com
> >
> > > > > > >
> > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
> >
> > >
> > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Miguel Angel Ajo Pelayo
> > > > http://www.nbee.es > > >
> > > > +34 91 120 1798
> > > > +34 636 52 25 69
> > > > skype: ajoajoajo
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Sutton Mehaffey
> > > Lookout Portable Security
> > > 4040 Royal Dr.
> > > Kennesaw, GA 30144
> > > 770-514-7999, 800-207-6269
> > > Fax: 770-514-1285
> > > http://www.lookoutportablesecurity.com
> >
> > > s...@lookoutportablesecurity.com
> > > >
> > >
> > >
> > >
> >
> > --
> > Miguel Angel Ajo Pelayo
> > http://www.nbee.es
> > +34 91 120 1798
> > +34 636 52 25 69
> > skype: ajoajoajo
> >
> >
> >
> > --
> 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
Why do you think the image is incomplete? The SD card code matches
exactly the intermediate serial flash code which matches exactly the CPU
code at 0x00004000. I have the image length, which is the size of the
SD card code. I'm not using a checksum, because I check each and every
byte on 2 occasions to verify. I would think that is enough.
Miguel Angel wrote:
>
>
> Hmmm,
>
> I think the only way you could fix incomplete image uploads is to
> put more fields on the image "header" inside your startup.s, and, just
> after compiling the target app, and building the binary use a program
> in the PC to fill those fields that could be:
>
> 1) Image length
> 2) Image CRC or checksum
>
> with those two fields at startup in your bootloader you could
> check the whole image length for CRC match before jumping into the app,
> if it doesn't match, then jump into (for example) "wait for SD to get
> inserted
> to load a new app, and blink leds"
>
> 2009/8/20 Sutton Mehaffey > > >
> >
> > I actually do in the 'Target' link put my base address at 0x00004000.
> > That's how the code initially gets transferred from the bootloader to
> > app correctly. The bootloader (located at 0) transfers execution
> > perfectly to 0x00004000 before the SD card upload. But, that is loading
> > the 2 sections of code via Keil's JTAG.
> >
> > The problem is that the Keil JTAG does some other programming (that I
> > haven't figured out) that my upload from SD card doesn't do.
> >
> > If when the code hangs after my SD card upload (the WDT causes a reset,
> > the bootloader finds that the RAM value is back to 0xA5, meaning valid
> > code at 0x00004000, and tries to transfer to execution to 0x00004000), I
> > load the same code thru Keil's JTAG, the transfer works perfectly again.
> >
> >
> > Miguel Angel wrote:
> > >
> > >
> > > Yes, my code will only help if you're using FIQs or SWIs,
> > >
> > > For the application binary, alex's comment is quite important, you
> > > should really set the application code base address to 0x4000 or
> > > some jump/calls will get bad addresses.
> > >
> > > 2009/8/20 Sutton Mehaffey >
> > >
>
> > >>
> >
> > >
> > > >
> > > >
> > > > I must have missed that post. I don't see it in my folder.
> > > >
> > > > Anyway, I just tried changing the startup file as per your request
> > > > (Miguel), and it still doesn't transfer to 0x4000 correctly. It hangs
> > > > after a successful upload, just like before.
> > > >
> > >
> > > >
> > > > I do use "Memory Layout from Target Dialog", so maybe Alex's comment
> > has
> > > > some merit. Maybe I need to learn and use the scatter files.
> > > >
> > > > Sutton
> > > >
> > > >
> > > > Miguel Angel wrote:
> > > > >
> > > > >
> > > > > Copy & Paste, I already told you (some weeks ago) a way of doing it
> > :)
> > > > >
> > > > > This is an example of IRQ pass-thru from my usual bootloader to the
> > > > > application
> > > > > (that starts at 0x2000): (ARM Assembler format for a 214x/213x
> > device)
> > > > > Modify your Startup.s to put the vectors this way:
> > > > >
> > > > > Vectors LDR PC, Reset_Addr
> > > > > LDR PC, Undef_Addr
> > > > > LDR PC, SWI_Addr
> > > > > LDR PC, PAbt_Addr
> > > > > LDR PC, DAbt_Addr
> > > > > NOP ; Reserved Vector
> > > > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > > > LDR PC, FIQ_Addr
> > > > >
> > > > > Reset_Addr DCD Reset_Handler
> > > > > Undef_Addr DCD 0x4004
> > > > > SWI_Addr DCD 0x4008
> > > > > PAbt_Addr DCD 0x400C
> > > > > DAbt_Addr DCD 0x4010
> > > > > DCD 0 ; Reserved Address
> > > > > 0x2014
> > > > > FIQ_Addr DCD 0x401C
> > > > >
> > > > > And something important too, is to end the Startup initialization
> > with:
> > > > >
> > > > > MSR CPSR_c, #Mode_SYS (instead of
> > > > > MSR CPSR_c, #Mode_USR)
> > > > >
> > > > > so your app startup can change processor mode again and setup
> all the
> > > > mode's
> > > > > stacks, according
> > > > > to your app configuration.
> > > > >
> > > > > 2009/8/20 Sutton Mehaffey >
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >>
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > The code is compiled at 0x00004000, converted to binary and
> loaded
> > on
> > > > > > the SD card. The application always runs at 0x00004000. The
> > > bootloader
> > > > > > is never changed in the field and always runs at 0. The first 6
> > bytes
> > > > > > of the compiled file hold the 0x00004000. I assume that's how
> Keil
> > > > > > knows to locate it at 0x00004000 thru the JTAG.
> > > > > >
> > > > > > Where in the startup code do I specify that the vectors starts at
> > > > > > 0x00004000?
> > > > > >
> > > > > > typedef void (*APP)(void);
> > > > > > APP app = (APP)0x00004000;
> > > > > >
> > > > > > app();
> > > > > >
> > > > > >
> > > > > > Michael Anton wrote:
> > > > > > >
> > > > > > >
> > > > > > > How does your bootloader handle revectoring all of the
> > interrupts?
> > > > > > > I don't understand why the vectors located at 0x0004000 would
> > > be the
> > > > > > > same as those at 0x00000000, since they are for different
> > > > applications.
> > > > > > >
> > > > > > > Am I to understand that the code on the SD card begins at 0? If
> > so
> > > > that
> > > > > > > is not correct, as it should be located at 0x00004000. It
> > wouldn't
> > > > make
> > > > > > > sense to have the vectors in the main application loaded at
> zero,
> > > > > unless
> > > > > > > they would be executed from there. Also, given that the startup
> > > code
> > > > > > > usually contains the vectors and the startup routines, they
> > > certainly
> > > > > > > shouldn't be located at 0.
> > > > > > >
> > > > > > > How do you jump to the main app from your bootloader?
> > > > > > >
> > > > > > > This would all me much easier for us to figure out if we
> had the
> > > > > > > relevant bits of code.
> > > > > > >
> > > > > > > Mike
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: l...
>
> > > >
> > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > [mailto:l...
>
> > > >
> >
> > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > lpc2000%40yahoogroups.com >]On
> > > > > > > Behalf
> > > > > > > > Of Sutton Mehaffey
> > > > > > > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > > > > > > To: l...
>
> > > >
> > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > >
> > > > > > > > Subject: Re: [lpc2000] Re: new SD code transfer to
> LPC2148 not
> > > > quite
> > > > > > > > working
> > > > > > > >
> > > > > > > >
> > > > > > > > I have a variable in serial eeprom that indicates 'app code
> > good'
> > > > or
> > > > > > > > not. I use an intermediate serial flash to hold the file from
> > the
> > > > SD
> > > > > > > > card. I compare byte for byte the code on the SD card to the
> > > serial
> > > > > > > > flash. When valid, I change the serial eeprom value to 0. I
> > > > > > > > initiate a
> > > > > > > > WDT reset and the bootloader at 0 sees that the eeprom
> value is
> > 0
> > > > and
> > > > > > > > starts the upload from the serial flash to the CPU flash (via
> > > > > > > > IAP). I
> > > > > > > > compare byte for byte the upload to 0x00004000 and when
> > > > > > > > valid, I change
> > > > > > > > the serial eeprom value to 'good code (0xA5). I initiate
> > another
> > > > WDT
> > > > > > > > reset, which works, but the transfer to 0x00004000 doesn't
> > work.
> > > > > > > >
> > > > > > > > This update is to be done in the field by customers without
> > JTAG.
> > > > > > > >
> > > > > > > > From the previous posts, I guess I'm trying to figure out how
> > the
> > > > > > > > interrupt vectors are affected by all of this. They are
> > > > > > > > stored at 0.
> > > > > > > > I'm guessing by Richard's post that depending on what
> > > application I
> > > > > > > > loaded last by JTAG (bootloader or app), the interrupt
> > > vectors are
> > > > > > > > correct, but not for the first loaded code. The code
> > > > > > > > 0x00-0x1C on the
> > > > > > > > SD card (which is Keil's compiled code converted to binary)
> > looks
> > > > > > > > exactly like the code at 0x00-0x1C at 0x00000000. It is
> put at
> > > > > > > > 0x00004000, which I thought was sufficient. Still trying to
> > > > > > > > figure it out.
> > > > > > > >
> > > > > > > > Sutton
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > m...@compusmart.ab.ca
> > > manton%40compusmart.ab.ca >
> > > > > > > manton%40compusmart.ab.ca >
> > > > > > > > > > > manton%40compusmart.ab.ca > wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > What criteria do you use to determine if control can be
> > passed
> > > > from
> > > > > > > > > your bootloader to the main application? Do you use a
> CRC or
> > > > verify
> > > > > > > > > it to make sure
> > > > > > > > > it was written correctly?
> > > > > > > > >
> > > > > > > > > Could you use your bootloader to write the main app, and
> > > then do
> > > > a
> > > > > > > > > verify via JTAG to see if they are the same?
> > > > > > > > >
> > > > > > > > > Mike
> > > > > > > > >
> > > > > > > > > Quoting Sutton Mehaffey
> >
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >
> > > > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >>:
> > > > > > > > >
> > > > > > > > > > OK. So, what is happening in Keil's uVision when I use
> > > > > > > > the JTAG to load
> > > > > > > > > > the bootloader at 0x00000000 and then the app at
> > > > > > > > 0x00004000? Is the
> > > > > > > > > > one I load last is the one that has the correct interrupt
> > > > vector
> > > > > > > > > > pointers? It doesn't seem to matter which one I load
> > > > > > > > first and last,
> > > > > > > > > > the interrupts in both sets of code seem to work just
> fine
> > > > > and the
> > > > > > > > > > bootloader transfers correctly to the app.
> > > > > > > > > >
> > > > > > > > > > Sutton
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > rtstofer wrote:
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> --- In l...
>
> > > >
> >
> > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > >
>
> > > > > > > 2540yahoogroups.com>>
> > > > > > > > >
>
> > > > >
> > > > 2540yahoogroups.com>>,
> > > >
> > > > > > > > > >> "Sutton Mehaffey" wrote:
> > > > > > > > > >> >
> > > > > > > > > >> > Because I'm not clear on why, why do I need to remap
> > > > > > > > the interrupt
> > > > > > > > > >> vector when my bootloader code at 0x00000000 never
> > > > > > > > changes? I'm not
> > > > > > > > > >> copying my SD code to location 0x00000000.
> > > > > > > > > >> >
> > > > > > > > > >> > Sutton
> > > > > > > > > >>
> > > > > > > > > >> So the vectors point to the functions in the code that
> > > > > > > > is actually
> > > > > > > > > >> running.
> > > > > > > > > >>
> > > > > > > > > >> Now, if you ignore every vector except IRG and you do
> > > > > > > > the VIC trick of
> > > > > > > > > >> using the vector to get the address from the VIC, then
> > > > > > > > you don't have
> > > > > > > > > >> to do anything.
> > > > > > > > > >>
> > > > > > > > > >> The IRQ interrupt vector should have code like:
> > > > > > > > > >>
> > > > > > > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > > > > > > > > >>
> > > > > > > > > >> However, none of the other interrupt vectors will
> point to
> > > > your
> > > > > > > > > >> downloaded code. They will only point to entries in your
> > > > > > > > boot code.
> > > > > > > > > >>
> > > > > > > > > >> That might be good enough.
> > > > > > > > > >>
> > > > > > > > > >> Richard
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Sutton Mehaffey
> > > > > > > > > > Lookout Portable Security
> > > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >
> > > > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Sutton Mehaffey
> > > > > > > > Lookout Portable Security
> > > > > > > > 4040 Royal Dr. #100
> > > > > > > > Kennesaw, GA 30144
> > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Sutton Mehaffey
> > > > > > Lookout Portable Security
> > > > > > 4040 Royal Dr.
> > > > > > Kennesaw, GA 30144
> > > > > > 770-514-7999, 800-207-6269
> > > > > > Fax: 770-514-1285
> > > > > > http://www.lookoutportablesecurity.com
>
> > > > >
> > > > > >
> > > > >>
> > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Miguel Angel Ajo Pelayo
> > > > > http://www.nbee.es > >
> > > >>
> > > > > +34 91 120 1798
> > > > > +34 636 52 25 69
> > > > > skype: ajoajoajo
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Sutton Mehaffey
> > > > Lookout Portable Security
> > > > 4040 Royal Dr.
> > > > Kennesaw, GA 30144
> > > > 770-514-7999, 800-207-6269
> > > > Fax: 770-514-1285
> > > > http://www.lookoutportablesecurity.com
>
> > > > >
> > > > s...@lookoutportablesecurity.com
>
> > >
> >
> >
> > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Miguel Angel Ajo Pelayo
> > > http://www.nbee.es > >
> > > +34 91 120 1798
> > > +34 636 52 25 69
> > > skype: ajoajoajo
> > >
> > >
> > >
> > >
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr.
> > Kennesaw, GA 30144
> > 770-514-7999, 800-207-6269
> > Fax: 770-514-1285
> > http://www.lookoutportablesecurity.com
>
> > s...@lookoutportablesecurity.com
>
>
> >
> >
> > --
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 91 120 1798
> +34 636 52 25 69
> skype: ajoajoajo
>
>
--
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
exactly the intermediate serial flash code which matches exactly the CPU
code at 0x00004000. I have the image length, which is the size of the
SD card code. I'm not using a checksum, because I check each and every
byte on 2 occasions to verify. I would think that is enough.
Miguel Angel wrote:
>
>
> Hmmm,
>
> I think the only way you could fix incomplete image uploads is to
> put more fields on the image "header" inside your startup.s, and, just
> after compiling the target app, and building the binary use a program
> in the PC to fill those fields that could be:
>
> 1) Image length
> 2) Image CRC or checksum
>
> with those two fields at startup in your bootloader you could
> check the whole image length for CRC match before jumping into the app,
> if it doesn't match, then jump into (for example) "wait for SD to get
> inserted
> to load a new app, and blink leds"
>
> 2009/8/20 Sutton Mehaffey > > >
> >
> > I actually do in the 'Target' link put my base address at 0x00004000.
> > That's how the code initially gets transferred from the bootloader to
> > app correctly. The bootloader (located at 0) transfers execution
> > perfectly to 0x00004000 before the SD card upload. But, that is loading
> > the 2 sections of code via Keil's JTAG.
> >
> > The problem is that the Keil JTAG does some other programming (that I
> > haven't figured out) that my upload from SD card doesn't do.
> >
> > If when the code hangs after my SD card upload (the WDT causes a reset,
> > the bootloader finds that the RAM value is back to 0xA5, meaning valid
> > code at 0x00004000, and tries to transfer to execution to 0x00004000), I
> > load the same code thru Keil's JTAG, the transfer works perfectly again.
> >
> >
> > Miguel Angel wrote:
> > >
> > >
> > > Yes, my code will only help if you're using FIQs or SWIs,
> > >
> > > For the application binary, alex's comment is quite important, you
> > > should really set the application code base address to 0x4000 or
> > > some jump/calls will get bad addresses.
> > >
> > > 2009/8/20 Sutton Mehaffey >
> > >
>
> > >>
> >
> > >
> > > >
> > > >
> > > > I must have missed that post. I don't see it in my folder.
> > > >
> > > > Anyway, I just tried changing the startup file as per your request
> > > > (Miguel), and it still doesn't transfer to 0x4000 correctly. It hangs
> > > > after a successful upload, just like before.
> > > >
> > >
> > > >
> > > > I do use "Memory Layout from Target Dialog", so maybe Alex's comment
> > has
> > > > some merit. Maybe I need to learn and use the scatter files.
> > > >
> > > > Sutton
> > > >
> > > >
> > > > Miguel Angel wrote:
> > > > >
> > > > >
> > > > > Copy & Paste, I already told you (some weeks ago) a way of doing it
> > :)
> > > > >
> > > > > This is an example of IRQ pass-thru from my usual bootloader to the
> > > > > application
> > > > > (that starts at 0x2000): (ARM Assembler format for a 214x/213x
> > device)
> > > > > Modify your Startup.s to put the vectors this way:
> > > > >
> > > > > Vectors LDR PC, Reset_Addr
> > > > > LDR PC, Undef_Addr
> > > > > LDR PC, SWI_Addr
> > > > > LDR PC, PAbt_Addr
> > > > > LDR PC, DAbt_Addr
> > > > > NOP ; Reserved Vector
> > > > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > > > LDR PC, FIQ_Addr
> > > > >
> > > > > Reset_Addr DCD Reset_Handler
> > > > > Undef_Addr DCD 0x4004
> > > > > SWI_Addr DCD 0x4008
> > > > > PAbt_Addr DCD 0x400C
> > > > > DAbt_Addr DCD 0x4010
> > > > > DCD 0 ; Reserved Address
> > > > > 0x2014
> > > > > FIQ_Addr DCD 0x401C
> > > > >
> > > > > And something important too, is to end the Startup initialization
> > with:
> > > > >
> > > > > MSR CPSR_c, #Mode_SYS (instead of
> > > > > MSR CPSR_c, #Mode_USR)
> > > > >
> > > > > so your app startup can change processor mode again and setup
> all the
> > > > mode's
> > > > > stacks, according
> > > > > to your app configuration.
> > > > >
> > > > > 2009/8/20 Sutton Mehaffey >
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >>
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > The code is compiled at 0x00004000, converted to binary and
> loaded
> > on
> > > > > > the SD card. The application always runs at 0x00004000. The
> > > bootloader
> > > > > > is never changed in the field and always runs at 0. The first 6
> > bytes
> > > > > > of the compiled file hold the 0x00004000. I assume that's how
> Keil
> > > > > > knows to locate it at 0x00004000 thru the JTAG.
> > > > > >
> > > > > > Where in the startup code do I specify that the vectors starts at
> > > > > > 0x00004000?
> > > > > >
> > > > > > typedef void (*APP)(void);
> > > > > > APP app = (APP)0x00004000;
> > > > > >
> > > > > > app();
> > > > > >
> > > > > >
> > > > > > Michael Anton wrote:
> > > > > > >
> > > > > > >
> > > > > > > How does your bootloader handle revectoring all of the
> > interrupts?
> > > > > > > I don't understand why the vectors located at 0x0004000 would
> > > be the
> > > > > > > same as those at 0x00000000, since they are for different
> > > > applications.
> > > > > > >
> > > > > > > Am I to understand that the code on the SD card begins at 0? If
> > so
> > > > that
> > > > > > > is not correct, as it should be located at 0x00004000. It
> > wouldn't
> > > > make
> > > > > > > sense to have the vectors in the main application loaded at
> zero,
> > > > > unless
> > > > > > > they would be executed from there. Also, given that the startup
> > > code
> > > > > > > usually contains the vectors and the startup routines, they
> > > certainly
> > > > > > > shouldn't be located at 0.
> > > > > > >
> > > > > > > How do you jump to the main app from your bootloader?
> > > > > > >
> > > > > > > This would all me much easier for us to figure out if we
> had the
> > > > > > > relevant bits of code.
> > > > > > >
> > > > > > > Mike
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: l...
>
> > > >
> > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > [mailto:l...
>
> > > >
> >
> > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > lpc2000%40yahoogroups.com >]On
> > > > > > > Behalf
> > > > > > > > Of Sutton Mehaffey
> > > > > > > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > > > > > > To: l...
>
> > > >
> > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > >
> > > > > > > > Subject: Re: [lpc2000] Re: new SD code transfer to
> LPC2148 not
> > > > quite
> > > > > > > > working
> > > > > > > >
> > > > > > > >
> > > > > > > > I have a variable in serial eeprom that indicates 'app code
> > good'
> > > > or
> > > > > > > > not. I use an intermediate serial flash to hold the file from
> > the
> > > > SD
> > > > > > > > card. I compare byte for byte the code on the SD card to the
> > > serial
> > > > > > > > flash. When valid, I change the serial eeprom value to 0. I
> > > > > > > > initiate a
> > > > > > > > WDT reset and the bootloader at 0 sees that the eeprom
> value is
> > 0
> > > > and
> > > > > > > > starts the upload from the serial flash to the CPU flash (via
> > > > > > > > IAP). I
> > > > > > > > compare byte for byte the upload to 0x00004000 and when
> > > > > > > > valid, I change
> > > > > > > > the serial eeprom value to 'good code (0xA5). I initiate
> > another
> > > > WDT
> > > > > > > > reset, which works, but the transfer to 0x00004000 doesn't
> > work.
> > > > > > > >
> > > > > > > > This update is to be done in the field by customers without
> > JTAG.
> > > > > > > >
> > > > > > > > From the previous posts, I guess I'm trying to figure out how
> > the
> > > > > > > > interrupt vectors are affected by all of this. They are
> > > > > > > > stored at 0.
> > > > > > > > I'm guessing by Richard's post that depending on what
> > > application I
> > > > > > > > loaded last by JTAG (bootloader or app), the interrupt
> > > vectors are
> > > > > > > > correct, but not for the first loaded code. The code
> > > > > > > > 0x00-0x1C on the
> > > > > > > > SD card (which is Keil's compiled code converted to binary)
> > looks
> > > > > > > > exactly like the code at 0x00-0x1C at 0x00000000. It is
> put at
> > > > > > > > 0x00004000, which I thought was sufficient. Still trying to
> > > > > > > > figure it out.
> > > > > > > >
> > > > > > > > Sutton
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > m...@compusmart.ab.ca
> > > manton%40compusmart.ab.ca >
> > > > > > > manton%40compusmart.ab.ca >
> > > > > > > > > > > manton%40compusmart.ab.ca > wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > What criteria do you use to determine if control can be
> > passed
> > > > from
> > > > > > > > > your bootloader to the main application? Do you use a
> CRC or
> > > > verify
> > > > > > > > > it to make sure
> > > > > > > > > it was written correctly?
> > > > > > > > >
> > > > > > > > > Could you use your bootloader to write the main app, and
> > > then do
> > > > a
> > > > > > > > > verify via JTAG to see if they are the same?
> > > > > > > > >
> > > > > > > > > Mike
> > > > > > > > >
> > > > > > > > > Quoting Sutton Mehaffey
> >
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >
> > > > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >>:
> > > > > > > > >
> > > > > > > > > > OK. So, what is happening in Keil's uVision when I use
> > > > > > > > the JTAG to load
> > > > > > > > > > the bootloader at 0x00000000 and then the app at
> > > > > > > > 0x00004000? Is the
> > > > > > > > > > one I load last is the one that has the correct interrupt
> > > > vector
> > > > > > > > > > pointers? It doesn't seem to matter which one I load
> > > > > > > > first and last,
> > > > > > > > > > the interrupts in both sets of code seem to work just
> fine
> > > > > and the
> > > > > > > > > > bootloader transfers correctly to the app.
> > > > > > > > > >
> > > > > > > > > > Sutton
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > rtstofer wrote:
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> --- In l...
>
> > > >
> >
> > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > >
>
> > > > > > > 2540yahoogroups.com>>
> > > > > > > > >
>
> > > > >
> > > > 2540yahoogroups.com>>,
> > > >
> > > > > > > > > >> "Sutton Mehaffey" wrote:
> > > > > > > > > >> >
> > > > > > > > > >> > Because I'm not clear on why, why do I need to remap
> > > > > > > > the interrupt
> > > > > > > > > >> vector when my bootloader code at 0x00000000 never
> > > > > > > > changes? I'm not
> > > > > > > > > >> copying my SD code to location 0x00000000.
> > > > > > > > > >> >
> > > > > > > > > >> > Sutton
> > > > > > > > > >>
> > > > > > > > > >> So the vectors point to the functions in the code that
> > > > > > > > is actually
> > > > > > > > > >> running.
> > > > > > > > > >>
> > > > > > > > > >> Now, if you ignore every vector except IRG and you do
> > > > > > > > the VIC trick of
> > > > > > > > > >> using the vector to get the address from the VIC, then
> > > > > > > > you don't have
> > > > > > > > > >> to do anything.
> > > > > > > > > >>
> > > > > > > > > >> The IRQ interrupt vector should have code like:
> > > > > > > > > >>
> > > > > > > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > > > > > > > > >>
> > > > > > > > > >> However, none of the other interrupt vectors will
> point to
> > > > your
> > > > > > > > > >> downloaded code. They will only point to entries in your
> > > > > > > > boot code.
> > > > > > > > > >>
> > > > > > > > > >> That might be good enough.
> > > > > > > > > >>
> > > > > > > > > >> Richard
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Sutton Mehaffey
> > > > > > > > > > Lookout Portable Security
> > > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >
> > > > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Sutton Mehaffey
> > > > > > > > Lookout Portable Security
> > > > > > > > 4040 Royal Dr. #100
> > > > > > > > Kennesaw, GA 30144
> > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Sutton Mehaffey
> > > > > > Lookout Portable Security
> > > > > > 4040 Royal Dr.
> > > > > > Kennesaw, GA 30144
> > > > > > 770-514-7999, 800-207-6269
> > > > > > Fax: 770-514-1285
> > > > > > http://www.lookoutportablesecurity.com
>
> > > > >
> > > > > >
> > > > >>
> > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Miguel Angel Ajo Pelayo
> > > > > http://www.nbee.es > >
> > > >>
> > > > > +34 91 120 1798
> > > > > +34 636 52 25 69
> > > > > skype: ajoajoajo
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Sutton Mehaffey
> > > > Lookout Portable Security
> > > > 4040 Royal Dr.
> > > > Kennesaw, GA 30144
> > > > 770-514-7999, 800-207-6269
> > > > Fax: 770-514-1285
> > > > http://www.lookoutportablesecurity.com
>
> > > > >
> > > > s...@lookoutportablesecurity.com
>
> > >
> >
> >
> > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Miguel Angel Ajo Pelayo
> > > http://www.nbee.es > >
> > > +34 91 120 1798
> > > +34 636 52 25 69
> > > skype: ajoajoajo
> > >
> > >
> > >
> > >
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr.
> > Kennesaw, GA 30144
> > 770-514-7999, 800-207-6269
> > Fax: 770-514-1285
> > http://www.lookoutportablesecurity.com
>
> > s...@lookoutportablesecurity.com
>
>
> >
> >
> > --
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 91 120 1798
> +34 636 52 25 69
> skype: ajoajoajo
>
>
--
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
And I have actually put the same code on the SD card as is running at
0x00004000. So, that everything supposedly matches. After the upload,
code still hangs in bootloader transferring to 0x00004000. But, works
again if I upload the same code via JTAG.
Miguel Angel wrote:
>
>
> Sorry sutton, I misunderstood your phrase:
>
> """
> If when the code hangs after my SD card upload (the WDT causes a reset,
> the bootloader finds that the RAM value is back to 0xA5, meaning valid
> code at 0x00004000, and tries to transfer to execution to 0x00004000), I
> load the same code thru Keil's JTAG, the transfer works perfectly again.
>
> """
>
> 2009/8/20 Sutton Mehaffey > > >
> >
> > Why do you think the image is incomplete? The SD card code matches
> > exactly the intermediate serial flash code which matches exactly the CPU
> > code at 0x00004000. I have the image length, which is the size of the
> > SD card code. I'm not using a checksum, because I check each and every
> > byte on 2 occasions to verify. I would think that is enough.
> >
> >
> > Miguel Angel wrote:
> > >
> > >
> > > Hmmm,
> > >
> > > I think the only way you could fix incomplete image uploads is to
> > > put more fields on the image "header" inside your startup.s, and, just
> > > after compiling the target app, and building the binary use a program
> > > in the PC to fill those fields that could be:
> > >
> > > 1) Image length
> > > 2) Image CRC or checksum
> > >
> > > with those two fields at startup in your bootloader you could
> > > check the whole image length for CRC match before jumping into the app,
> > > if it doesn't match, then jump into (for example) "wait for SD to get
> > > inserted
> > > to load a new app, and blink leds"
> > >
> > > 2009/8/20 Sutton Mehaffey >
> > >
>
> > >>
> > >
> > > >
> > > >
> > > > I actually do in the 'Target' link put my base address at 0x00004000.
> > > > That's how the code initially gets transferred from the bootloader to
> > > > app correctly. The bootloader (located at 0) transfers execution
> > > > perfectly to 0x00004000 before the SD card upload. But, that is
> loading
> > > > the 2 sections of code via Keil's JTAG.
> > > >
> > > > The problem is that the Keil JTAG does some other programming (that I
> > > > haven't figured out) that my upload from SD card doesn't do.
> > > >
> > > > If when the code hangs after my SD card upload (the WDT causes a
> reset,
> > > > the bootloader finds that the RAM value is back to 0xA5, meaning
> valid
> > > > code at 0x00004000, and tries to transfer to execution to
> 0x00004000),
> > I
> > > > load the same code thru Keil's JTAG, the transfer works perfectly
> > again.
> > > >
> > > >
> > > > Miguel Angel wrote:
> > > > >
> > > > >
> > > > > Yes, my code will only help if you're using FIQs or SWIs,
> > > > >
> > > > > For the application binary, alex's comment is quite important, you
> > > > > should really set the application code base address to 0x4000 or
> > > > > some jump/calls will get bad addresses.
> > > > >
> > > > > 2009/8/20 Sutton Mehaffey >
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >>
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > I must have missed that post. I don't see it in my folder.
> > > > > >
> > > > > > Anyway, I just tried changing the startup file as per your
> request
> > > > > > (Miguel), and it still doesn't transfer to 0x4000 correctly. It
> > hangs
> > > > > > after a successful upload, just like before.
> > > > > >
> > > > >
> > > > > >
> > > > > > I do use "Memory Layout from Target Dialog", so maybe Alex's
> > comment
> > > > has
> > > > > > some merit. Maybe I need to learn and use the scatter files.
> > > > > >
> > > > > > Sutton
> > > > > >
> > > > > >
> > > > > > Miguel Angel wrote:
> > > > > > >
> > > > > > >
> > > > > > > Copy & Paste, I already told you (some weeks ago) a way of
> doing
> > it
> > > > :)
> > > > > > >
> > > > > > > This is an example of IRQ pass-thru from my usual bootloader to
> > the
> > > > > > > application
> > > > > > > (that starts at 0x2000): (ARM Assembler format for a 214x/213x
> > > > device)
> > > > > > > Modify your Startup.s to put the vectors this way:
> > > > > > >
> > > > > > > Vectors LDR PC, Reset_Addr
> > > > > > > LDR PC, Undef_Addr
> > > > > > > LDR PC, SWI_Addr
> > > > > > > LDR PC, PAbt_Addr
> > > > > > > LDR PC, DAbt_Addr
> > > > > > > NOP ; Reserved Vector
> > > > > > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > > > > > LDR PC, FIQ_Addr
> > > > > > >
> > > > > > > Reset_Addr DCD Reset_Handler
> > > > > > > Undef_Addr DCD 0x4004
> > > > > > > SWI_Addr DCD 0x4008
> > > > > > > PAbt_Addr DCD 0x400C
> > > > > > > DAbt_Addr DCD 0x4010
> > > > > > > DCD 0 ; Reserved Address
> > > > > > > 0x2014
> > > > > > > FIQ_Addr DCD 0x401C
> > > > > > >
> > > > > > > And something important too, is to end the Startup
> initialization
> > > > with:
> > > > > > >
> > > > > > > MSR CPSR_c, #Mode_SYS (instead of
> > > > > > > MSR CPSR_c, #Mode_USR)
> > > > > > >
> > > > > > > so your app startup can change processor mode again and setup
> > > all the
> > > > > > mode's
> > > > > > > stacks, according
> > > > > > > to your app configuration.
> > > > > > >
> > > > > > > 2009/8/20 Sutton Mehaffey
> >
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >>
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > The code is compiled at 0x00004000, converted to binary and
> > > loaded
> > > > on
> > > > > > > > the SD card. The application always runs at 0x00004000. The
> > > > > bootloader
> > > > > > > > is never changed in the field and always runs at 0. The
> first 6
> > > > bytes
> > > > > > > > of the compiled file hold the 0x00004000. I assume that's how
> > > Keil
> > > > > > > > knows to locate it at 0x00004000 thru the JTAG.
> > > > > > > >
> > > > > > > > Where in the startup code do I specify that the vectors
> starts
> > at
> > > > > > > > 0x00004000?
> > > > > > > >
> > > > > > > > typedef void (*APP)(void);
> > > > > > > > APP app = (APP)0x00004000;
> > > > > > > >
> > > > > > > > app();
> > > > > > > >
> > > > > > > >
> > > > > > > > Michael Anton wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > How does your bootloader handle revectoring all of the
> > > > interrupts?
> > > > > > > > > I don't understand why the vectors located at 0x0004000
> would
> > > > > be the
> > > > > > > > > same as those at 0x00000000, since they are for different
> > > > > > applications.
> > > > > > > > >
> > > > > > > > > Am I to understand that the code on the SD card begins
> at 0?
> > If
> > > > so
> > > > > > that
> > > > > > > > > is not correct, as it should be located at 0x00004000. It
> > > > wouldn't
> > > > > > make
> > > > > > > > > sense to have the vectors in the main application loaded at
> > > zero,
> > > > > > > unless
> > > > > > > > > they would be executed from there. Also, given that the
> > startup
> > > > > code
> > > > > > > > > usually contains the vectors and the startup routines, they
> > > > > certainly
> > > > > > > > > shouldn't be located at 0.
> > > > > > > > >
> > > > > > > > > How do you jump to the main app from your bootloader?
> > > > > > > > >
> > > > > > > > > This would all me much easier for us to figure out if we
> > > had the
> > > > > > > > > relevant bits of code.
> > > > > > > > >
> > > > > > > > > Mike
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: l...
>
> > > >
> >
> > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > [mailto:l...
>
> > > >
> >
> > > > > > > > 2540yahoogroups.com>>
> > > >
> > > > > > >
> > > > >
> > > > 2540yahoogroups.com>>
> > > > > > > > > > > > > > lpc2000%40yahoogroups.com >]On
> > > > > > > > > Behalf
> > > > > > > > > > Of Sutton Mehaffey
> > > > > > > > > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > > > > > > > > To: l...
>
> > > >
> >
> > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > >
> > > > > > > > > > Subject: Re: [lpc2000] Re: new SD code transfer to
> > > LPC2148 not
> > > > > > quite
> > > > > > > > > > working
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I have a variable in serial eeprom that indicates
> 'app code
> > > > good'
> > > > > > or
> > > > > > > > > > not. I use an intermediate serial flash to hold the file
> > from
> > > > the
> > > > > > SD
> > > > > > > > > > card. I compare byte for byte the code on the SD card to
> > the
> > > > > serial
> > > > > > > > > > flash. When valid, I change the serial eeprom value
> to 0. I
> > > > > > > > > > initiate a
> > > > > > > > > > WDT reset and the bootloader at 0 sees that the eeprom
> > > value is
> > > > 0
> > > > > > and
> > > > > > > > > > starts the upload from the serial flash to the CPU flash
> > (via
> > > > > > > > > > IAP). I
> > > > > > > > > > compare byte for byte the upload to 0x00004000 and when
> > > > > > > > > > valid, I change
> > > > > > > > > > the serial eeprom value to 'good code (0xA5). I initiate
> > > > another
> > > > > > WDT
> > > > > > > > > > reset, which works, but the transfer to 0x00004000
> doesn't
> > > > work.
> > > > > > > > > >
> > > > > > > > > > This update is to be done in the field by customers
> without
> > > > JTAG.
> > > > > > > > > >
> > > > > > > > > > From the previous posts, I guess I'm trying to figure out
> > how
> > > > the
> > > > > > > > > > interrupt vectors are affected by all of this. They are
> > > > > > > > > > stored at 0.
> > > > > > > > > > I'm guessing by Richard's post that depending on what
> > > > > application I
> > > > > > > > > > loaded last by JTAG (bootloader or app), the interrupt
> > > > > vectors are
> > > > > > > > > > correct, but not for the first loaded code. The code
> > > > > > > > > > 0x00-0x1C on the
> > > > > > > > > > SD card (which is Keil's compiled code converted to
> binary)
> > > > looks
> > > > > > > > > > exactly like the code at 0x00-0x1C at 0x00000000. It is
> > > put at
> > > > > > > > > > 0x00004000, which I thought was sufficient. Still
> trying to
> > > > > > > > > > figure it out.
> > > > > > > > > >
> > > > > > > > > > Sutton
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > m...@compusmart.ab.ca
>
> > > >
> > > > > > manton%40compusmart.ab.ca >
> > > > > > > > > > > manton%40compusmart.ab.ca >
> > > > > > > > > > > > > > > manton%40compusmart.ab.ca >
> > wrote:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > What criteria do you use to determine if control can be
> > > > passed
> > > > > > from
> > > > > > > > > > > your bootloader to the main application? Do you use a
> > > CRC or
> > > > > > verify
> > > > > > > > > > > it to make sure
> > > > > > > > > > > it was written correctly?
> > > > > > > > > > >
> > > > > > > > > > > Could you use your bootloader to write the main
> app, and
> > > > > then do
> > > > > > a
> > > > > > > > > > > verify via JTAG to see if they are the same?
> > > > > > > > > > >
> > > > > > > > > > > Mike
> > > > > > > > > > >
> > > > > > > > > > > Quoting Sutton Mehaffey
> > > >
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > >
> > > > > > > > >
> > > > > > > > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > >
> > > > > > > > >>:
> > > > > > > > > > >
> > > > > > > > > > > > OK. So, what is happening in Keil's uVision when
> I use
> > > > > > > > > > the JTAG to load
> > > > > > > > > > > > the bootloader at 0x00000000 and then the app at
> > > > > > > > > > 0x00004000? Is the
> > > > > > > > > > > > one I load last is the one that has the correct
> > interrupt
> > > > > > vector
> > > > > > > > > > > > pointers? It doesn't seem to matter which one I load
> > > > > > > > > > first and last,
> > > > > > > > > > > > the interrupts in both sets of code seem to work just
> > > fine
> > > > > > > and the
> > > > > > > > > > > > bootloader transfers correctly to the app.
> > > > > > > > > > > >
> > > > > > > > > > > > Sutton
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > rtstofer wrote:
> > > > > > > > > > > >>
> > > > > > > > > > > >>
> > > > > > > > > > > >> --- In l...
>
> > >
> > >
> > > > > > > > 2540yahoogroups.com>>
> > > >
> > > > > > >
> > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > >
> > > > > > 2540yahoogroups.com>
> > > > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > >
> > > > > > 2540yahoogroups.com>
> > > > > > > > >
> > > > > > 2540yahoogroups.com>>,
> > > > > >
> > > > > > > > > > > >> "Sutton Mehaffey" wrote:
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > Because I'm not clear on why, why do I need to
> remap
> > > > > > > > > > the interrupt
> > > > > > > > > > > >> vector when my bootloader code at 0x00000000 never
> > > > > > > > > > changes? I'm not
> > > > > > > > > > > >> copying my SD code to location 0x00000000.
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > Sutton
> > > > > > > > > > > >>
> > > > > > > > > > > >> So the vectors point to the functions in the
> code that
> > > > > > > > > > is actually
> > > > > > > > > > > >> running.
> > > > > > > > > > > >>
> > > > > > > > > > > >> Now, if you ignore every vector except IRG and
> you do
> > > > > > > > > > the VIC trick of
> > > > > > > > > > > >> using the vector to get the address from the
> VIC, then
> > > > > > > > > > you don't have
> > > > > > > > > > > >> to do anything.
> > > > > > > > > > > >>
> > > > > > > > > > > >> The IRQ interrupt vector should have code like:
> > > > > > > > > > > >>
> > > > > > > > > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > > > > > > > > > > >>
> > > > > > > > > > > >> However, none of the other interrupt vectors will
> > > point to
> > > > > > your
> > > > > > > > > > > >> downloaded code. They will only point to entries in
> > your
> > > > > > > > > > boot code.
> > > > > > > > > > > >>
> > > > > > > > > > > >> That might be good enough.
> > > > > > > > > > > >>
> > > > > > > > > > > >> Richard
> > > > > > > > > > > >>
> > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Sutton Mehaffey
> > > > > > > > > > > > Lookout Portable Security
> > > > > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > >
> > > > > > > > >
> > > > > > > > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > >
> > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Sutton Mehaffey
> > > > > > > > > > Lookout Portable Security
> > > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Sutton Mehaffey
> > > > > > > > Lookout Portable Security
> > > > > > > > 4040 Royal Dr.
> > > > > > > > Kennesaw, GA 30144
> > > > > > > > 770-514-7999, 800-207-6269
> > > > > > > > Fax: 770-514-1285
> > > > > > > > http://www.lookoutportablesecurity.com
>
> > > > >
> > > > > >
> > > > >>
> > > > > > > >
> > > > >
> > > > > >
> > > > >>>
> > > > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Miguel Angel Ajo Pelayo
> > > > > > > http://www.nbee.es > >
> > > >> > >
> >
> > > > > > >>>
> > > > > > > +34 91 120 1798
> > > > > > > +34 636 52 25 69
> > > > > > > skype: ajoajoajo
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Sutton Mehaffey
> > > > > > Lookout Portable Security
> > > > > > 4040 Royal Dr.
> > > > > > Kennesaw, GA 30144
> > > > > > 770-514-7999, 800-207-6269
> > > > > > Fax: 770-514-1285
> > > > > > http://www.lookoutportablesecurity.com
>
> > > > >
> > > > > >
> > > > >>
> > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Miguel Angel Ajo Pelayo
> > > > > http://www.nbee.es > >
> > > >>
> > > > > +34 91 120 1798
> > > > > +34 636 52 25 69
> > > > > skype: ajoajoajo
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Sutton Mehaffey
> > > > Lookout Portable Security
> > > > 4040 Royal Dr.
> > > > Kennesaw, GA 30144
> > > > 770-514-7999, 800-207-6269
> > > > Fax: 770-514-1285
> > > > http://www.lookoutportablesecurity.com
>
> > > > >
> > > > s...@lookoutportablesecurity.com
>
> > >
> >
> >
> > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Miguel Angel Ajo Pelayo
> > > http://www.nbee.es > >
> > > +34 91 120 1798
> > > +34 636 52 25 69
> > > skype: ajoajoajo
> > >
> > >
> > >
> > >
> >
> > --
> > 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
0x00004000. So, that everything supposedly matches. After the upload,
code still hangs in bootloader transferring to 0x00004000. But, works
again if I upload the same code via JTAG.
Miguel Angel wrote:
>
>
> Sorry sutton, I misunderstood your phrase:
>
> """
> If when the code hangs after my SD card upload (the WDT causes a reset,
> the bootloader finds that the RAM value is back to 0xA5, meaning valid
> code at 0x00004000, and tries to transfer to execution to 0x00004000), I
> load the same code thru Keil's JTAG, the transfer works perfectly again.
>
> """
>
> 2009/8/20 Sutton Mehaffey > > >
> >
> > Why do you think the image is incomplete? The SD card code matches
> > exactly the intermediate serial flash code which matches exactly the CPU
> > code at 0x00004000. I have the image length, which is the size of the
> > SD card code. I'm not using a checksum, because I check each and every
> > byte on 2 occasions to verify. I would think that is enough.
> >
> >
> > Miguel Angel wrote:
> > >
> > >
> > > Hmmm,
> > >
> > > I think the only way you could fix incomplete image uploads is to
> > > put more fields on the image "header" inside your startup.s, and, just
> > > after compiling the target app, and building the binary use a program
> > > in the PC to fill those fields that could be:
> > >
> > > 1) Image length
> > > 2) Image CRC or checksum
> > >
> > > with those two fields at startup in your bootloader you could
> > > check the whole image length for CRC match before jumping into the app,
> > > if it doesn't match, then jump into (for example) "wait for SD to get
> > > inserted
> > > to load a new app, and blink leds"
> > >
> > > 2009/8/20 Sutton Mehaffey >
> > >
>
> > >>
> > >
> > > >
> > > >
> > > > I actually do in the 'Target' link put my base address at 0x00004000.
> > > > That's how the code initially gets transferred from the bootloader to
> > > > app correctly. The bootloader (located at 0) transfers execution
> > > > perfectly to 0x00004000 before the SD card upload. But, that is
> loading
> > > > the 2 sections of code via Keil's JTAG.
> > > >
> > > > The problem is that the Keil JTAG does some other programming (that I
> > > > haven't figured out) that my upload from SD card doesn't do.
> > > >
> > > > If when the code hangs after my SD card upload (the WDT causes a
> reset,
> > > > the bootloader finds that the RAM value is back to 0xA5, meaning
> valid
> > > > code at 0x00004000, and tries to transfer to execution to
> 0x00004000),
> > I
> > > > load the same code thru Keil's JTAG, the transfer works perfectly
> > again.
> > > >
> > > >
> > > > Miguel Angel wrote:
> > > > >
> > > > >
> > > > > Yes, my code will only help if you're using FIQs or SWIs,
> > > > >
> > > > > For the application binary, alex's comment is quite important, you
> > > > > should really set the application code base address to 0x4000 or
> > > > > some jump/calls will get bad addresses.
> > > > >
> > > > > 2009/8/20 Sutton Mehaffey >
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >>
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > I must have missed that post. I don't see it in my folder.
> > > > > >
> > > > > > Anyway, I just tried changing the startup file as per your
> request
> > > > > > (Miguel), and it still doesn't transfer to 0x4000 correctly. It
> > hangs
> > > > > > after a successful upload, just like before.
> > > > > >
> > > > >
> > > > > >
> > > > > > I do use "Memory Layout from Target Dialog", so maybe Alex's
> > comment
> > > > has
> > > > > > some merit. Maybe I need to learn and use the scatter files.
> > > > > >
> > > > > > Sutton
> > > > > >
> > > > > >
> > > > > > Miguel Angel wrote:
> > > > > > >
> > > > > > >
> > > > > > > Copy & Paste, I already told you (some weeks ago) a way of
> doing
> > it
> > > > :)
> > > > > > >
> > > > > > > This is an example of IRQ pass-thru from my usual bootloader to
> > the
> > > > > > > application
> > > > > > > (that starts at 0x2000): (ARM Assembler format for a 214x/213x
> > > > device)
> > > > > > > Modify your Startup.s to put the vectors this way:
> > > > > > >
> > > > > > > Vectors LDR PC, Reset_Addr
> > > > > > > LDR PC, Undef_Addr
> > > > > > > LDR PC, SWI_Addr
> > > > > > > LDR PC, PAbt_Addr
> > > > > > > LDR PC, DAbt_Addr
> > > > > > > NOP ; Reserved Vector
> > > > > > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > > > > > LDR PC, FIQ_Addr
> > > > > > >
> > > > > > > Reset_Addr DCD Reset_Handler
> > > > > > > Undef_Addr DCD 0x4004
> > > > > > > SWI_Addr DCD 0x4008
> > > > > > > PAbt_Addr DCD 0x400C
> > > > > > > DAbt_Addr DCD 0x4010
> > > > > > > DCD 0 ; Reserved Address
> > > > > > > 0x2014
> > > > > > > FIQ_Addr DCD 0x401C
> > > > > > >
> > > > > > > And something important too, is to end the Startup
> initialization
> > > > with:
> > > > > > >
> > > > > > > MSR CPSR_c, #Mode_SYS (instead of
> > > > > > > MSR CPSR_c, #Mode_USR)
> > > > > > >
> > > > > > > so your app startup can change processor mode again and setup
> > > all the
> > > > > > mode's
> > > > > > > stacks, according
> > > > > > > to your app configuration.
> > > > > > >
> > > > > > > 2009/8/20 Sutton Mehaffey
> >
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >>
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > The code is compiled at 0x00004000, converted to binary and
> > > loaded
> > > > on
> > > > > > > > the SD card. The application always runs at 0x00004000. The
> > > > > bootloader
> > > > > > > > is never changed in the field and always runs at 0. The
> first 6
> > > > bytes
> > > > > > > > of the compiled file hold the 0x00004000. I assume that's how
> > > Keil
> > > > > > > > knows to locate it at 0x00004000 thru the JTAG.
> > > > > > > >
> > > > > > > > Where in the startup code do I specify that the vectors
> starts
> > at
> > > > > > > > 0x00004000?
> > > > > > > >
> > > > > > > > typedef void (*APP)(void);
> > > > > > > > APP app = (APP)0x00004000;
> > > > > > > >
> > > > > > > > app();
> > > > > > > >
> > > > > > > >
> > > > > > > > Michael Anton wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > How does your bootloader handle revectoring all of the
> > > > interrupts?
> > > > > > > > > I don't understand why the vectors located at 0x0004000
> would
> > > > > be the
> > > > > > > > > same as those at 0x00000000, since they are for different
> > > > > > applications.
> > > > > > > > >
> > > > > > > > > Am I to understand that the code on the SD card begins
> at 0?
> > If
> > > > so
> > > > > > that
> > > > > > > > > is not correct, as it should be located at 0x00004000. It
> > > > wouldn't
> > > > > > make
> > > > > > > > > sense to have the vectors in the main application loaded at
> > > zero,
> > > > > > > unless
> > > > > > > > > they would be executed from there. Also, given that the
> > startup
> > > > > code
> > > > > > > > > usually contains the vectors and the startup routines, they
> > > > > certainly
> > > > > > > > > shouldn't be located at 0.
> > > > > > > > >
> > > > > > > > > How do you jump to the main app from your bootloader?
> > > > > > > > >
> > > > > > > > > This would all me much easier for us to figure out if we
> > > had the
> > > > > > > > > relevant bits of code.
> > > > > > > > >
> > > > > > > > > Mike
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: l...
>
> > > >
> >
> > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > [mailto:l...
>
> > > >
> >
> > > > > > > > 2540yahoogroups.com>>
> > > >
> > > > > > >
> > > > >
> > > > 2540yahoogroups.com>>
> > > > > > > > > > > > > > lpc2000%40yahoogroups.com >]On
> > > > > > > > > Behalf
> > > > > > > > > > Of Sutton Mehaffey
> > > > > > > > > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > > > > > > > > To: l...
>
> > > >
> >
> > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > >
> > > > > > > > > > Subject: Re: [lpc2000] Re: new SD code transfer to
> > > LPC2148 not
> > > > > > quite
> > > > > > > > > > working
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I have a variable in serial eeprom that indicates
> 'app code
> > > > good'
> > > > > > or
> > > > > > > > > > not. I use an intermediate serial flash to hold the file
> > from
> > > > the
> > > > > > SD
> > > > > > > > > > card. I compare byte for byte the code on the SD card to
> > the
> > > > > serial
> > > > > > > > > > flash. When valid, I change the serial eeprom value
> to 0. I
> > > > > > > > > > initiate a
> > > > > > > > > > WDT reset and the bootloader at 0 sees that the eeprom
> > > value is
> > > > 0
> > > > > > and
> > > > > > > > > > starts the upload from the serial flash to the CPU flash
> > (via
> > > > > > > > > > IAP). I
> > > > > > > > > > compare byte for byte the upload to 0x00004000 and when
> > > > > > > > > > valid, I change
> > > > > > > > > > the serial eeprom value to 'good code (0xA5). I initiate
> > > > another
> > > > > > WDT
> > > > > > > > > > reset, which works, but the transfer to 0x00004000
> doesn't
> > > > work.
> > > > > > > > > >
> > > > > > > > > > This update is to be done in the field by customers
> without
> > > > JTAG.
> > > > > > > > > >
> > > > > > > > > > From the previous posts, I guess I'm trying to figure out
> > how
> > > > the
> > > > > > > > > > interrupt vectors are affected by all of this. They are
> > > > > > > > > > stored at 0.
> > > > > > > > > > I'm guessing by Richard's post that depending on what
> > > > > application I
> > > > > > > > > > loaded last by JTAG (bootloader or app), the interrupt
> > > > > vectors are
> > > > > > > > > > correct, but not for the first loaded code. The code
> > > > > > > > > > 0x00-0x1C on the
> > > > > > > > > > SD card (which is Keil's compiled code converted to
> binary)
> > > > looks
> > > > > > > > > > exactly like the code at 0x00-0x1C at 0x00000000. It is
> > > put at
> > > > > > > > > > 0x00004000, which I thought was sufficient. Still
> trying to
> > > > > > > > > > figure it out.
> > > > > > > > > >
> > > > > > > > > > Sutton
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > m...@compusmart.ab.ca
>
> > > >
> > > > > > manton%40compusmart.ab.ca >
> > > > > > > > > > > manton%40compusmart.ab.ca >
> > > > > > > > > > > > > > > manton%40compusmart.ab.ca >
> > wrote:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > What criteria do you use to determine if control can be
> > > > passed
> > > > > > from
> > > > > > > > > > > your bootloader to the main application? Do you use a
> > > CRC or
> > > > > > verify
> > > > > > > > > > > it to make sure
> > > > > > > > > > > it was written correctly?
> > > > > > > > > > >
> > > > > > > > > > > Could you use your bootloader to write the main
> app, and
> > > > > then do
> > > > > > a
> > > > > > > > > > > verify via JTAG to see if they are the same?
> > > > > > > > > > >
> > > > > > > > > > > Mike
> > > > > > > > > > >
> > > > > > > > > > > Quoting Sutton Mehaffey
> > > >
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > >
> > > > > > > > >
> > > > > > > > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > >
> > > > > > > > >>:
> > > > > > > > > > >
> > > > > > > > > > > > OK. So, what is happening in Keil's uVision when
> I use
> > > > > > > > > > the JTAG to load
> > > > > > > > > > > > the bootloader at 0x00000000 and then the app at
> > > > > > > > > > 0x00004000? Is the
> > > > > > > > > > > > one I load last is the one that has the correct
> > interrupt
> > > > > > vector
> > > > > > > > > > > > pointers? It doesn't seem to matter which one I load
> > > > > > > > > > first and last,
> > > > > > > > > > > > the interrupts in both sets of code seem to work just
> > > fine
> > > > > > > and the
> > > > > > > > > > > > bootloader transfers correctly to the app.
> > > > > > > > > > > >
> > > > > > > > > > > > Sutton
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > rtstofer wrote:
> > > > > > > > > > > >>
> > > > > > > > > > > >>
> > > > > > > > > > > >> --- In l...
>
> > >
> > >
> > > > > > > > 2540yahoogroups.com>>
> > > >
> > > > > > >
> > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > >
> > > > > > 2540yahoogroups.com>
> > > > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > >
> > > > > > 2540yahoogroups.com>
> > > > > > > > >
> > > > > > 2540yahoogroups.com>>,
> > > > > >
> > > > > > > > > > > >> "Sutton Mehaffey" wrote:
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > Because I'm not clear on why, why do I need to
> remap
> > > > > > > > > > the interrupt
> > > > > > > > > > > >> vector when my bootloader code at 0x00000000 never
> > > > > > > > > > changes? I'm not
> > > > > > > > > > > >> copying my SD code to location 0x00000000.
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > Sutton
> > > > > > > > > > > >>
> > > > > > > > > > > >> So the vectors point to the functions in the
> code that
> > > > > > > > > > is actually
> > > > > > > > > > > >> running.
> > > > > > > > > > > >>
> > > > > > > > > > > >> Now, if you ignore every vector except IRG and
> you do
> > > > > > > > > > the VIC trick of
> > > > > > > > > > > >> using the vector to get the address from the
> VIC, then
> > > > > > > > > > you don't have
> > > > > > > > > > > >> to do anything.
> > > > > > > > > > > >>
> > > > > > > > > > > >> The IRQ interrupt vector should have code like:
> > > > > > > > > > > >>
> > > > > > > > > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > > > > > > > > > > >>
> > > > > > > > > > > >> However, none of the other interrupt vectors will
> > > point to
> > > > > > your
> > > > > > > > > > > >> downloaded code. They will only point to entries in
> > your
> > > > > > > > > > boot code.
> > > > > > > > > > > >>
> > > > > > > > > > > >> That might be good enough.
> > > > > > > > > > > >>
> > > > > > > > > > > >> Richard
> > > > > > > > > > > >>
> > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Sutton Mehaffey
> > > > > > > > > > > > Lookout Portable Security
> > > > > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > >
> > > > > > > > >
> > > > > > > > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > >
> > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Sutton Mehaffey
> > > > > > > > > > Lookout Portable Security
> > > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > >
> > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Sutton Mehaffey
> > > > > > > > Lookout Portable Security
> > > > > > > > 4040 Royal Dr.
> > > > > > > > Kennesaw, GA 30144
> > > > > > > > 770-514-7999, 800-207-6269
> > > > > > > > Fax: 770-514-1285
> > > > > > > > http://www.lookoutportablesecurity.com
>
> > > > >
> > > > > >
> > > > >>
> > > > > > > >
> > > > >
> > > > > >
> > > > >>>
> > > > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> >
> > > > >
> > > > > > >
> > > > >
> > >
>
> >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Miguel Angel Ajo Pelayo
> > > > > > > http://www.nbee.es > >
> > > >> > >
> >
> > > > > > >>>
> > > > > > > +34 91 120 1798
> > > > > > > +34 636 52 25 69
> > > > > > > skype: ajoajoajo
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Sutton Mehaffey
> > > > > > Lookout Portable Security
> > > > > > 4040 Royal Dr.
> > > > > > Kennesaw, GA 30144
> > > > > > 770-514-7999, 800-207-6269
> > > > > > Fax: 770-514-1285
> > > > > > http://www.lookoutportablesecurity.com
>
> > > > >
> > > > > >
> > > > >>
> > > > > > s...@lookoutportablesecurity.com
>
> > >
>
> > >
> > > > >
> > >
>
> > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Miguel Angel Ajo Pelayo
> > > > > http://www.nbee.es > >
> > > >>
> > > > > +34 91 120 1798
> > > > > +34 636 52 25 69
> > > > > skype: ajoajoajo
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Sutton Mehaffey
> > > > Lookout Portable Security
> > > > 4040 Royal Dr.
> > > > Kennesaw, GA 30144
> > > > 770-514-7999, 800-207-6269
> > > > Fax: 770-514-1285
> > > > http://www.lookoutportablesecurity.com
>
> > > > >
> > > > s...@lookoutportablesecurity.com
>
> > >
> >
> >
> > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Miguel Angel Ajo Pelayo
> > > http://www.nbee.es > >
> > > +34 91 120 1798
> > > +34 636 52 25 69
> > > skype: ajoajoajo
> > >
> > >
> > >
> > >
> >
> > --
> > 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
If you want to know where did it crashed exactly you can do something:
Start the bootloader from JTAG:
1) "hit run" (making the bootloader download from the SD)
2) let it run, and then jump to 0x4000 and crash
3) when you're sure it crashed, hit "break"
4) you can know where the crash could come from looking at:
a) current processor state (SYS, IRQ, FIQ, SWI, DABT, CABT...)...
b) LR -> the return address
c) SYS/USER mode: [SP+0] [SP+4] [SP+8] ........
if you're in DATA Abort -> misaligned access, wrong direction access
CODE Abort- > bad instruction at some address (look the PC/LR in SYS/USER
mode registers)
2009/8/20 Sutton Mehaffey
> And I have actually put the same code on the SD card as is running at
> 0x00004000. So, that everything supposedly matches. After the upload,
> code still hangs in bootloader transferring to 0x00004000. But, works
> again if I upload the same code via JTAG.
> Miguel Angel wrote:
> >
> >
> > Sorry sutton, I misunderstood your phrase:
> >
> > """
> > If when the code hangs after my SD card upload (the WDT causes a reset,
> > the bootloader finds that the RAM value is back to 0xA5, meaning valid
> > code at 0x00004000, and tries to transfer to execution to 0x00004000), I
> > load the same code thru Keil's JTAG, the transfer works perfectly again.
> >
> > """
> >
> > 2009/8/20 Sutton Mehaffey
> >
> >>
> >
> > >
> > >
> > > Why do you think the image is incomplete? The SD card code matches
> > > exactly the intermediate serial flash code which matches exactly the
> CPU
> > > code at 0x00004000. I have the image length, which is the size of the
> > > SD card code. I'm not using a checksum, because I check each and every
> > > byte on 2 occasions to verify. I would think that is enough.
> > >
> > >
> > > Miguel Angel wrote:
> > > >
> > > >
> > > > Hmmm,
> > > >
> > > > I think the only way you could fix incomplete image uploads is to
> > > > put more fields on the image "header" inside your startup.s, and,
> just
> > > > after compiling the target app, and building the binary use a program
> > > > in the PC to fill those fields that could be:
> > > >
> > > > 1) Image length
> > > > 2) Image CRC or checksum
> > > >
> > > > with those two fields at startup in your bootloader you could
> > > > check the whole image length for CRC match before jumping into the
> app,
> > > > if it doesn't match, then jump into (for example) "wait for SD to get
> > > > inserted
> > > > to load a new app, and blink leds"
> > > >
> > > > 2009/8/20 Sutton Mehaffey
> >
> >
> > > >
> >
>
> > > >>
> > > >
> > > > >
> > > > >
> > > > > I actually do in the 'Target' link put my base address at
> 0x00004000.
> > > > > That's how the code initially gets transferred from the bootloader
> to
> > > > > app correctly. The bootloader (located at 0) transfers execution
> > > > > perfectly to 0x00004000 before the SD card upload. But, that is
> > loading
> > > > > the 2 sections of code via Keil's JTAG.
> > > > >
> > > > > The problem is that the Keil JTAG does some other programming (that
> I
> > > > > haven't figured out) that my upload from SD card doesn't do.
> > > > >
> > > > > If when the code hangs after my SD card upload (the WDT causes a
> > reset,
> > > > > the bootloader finds that the RAM value is back to 0xA5, meaning
> > valid
> > > > > code at 0x00004000, and tries to transfer to execution to
> > 0x00004000),
> > > I
> > > > > load the same code thru Keil's JTAG, the transfer works perfectly
> > > again.
> > > > >
> > > > >
> > > > > Miguel Angel wrote:
> > > > > >
> > > > > >
> > > > > > Yes, my code will only help if you're using FIQs or SWIs,
> > > > > >
> > > > > > For the application binary, alex's comment is quite important,
> you
> > > > > > should really set the application code base address to 0x4000 or
> > > > > > some jump/calls will get bad addresses.
> > > > > >
> > > > > > 2009/8/20 Sutton Mehaffey
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >>
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I must have missed that post. I don't see it in my folder.
> > > > > > >
> > > > > > > Anyway, I just tried changing the startup file as per your
> > request
> > > > > > > (Miguel), and it still doesn't transfer to 0x4000 correctly. It
> > > hangs
> > > > > > > after a successful upload, just like before.
> > > > > > >
> > > > > >
> > > > > > >
> > > > > > > I do use "Memory Layout from Target Dialog", so maybe Alex's
> > > comment
> > > > > has
> > > > > > > some merit. Maybe I need to learn and use the scatter files.
> > > > > > >
> > > > > > > Sutton
> > > > > > >
> > > > > > >
> > > > > > > Miguel Angel wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > Copy & Paste, I already told you (some weeks ago) a way of
> > doing
> > > it
> > > > > :)
> > > > > > > >
> > > > > > > > This is an example of IRQ pass-thru from my usual bootloader
> to
> > > the
> > > > > > > > application
> > > > > > > > (that starts at 0x2000): (ARM Assembler format for a
> 214x/213x
> > > > > device)
> > > > > > > > Modify your Startup.s to put the vectors this way:
> > > > > > > >
> > > > > > > > Vectors LDR PC, Reset_Addr
> > > > > > > > LDR PC, Undef_Addr
> > > > > > > > LDR PC, SWI_Addr
> > > > > > > > LDR PC, PAbt_Addr
> > > > > > > > LDR PC, DAbt_Addr
> > > > > > > > NOP ; Reserved Vector
> > > > > > > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > > > > > > LDR PC, FIQ_Addr
> > > > > > > >
> > > > > > > > Reset_Addr DCD Reset_Handler
> > > > > > > > Undef_Addr DCD 0x4004
> > > > > > > > SWI_Addr DCD 0x4008
> > > > > > > > PAbt_Addr DCD 0x400C
> > > > > > > > DAbt_Addr DCD 0x4010
> > > > > > > > DCD 0 ; Reserved Address
> > > > > > > > 0x2014
> > > > > > > > FIQ_Addr DCD 0x401C
> > > > > > > >
> > > > > > > > And something important too, is to end the Startup
> > initialization
> > > > > with:
> > > > > > > >
> > > > > > > > MSR CPSR_c, #Mode_SYS (instead of
> > > > > > > > MSR CPSR_c, #Mode_USR)
> > > > > > > >
> > > > > > > > so your app startup can change processor mode again and setup
> > > > all the
> > > > > > > mode's
> > > > > > > > stacks, according
> > > > > > > > to your app configuration.
> > > > > > > >
> > > > > > > > 2009/8/20 Sutton Mehaffey
> >
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >>
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > The code is compiled at 0x00004000, converted to binary and
> > > > loaded
> > > > > on
> > > > > > > > > the SD card. The application always runs at 0x00004000. The
> > > > > > bootloader
> > > > > > > > > is never changed in the field and always runs at 0. The
> > first 6
> > > > > bytes
> > > > > > > > > of the compiled file hold the 0x00004000. I assume that's
> how
> > > > Keil
> > > > > > > > > knows to locate it at 0x00004000 thru the JTAG.
> > > > > > > > >
> > > > > > > > > Where in the startup code do I specify that the vectors
> > starts
> > > at
> > > > > > > > > 0x00004000?
> > > > > > > > >
> > > > > > > > > typedef void (*APP)(void);
> > > > > > > > > APP app = (APP)0x00004000;
> > > > > > > > >
> > > > > > > > > app();
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Michael Anton wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > How does your bootloader handle revectoring all of the
> > > > > interrupts?
> > > > > > > > > > I don't understand why the vectors located at 0x0004000
> > would
> > > > > > be the
> > > > > > > > > > same as those at 0x00000000, since they are for different
> > > > > > > applications.
> > > > > > > > > >
> > > > > > > > > > Am I to understand that the code on the SD card begins
> > at 0?
> > > If
> > > > > so
> > > > > > > that
> > > > > > > > > > is not correct, as it should be located at 0x00004000. It
> > > > > wouldn't
> > > > > > > make
> > > > > > > > > > sense to have the vectors in the main application loaded
> at
> > > > zero,
> > > > > > > > unless
> > > > > > > > > > they would be executed from there. Also, given that the
> > > startup
> > > > > > code
> > > > > > > > > > usually contains the vectors and the startup routines,
> they
> > > > > > certainly
> > > > > > > > > > shouldn't be located at 0.
> > > > > > > > > >
> > > > > > > > > > How do you jump to the main app from your bootloader?
> > > > > > > > > >
> > > > > > > > > > This would all me much easier for us to figure out if we
> > > > had the
> > > > > > > > > > relevant bits of code.
> > > > > > > > > >
> > > > > > > > > > Mike
> > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: l...
> > >
>
> > > > > 2540yahoogroups.com>>
> > >
> > > > > >
> > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > [mailto:l...
> >
> >
> > > > > 2540yahoogroups.com>>
> > >
> > > > > >
> > > > > 2540yahoogroups.com>>
> > > > >
> > > > > > > > > 2540yahoogroups.com>
> > > > > > >
> > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > > > > > lpc2000%40yahoogroups.com > >>]On
> > > > > > > > > > Behalf
> > > > > > > > > > > Of Sutton Mehaffey
> > > > > > > > > > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > > > > > > > > > To: l...
> > >
>
> > > > > 2540yahoogroups.com>>
> > >
> > > > > >
> > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > >
> > > > > > > > > > > Subject: Re: [lpc2000] Re: new SD code transfer to
> > > > LPC2148 not
> > > > > > > quite
> > > > > > > > > > > working
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I have a variable in serial eeprom that indicates
> > 'app code
> > > > > good'
> > > > > > > or
> > > > > > > > > > > not. I use an intermediate serial flash to hold the
> file
> > > from
> > > > > the
> > > > > > > SD
> > > > > > > > > > > card. I compare byte for byte the code on the SD card
> to
> > > the
> > > > > > serial
> > > > > > > > > > > flash. When valid, I change the serial eeprom value
> > to 0. I
> > > > > > > > > > > initiate a
> > > > > > > > > > > WDT reset and the bootloader at 0 sees that the eeprom
> > > > value is
> > > > > 0
> > > > > > > and
> > > > > > > > > > > starts the upload from the serial flash to the CPU
> flash
> > > (via
> > > > > > > > > > > IAP). I
> > > > > > > > > > > compare byte for byte the upload to 0x00004000 and when
> > > > > > > > > > > valid, I change
> > > > > > > > > > > the serial eeprom value to 'good code (0xA5). I
> initiate
> > > > > another
> > > > > > > WDT
> > > > > > > > > > > reset, which works, but the transfer to 0x00004000
> > doesn't
> > > > > work.
> > > > > > > > > > >
> > > > > > > > > > > This update is to be done in the field by customers
> > without
> > > > > JTAG.
> > > > > > > > > > >
> > > > > > > > > > > From the previous posts, I guess I'm trying to figure
> out
> > > how
> > > > > the
> > > > > > > > > > > interrupt vectors are affected by all of this. They are
> > > > > > > > > > > stored at 0.
> > > > > > > > > > > I'm guessing by Richard's post that depending on what
> > > > > > application I
> > > > > > > > > > > loaded last by JTAG (bootloader or app), the interrupt
> > > > > > vectors are
> > > > > > > > > > > correct, but not for the first loaded code. The code
> > > > > > > > > > > 0x00-0x1C on the
> > > > > > > > > > > SD card (which is Keil's compiled code converted to
> > binary)
> > > > > looks
> > > > > > > > > > > exactly like the code at 0x00-0x1C at 0x00000000. It is
> > > > put at
> > > > > > > > > > > 0x00004000, which I thought was sufficient. Still
> > trying to
> > > > > > > > > > > figure it out.
> > > > > > > > > > >
> > > > > > > > > > > Sutton
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > m...@compusmart.ab.ca
> > >
>
> > > > > 2540compusmart.ab.ca>>
> > > > > > > > manton%40compusmart.ab.ca >
> > > > > > > > > > > > > manton%40compusmart.ab.ca >
> > > > > > > > > > > > > > > > > manton%40compusmart.ab.ca >
> > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > What criteria do you use to determine if control can
> be
> > > > > passed
> > > > > > > from
> > > > > > > > > > > > your bootloader to the main application? Do you use a
> > > > CRC or
> > > > > > > verify
> > > > > > > > > > > > it to make sure
> > > > > > > > > > > > it was written correctly?
> > > > > > > > > > > >
> > > > > > > > > > > > Could you use your bootloader to write the main
> > app, and
> > > > > > then do
> > > > > > > a
> > > > > > > > > > > > verify via JTAG to see if they are the same?
> > > > > > > > > > > >
> > > > > > > > > > > > Mike
> > > > > > > > > > > >
> > > > > > > > > > > > Quoting Sutton Mehaffey
> > > >
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >>:
> > > > > > > > > > > >
> > > > > > > > > > > > > OK. So, what is happening in Keil's uVision when
> > I use
> > > > > > > > > > > the JTAG to load
> > > > > > > > > > > > > the bootloader at 0x00000000 and then the app at
> > > > > > > > > > > 0x00004000? Is the
> > > > > > > > > > > > > one I load last is the one that has the correct
> > > interrupt
> > > > > > > vector
> > > > > > > > > > > > > pointers? It doesn't seem to matter which one I
> load
> > > > > > > > > > > first and last,
> > > > > > > > > > > > > the interrupts in both sets of code seem to work
> just
> > > > fine
> > > > > > > > and the
> > > > > > > > > > > > > bootloader transfers correctly to the app.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Sutton
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > rtstofer wrote:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> --- In l...
> >
> >
> > > > > 2540yahoogroups.com>
> > > >
> > > > > >
> > > > > 2540yahoogroups.com>>
> > > > >
> > > > > > > > > 2540yahoogroups.com>
> > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > >
> > > >
> > > > > 2540yahoogroups.com>
> > > > > > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > > >
> > > >
> > > > > 2540yahoogroups.com>
> > > > > > > > > > >
> > > > > > > 2540yahoogroups.com>>,
> > > > > > >
> > > > > > > > > > > > >> "Sutton Mehaffey" wrote:
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > Because I'm not clear on why, why do I need to
> > remap
> > > > > > > > > > > the interrupt
> > > > > > > > > > > > >> vector when my bootloader code at 0x00000000 never
> > > > > > > > > > > changes? I'm not
> > > > > > > > > > > > >> copying my SD code to location 0x00000000.
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > Sutton
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> So the vectors point to the functions in the
> > code that
> > > > > > > > > > > is actually
> > > > > > > > > > > > >> running.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Now, if you ignore every vector except IRG and
> > you do
> > > > > > > > > > > the VIC trick of
> > > > > > > > > > > > >> using the vector to get the address from the
> > VIC, then
> > > > > > > > > > > you don't have
> > > > > > > > > > > > >> to do anything.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> The IRQ interrupt vector should have code like:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> However, none of the other interrupt vectors will
> > > > point to
> > > > > > > your
> > > > > > > > > > > > >> downloaded code. They will only point to entries
> in
> > > your
> > > > > > > > > > > boot code.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> That might be good enough.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Richard
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Sutton Mehaffey
> > > > > > > > > > > > > Lookout Portable Security
> > > > > > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Sutton Mehaffey
> > > > > > > > > > > Lookout Portable Security
> > > > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Sutton Mehaffey
> > > > > > > > > Lookout Portable Security
> > > > > > > > > 4040 Royal Dr.
> > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > 770-514-7999, 800-207-6269
> > > > > > > > > Fax: 770-514-1285
> > > > > > > > > http://www.lookoutportablesecurity.com
> >
> > > > > > >
> > > > > > > >
> > > > > > >>
> > > > > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > >>>
> > > > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Miguel Angel Ajo Pelayo
> > > > > > > > http://www.nbee.es > > >
> > > > >> > > >
> > >
> > > > > > > > >>>
> > > > > > > > +34 91 120 1798
> > > > > > > > +34 636 52 25 69
> > > > > > > > skype: ajoajoajo
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Sutton Mehaffey
> > > > > > > Lookout Portable Security
> > > > > > > 4040 Royal Dr.
> > > > > > > Kennesaw, GA 30144
> > > > > > > 770-514-7999, 800-207-6269
> > > > > > > Fax: 770-514-1285
> > > > > > > http://www.lookoutportablesecurity.com
> >
> > > > > > >
> > > > > > > >
> > > > > > >>
> > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Miguel Angel Ajo Pelayo
> > > > > > http://www.nbee.es > > >
> > > > >>
> > > > > > +34 91 120 1798
> > > > > > +34 636 52 25 69
> > > > > > skype: ajoajoajo
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Sutton Mehaffey
> > > > > Lookout Portable Security
> > > > > 4040 Royal Dr.
> > > > > Kennesaw, GA 30144
> > > > > 770-514-7999, 800-207-6269
> > > > > Fax: 770-514-1285
> > > > > http://www.lookoutportablesecurity.com
> >
> > > > > > >
> > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
> >
> > >
> > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Miguel Angel Ajo Pelayo
> > > > http://www.nbee.es > > >
> > > > +34 91 120 1798
> > > > +34 636 52 25 69
> > > > skype: ajoajoajo
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Sutton Mehaffey
> > > Lookout Portable Security
> > > 4040 Royal Dr.
> > > Kennesaw, GA 30144
> > > 770-514-7999, 800-207-6269
> > > Fax: 770-514-1285
> > > http://www.lookoutportablesecurity.com
> >
> > > s...@lookoutportablesecurity.com
> > > >
> > >
> > >
> > >
> >
> > --
> > Miguel Angel Ajo Pelayo
> > http://www.nbee.es
> > +34 91 120 1798
> > +34 636 52 25 69
> > skype: ajoajoajo
> >
> >
> >
> > --
> Sutton Mehaffey
> Lookout Portable Security
> 4040 Royal Dr.
> Kennesaw, GA 30144
> 770-514-7999, 800-207-6269
> Fax: 770-514-1285
> http://www.lookoutportablesecurity.com
> s...@lookoutportablesecurity.com
>
--
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
Start the bootloader from JTAG:
1) "hit run" (making the bootloader download from the SD)
2) let it run, and then jump to 0x4000 and crash
3) when you're sure it crashed, hit "break"
4) you can know where the crash could come from looking at:
a) current processor state (SYS, IRQ, FIQ, SWI, DABT, CABT...)...
b) LR -> the return address
c) SYS/USER mode: [SP+0] [SP+4] [SP+8] ........
if you're in DATA Abort -> misaligned access, wrong direction access
CODE Abort- > bad instruction at some address (look the PC/LR in SYS/USER
mode registers)
2009/8/20 Sutton Mehaffey
> And I have actually put the same code on the SD card as is running at
> 0x00004000. So, that everything supposedly matches. After the upload,
> code still hangs in bootloader transferring to 0x00004000. But, works
> again if I upload the same code via JTAG.
> Miguel Angel wrote:
> >
> >
> > Sorry sutton, I misunderstood your phrase:
> >
> > """
> > If when the code hangs after my SD card upload (the WDT causes a reset,
> > the bootloader finds that the RAM value is back to 0xA5, meaning valid
> > code at 0x00004000, and tries to transfer to execution to 0x00004000), I
> > load the same code thru Keil's JTAG, the transfer works perfectly again.
> >
> > """
> >
> > 2009/8/20 Sutton Mehaffey
> >
> >>
> >
> > >
> > >
> > > Why do you think the image is incomplete? The SD card code matches
> > > exactly the intermediate serial flash code which matches exactly the
> CPU
> > > code at 0x00004000. I have the image length, which is the size of the
> > > SD card code. I'm not using a checksum, because I check each and every
> > > byte on 2 occasions to verify. I would think that is enough.
> > >
> > >
> > > Miguel Angel wrote:
> > > >
> > > >
> > > > Hmmm,
> > > >
> > > > I think the only way you could fix incomplete image uploads is to
> > > > put more fields on the image "header" inside your startup.s, and,
> just
> > > > after compiling the target app, and building the binary use a program
> > > > in the PC to fill those fields that could be:
> > > >
> > > > 1) Image length
> > > > 2) Image CRC or checksum
> > > >
> > > > with those two fields at startup in your bootloader you could
> > > > check the whole image length for CRC match before jumping into the
> app,
> > > > if it doesn't match, then jump into (for example) "wait for SD to get
> > > > inserted
> > > > to load a new app, and blink leds"
> > > >
> > > > 2009/8/20 Sutton Mehaffey
> >
> >
> > > >
> >
>
> > > >>
> > > >
> > > > >
> > > > >
> > > > > I actually do in the 'Target' link put my base address at
> 0x00004000.
> > > > > That's how the code initially gets transferred from the bootloader
> to
> > > > > app correctly. The bootloader (located at 0) transfers execution
> > > > > perfectly to 0x00004000 before the SD card upload. But, that is
> > loading
> > > > > the 2 sections of code via Keil's JTAG.
> > > > >
> > > > > The problem is that the Keil JTAG does some other programming (that
> I
> > > > > haven't figured out) that my upload from SD card doesn't do.
> > > > >
> > > > > If when the code hangs after my SD card upload (the WDT causes a
> > reset,
> > > > > the bootloader finds that the RAM value is back to 0xA5, meaning
> > valid
> > > > > code at 0x00004000, and tries to transfer to execution to
> > 0x00004000),
> > > I
> > > > > load the same code thru Keil's JTAG, the transfer works perfectly
> > > again.
> > > > >
> > > > >
> > > > > Miguel Angel wrote:
> > > > > >
> > > > > >
> > > > > > Yes, my code will only help if you're using FIQs or SWIs,
> > > > > >
> > > > > > For the application binary, alex's comment is quite important,
> you
> > > > > > should really set the application code base address to 0x4000 or
> > > > > > some jump/calls will get bad addresses.
> > > > > >
> > > > > > 2009/8/20 Sutton Mehaffey
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >>
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I must have missed that post. I don't see it in my folder.
> > > > > > >
> > > > > > > Anyway, I just tried changing the startup file as per your
> > request
> > > > > > > (Miguel), and it still doesn't transfer to 0x4000 correctly. It
> > > hangs
> > > > > > > after a successful upload, just like before.
> > > > > > >
> > > > > >
> > > > > > >
> > > > > > > I do use "Memory Layout from Target Dialog", so maybe Alex's
> > > comment
> > > > > has
> > > > > > > some merit. Maybe I need to learn and use the scatter files.
> > > > > > >
> > > > > > > Sutton
> > > > > > >
> > > > > > >
> > > > > > > Miguel Angel wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > Copy & Paste, I already told you (some weeks ago) a way of
> > doing
> > > it
> > > > > :)
> > > > > > > >
> > > > > > > > This is an example of IRQ pass-thru from my usual bootloader
> to
> > > the
> > > > > > > > application
> > > > > > > > (that starts at 0x2000): (ARM Assembler format for a
> 214x/213x
> > > > > device)
> > > > > > > > Modify your Startup.s to put the vectors this way:
> > > > > > > >
> > > > > > > > Vectors LDR PC, Reset_Addr
> > > > > > > > LDR PC, Undef_Addr
> > > > > > > > LDR PC, SWI_Addr
> > > > > > > > LDR PC, PAbt_Addr
> > > > > > > > LDR PC, DAbt_Addr
> > > > > > > > NOP ; Reserved Vector
> > > > > > > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > > > > > > LDR PC, FIQ_Addr
> > > > > > > >
> > > > > > > > Reset_Addr DCD Reset_Handler
> > > > > > > > Undef_Addr DCD 0x4004
> > > > > > > > SWI_Addr DCD 0x4008
> > > > > > > > PAbt_Addr DCD 0x400C
> > > > > > > > DAbt_Addr DCD 0x4010
> > > > > > > > DCD 0 ; Reserved Address
> > > > > > > > 0x2014
> > > > > > > > FIQ_Addr DCD 0x401C
> > > > > > > >
> > > > > > > > And something important too, is to end the Startup
> > initialization
> > > > > with:
> > > > > > > >
> > > > > > > > MSR CPSR_c, #Mode_SYS (instead of
> > > > > > > > MSR CPSR_c, #Mode_USR)
> > > > > > > >
> > > > > > > > so your app startup can change processor mode again and setup
> > > > all the
> > > > > > > mode's
> > > > > > > > stacks, according
> > > > > > > > to your app configuration.
> > > > > > > >
> > > > > > > > 2009/8/20 Sutton Mehaffey
> >
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >>
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > The code is compiled at 0x00004000, converted to binary and
> > > > loaded
> > > > > on
> > > > > > > > > the SD card. The application always runs at 0x00004000. The
> > > > > > bootloader
> > > > > > > > > is never changed in the field and always runs at 0. The
> > first 6
> > > > > bytes
> > > > > > > > > of the compiled file hold the 0x00004000. I assume that's
> how
> > > > Keil
> > > > > > > > > knows to locate it at 0x00004000 thru the JTAG.
> > > > > > > > >
> > > > > > > > > Where in the startup code do I specify that the vectors
> > starts
> > > at
> > > > > > > > > 0x00004000?
> > > > > > > > >
> > > > > > > > > typedef void (*APP)(void);
> > > > > > > > > APP app = (APP)0x00004000;
> > > > > > > > >
> > > > > > > > > app();
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Michael Anton wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > How does your bootloader handle revectoring all of the
> > > > > interrupts?
> > > > > > > > > > I don't understand why the vectors located at 0x0004000
> > would
> > > > > > be the
> > > > > > > > > > same as those at 0x00000000, since they are for different
> > > > > > > applications.
> > > > > > > > > >
> > > > > > > > > > Am I to understand that the code on the SD card begins
> > at 0?
> > > If
> > > > > so
> > > > > > > that
> > > > > > > > > > is not correct, as it should be located at 0x00004000. It
> > > > > wouldn't
> > > > > > > make
> > > > > > > > > > sense to have the vectors in the main application loaded
> at
> > > > zero,
> > > > > > > > unless
> > > > > > > > > > they would be executed from there. Also, given that the
> > > startup
> > > > > > code
> > > > > > > > > > usually contains the vectors and the startup routines,
> they
> > > > > > certainly
> > > > > > > > > > shouldn't be located at 0.
> > > > > > > > > >
> > > > > > > > > > How do you jump to the main app from your bootloader?
> > > > > > > > > >
> > > > > > > > > > This would all me much easier for us to figure out if we
> > > > had the
> > > > > > > > > > relevant bits of code.
> > > > > > > > > >
> > > > > > > > > > Mike
> > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: l...
> > >
>
> > > > > 2540yahoogroups.com>>
> > >
> > > > > >
> > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > [mailto:l...
> >
> >
> > > > > 2540yahoogroups.com>>
> > >
> > > > > >
> > > > > 2540yahoogroups.com>>
> > > > >
> > > > > > > > > 2540yahoogroups.com>
> > > > > > >
> > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > > > > > lpc2000%40yahoogroups.com > >>]On
> > > > > > > > > > Behalf
> > > > > > > > > > > Of Sutton Mehaffey
> > > > > > > > > > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > > > > > > > > > To: l...
> > >
>
> > > > > 2540yahoogroups.com>>
> > >
> > > > > >
> > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > >
> > > > > > > > > > > Subject: Re: [lpc2000] Re: new SD code transfer to
> > > > LPC2148 not
> > > > > > > quite
> > > > > > > > > > > working
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I have a variable in serial eeprom that indicates
> > 'app code
> > > > > good'
> > > > > > > or
> > > > > > > > > > > not. I use an intermediate serial flash to hold the
> file
> > > from
> > > > > the
> > > > > > > SD
> > > > > > > > > > > card. I compare byte for byte the code on the SD card
> to
> > > the
> > > > > > serial
> > > > > > > > > > > flash. When valid, I change the serial eeprom value
> > to 0. I
> > > > > > > > > > > initiate a
> > > > > > > > > > > WDT reset and the bootloader at 0 sees that the eeprom
> > > > value is
> > > > > 0
> > > > > > > and
> > > > > > > > > > > starts the upload from the serial flash to the CPU
> flash
> > > (via
> > > > > > > > > > > IAP). I
> > > > > > > > > > > compare byte for byte the upload to 0x00004000 and when
> > > > > > > > > > > valid, I change
> > > > > > > > > > > the serial eeprom value to 'good code (0xA5). I
> initiate
> > > > > another
> > > > > > > WDT
> > > > > > > > > > > reset, which works, but the transfer to 0x00004000
> > doesn't
> > > > > work.
> > > > > > > > > > >
> > > > > > > > > > > This update is to be done in the field by customers
> > without
> > > > > JTAG.
> > > > > > > > > > >
> > > > > > > > > > > From the previous posts, I guess I'm trying to figure
> out
> > > how
> > > > > the
> > > > > > > > > > > interrupt vectors are affected by all of this. They are
> > > > > > > > > > > stored at 0.
> > > > > > > > > > > I'm guessing by Richard's post that depending on what
> > > > > > application I
> > > > > > > > > > > loaded last by JTAG (bootloader or app), the interrupt
> > > > > > vectors are
> > > > > > > > > > > correct, but not for the first loaded code. The code
> > > > > > > > > > > 0x00-0x1C on the
> > > > > > > > > > > SD card (which is Keil's compiled code converted to
> > binary)
> > > > > looks
> > > > > > > > > > > exactly like the code at 0x00-0x1C at 0x00000000. It is
> > > > put at
> > > > > > > > > > > 0x00004000, which I thought was sufficient. Still
> > trying to
> > > > > > > > > > > figure it out.
> > > > > > > > > > >
> > > > > > > > > > > Sutton
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > m...@compusmart.ab.ca
> > >
>
> > > > > 2540compusmart.ab.ca>>
> > > > > > > > manton%40compusmart.ab.ca >
> > > > > > > > > > > > > manton%40compusmart.ab.ca >
> > > > > > > > > > > > > > > > > manton%40compusmart.ab.ca >
> > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > What criteria do you use to determine if control can
> be
> > > > > passed
> > > > > > > from
> > > > > > > > > > > > your bootloader to the main application? Do you use a
> > > > CRC or
> > > > > > > verify
> > > > > > > > > > > > it to make sure
> > > > > > > > > > > > it was written correctly?
> > > > > > > > > > > >
> > > > > > > > > > > > Could you use your bootloader to write the main
> > app, and
> > > > > > then do
> > > > > > > a
> > > > > > > > > > > > verify via JTAG to see if they are the same?
> > > > > > > > > > > >
> > > > > > > > > > > > Mike
> > > > > > > > > > > >
> > > > > > > > > > > > Quoting Sutton Mehaffey
> > > >
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >>:
> > > > > > > > > > > >
> > > > > > > > > > > > > OK. So, what is happening in Keil's uVision when
> > I use
> > > > > > > > > > > the JTAG to load
> > > > > > > > > > > > > the bootloader at 0x00000000 and then the app at
> > > > > > > > > > > 0x00004000? Is the
> > > > > > > > > > > > > one I load last is the one that has the correct
> > > interrupt
> > > > > > > vector
> > > > > > > > > > > > > pointers? It doesn't seem to matter which one I
> load
> > > > > > > > > > > first and last,
> > > > > > > > > > > > > the interrupts in both sets of code seem to work
> just
> > > > fine
> > > > > > > > and the
> > > > > > > > > > > > > bootloader transfers correctly to the app.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Sutton
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > rtstofer wrote:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> --- In l...
> >
> >
> > > > > 2540yahoogroups.com>
> > > >
> > > > > >
> > > > > 2540yahoogroups.com>>
> > > > >
> > > > > > > > > 2540yahoogroups.com>
> > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > >
> > > >
> > > > > 2540yahoogroups.com>
> > > > > > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > > >
> > > >
> > > > > 2540yahoogroups.com>
> > > > > > > > > > >
> > > > > > > 2540yahoogroups.com>>,
> > > > > > >
> > > > > > > > > > > > >> "Sutton Mehaffey" wrote:
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > Because I'm not clear on why, why do I need to
> > remap
> > > > > > > > > > > the interrupt
> > > > > > > > > > > > >> vector when my bootloader code at 0x00000000 never
> > > > > > > > > > > changes? I'm not
> > > > > > > > > > > > >> copying my SD code to location 0x00000000.
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > Sutton
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> So the vectors point to the functions in the
> > code that
> > > > > > > > > > > is actually
> > > > > > > > > > > > >> running.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Now, if you ignore every vector except IRG and
> > you do
> > > > > > > > > > > the VIC trick of
> > > > > > > > > > > > >> using the vector to get the address from the
> > VIC, then
> > > > > > > > > > > you don't have
> > > > > > > > > > > > >> to do anything.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> The IRQ interrupt vector should have code like:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read the VIC */
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> However, none of the other interrupt vectors will
> > > > point to
> > > > > > > your
> > > > > > > > > > > > >> downloaded code. They will only point to entries
> in
> > > your
> > > > > > > > > > > boot code.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> That might be good enough.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Richard
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Sutton Mehaffey
> > > > > > > > > > > > > Lookout Portable Security
> > > > > > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Sutton Mehaffey
> > > > > > > > > > > Lookout Portable Security
> > > > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Sutton Mehaffey
> > > > > > > > > Lookout Portable Security
> > > > > > > > > 4040 Royal Dr.
> > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > 770-514-7999, 800-207-6269
> > > > > > > > > Fax: 770-514-1285
> > > > > > > > > http://www.lookoutportablesecurity.com
> >
> > > > > > >
> > > > > > > >
> > > > > > >>
> > > > > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > >>>
> > > > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
> > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Miguel Angel Ajo Pelayo
> > > > > > > > http://www.nbee.es > > >
> > > > >> > > >
> > >
> > > > > > > > >>>
> > > > > > > > +34 91 120 1798
> > > > > > > > +34 636 52 25 69
> > > > > > > > skype: ajoajoajo
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Sutton Mehaffey
> > > > > > > Lookout Portable Security
> > > > > > > 4040 Royal Dr.
> > > > > > > Kennesaw, GA 30144
> > > > > > > 770-514-7999, 800-207-6269
> > > > > > > Fax: 770-514-1285
> > > > > > > http://www.lookoutportablesecurity.com
> >
> > > > > > >
> > > > > > > >
> > > > > > >>
> > > > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
>
> > > >
> > > > > >
> > > >
> >
>
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Miguel Angel Ajo Pelayo
> > > > > > http://www.nbee.es > > >
> > > > >>
> > > > > > +34 91 120 1798
> > > > > > +34 636 52 25 69
> > > > > > skype: ajoajoajo
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Sutton Mehaffey
> > > > > Lookout Portable Security
> > > > > 4040 Royal Dr.
> > > > > Kennesaw, GA 30144
> > > > > 770-514-7999, 800-207-6269
> > > > > Fax: 770-514-1285
> > > > > http://www.lookoutportablesecurity.com
> >
> > > > > > >
> > > > > s...@lookoutportablesecurity.com
> >
> >
> > > >
> >
> >
> > >
> > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Miguel Angel Ajo Pelayo
> > > > http://www.nbee.es > > >
> > > > +34 91 120 1798
> > > > +34 636 52 25 69
> > > > skype: ajoajoajo
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > 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:
I have a couple of questions:
1. Does your main application has an option to jump to the bootloader? (let's say, when a SD card is inserted or by any other means, for example)?
2. If so, does it works? (assuming that the main application is running correctly, which is the case when you program it via JTAG).
3. Does your bootloader gets corrupted after finishing the installation of the new main application from SD card? That is, can you install multiple times the main application from SD card, without having to reprogram the bootloader application via JTAG?
4. After programming both the bootloader and the main application with the JTAG (as you have done to confirm that the main application works), does the bootloader works correctly? That is, can the bootloader upload a new main application from SD card (without having to be reprogrammed via JTAG)?
I still believe the solution lies on using the scatter files to properly set the correct location for the necessary sections, for each target (bootloader, main application debug target, and main application Release target). This also requires the correct interrupt vector remapping in the startup.s file.
Would you be able to share the .s files and scatter files used?
Regards,
Alex
I have a couple of questions:
1. Does your main application has an option to jump to the bootloader? (let's say, when a SD card is inserted or by any other means, for example)?
2. If so, does it works? (assuming that the main application is running correctly, which is the case when you program it via JTAG).
3. Does your bootloader gets corrupted after finishing the installation of the new main application from SD card? That is, can you install multiple times the main application from SD card, without having to reprogram the bootloader application via JTAG?
4. After programming both the bootloader and the main application with the JTAG (as you have done to confirm that the main application works), does the bootloader works correctly? That is, can the bootloader upload a new main application from SD card (without having to be reprogrammed via JTAG)?
I still believe the solution lies on using the scatter files to properly set the correct location for the necessary sections, for each target (bootloader, main application debug target, and main application Release target). This also requires the correct interrupt vector remapping in the startup.s file.
Would you be able to share the .s files and scatter files used?
Regards,
Alex
Reply by ●August 20, 20092009-08-20
Again, I would suggest that you use the bootloader to write the
app image, and then use the JTAG to compare it against the original.
Perhaps something is not written as you expect, or there are
problems with the binary image.
Mike
> -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of Sutton Mehaffey
> Sent: Thursday, August 20, 2009 10:24 AM
> To: l...
> Subject: Re: [lpc2000] Re: new SD code transfer to LPC2148 not quite
> working
> And I have actually put the same code on the SD card as is running at
> 0x00004000. So, that everything supposedly matches. After
> the upload,
> code still hangs in bootloader transferring to 0x00004000.
> But, works
> again if I upload the same code via JTAG.
>
> Miguel Angel wrote:
> >
> >
> > Sorry sutton, I misunderstood your phrase:
> >
> > """
> > If when the code hangs after my SD card upload (the WDT
> causes a reset,
> > the bootloader finds that the RAM value is back to 0xA5,
> meaning valid
> > code at 0x00004000, and tries to transfer to execution to
> 0x00004000), I
> > load the same code thru Keil's JTAG, the transfer works
> perfectly again.
> >
> > """
> >
> > 2009/8/20 Sutton Mehaffey > > >
> >
> > >
> > >
> > > Why do you think the image is incomplete? The SD card
> code matches
> > > exactly the intermediate serial flash code which matches
> exactly the CPU
> > > code at 0x00004000. I have the image length, which is
> the size of the
> > > SD card code. I'm not using a checksum, because I check
> each and every
> > > byte on 2 occasions to verify. I would think that is enough.
> > >
> > >
> > > Miguel Angel wrote:
> > > >
> > > >
> > > > Hmmm,
> > > >
> > > > I think the only way you could fix incomplete image
> uploads is to
> > > > put more fields on the image "header" inside your
> startup.s, and, just
> > > > after compiling the target app, and building the
> binary use a program
> > > > in the PC to fill those fields that could be:
> > > >
> > > > 1) Image length
> > > > 2) Image CRC or checksum
> > > >
> > > > with those two fields at startup in your bootloader you could
> > > > check the whole image length for CRC match before
> jumping into the app,
> > > > if it doesn't match, then jump into (for example)
> "wait for SD to get
> > > > inserted
> > > > to load a new app, and blink leds"
> > > >
> > > > 2009/8/20 Sutton Mehaffey > >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.com>
> > > >>
> > > >
> > > > >
> > > > >
> > > > > I actually do in the 'Target' link put my base
> address at 0x00004000.
> > > > > That's how the code initially gets transferred from
> the bootloader to
> > > > > app correctly. The bootloader (located at 0)
> transfers execution
> > > > > perfectly to 0x00004000 before the SD card upload.
> But, that is
> > loading
> > > > > the 2 sections of code via Keil's JTAG.
> > > > >
> > > > > The problem is that the Keil JTAG does some other
> programming (that I
> > > > > haven't figured out) that my upload from SD card doesn't do.
> > > > >
> > > > > If when the code hangs after my SD card upload (the
> WDT causes a
> > reset,
> > > > > the bootloader finds that the RAM value is back to
> 0xA5, meaning
> > valid
> > > > > code at 0x00004000, and tries to transfer to execution to
> > 0x00004000),
> > > I
> > > > > load the same code thru Keil's JTAG, the transfer
> works perfectly
> > > again.
> > > > >
> > > > >
> > > > > Miguel Angel wrote:
> > > > > >
> > > > > >
> > > > > > Yes, my code will only help if you're using FIQs or SWIs,
> > > > > >
> > > > > > For the application binary, alex's comment is
> quite important, you
> > > > > > should really set the application code base
> address to 0x4000 or
> > > > > > some jump/calls will get bad addresses.
> > > > > >
> > > > > > 2009/8/20 Sutton Mehaffey
> > >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.com>
> > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > > >>
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I must have missed that post. I don't see it in
> my folder.
> > > > > > >
> > > > > > > Anyway, I just tried changing the startup file
> as per your
> > request
> > > > > > > (Miguel), and it still doesn't transfer to
> 0x4000 correctly. It
> > > hangs
> > > > > > > after a successful upload, just like before.
> > > > > > >
> > > > > >
> > > > > > >
> > > > > > > I do use "Memory Layout from Target Dialog", so
> maybe Alex's
> > > comment
> > > > > has
> > > > > > > some merit. Maybe I need to learn and use the
> scatter files.
> > > > > > >
> > > > > > > Sutton
> > > > > > >
> > > > > > >
> > > > > > > Miguel Angel wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > Copy & Paste, I already told you (some weeks
> ago) a way of
> > doing
> > > it
> > > > > :)
> > > > > > > >
> > > > > > > > This is an example of IRQ pass-thru from my
> usual bootloader to
> > > the
> > > > > > > > application
> > > > > > > > (that starts at 0x2000): (ARM Assembler format
> for a 214x/213x
> > > > > device)
> > > > > > > > Modify your Startup.s to put the vectors this way:
> > > > > > > >
> > > > > > > > Vectors LDR PC, Reset_Addr
> > > > > > > > LDR PC, Undef_Addr
> > > > > > > > LDR PC, SWI_Addr
> > > > > > > > LDR PC, PAbt_Addr
> > > > > > > > LDR PC, DAbt_Addr
> > > > > > > > NOP ; Reserved Vector
> > > > > > > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > > > > > > LDR PC, FIQ_Addr
> > > > > > > >
> > > > > > > > Reset_Addr DCD Reset_Handler
> > > > > > > > Undef_Addr DCD 0x4004
> > > > > > > > SWI_Addr DCD 0x4008
> > > > > > > > PAbt_Addr DCD 0x400C
> > > > > > > > DAbt_Addr DCD 0x4010
> > > > > > > > DCD 0 ; Reserved Address
> > > > > > > > 0x2014
> > > > > > > > FIQ_Addr DCD 0x401C
> > > > > > > >
> > > > > > > > And something important too, is to end the Startup
> > initialization
> > > > > with:
> > > > > > > >
> > > > > > > > MSR CPSR_c, #Mode_SYS (instead of
> > > > > > > > MSR CPSR_c, #Mode_USR)
> > > > > > > >
> > > > > > > > so your app startup can change processor mode
> again and setup
> > > > all the
> > > > > > > mode's
> > > > > > > > stacks, according
> > > > > > > > to your app configuration.
> > > > > > > >
> > > > > > > > 2009/8/20 Sutton Mehaffey
> > > >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.com>
> > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > > >>
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > The code is compiled at 0x00004000,
> converted to binary and
> > > > loaded
> > > > > on
> > > > > > > > > the SD card. The application always runs at
> 0x00004000. The
> > > > > > bootloader
> > > > > > > > > is never changed in the field and always
> runs at 0. The
> > first 6
> > > > > bytes
> > > > > > > > > of the compiled file hold the 0x00004000. I
> assume that's how
> > > > Keil
> > > > > > > > > knows to locate it at 0x00004000 thru the JTAG.
> > > > > > > > >
> > > > > > > > > Where in the startup code do I specify that
> the vectors
> > starts
> > > at
> > > > > > > > > 0x00004000?
> > > > > > > > >
> > > > > > > > > typedef void (*APP)(void);
> > > > > > > > > APP app = (APP)0x00004000;
> > > > > > > > >
> > > > > > > > > app();
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Michael Anton wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > How does your bootloader handle
> revectoring all of the
> > > > > interrupts?
> > > > > > > > > > I don't understand why the vectors located
> at 0x0004000
> > would
> > > > > > be the
> > > > > > > > > > same as those at 0x00000000, since they
> are for different
> > > > > > > applications.
> > > > > > > > > >
> > > > > > > > > > Am I to understand that the code on the SD
> card begins
> > at 0?
> > > If
> > > > > so
> > > > > > > that
> > > > > > > > > > is not correct, as it should be located at
> 0x00004000. It
> > > > > wouldn't
> > > > > > > make
> > > > > > > > > > sense to have the vectors in the main
> application loaded at
> > > > zero,
> > > > > > > > unless
> > > > > > > > > > they would be executed from there. Also,
> given that the
> > > startup
> > > > > > code
> > > > > > > > > > usually contains the vectors and the
> startup routines, they
> > > > > > certainly
> > > > > > > > > > shouldn't be located at 0.
> > > > > > > > > >
> > > > > > > > > > How do you jump to the main app from your
> bootloader?
> > > > > > > > > >
> > > > > > > > > > This would all me much easier for us to
> figure out if we
> > > > had the
> > > > > > > > > > relevant bits of code.
> > > > > > > > > >
> > > > > > > > > > Mike
> > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: l...
> >
> > > > > >
> > >
> > > > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > > > > > > > lpc2000%40yahoogroups.com
> >
> > > > > > > > > > > [mailto:l...
> >
> > > > > >
> > >
> > > > > > > > > > > 2540yahoogroups.com>>
> > > > >
> > > > > > > > >
> > > > > > >
> > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > > > > > lpc2000%40yahoogroups.com
> >]On
> > > > > > > > > > Behalf
> > > > > > > > > > > Of Sutton Mehaffey
> > > > > > > > > > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > > > > > > > > > To: l...
> >
> > > > > >
> > >
> > > > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > > > > > > > lpc2000%40yahoogroups.com
> >
> > > > > > >
> > > > > > > > > > > Subject: Re: [lpc2000] Re: new SD code
> transfer to
> > > > LPC2148 not
> > > > > > > quite
> > > > > > > > > > > working
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I have a variable in serial eeprom that
> indicates
> > 'app code
> > > > > good'
> > > > > > > or
> > > > > > > > > > > not. I use an intermediate serial flash
> to hold the file
> > > from
> > > > > the
> > > > > > > SD
> > > > > > > > > > > card. I compare byte for byte the code
> on the SD card to
> > > the
> > > > > > serial
> > > > > > > > > > > flash. When valid, I change the serial
> eeprom value
> > to 0. I
> > > > > > > > > > > initiate a
> > > > > > > > > > > WDT reset and the bootloader at 0 sees
> that the eeprom
> > > > value is
> > > > > 0
> > > > > > > and
> > > > > > > > > > > starts the upload from the serial flash
> to the CPU flash
> > > (via
> > > > > > > > > > > IAP). I
> > > > > > > > > > > compare byte for byte the upload to
> 0x00004000 and when
> > > > > > > > > > > valid, I change
> > > > > > > > > > > the serial eeprom value to 'good code
> (0xA5). I initiate
> > > > > another
> > > > > > > WDT
> > > > > > > > > > > reset, which works, but the transfer to
> 0x00004000
> > doesn't
> > > > > work.
> > > > > > > > > > >
> > > > > > > > > > > This update is to be done in the field
> by customers
> > without
> > > > > JTAG.
> > > > > > > > > > >
> > > > > > > > > > > From the previous posts, I guess I'm
> trying to figure out
> > > how
> > > > > the
> > > > > > > > > > > interrupt vectors are affected by all of
> this. They are
> > > > > > > > > > > stored at 0.
> > > > > > > > > > > I'm guessing by Richard's post that
> depending on what
> > > > > > application I
> > > > > > > > > > > loaded last by JTAG (bootloader or app),
> the interrupt
> > > > > > vectors are
> > > > > > > > > > > correct, but not for the first loaded
> code. The code
> > > > > > > > > > > 0x00-0x1C on the
> > > > > > > > > > > SD card (which is Keil's compiled code
> converted to
> > binary)
> > > > > looks
> > > > > > > > > > > exactly like the code at 0x00-0x1C at
> 0x00000000. It is
> > > > put at
> > > > > > > > > > > 0x00004000, which I thought was
> sufficient. Still
> > trying to
> > > > > > > > > > > figure it out.
> > > > > > > > > > >
> > > > > > > > > > > Sutton
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > m...@compusmart.ab.ca
> >
> > > > > >
> > > > > > > > manton%40compusmart.ab.ca >
> > > > > > > > > > > > > manton%40compusmart.ab.ca >
> > > > > > > > > > > > > > > > > manton%40compusmart.ab.ca
> >
> > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > What criteria do you use to determine
> if control can be
> > > > > passed
> > > > > > > from
> > > > > > > > > > > > your bootloader to the main
> application? Do you use a
> > > > CRC or
> > > > > > > verify
> > > > > > > > > > > > it to make sure
> > > > > > > > > > > > it was written correctly?
> > > > > > > > > > > >
> > > > > > > > > > > > Could you use your bootloader to write
> the main
> > app, and
> > > > > > then do
> > > > > > > a
> > > > > > > > > > > > verify via JTAG to see if they are the same?
> > > > > > > > > > > >
> > > > > > > > > > > > Mike
> > > > > > > > > > > >
> > > > > > > > > > > > Quoting Sutton Mehaffey
> > > > > >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.com>
> > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >>:
> > > > > > > > > > > >
> > > > > > > > > > > > > OK. So, what is happening in Keil's
> uVision when
> > I use
> > > > > > > > > > > the JTAG to load
> > > > > > > > > > > > > the bootloader at 0x00000000 and
> then the app at
> > > > > > > > > > > 0x00004000? Is the
> > > > > > > > > > > > > one I load last is the one that has
> the correct
> > > interrupt
> > > > > > > vector
> > > > > > > > > > > > > pointers? It doesn't seem to matter
> which one I load
> > > > > > > > > > > first and last,
> > > > > > > > > > > > > the interrupts in both sets of code
> seem to work just
> > > > fine
> > > > > > > > and the
> > > > > > > > > > > > > bootloader transfers correctly to the app.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Sutton
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > rtstofer wrote:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> --- In l...
> >
> > > >
> > > >
> > > > > > > > > > > 2540yahoogroups.com>>
> > > > >
> > > > > > > > >
> > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > > > > > lpc2000%40yahoogroups.com
> >
> > > > > > > > > > >
> > > > > > > > > 2540yahoogroups.com>
> > > > > > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > > >
> > > > > > > > > 2540yahoogroups.com>
> > > > > > > > > > >
> > > > > > > 2540yahoogroups.com>>,
> > > > > > >
> > > > > > > > > > > > >> "Sutton Mehaffey" wrote:
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > Because I'm not clear on why, why
> do I need to
> > remap
> > > > > > > > > > > the interrupt
> > > > > > > > > > > > >> vector when my bootloader code at
> 0x00000000 never
> > > > > > > > > > > changes? I'm not
> > > > > > > > > > > > >> copying my SD code to location 0x00000000.
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > Sutton
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> So the vectors point to the
> functions in the
> > code that
> > > > > > > > > > > is actually
> > > > > > > > > > > > >> running.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Now, if you ignore every vector
> except IRG and
> > you do
> > > > > > > > > > > the VIC trick of
> > > > > > > > > > > > >> using the vector to get the address
> from the
> > VIC, then
> > > > > > > > > > > you don't have
> > > > > > > > > > > > >> to do anything.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> The IRQ interrupt vector should
> have code like:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read
> the VIC */
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> However, none of the other
> interrupt vectors will
> > > > point to
> > > > > > > your
> > > > > > > > > > > > >> downloaded code. They will only
> point to entries in
> > > your
> > > > > > > > > > > boot code.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> That might be good enough.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Richard
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Sutton Mehaffey
> > > > > > > > > > > > > Lookout Portable Security
> > > > > > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > > > > > s...@lookoutportablesecurity.com
> >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.com>
> > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Sutton Mehaffey
> > > > > > > > > > > Lookout Portable Security
> > > > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > > > s...@lookoutportablesecurity.com
> >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.com>
> > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Sutton Mehaffey
> > > > > > > > > Lookout Portable Security
> > > > > > > > > 4040 Royal Dr.
> > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > 770-514-7999, 800-207-6269
> > > > > > > > > Fax: 770-514-1285
> > > > > > > > > http://www.lookoutportablesecurity.com
> >
> > > > > > >
> > > > > > > >
> > > > > > >>
> > > > > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > >>>
> > > > > > > > > s...@lookoutportablesecurity.com
> >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.com>
> > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.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
> >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.com>
> > > >
> > > > > >
> > > >
> >
> > tportablesecurity.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
> >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.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
>
>
app image, and then use the JTAG to compare it against the original.
Perhaps something is not written as you expect, or there are
problems with the binary image.
Mike
> -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of Sutton Mehaffey
> Sent: Thursday, August 20, 2009 10:24 AM
> To: l...
> Subject: Re: [lpc2000] Re: new SD code transfer to LPC2148 not quite
> working
> And I have actually put the same code on the SD card as is running at
> 0x00004000. So, that everything supposedly matches. After
> the upload,
> code still hangs in bootloader transferring to 0x00004000.
> But, works
> again if I upload the same code via JTAG.
>
> Miguel Angel wrote:
> >
> >
> > Sorry sutton, I misunderstood your phrase:
> >
> > """
> > If when the code hangs after my SD card upload (the WDT
> causes a reset,
> > the bootloader finds that the RAM value is back to 0xA5,
> meaning valid
> > code at 0x00004000, and tries to transfer to execution to
> 0x00004000), I
> > load the same code thru Keil's JTAG, the transfer works
> perfectly again.
> >
> > """
> >
> > 2009/8/20 Sutton Mehaffey > > >
> >
> > >
> > >
> > > Why do you think the image is incomplete? The SD card
> code matches
> > > exactly the intermediate serial flash code which matches
> exactly the CPU
> > > code at 0x00004000. I have the image length, which is
> the size of the
> > > SD card code. I'm not using a checksum, because I check
> each and every
> > > byte on 2 occasions to verify. I would think that is enough.
> > >
> > >
> > > Miguel Angel wrote:
> > > >
> > > >
> > > > Hmmm,
> > > >
> > > > I think the only way you could fix incomplete image
> uploads is to
> > > > put more fields on the image "header" inside your
> startup.s, and, just
> > > > after compiling the target app, and building the
> binary use a program
> > > > in the PC to fill those fields that could be:
> > > >
> > > > 1) Image length
> > > > 2) Image CRC or checksum
> > > >
> > > > with those two fields at startup in your bootloader you could
> > > > check the whole image length for CRC match before
> jumping into the app,
> > > > if it doesn't match, then jump into (for example)
> "wait for SD to get
> > > > inserted
> > > > to load a new app, and blink leds"
> > > >
> > > > 2009/8/20 Sutton Mehaffey > >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.com>
> > > >>
> > > >
> > > > >
> > > > >
> > > > > I actually do in the 'Target' link put my base
> address at 0x00004000.
> > > > > That's how the code initially gets transferred from
> the bootloader to
> > > > > app correctly. The bootloader (located at 0)
> transfers execution
> > > > > perfectly to 0x00004000 before the SD card upload.
> But, that is
> > loading
> > > > > the 2 sections of code via Keil's JTAG.
> > > > >
> > > > > The problem is that the Keil JTAG does some other
> programming (that I
> > > > > haven't figured out) that my upload from SD card doesn't do.
> > > > >
> > > > > If when the code hangs after my SD card upload (the
> WDT causes a
> > reset,
> > > > > the bootloader finds that the RAM value is back to
> 0xA5, meaning
> > valid
> > > > > code at 0x00004000, and tries to transfer to execution to
> > 0x00004000),
> > > I
> > > > > load the same code thru Keil's JTAG, the transfer
> works perfectly
> > > again.
> > > > >
> > > > >
> > > > > Miguel Angel wrote:
> > > > > >
> > > > > >
> > > > > > Yes, my code will only help if you're using FIQs or SWIs,
> > > > > >
> > > > > > For the application binary, alex's comment is
> quite important, you
> > > > > > should really set the application code base
> address to 0x4000 or
> > > > > > some jump/calls will get bad addresses.
> > > > > >
> > > > > > 2009/8/20 Sutton Mehaffey
> > >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.com>
> > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > > >>
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I must have missed that post. I don't see it in
> my folder.
> > > > > > >
> > > > > > > Anyway, I just tried changing the startup file
> as per your
> > request
> > > > > > > (Miguel), and it still doesn't transfer to
> 0x4000 correctly. It
> > > hangs
> > > > > > > after a successful upload, just like before.
> > > > > > >
> > > > > >
> > > > > > >
> > > > > > > I do use "Memory Layout from Target Dialog", so
> maybe Alex's
> > > comment
> > > > > has
> > > > > > > some merit. Maybe I need to learn and use the
> scatter files.
> > > > > > >
> > > > > > > Sutton
> > > > > > >
> > > > > > >
> > > > > > > Miguel Angel wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > Copy & Paste, I already told you (some weeks
> ago) a way of
> > doing
> > > it
> > > > > :)
> > > > > > > >
> > > > > > > > This is an example of IRQ pass-thru from my
> usual bootloader to
> > > the
> > > > > > > > application
> > > > > > > > (that starts at 0x2000): (ARM Assembler format
> for a 214x/213x
> > > > > device)
> > > > > > > > Modify your Startup.s to put the vectors this way:
> > > > > > > >
> > > > > > > > Vectors LDR PC, Reset_Addr
> > > > > > > > LDR PC, Undef_Addr
> > > > > > > > LDR PC, SWI_Addr
> > > > > > > > LDR PC, PAbt_Addr
> > > > > > > > LDR PC, DAbt_Addr
> > > > > > > > NOP ; Reserved Vector
> > > > > > > > LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
> > > > > > > > LDR PC, FIQ_Addr
> > > > > > > >
> > > > > > > > Reset_Addr DCD Reset_Handler
> > > > > > > > Undef_Addr DCD 0x4004
> > > > > > > > SWI_Addr DCD 0x4008
> > > > > > > > PAbt_Addr DCD 0x400C
> > > > > > > > DAbt_Addr DCD 0x4010
> > > > > > > > DCD 0 ; Reserved Address
> > > > > > > > 0x2014
> > > > > > > > FIQ_Addr DCD 0x401C
> > > > > > > >
> > > > > > > > And something important too, is to end the Startup
> > initialization
> > > > > with:
> > > > > > > >
> > > > > > > > MSR CPSR_c, #Mode_SYS (instead of
> > > > > > > > MSR CPSR_c, #Mode_USR)
> > > > > > > >
> > > > > > > > so your app startup can change processor mode
> again and setup
> > > > all the
> > > > > > > mode's
> > > > > > > > stacks, according
> > > > > > > > to your app configuration.
> > > > > > > >
> > > > > > > > 2009/8/20 Sutton Mehaffey
> > > >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.com>
> > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > > >>
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > The code is compiled at 0x00004000,
> converted to binary and
> > > > loaded
> > > > > on
> > > > > > > > > the SD card. The application always runs at
> 0x00004000. The
> > > > > > bootloader
> > > > > > > > > is never changed in the field and always
> runs at 0. The
> > first 6
> > > > > bytes
> > > > > > > > > of the compiled file hold the 0x00004000. I
> assume that's how
> > > > Keil
> > > > > > > > > knows to locate it at 0x00004000 thru the JTAG.
> > > > > > > > >
> > > > > > > > > Where in the startup code do I specify that
> the vectors
> > starts
> > > at
> > > > > > > > > 0x00004000?
> > > > > > > > >
> > > > > > > > > typedef void (*APP)(void);
> > > > > > > > > APP app = (APP)0x00004000;
> > > > > > > > >
> > > > > > > > > app();
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Michael Anton wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > How does your bootloader handle
> revectoring all of the
> > > > > interrupts?
> > > > > > > > > > I don't understand why the vectors located
> at 0x0004000
> > would
> > > > > > be the
> > > > > > > > > > same as those at 0x00000000, since they
> are for different
> > > > > > > applications.
> > > > > > > > > >
> > > > > > > > > > Am I to understand that the code on the SD
> card begins
> > at 0?
> > > If
> > > > > so
> > > > > > > that
> > > > > > > > > > is not correct, as it should be located at
> 0x00004000. It
> > > > > wouldn't
> > > > > > > make
> > > > > > > > > > sense to have the vectors in the main
> application loaded at
> > > > zero,
> > > > > > > > unless
> > > > > > > > > > they would be executed from there. Also,
> given that the
> > > startup
> > > > > > code
> > > > > > > > > > usually contains the vectors and the
> startup routines, they
> > > > > > certainly
> > > > > > > > > > shouldn't be located at 0.
> > > > > > > > > >
> > > > > > > > > > How do you jump to the main app from your
> bootloader?
> > > > > > > > > >
> > > > > > > > > > This would all me much easier for us to
> figure out if we
> > > > had the
> > > > > > > > > > relevant bits of code.
> > > > > > > > > >
> > > > > > > > > > Mike
> > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: l...
> >
> > > > > >
> > >
> > > > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > > > > > > > lpc2000%40yahoogroups.com
> >
> > > > > > > > > > > [mailto:l...
> >
> > > > > >
> > >
> > > > > > > > > > > 2540yahoogroups.com>>
> > > > >
> > > > > > > > >
> > > > > > >
> > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > > > > > lpc2000%40yahoogroups.com
> >]On
> > > > > > > > > > Behalf
> > > > > > > > > > > Of Sutton Mehaffey
> > > > > > > > > > > Sent: Wednesday, August 19, 2009 5:57 PM
> > > > > > > > > > > To: l...
> >
> > > > > >
> > >
> > > > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > lpc2000%40yahoogroups.com >
> > > > > > > > > > > > > > > > > lpc2000%40yahoogroups.com
> >
> > > > > > >
> > > > > > > > > > > Subject: Re: [lpc2000] Re: new SD code
> transfer to
> > > > LPC2148 not
> > > > > > > quite
> > > > > > > > > > > working
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I have a variable in serial eeprom that
> indicates
> > 'app code
> > > > > good'
> > > > > > > or
> > > > > > > > > > > not. I use an intermediate serial flash
> to hold the file
> > > from
> > > > > the
> > > > > > > SD
> > > > > > > > > > > card. I compare byte for byte the code
> on the SD card to
> > > the
> > > > > > serial
> > > > > > > > > > > flash. When valid, I change the serial
> eeprom value
> > to 0. I
> > > > > > > > > > > initiate a
> > > > > > > > > > > WDT reset and the bootloader at 0 sees
> that the eeprom
> > > > value is
> > > > > 0
> > > > > > > and
> > > > > > > > > > > starts the upload from the serial flash
> to the CPU flash
> > > (via
> > > > > > > > > > > IAP). I
> > > > > > > > > > > compare byte for byte the upload to
> 0x00004000 and when
> > > > > > > > > > > valid, I change
> > > > > > > > > > > the serial eeprom value to 'good code
> (0xA5). I initiate
> > > > > another
> > > > > > > WDT
> > > > > > > > > > > reset, which works, but the transfer to
> 0x00004000
> > doesn't
> > > > > work.
> > > > > > > > > > >
> > > > > > > > > > > This update is to be done in the field
> by customers
> > without
> > > > > JTAG.
> > > > > > > > > > >
> > > > > > > > > > > From the previous posts, I guess I'm
> trying to figure out
> > > how
> > > > > the
> > > > > > > > > > > interrupt vectors are affected by all of
> this. They are
> > > > > > > > > > > stored at 0.
> > > > > > > > > > > I'm guessing by Richard's post that
> depending on what
> > > > > > application I
> > > > > > > > > > > loaded last by JTAG (bootloader or app),
> the interrupt
> > > > > > vectors are
> > > > > > > > > > > correct, but not for the first loaded
> code. The code
> > > > > > > > > > > 0x00-0x1C on the
> > > > > > > > > > > SD card (which is Keil's compiled code
> converted to
> > binary)
> > > > > looks
> > > > > > > > > > > exactly like the code at 0x00-0x1C at
> 0x00000000. It is
> > > > put at
> > > > > > > > > > > 0x00004000, which I thought was
> sufficient. Still
> > trying to
> > > > > > > > > > > figure it out.
> > > > > > > > > > >
> > > > > > > > > > > Sutton
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > m...@compusmart.ab.ca
> >
> > > > > >
> > > > > > > > manton%40compusmart.ab.ca >
> > > > > > > > > > > > > manton%40compusmart.ab.ca >
> > > > > > > > > > > > > > > > > manton%40compusmart.ab.ca
> >
> > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > What criteria do you use to determine
> if control can be
> > > > > passed
> > > > > > > from
> > > > > > > > > > > > your bootloader to the main
> application? Do you use a
> > > > CRC or
> > > > > > > verify
> > > > > > > > > > > > it to make sure
> > > > > > > > > > > > it was written correctly?
> > > > > > > > > > > >
> > > > > > > > > > > > Could you use your bootloader to write
> the main
> > app, and
> > > > > > then do
> > > > > > > a
> > > > > > > > > > > > verify via JTAG to see if they are the same?
> > > > > > > > > > > >
> > > > > > > > > > > > Mike
> > > > > > > > > > > >
> > > > > > > > > > > > Quoting Sutton Mehaffey
> > > > > >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.com>
> > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >>:
> > > > > > > > > > > >
> > > > > > > > > > > > > OK. So, what is happening in Keil's
> uVision when
> > I use
> > > > > > > > > > > the JTAG to load
> > > > > > > > > > > > > the bootloader at 0x00000000 and
> then the app at
> > > > > > > > > > > 0x00004000? Is the
> > > > > > > > > > > > > one I load last is the one that has
> the correct
> > > interrupt
> > > > > > > vector
> > > > > > > > > > > > > pointers? It doesn't seem to matter
> which one I load
> > > > > > > > > > > first and last,
> > > > > > > > > > > > > the interrupts in both sets of code
> seem to work just
> > > > fine
> > > > > > > > and the
> > > > > > > > > > > > > bootloader transfers correctly to the app.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Sutton
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > rtstofer wrote:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> --- In l...
> >
> > > >
> > > >
> > > > > > > > > > > 2540yahoogroups.com>>
> > > > >
> > > > > > > > >
> > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > > > > > > > lpc2000%40yahoogroups.com
> >
> > > > > > > > > > >
> > > > > > > > > 2540yahoogroups.com>
> > > > > > > > > > > > > 2540yahoogroups.com>>
> > > > > > > > > > > >
> > > > > > > > > 2540yahoogroups.com>
> > > > > > > > > > >
> > > > > > > 2540yahoogroups.com>>,
> > > > > > >
> > > > > > > > > > > > >> "Sutton Mehaffey" wrote:
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > Because I'm not clear on why, why
> do I need to
> > remap
> > > > > > > > > > > the interrupt
> > > > > > > > > > > > >> vector when my bootloader code at
> 0x00000000 never
> > > > > > > > > > > changes? I'm not
> > > > > > > > > > > > >> copying my SD code to location 0x00000000.
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > Sutton
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> So the vectors point to the
> functions in the
> > code that
> > > > > > > > > > > is actually
> > > > > > > > > > > > >> running.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Now, if you ignore every vector
> except IRG and
> > you do
> > > > > > > > > > > the VIC trick of
> > > > > > > > > > > > >> using the vector to get the address
> from the
> > VIC, then
> > > > > > > > > > > you don't have
> > > > > > > > > > > > >> to do anything.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> The IRQ interrupt vector should
> have code like:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> ldr pc,[pc, #-0xff0] /* IRQ - read
> the VIC */
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> However, none of the other
> interrupt vectors will
> > > > point to
> > > > > > > your
> > > > > > > > > > > > >> downloaded code. They will only
> point to entries in
> > > your
> > > > > > > > > > > boot code.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> That might be good enough.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Richard
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Sutton Mehaffey
> > > > > > > > > > > > > Lookout Portable Security
> > > > > > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > > > > > s...@lookoutportablesecurity.com
> >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.com>
> > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Sutton Mehaffey
> > > > > > > > > > > Lookout Portable Security
> > > > > > > > > > > 4040 Royal Dr. #100
> > > > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > > > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > > > > > > > > > > s...@lookoutportablesecurity.com
> >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.com>
> > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Sutton Mehaffey
> > > > > > > > > Lookout Portable Security
> > > > > > > > > 4040 Royal Dr.
> > > > > > > > > Kennesaw, GA 30144
> > > > > > > > > 770-514-7999, 800-207-6269
> > > > > > > > > Fax: 770-514-1285
> > > > > > > > > http://www.lookoutportablesecurity.com
> >
> > > > > > >
> > > > > > > >
> > > > > > >>
> > > > > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > >>>
> > > > > > > > > s...@lookoutportablesecurity.com
> >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.com>
> > > >
> > > > > >
> > > >
> >
> > tportablesecurity.com>
> > >
> > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> > tportablesecurity.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
> >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.com>
> > > >
> > > > > >
> > > >
> >
> > tportablesecurity.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
> >
> > portablesecurity.com>
> > > >
> >
> > tportablesecurity.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
>
>
Reply by ●August 20, 20092009-08-20
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.
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.
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).
I don't currently use scatter files, but here is the app startup file
that I just changed.
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:
E8BA000F LDMIA R10!,(R0-R3) that changes R3 to 0x2CB88 and 4 lines
down this register is used in BX R3 as a branch. This is a bogus
location that is causing the eventual crash.
In the 'good transfer', this statement causes R3 to be set to 0x4158,
which is much more reasonable. And, thus the transfer works.
; Exception Vectors
; Mapped to Address 0x4000.
; Absolute addressing mode must be used.
; Dummy Handlers are implemented as infinite loops which can be modified.
Vectors LDR PC, Reset_Addr
LDR PC, Undef_Addr
LDR PC, SWI_Addr
LDR PC, PAbt_Addr
LDR PC, DAbt_Addr
NOP ; Reserved Vector
; LDR PC, IRQ_Addr
LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
LDR PC, FIQ_Addr
Reset_Addr DCD Reset_Handler
Undef_Addr DCD 0x4004
SWI_Addr DCD 0x4008
PAbt_Addr DCD 0x400C
DAbt_Addr DCD 0x4010
DCD 0 ; Reserved Address
IRQ_Addr DCD 0x4014
FIQ_Addr DCD 0x401C
Undef_Handler B Undef_Handler
SWI_Handler B SWI_Handler
PAbt_Handler B PAbt_Handler
DAbt_Handler B DAbt_Handler
IRQ_Handler B IRQ_Handler
FIQ_Handler B FIQ_Handler
; Reset Handler
EXPORT Reset_Handler
Reset_Handler
; Setup External Memory Pins
IF :DEF:EXTERNAL_MODE
LDR R0, =PINSEL2
LDR R1, =PINSEL2_Val
STR R1, [R0]
ENDIF
; Setup External Memory Controller
IF EMC_SETUP <> 0
LDR R0, =EMC_BASE
IF BCFG0_SETUP <> 0
LDR R1, FG0_Val
STR R1, [R0, #BCFG0_OFS]
ENDIF
IF BCFG1_SETUP <> 0
LDR R1, FG1_Val
STR R1, [R0, #BCFG1_OFS]
ENDIF
IF BCFG2_SETUP <> 0
LDR R1, FG2_Val
STR R1, [R0, #BCFG2_OFS]
ENDIF
IF BCFG3_SETUP <> 0
LDR R1, FG3_Val
STR R1, [R0, #BCFG3_OFS]
ENDIF
ENDIF ; EMC_SETUP
; Setup VPBDIV
IF VPBDIV_SETUP <> 0
LDR R0, =VPBDIV
LDR R1, =VPBDIV_Val
STR R1, [R0]
ENDIF
; Setup PLL
IF PLL_SETUP <> 0
LDR R0, =PLL_BASE
MOV R1, #0xAA
MOV R2, #0x55
; Configure and Enable PLL
MOV R3, #PLLCFG_Val
STR R3, [R0, #PLLCFG_OFS]
MOV R3, #PLLCON_PLLE
STR R3, [R0, #PLLCON_OFS]
STR R1, [R0, #PLLFEED_OFS]
STR R2, [R0, #PLLFEED_OFS]
; Wait until PLL Locked
PLL_Loop LDR R3, [R0, #PLLSTAT_OFS]
ANDS R3, R3, #PLLSTAT_PLOCK
BEQ PLL_Loop
; Switch to PLL Clock
MOV R3, #(PLLCON_PLLE:OR:PLLCON_PLLC)
STR R3, [R0, #PLLCON_OFS]
STR R1, [R0, #PLLFEED_OFS]
STR R2, [R0, #PLLFEED_OFS]
ENDIF ; PLL_SETUP
; Setup MAM
IF MAM_SETUP <> 0
LDR R0, =MAM_BASE
MOV R1, #MAMTIM_Val
STR R1, [R0, #MAMTIM_OFS]
MOV R1, #MAMCR_Val
STR R1, [R0, #MAMCR_OFS]
ENDIF ; MAM_SETUP
; Memory Mapping (when Interrupt Vectors are in RAM)
MEMMAP EQU 0xE01FC040 ; Memory Mapping Control
IF :DEF:REMAP
LDR R0, =MEMMAP
IF :DEF:EXTMEM_MODE
MOV R1, #3
ELIF :DEF:RAM_MODE
MOV R1, #2
ELSE
MOV R1, #1
ENDIF
STR R1, [R0]
ENDIF
; Initialise Interrupt System
; ...
; Setup Stack for each mode
LDR R0, =Stack_Top
; Enter Undefined Instruction Mode and set its Stack Pointer
MSR CPSR_c, #Mode_UND:OR:I_Bit:OR:F_Bit
MOV SP, R0
SUB R0, R0, #UND_Stack_Size
; Enter Abort Mode and set its Stack Pointer
MSR CPSR_c, #Mode_ABT:OR:I_Bit:OR:F_Bit
MOV SP, R0
SUB R0, R0, #ABT_Stack_Size
; Enter FIQ Mode and set its Stack Pointer
MSR CPSR_c, #Mode_FIQ:OR:I_Bit:OR:F_Bit
MOV SP, R0
SUB R0, R0, #FIQ_Stack_Size
; Enter IRQ Mode and set its Stack Pointer
MSR CPSR_c, #Mode_IRQ:OR:I_Bit:OR:F_Bit
MOV SP, R0
SUB R0, R0, #IRQ_Stack_Size
; Enter Supervisor Mode and set its Stack Pointer
MSR CPSR_c, #Mode_SVC:OR:I_Bit:OR:F_Bit
MOV SP, R0
SUB R0, R0, #SVC_Stack_Size
; Enter User Mode and set its Stack Pointer
; MSR CPSR_c, #Mode_USR
MSR CPSR_c, #Mode_SYS
IF :DEF:__MICROLIB
EXPORT __initial_sp
ELSE
MOV SP, R0
SUB SL, SP, #USR_Stack_Size
ENDIF
; Enter the C code
IMPORT __main
LDR R0, =__main
BX R0
IF :DEF:__MICROLIB
EXPORT __heap_base
EXPORT __heap_limit
ELSE
; User Initial Stack & Heap
AREA |.text|, CODE, READONLY
IMPORT __use_two_region_memory
EXPORT __user_initial_stackheap
__user_initial_stackheap
LDR R0, = Heap_Mem
LDR R1, =(Stack_Mem + USR_Stack_Size)
LDR R2, = (Heap_Mem + Heap_Size)
LDR R3, = Stack_Mem
BX LR
ENDIF
END
alexander_ribero wrote:
>
>
> Hi:
>
> I have a couple of questions:
>
> 1. Does your main application has an option to jump to the bootloader?
> (let's say, when a SD card is inserted or by any other means, for example)?
>
> 2. If so, does it works? (assuming that the main application is running
> correctly, which is the case when you program it via JTAG).
>
> 3. Does your bootloader gets corrupted after finishing the installation
> of the new main application from SD card? That is, can you install
> multiple times the main application from SD card, without having to
> reprogram the bootloader application via JTAG?
>
> 4. After programming both the bootloader and the main application with
> the JTAG (as you have done to confirm that the main application works),
> does the bootloader works correctly? That is, can the bootloader upload
> a new main application from SD card (without having to be reprogrammed
> via JTAG)?
>
> I still believe the solution lies on using the scatter files to properly
> set the correct location for the necessary sections, for each target
> (bootloader, main application debug target, and main application Release
> target). This also requires the correct interrupt vector remapping in
> the startup.s file.
>
> Would you be able to share the .s files and scatter files used?
>
> Regards,
>
> Alex
--
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
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.
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.
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).
I don't currently use scatter files, but here is the app startup file
that I just changed.
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:
E8BA000F LDMIA R10!,(R0-R3) that changes R3 to 0x2CB88 and 4 lines
down this register is used in BX R3 as a branch. This is a bogus
location that is causing the eventual crash.
In the 'good transfer', this statement causes R3 to be set to 0x4158,
which is much more reasonable. And, thus the transfer works.
; Exception Vectors
; Mapped to Address 0x4000.
; Absolute addressing mode must be used.
; Dummy Handlers are implemented as infinite loops which can be modified.
Vectors LDR PC, Reset_Addr
LDR PC, Undef_Addr
LDR PC, SWI_Addr
LDR PC, PAbt_Addr
LDR PC, DAbt_Addr
NOP ; Reserved Vector
; LDR PC, IRQ_Addr
LDR PC, [PC, #-0x0FF0] ; Vector from VicVectAddr
LDR PC, FIQ_Addr
Reset_Addr DCD Reset_Handler
Undef_Addr DCD 0x4004
SWI_Addr DCD 0x4008
PAbt_Addr DCD 0x400C
DAbt_Addr DCD 0x4010
DCD 0 ; Reserved Address
IRQ_Addr DCD 0x4014
FIQ_Addr DCD 0x401C
Undef_Handler B Undef_Handler
SWI_Handler B SWI_Handler
PAbt_Handler B PAbt_Handler
DAbt_Handler B DAbt_Handler
IRQ_Handler B IRQ_Handler
FIQ_Handler B FIQ_Handler
; Reset Handler
EXPORT Reset_Handler
Reset_Handler
; Setup External Memory Pins
IF :DEF:EXTERNAL_MODE
LDR R0, =PINSEL2
LDR R1, =PINSEL2_Val
STR R1, [R0]
ENDIF
; Setup External Memory Controller
IF EMC_SETUP <> 0
LDR R0, =EMC_BASE
IF BCFG0_SETUP <> 0
LDR R1, FG0_Val
STR R1, [R0, #BCFG0_OFS]
ENDIF
IF BCFG1_SETUP <> 0
LDR R1, FG1_Val
STR R1, [R0, #BCFG1_OFS]
ENDIF
IF BCFG2_SETUP <> 0
LDR R1, FG2_Val
STR R1, [R0, #BCFG2_OFS]
ENDIF
IF BCFG3_SETUP <> 0
LDR R1, FG3_Val
STR R1, [R0, #BCFG3_OFS]
ENDIF
ENDIF ; EMC_SETUP
; Setup VPBDIV
IF VPBDIV_SETUP <> 0
LDR R0, =VPBDIV
LDR R1, =VPBDIV_Val
STR R1, [R0]
ENDIF
; Setup PLL
IF PLL_SETUP <> 0
LDR R0, =PLL_BASE
MOV R1, #0xAA
MOV R2, #0x55
; Configure and Enable PLL
MOV R3, #PLLCFG_Val
STR R3, [R0, #PLLCFG_OFS]
MOV R3, #PLLCON_PLLE
STR R3, [R0, #PLLCON_OFS]
STR R1, [R0, #PLLFEED_OFS]
STR R2, [R0, #PLLFEED_OFS]
; Wait until PLL Locked
PLL_Loop LDR R3, [R0, #PLLSTAT_OFS]
ANDS R3, R3, #PLLSTAT_PLOCK
BEQ PLL_Loop
; Switch to PLL Clock
MOV R3, #(PLLCON_PLLE:OR:PLLCON_PLLC)
STR R3, [R0, #PLLCON_OFS]
STR R1, [R0, #PLLFEED_OFS]
STR R2, [R0, #PLLFEED_OFS]
ENDIF ; PLL_SETUP
; Setup MAM
IF MAM_SETUP <> 0
LDR R0, =MAM_BASE
MOV R1, #MAMTIM_Val
STR R1, [R0, #MAMTIM_OFS]
MOV R1, #MAMCR_Val
STR R1, [R0, #MAMCR_OFS]
ENDIF ; MAM_SETUP
; Memory Mapping (when Interrupt Vectors are in RAM)
MEMMAP EQU 0xE01FC040 ; Memory Mapping Control
IF :DEF:REMAP
LDR R0, =MEMMAP
IF :DEF:EXTMEM_MODE
MOV R1, #3
ELIF :DEF:RAM_MODE
MOV R1, #2
ELSE
MOV R1, #1
ENDIF
STR R1, [R0]
ENDIF
; Initialise Interrupt System
; ...
; Setup Stack for each mode
LDR R0, =Stack_Top
; Enter Undefined Instruction Mode and set its Stack Pointer
MSR CPSR_c, #Mode_UND:OR:I_Bit:OR:F_Bit
MOV SP, R0
SUB R0, R0, #UND_Stack_Size
; Enter Abort Mode and set its Stack Pointer
MSR CPSR_c, #Mode_ABT:OR:I_Bit:OR:F_Bit
MOV SP, R0
SUB R0, R0, #ABT_Stack_Size
; Enter FIQ Mode and set its Stack Pointer
MSR CPSR_c, #Mode_FIQ:OR:I_Bit:OR:F_Bit
MOV SP, R0
SUB R0, R0, #FIQ_Stack_Size
; Enter IRQ Mode and set its Stack Pointer
MSR CPSR_c, #Mode_IRQ:OR:I_Bit:OR:F_Bit
MOV SP, R0
SUB R0, R0, #IRQ_Stack_Size
; Enter Supervisor Mode and set its Stack Pointer
MSR CPSR_c, #Mode_SVC:OR:I_Bit:OR:F_Bit
MOV SP, R0
SUB R0, R0, #SVC_Stack_Size
; Enter User Mode and set its Stack Pointer
; MSR CPSR_c, #Mode_USR
MSR CPSR_c, #Mode_SYS
IF :DEF:__MICROLIB
EXPORT __initial_sp
ELSE
MOV SP, R0
SUB SL, SP, #USR_Stack_Size
ENDIF
; Enter the C code
IMPORT __main
LDR R0, =__main
BX R0
IF :DEF:__MICROLIB
EXPORT __heap_base
EXPORT __heap_limit
ELSE
; User Initial Stack & Heap
AREA |.text|, CODE, READONLY
IMPORT __use_two_region_memory
EXPORT __user_initial_stackheap
__user_initial_stackheap
LDR R0, = Heap_Mem
LDR R1, =(Stack_Mem + USR_Stack_Size)
LDR R2, = (Heap_Mem + Heap_Size)
LDR R3, = Stack_Mem
BX LR
ENDIF
END
alexander_ribero wrote:
>
>
> Hi:
>
> I have a couple of questions:
>
> 1. Does your main application has an option to jump to the bootloader?
> (let's say, when a SD card is inserted or by any other means, for example)?
>
> 2. If so, does it works? (assuming that the main application is running
> correctly, which is the case when you program it via JTAG).
>
> 3. Does your bootloader gets corrupted after finishing the installation
> of the new main application from SD card? That is, can you install
> multiple times the main application from SD card, without having to
> reprogram the bootloader application via JTAG?
>
> 4. After programming both the bootloader and the main application with
> the JTAG (as you have done to confirm that the main application works),
> does the bootloader works correctly? That is, can the bootloader upload
> a new main application from SD card (without having to be reprogrammed
> via JTAG)?
>
> I still believe the solution lies on using the scatter files to properly
> set the correct location for the necessary sections, for each target
> (bootloader, main application debug target, and main application Release
> target). This also requires the correct interrupt vector remapping in
> the startup.s file.
>
> Would you be able to share the .s files and scatter files used?
>
> Regards,
>
> Alex
--
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
--- In l..., Sutton Mehaffey wrote:
>
> 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),
Why do you assume that RAM will have 0xA5 on power up?
Richard
>
> 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),
Why do you assume that RAM will have 0xA5 on power up?
Richard
Reply by ●August 20, 20092009-08-20
This is I2C serial flash, not onboard RAM.
rtstofer wrote:
>
>
> --- In l... ,
> Sutton Mehaffey wrote:
> >
> > 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),
>
> Why do you assume that RAM will have 0xA5 on power up?
>
> Richard
--
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
rtstofer wrote:
>
>
> --- In l... ,
> Sutton Mehaffey wrote:
> >
> > 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),
>
> Why do you assume that RAM will have 0xA5 on power up?
>
> Richard
--
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
