Flash self-programming - must page fill be done from NRWW section?

Log in or register to post comments
Go To Last Post
5 posts / 0 new
Author
Message
hooverphonique
hooverphonique's picture
Level: Hangaround
Joined: Fri. Aug 29, 2008
Posts: 120 View posts
Location: Fyn, Denmark
#1
Posted by hooverphonique: Wed. May 31, 2017 - 02:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am trying to program flash on an atmega1281, and the datasheet doesn't say that doing page fill (i.e. only SPMEN set in SPMCSR, boot_page_fill() from avr/boot.h, etc.) must happen from NRWW, but mentions numerous times that page erase and write *must* be done from NRWW (when flashing RWW) - it basically implies that page fill should work no matter which address space you're executing from!

 

I am (trying to) program pages in RWW using a function located in NRWW that performs the erase and write, that I call from code executing in RWW - since this function is located in NRWW, it should be alright. I am doing page fill directly from RWW address space, though, and the flash stays in the erased state (i.e. 0xFF).

 

I tried filling the page (with some static data) from inside my "erase and write"-function, and this indeed gets flashed - so is the datasheet just "wrong" about this, or is it something else I'm doing wrong?

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97532 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. May 31, 2017 - 02:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I seem to remember a thread within the last month asking this very question and I think the answer (found by experimentation) was that, no the page fill can be done anywhere. It's just the final SPM that needs to occur in the BLS.

 

Remember though that after doing erase/write you MUST re-enable the lower section (that is boot_rww_enable() if using avr/boot.h) to be able to get back to the code that does the page filling - because otherwise the lower flash all reads as 0xFFFF and no opcodes can be fetched from it. (been bitten by that before now - thank goodness for ICEs!).

 

BTW if writing a true bootloader (not just some flash storage code to accompany an app) it would be VERY unwise to have any part of it not in the protection of the bootloader area itself.

Last Edited: Wed. May 31, 2017 - 03:00 PM
Top
hooverphonique
hooverphonique's picture
Level: Hangaround
Joined: Fri. Aug 29, 2008
Posts: 120 View posts
Location: Fyn, Denmark
Posted by hooverphonique: Wed. May 31, 2017 - 03:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

I seem to remember a thread within the last month asking this very question and I think the answer (found by experimentation) was that, no the page fill can be done anywhere. It's just the final SPM that needs to occur in the BLS.

Hmm.. I guess I'll have to do some more digging then

 

clawson wrote:

Remember though that after doing erase/write you MUST re-enable the lower section (that is boot_rww_enable() if using avr/boot.h) to be able to get back to the code that does the page filling - because otherwise the lower flash all reads as 0xFFFF and no opcodes can be fetched from it. (been bitten by that before now - thank goodness for ICEs!).

My "page erase and write"-function indeed ends with "boot_rww_enable();" ;-)

 

clawson wrote:

BTW if writing a true bootloader (not just some flash storage code to accompany an app) it would be VERY unwise to have any part of it not in the protection of the bootloader area itself.

What I'm doing is a little untraditional bootloader approach, where I split the RWW section in two, using the lower part for the app, the upper for storing an update image (flashed by the app), and then a small bootloader that just flashes the upper part to the lower part on reset (after a few checks, of course). This way I don't need any comms interface in the bootloader, and reliability will be high due to the fact that the risk of both images being bad is minimal (presuming the app doesn't corrupt itself *and* the update, of course).

 

Are you thinking about anything specifically being unwise?

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97532 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. May 31, 2017 - 03:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hooverphonique wrote:
Are you thinking about anything specifically being unwise?
Nope. If you have "secondary storage" available to be able to hold a complete copy of the application then the dual image thing is about as "foolproof" as you can make it as you won't start the update process until you know you have a verified new application image totally delivered and even if the power fails half way through the app replacement process it doesn't matter because the bootloader can just restart at next power on.

 

However if some part of that bootloading process were dependent on something in the app image area imagine the scenario where that has already been deleted just ready for the next image to be written but then power fails or whatever. You don't want to be left in the situation where the bootloader can no longer recover because some part of its operation has already been wiped.

 

Given that there are no comms (while bootloading) in your process surely there must be room in the BLS (even set to the smallest size?) to accommodate EVERYTHING - the page loading and the erase/write stuff too?

Top
hooverphonique
hooverphonique's picture
Level: Hangaround
Joined: Fri. Aug 29, 2008
Posts: 120 View posts
Location: Fyn, Denmark
Posted by hooverphonique: Wed. May 31, 2017 - 04:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

However if some part of that bootloading process were dependent on something in the app image area imagine the scenario where that has already been deleted just ready for the next image to be written but then power fails or whatever. You don't want to be left in the situation where the bootloader can no longer recover because some part of its operation has already been wiped.

 

Given that there are no comms (while bootloading) in your process surely there must be room in the BLS (even set to the smallest size?) to accommodate EVERYTHING - the page loading and the erase/write stuff too?

 

Since boot_page_fill() is just a few instructions, it currently is present both in the app image and the bootloader. I can't seem to get page fill to fly when executing in RWW, so I think I will just move that to the bootloader as well as you suggested.

 

Thanks...

 

Edit: Making the mentioned changes resulted in my host upload software outputting this ('result' is the response from the atmega):

.

.

UploadChunk: offset 0x6980, result 0 (kReadyForData)
UploadChunk: offset 0x6a00, result 0 (kReadyForData)
UploadChunk: offset 0x6a80, result 0 (kReadyForData)
UploadChunk: offset 0x6b00, result 0 (kReadyForData)
UploadChunk: offset 0x6b34, result 1 (kUploadDoneCrcOk)

 

So I guess my conclusion basically is that page fill doesn't work from RWW (I just moved the page fill code from the app to the bootloader unmodified).

Last Edited: Wed. May 31, 2017 - 04:52 PM
Top