FW update using external EERPOM

Log in or register to post comments
Go To Last Post
15 posts / 0 new
Author
Message
DanR
DanR's picture
Level: New Member
Joined: Mon. Jun 5, 2017
Posts: 14 View posts
#1
Posted by DanR: Tue. Jul 9, 2019 - 08:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all!

I'm using:

MCU AtXMEGA256A3U.

EEPROM - what ever 64Kb-256Kb.

Program - approximately 40-50Kb.

The issue : 

I'd like to upload new FW version of the MCU to EEPROM using (I2C/SPI/UART/other) communication. 

HOST>>EEPROM>>MCU.

So where would you copy/put this data from EEPROM to be able to boot the MCU from that adress?

The idea is, if possible, block memory for FW_UPDATE_BLOCK (to avoid erasing of old program).

Copy from EEPROM to BLOCKED aria new FW.

Boot with specified bootloader address. 

 

OR

 

The other idea, if possible, in bootloader mode configure FW update from external EEPROM, similar to FPGA and EPC.

 

I would be happy to receive any recommendations, those with some basic and links to datasheet/application notes even more)   

Thanks,

Dan

Thanks!
Dan

Tags:

AVR Microcontrollers, AVR and XMEGA, #EEPROM #Bootloader #FWUPDATE, #XMEGA #ATXMEGA256
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101069 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Jul 9, 2019 - 09:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you previously download the f/w to the EEPROM so you already have the entire image before replacement why would you need to keep the old f/w? Surely you can validate the delivery first and then, when you are ready for it, just enter the bootload/SPM code to do a complete image replacement?

 

