While we're on the subject of IAP, I've got a question...
I'm working with the LPC214X and doing a bootloader. The LPC2XXX
evidently requires the start of the copy RAM to Flash to be on
a 256 byte boundary. There are places, (eg. reset vectors)
where the intel hex address is not on a 256 byte boundary.
It will output the 4 byte vector for address 000000 and then
another at 000018 etc... This doesn't limit itself to just
the jump vectors of course, but I used that as an example.
Have any others run into this problem and found an easy or
maybe a semi-standard way around it ?
Just wondering...
Thanks,
boB
IAP 256 word boundaries and IAR intel hex output
Started by ●February 27, 2007
Reply by ●February 27, 20072007-02-27
--- In l..., "bobtransformer" wrote:
> While we're on the subject of IAP, I've got a question...
>
> I'm working with the LPC214X and doing a bootloader. The LPC2XXX
> evidently requires the start of the copy RAM to Flash to be on
> a 256 byte boundary. There are places, (eg. reset vectors)
> where the intel hex address is not on a 256 byte boundary.
> It will output the 4 byte vector for address 000000 and then
> another at 000018 etc... This doesn't limit itself to just
> the jump vectors of course, but I used that as an example.
>
> Have any others run into this problem and found an easy or
> maybe a semi-standard way around it ?
>
> Just wondering...
>
> Thanks,
> boB
>
Maybe I'm misunderstanding, but it sounds like you want to program
each record independently. Why not buffer them (e.g. wait till you
have 256 bytes) and program that? This assumes the records are in
increasing address order if things aren't to get too complex. I know
that's generally the case, but I'm not sure it's always true.
The other obvious thing to do is post-process the file, either before
the load or on the fly as it's loaded down. That way, you can arrange
for the target to see what it needs to keep everything simple.
Brendan.
> While we're on the subject of IAP, I've got a question...
>
> I'm working with the LPC214X and doing a bootloader. The LPC2XXX
> evidently requires the start of the copy RAM to Flash to be on
> a 256 byte boundary. There are places, (eg. reset vectors)
> where the intel hex address is not on a 256 byte boundary.
> It will output the 4 byte vector for address 000000 and then
> another at 000018 etc... This doesn't limit itself to just
> the jump vectors of course, but I used that as an example.
>
> Have any others run into this problem and found an easy or
> maybe a semi-standard way around it ?
>
> Just wondering...
>
> Thanks,
> boB
>
Maybe I'm misunderstanding, but it sounds like you want to program
each record independently. Why not buffer them (e.g. wait till you
have 256 bytes) and program that? This assumes the records are in
increasing address order if things aren't to get too complex. I know
that's generally the case, but I'm not sure it's always true.
The other obvious thing to do is post-process the file, either before
the load or on the fly as it's loaded down. That way, you can arrange
for the target to see what it needs to keep everything simple.
Brendan.
Reply by ●February 27, 20072007-02-27
Thanks Brendan.
I don't want to program each area independently because
I can't do that because of the necessity that the programming
start on that 256 byte address boundary... 0000, 0100, 0200, 0200, etc...
However, I just had a thought. While I'm reading in these chunks
of data from the .hex file, I could fill up the first 256 bytes of
RAM at the proper places, dictated by the intel.hex file, and then
do the copy RAM to Flash via the IAP.
Does this sound like the best way to go about doing this??
Is it what everybody else does maybe ??
There will most likely be more places in memory that will have
"holes" in them and not be on 256 byte address boundaries too.
boB
--- In l..., "Brendan Murphy"
wrote:
>
> --- In l..., "bobtransformer" wrote:
> >
> >
> > While we're on the subject of IAP, I've got a question...
> >
> > I'm working with the LPC214X and doing a bootloader. The LPC2XXX
> > evidently requires the start of the copy RAM to Flash to be on
> > a 256 byte boundary. There are places, (eg. reset vectors)
> > where the intel hex address is not on a 256 byte boundary.
> > It will output the 4 byte vector for address 000000 and then
> > another at 000018 etc... This doesn't limit itself to just
> > the jump vectors of course, but I used that as an example.
> >
> > Have any others run into this problem and found an easy or
> > maybe a semi-standard way around it ?
> >
> > Just wondering...
> >
> > Thanks,
> > boB
> > Maybe I'm misunderstanding, but it sounds like you want to program
> each record independently. Why not buffer them (e.g. wait till you
> have 256 bytes) and program that? This assumes the records are in
> increasing address order if things aren't to get too complex. I know
> that's generally the case, but I'm not sure it's always true.
>
> The other obvious thing to do is post-process the file, either before
> the load or on the fly as it's loaded down. That way, you can arrange
> for the target to see what it needs to keep everything simple.
>
> Brendan.
>
I don't want to program each area independently because
I can't do that because of the necessity that the programming
start on that 256 byte address boundary... 0000, 0100, 0200, 0200, etc...
However, I just had a thought. While I'm reading in these chunks
of data from the .hex file, I could fill up the first 256 bytes of
RAM at the proper places, dictated by the intel.hex file, and then
do the copy RAM to Flash via the IAP.
Does this sound like the best way to go about doing this??
Is it what everybody else does maybe ??
There will most likely be more places in memory that will have
"holes" in them and not be on 256 byte address boundaries too.
boB
--- In l..., "Brendan Murphy"
wrote:
>
> --- In l..., "bobtransformer" wrote:
> >
> >
> > While we're on the subject of IAP, I've got a question...
> >
> > I'm working with the LPC214X and doing a bootloader. The LPC2XXX
> > evidently requires the start of the copy RAM to Flash to be on
> > a 256 byte boundary. There are places, (eg. reset vectors)
> > where the intel hex address is not on a 256 byte boundary.
> > It will output the 4 byte vector for address 000000 and then
> > another at 000018 etc... This doesn't limit itself to just
> > the jump vectors of course, but I used that as an example.
> >
> > Have any others run into this problem and found an easy or
> > maybe a semi-standard way around it ?
> >
> > Just wondering...
> >
> > Thanks,
> > boB
> > Maybe I'm misunderstanding, but it sounds like you want to program
> each record independently. Why not buffer them (e.g. wait till you
> have 256 bytes) and program that? This assumes the records are in
> increasing address order if things aren't to get too complex. I know
> that's generally the case, but I'm not sure it's always true.
>
> The other obvious thing to do is post-process the file, either before
> the load or on the fly as it's loaded down. That way, you can arrange
> for the target to see what it needs to keep everything simple.
>
> Brendan.
>
Reply by ●February 28, 20072007-02-28
--- In l..., "bobtransformer" wrote:
> Thanks Brendan.
>
> I don't want to program each area independently because
> I can't do that because of the necessity that the programming
> start on that 256 byte address boundary... 0000, 0100, 0200, 0200,
etc...
>
> However, I just had a thought. While I'm reading in these chunks
> of data from the .hex file, I could fill up the first 256 bytes of
> RAM at the proper places, dictated by the intel.hex file, and then
> do the copy RAM to Flash via the IAP.
>
That's exactly what I meant when I said "buffer" the data before
writing - I should have explained more fully.
To use your example, first clear (say) a 256 byte buffer (probably to
0xff); read in 1st record at address 0x0000, read in next record to
0x0018, keep reading while address is less than 0x100, then write
whole the entire buffer.
> Does this sound like the best way to go about doing this??
> Is it what everybody else does maybe ??
>
It's what I'd do....
> There will most likely be more places in memory that will have
> "holes" in them and not be on 256 byte address boundaries too.
>
> boB
You obviously have to account for cases where a record crosses a 256-
byte boundary, but if you write in 256 byte chunks then everything is
a lot simpler (i.e. if you have a "hole" followed by a record that
starts at 0x1234, then just read it into offset 0x34 of your 256 byte
buffer, and write the entire buffer to address 0x1200).
Brendan
> Thanks Brendan.
>
> I don't want to program each area independently because
> I can't do that because of the necessity that the programming
> start on that 256 byte address boundary... 0000, 0100, 0200, 0200,
etc...
>
> However, I just had a thought. While I'm reading in these chunks
> of data from the .hex file, I could fill up the first 256 bytes of
> RAM at the proper places, dictated by the intel.hex file, and then
> do the copy RAM to Flash via the IAP.
>
That's exactly what I meant when I said "buffer" the data before
writing - I should have explained more fully.
To use your example, first clear (say) a 256 byte buffer (probably to
0xff); read in 1st record at address 0x0000, read in next record to
0x0018, keep reading while address is less than 0x100, then write
whole the entire buffer.
> Does this sound like the best way to go about doing this??
> Is it what everybody else does maybe ??
>
It's what I'd do....
> There will most likely be more places in memory that will have
> "holes" in them and not be on 256 byte address boundaries too.
>
> boB
You obviously have to account for cases where a record crosses a 256-
byte boundary, but if you write in 256 byte chunks then everything is
a lot simpler (i.e. if you have a "hole" followed by a record that
starts at 0x1234, then just read it into offset 0x34 of your 256 byte
buffer, and write the entire buffer to address 0x1200).
Brendan
Reply by ●February 28, 20072007-02-28
--- In l..., "bobtransformer" wrote:
> While we're on the subject of IAP, I've got a question...
>
> I'm working with the LPC214X and doing a bootloader. The LPC2XXX
> evidently requires the start of the copy RAM to Flash to be on
> a 256 byte boundary. There are places, (eg. reset vectors)
> where the intel hex address is not on a 256 byte boundary.
> It will output the 4 byte vector for address 000000 and then
> another at 000018 etc... This doesn't limit itself to just
> the jump vectors of course, but I used that as an example.
>
> Have any others run into this problem and found an easy or
> maybe a semi-standard way around it ?
>
> Just wondering...
>
> Thanks,
> boB
Bob,
AFAIK 256-byte is a limitation of the Boot Loader implementation. LPC
flash controller allows you to write in 16-byte blocks.
I have explained the flash algorithm in my Boot Loader Internals page:
http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/boot-loader.html
If you dont have hang-ups bypassing the on-chip boot loader for flash
programming (I dont), you can adapt this algorithm to write in
16-bytes blocks -- the minimum block size for LPC flash. SILL does this.
I have implemented other boot loaders that do arbitrary
'non-destructive' writes by reading the block, modifying the changed
bytes, then writing the whole block back in a transparent manner. The
same can be done (but with limitations) for LPC flash.
Regards,
Jaya
> While we're on the subject of IAP, I've got a question...
>
> I'm working with the LPC214X and doing a bootloader. The LPC2XXX
> evidently requires the start of the copy RAM to Flash to be on
> a 256 byte boundary. There are places, (eg. reset vectors)
> where the intel hex address is not on a 256 byte boundary.
> It will output the 4 byte vector for address 000000 and then
> another at 000018 etc... This doesn't limit itself to just
> the jump vectors of course, but I used that as an example.
>
> Have any others run into this problem and found an easy or
> maybe a semi-standard way around it ?
>
> Just wondering...
>
> Thanks,
> boB
Bob,
AFAIK 256-byte is a limitation of the Boot Loader implementation. LPC
flash controller allows you to write in 16-byte blocks.
I have explained the flash algorithm in my Boot Loader Internals page:
http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/boot-loader.html
If you dont have hang-ups bypassing the on-chip boot loader for flash
programming (I dont), you can adapt this algorithm to write in
16-bytes blocks -- the minimum block size for LPC flash. SILL does this.
I have implemented other boot loaders that do arbitrary
'non-destructive' writes by reading the block, modifying the changed
bytes, then writing the whole block back in a transparent manner. The
same can be done (but with limitations) for LPC flash.
Regards,
Jaya
Reply by ●February 28, 20072007-02-28
Thank you Jaya ! I have looked at your software quite a bit
and it is very interesting and informative. I should definately
take a look at your options.
Also, thank you Brendan.
boB
--- In l..., "jayasooriah" wrote:
>
> --- In l..., "bobtransformer" wrote:
> > While we're on the subject of IAP, I've got a question...
> >
> > I'm working with the LPC214X and doing a bootloader. The LPC2XXX
> > evidently requires the start of the copy RAM to Flash to be on
> > a 256 byte boundary. There are places, (eg. reset vectors)
> > where the intel hex address is not on a 256 byte boundary.
> > It will output the 4 byte vector for address 000000 and then
> > another at 000018 etc... This doesn't limit itself to just
> > the jump vectors of course, but I used that as an example.
> >
> > Have any others run into this problem and found an easy or
> > maybe a semi-standard way around it ?
> >
> > Just wondering...
> >
> > Thanks,
> > boB
>
> Bob,
>
> AFAIK 256-byte is a limitation of the Boot Loader implementation. LPC
> flash controller allows you to write in 16-byte blocks.
>
> I have explained the flash algorithm in my Boot Loader Internals page:
>
> http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/boot-loader.html
>
> If you dont have hang-ups bypassing the on-chip boot loader for flash
> programming (I dont), you can adapt this algorithm to write in
> 16-bytes blocks -- the minimum block size for LPC flash. SILL does
this.
>
> I have implemented other boot loaders that do arbitrary
> 'non-destructive' writes by reading the block, modifying the changed
> bytes, then writing the whole block back in a transparent manner. The
> same can be done (but with limitations) for LPC flash.
>
> Regards,
>
> Jaya
>
and it is very interesting and informative. I should definately
take a look at your options.
Also, thank you Brendan.
boB
--- In l..., "jayasooriah" wrote:
>
> --- In l..., "bobtransformer" wrote:
> > While we're on the subject of IAP, I've got a question...
> >
> > I'm working with the LPC214X and doing a bootloader. The LPC2XXX
> > evidently requires the start of the copy RAM to Flash to be on
> > a 256 byte boundary. There are places, (eg. reset vectors)
> > where the intel hex address is not on a 256 byte boundary.
> > It will output the 4 byte vector for address 000000 and then
> > another at 000018 etc... This doesn't limit itself to just
> > the jump vectors of course, but I used that as an example.
> >
> > Have any others run into this problem and found an easy or
> > maybe a semi-standard way around it ?
> >
> > Just wondering...
> >
> > Thanks,
> > boB
>
> Bob,
>
> AFAIK 256-byte is a limitation of the Boot Loader implementation. LPC
> flash controller allows you to write in 16-byte blocks.
>
> I have explained the flash algorithm in my Boot Loader Internals page:
>
> http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/boot-loader.html
>
> If you dont have hang-ups bypassing the on-chip boot loader for flash
> programming (I dont), you can adapt this algorithm to write in
> 16-bytes blocks -- the minimum block size for LPC flash. SILL does
this.
>
> I have implemented other boot loaders that do arbitrary
> 'non-destructive' writes by reading the block, modifying the changed
> bytes, then writing the whole block back in a transparent manner. The
> same can be done (but with limitations) for LPC flash.
>
> Regards,
>
> Jaya
>