If you are talking about some kind of "ping pong" arrangement where the main app section holds two copies of the code and then you switch/alternate between them then your main issue is going to the the interrupt vector table (it can't move) so to support two differently located program images you'd need to take all the active vectors through some kind of redirectable mapping table (a table of function pointers?)

Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 30443 View posts
Location: Wormshill, England
Posted by david.prentice: Tue. Jul 9, 2019 - 09:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you explain exactly what you want to do readers can offer practical advice.

 

Since you have a USB chip there is probably a USB socket and cable.

Just update firmware via the factory DFU bootloader.

 

David.

Top
DanR
DanR's picture
Level: New Member
Joined: Mon. Jun 5, 2017
Posts: 14 View posts
Posted by DanR: Tue. Jul 9, 2019 - 09:43 AM (Reply to #2)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, for your respond.

 

I don't want to keep my old FW version but I want to avoid system crash due to FW rewriting on the run. 

I'm thinking of avoiding this situation.

 

In general i want to update my FW using external EEPROM.

Communication with the ex. EEPROM is serial, meaning I need to be able to use serial port all the time till i have the image on MCU(Flash probably).

Surely you can validate the delivery first and then, when you are ready for it, just enter the bootload/SPM code to do a complete image replacement?

 Yes.

What would be "SPM code"?

 

If the idea in general sounds ok...

For this point of time it's a "go" for me))) 

I'm looking at moment for few more points of view. 

 

Thanks!
Dan

Top
DanR
DanR's picture
Level: New Member
Joined: Mon. Jun 5, 2017
Posts: 14 View posts
Posted by DanR: Tue. Jul 9, 2019 - 09:50 AM (Reply to #3)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you explain exactly what you want to do

At the moment I would like to understand if FW update using EXTERNAL EEPROM is possible.

 

Since you have a USB chip there is probably a USB socket and cable.   

Mmm...no. No USB socket/cable. EEPROM is on my board, it will be updated by someone else. I don't see this data before it is on the EEPROM.

And more, I do nothing with the EEPROM before I receive  some input from "THE WORLD".

Thanks!
Dan

Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 30443 View posts
Location: Wormshill, England
Posted by david.prentice: Tue. Jul 9, 2019 - 10:09 AM (Reply to #5)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DanR wrote:

At the moment I would like to understand if FW update using EXTERNAL EEPROM is possible.

Yes.

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101069 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Jul 9, 2019 - 10:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SPM = Self Program Memory. It is the opcode the AVR can execute to rewrite bytes/pages in its own application flash. The Xmega are nice in that they have a separate flash area for the bootloader code. The only place you can successfully execute SPM is in code located in that bootloader area. There is a whole chapter in the Xmega datasheet that explains the operation of SPM. Suggest you read it. SPM is going to be the basis of any flash updating scheme you use.

 

Normally when you use a bootloader (SPM code) you want to ensure that if the app space is ever corrupted (like a previous attempt at updating that got interrupted part way through - perhaps someone disconnected the power or something?) then at the next power on the chip can recover itself. So you arrange at power on for the permanently present SPM code to run first every time (this is why it's called "bootloader" as it runs at boot time). It can somehow check the validity of the application area (CRCs are good for this and, guess what, the Xmega has a built in CRC generator!). If it finds that the app does not look good it would (in your case) then have a look at the EEPROM. As long as that contained a "good copy" of code the bootloader could now SPM that image into the main flash and then start the chip at 0x0000 to run it. At subsequent power-on's it would also do this check. Most of the time it would find a valid app so would just jump into it at 0x0000 every time. But if the CRC (or other) check were ever wrong it would do the bootloader thing. It might also have some other trigger mechanismn - like a flag byte in EEPROM say. If the app code receives new firmware and knows it needs to update. It would then set the EEPROM flag. At next power on the bootloader would also check that flag and, if set, it would do the replace app with external code image again.

 

BTW KB means something different to Kb. I imagine in #1 you meant KB not Kb.

 

(oh and to be truly pedantic it is Kib or KiB ;-)

Top
DanR
DanR's picture
Level: New Member
Joined: Mon. Jun 5, 2017
Posts: 14 View posts
Posted by DanR: Tue. Jul 9, 2019 - 10:23 AM (Reply to #6)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks)

Thanks!
Dan

Top
DanR
DanR's picture
Level: New Member
Joined: Mon. Jun 5, 2017
Posts: 14 View posts
Posted by DanR: Tue. Jul 9, 2019 - 10:34 AM (Reply to #7)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for explanation, may I summarize to see I understood it?

 

My real way to update the FW using ex. EEPROM is Host>>EEPROM>>copy to Flash>>if requested>> check CRC, if good>> go to boot section and use new FW.

Correct? 

  BTW KB means something different to Kb. I imagine in #1 you meant KB not Kb.

Mistype. I mean kilobyte -> KB->kB ->2^10 bits)).

   the Xmega has a built in CRC generator!

Using it as code check...message check... etc. check  

Thanks!
Dan

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101069 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Jul 9, 2019 - 10:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Host>>EEPROM>>copy to Flash>>if requested>> check CRC, if good>> go to boot section and use new FW

well it's more like:

 

Host>>EEPROM>>if requested::copy to Flash>> check CRC, if good>> already in boot section and use new FW

 

I'd study some pre-existng bootloaders - everything here has already been done to death. Admittedly most bootloaders don't have a "holding tank" to locally maintain a code image (usually it is delivered over a comms channel like UART as the reprogramming proceeds) but otherwise all the techniques are pretty much standard.

 

In fact, in the past, I've don bootloaders bother from AT45 Dataflash and also from SD/MMC memory cards. I guess either is fairly similar to what you plan here.

 

One of the key things you always have to to bear in mind - is there any kind of disaster that can occur that could ever render the device unrecoverable? Think about any kind of "interruption" like the power dying half way through reprogram or a break in comms while the code image is being delivered etc.

 

In particular don't rely on some mechanism in the app to be required to recover. Some times the app may only be "half there". So the app can use functionality from the bootloader code but the bootloader should have no reliance on the application code.

 

As always spend some time up front thinking about and designing the solution - do not just rush to implementation without thinking through all the use cases and disaster scenarios. What you cannot have happen is to "lose" a population of 50,000 deployed devices out in the field or something because there was something you hadn't thought of upfront!

Top
Brian Fairchild
Brian Fairchild's picture
Level: Raving Lunatic
Joined: Thu. Oct 18, 2001
Posts: 5354 View posts
Location: Eastern England.
Posted by Brian Fairchild: Tue. Jul 9, 2019 - 10:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DanR wrote:

My real way to update the FW using ex. EEPROM is Host>>EEPROM>>copy to Flash>>if requested>> check CRC, if good>> go to boot section and use new FW.

Correct? 

 

No, because once you've copied it to flash you have no way back. You should CRC check the EEPROM before you copy it to the flash.

 

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Top
DanR
DanR's picture
Level: New Member
Joined: Mon. Jun 5, 2017
Posts: 14 View posts
Posted by DanR: Tue. Jul 9, 2019 - 11:35 AM (Reply to #10)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks!

 

Thanks!
Dan

Top
DanR
DanR's picture
Level: New Member
Joined: Mon. Jun 5, 2017
Posts: 14 View posts
Posted by DanR: Tue. Jul 9, 2019 - 11:46 AM (Reply to #11)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That would be interesting point. 

How would this check help me if EEPROM's image is good, but the copy is with one wrong copied bit?

 

Thanks for heads up. 

 

So one CRC on EEPROM once it was fully updated, + one CRC on the copied to MCU's memory file.

Thanks!
Dan

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101069 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Jul 9, 2019 - 11:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The CRC thing is there to make sure it got safely from the EEPROM (you have to "trust" that copy) to the flash. It's specifically to detect when something like an interruption prevented the reflashing completing successfully.

 

I suppose then you first send the code from the host to the EEPROM then that image itself could also have the CRC passed alongside. That way, when the transfer was complete and you have the whole image in EEPROM ready to be programmed you could use the CRC that also came with it to check the validity before you pepper it all over your application space. Don't even contemplate starting a reprogramming if the image is not proven valid. (this is a bit like when you download a zip/tar/etc from the internet and the supplier also gives you an MD5 or an SHA256 - that is to prove that what you received is binary identical to what they put on their site in the first pace (in case it is "damaged" or even that someone malicious messed with it and tried to install a trojan etc)

Top
DanR
DanR's picture
Level: New Member
Joined: Mon. Jun 5, 2017
Posts: 14 View posts
Posted by DanR: Tue. Jul 9, 2019 - 12:23 PM (Reply to #14)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well yes, usually i work like that.

Code's CRC is hold in EEPROM, along with some calibration/some info.

And as i said before, CRC on each incoming data is coming together with the data. 

If CRC is NOT OK - data is cleared (if i have time for that), and the Host notified, If needed.

 

Thanks!
Dan

Top