remotly reflashing through internet

hi there,

don't know if i'm asking at the right place. please let me know if this post should be placed somewhere else.

i'm working on various ideas and i'd like to know something:

assuming i have an arduino connected to internet (probably ethernet, doesn't matter i guess)

==> can I remotly reflash it ? (sending it a new firmware to reprogram its behaviour like we do using the usb cable?)

thanks ! ;D

I don't believe it's possible for a AVR micro-controller to be running a program and at the same time reflash it's program memory. It sounds like a chicken and egg problem to me. ;)

Lefty

so i'd need another arduino just to reflash the first one ?

sounds like a pretty expensive approach...

sorry if my question seems dumb :)

maybe the compaison is off topic but for instance i have a siemens voip phone at home. When a new firmware is available, the phone asks the user if he/she wants to upgrade, upon clicking yes on the keyboard the thing "does something for a while" (probably downloading the new firmware), then rebots, and then it's got a new firmware

i was wondering if i could achieve something similar with a arduino

sorry if my question seems dumb

It's not a dumb question. But it is a unique question.

A "bootloader" is what writes your program into the Arduino's memory. The bootloader that comes with an Arduino works over a serial link. Your phone goes through a very similar process. But its "bootloader" is designed to work over a wireless connection.

To do what you want you would need to either write or locate a bootloader that works over an internet connection.

Alternatively, I believe there are devices that communicate TCP/IP on one side and serial on the other. Something like that may work.

To do what you want you would need to either write or locate a bootloader that works over an internet connection.

i'm a noob when it comes to electronics (well i do remember the basics taught at university), however i do have some rather serious background regarding programming. Does writing such a bootloader sound totally unrealistic in this context?

alternatively where can i find a custom boot loader to get some inspiration? or maybe even finding one that almost does exactly what i'm thinking of ? it is written in C like the arduino code or is it so short and close to metal that you have to write something assembly-like ?

Alternatively, I believe there are devices that communicate TCP/IP on one side and serial on the other. Something like that may work.

could you develop your point here ? i'm not sure i'm getting the big picture. do you have a reference for such an item ? a website where i could purchase such a product to make some experiments ? (i am not sure the standard arduino ethernet shield does this natively...)

thanks

Does writing such a bootloader sound totally unrealistic in this context?

My suspicion is that such a bootloader would be rather large. If it's too big, it cannot be installed as a bootloader. I think the limit is 2K.

alternatively where can i find a custom boot loader to get some inspiration?

The source code for Arduino bootloaders comes with the Arduino IDE software. For Arduino 0018, look in {Your Arduino Directory}\hardware\arduino\bootloaders. They will give you ideas on how to directly access hardware and how a program is placed into memory.

or maybe even finding one that almost does exactly what i'm thinking of ?

Can't help with that one.

it is written in C like the arduino code or is it so short and close to metal that you have to write something assembly-like ?

They seem to be a mix of C and assembly.

could you develop your point here ? i'm not sure i'm getting the big picture.

It's a box that has TCP/IP connection on one side and RS-232 or TTL serial on the other. What ever goes in on one side is retransmitted on the other side. Typically, they're configured through the TCP/IP side with a utility or built-in web server.

do you have a reference for such an item ?

Not any worth mentioning. It's been years since I worked with devices like that. You're much better served by performing your own search.

I think it is theoretically possible that you could download the HEX data into something like EEPROM over internet (supposing you have an arduino that has enough EEPROM space, or if you have an external EEPROM chip) and then re-write the bootloader to read the EEPROM, check some version number and then flash it if the current version is less then the EEPROM version, etc...

However, you would want to ensure the EEPROM matched a fairly good checksumming system too -

  • what if someone restarted the arduino during the download and only half of the EEPROM code was valid?
  • what if internet connection dropped during the download?
  • what if the EEPROM chip was faulty and a bit couldn't be set properly?

etc..

... or the next time you booted your arduino after any of the above occured, it would half-flash itself and never perform again! (until the code was re-uploaded manually, that is...)

thanks for the comments.

how much is an extra EEPROM big enough to store a new firmware?

regarding firmware integrity, i was thinking of calculating a md5 or a sha hash since I'm thinking of embedding this functionality into the aldruino anyway for the rest of the project. so i'm not too worried about this part (except i need to code it, but i've seen other having success with sha so i might just borrow their work... (hurray for open source !) i just hope such code won't fill the memory too much)

also i am planning to store original hashes on remote web server like it's being done for most linux distros and various other binaries distribution systems. if my remote server gets hacked i'd be in an even worse situation than having a complete adruino fleet broken in the middle of a firmware upgrade :)

MD5 in bootloader? May be a bit large for the standard bootloader space.

If you had an EEPROM the same size as the flash specs for the arduino you are using, that would theoretically work - since 2K of the flash is bootloader, you have 2K extra for control data like checksum, version, etc.

That kind of makes an interesting scenario for production - too; if you want to upload code, you could then also just plug in a new EEPROM with updated code and restart - it will update itself from that.

or if you have an external EEPROM chip

Because of the architecture of the chip that makes up the arduino you can't run instructions (code) out of EEPROM internal or external.

Because of the architecture of the chip that makes up the arduino you can't run instructions (code) out of EEPROM internal or external.

True, but can you not read internal/external EEPROM from the bootloader and write the code to the flash (instead of receiving from serial, for example)

You can but look at the sector mapping, that tells you what sectors you can write to while running code. I think you will find that the bootloader's 2K is all you can use while running. So you have to fit it all into the already nearly full bootloader space.

Maybe my idea isn't clearly being communicated; (or I am once again trying to make things too simple when they are not.)

First, bootloader is re-coded. Upon power on of the AVR:

  1. Bootloader examines the EEPROM for something to determine new code (compare perhaps some data on the external EEPROM with some data on the internal where the current code version number is). If the versions are the same, or checksum fails - goto step 4.
  2. New Codeload method from EEPROM - read code size from external EEPROM and program flash (same way the existing bootloader does it, just take input from EEPROM, not data from serial IO)
  3. Write the version in the internal EEPROM to satisfy step 1 on next boot.
  4. Jump to code, application (HEX) runs as current arduino does it.

Does that added info make sense?

Does that added info make sense?

It does if these steps are added…

  1. The Sketch checks the internet for updates. If none available, skip the rest and run the actual application.
  2. Download the update from into the EEPROM.
  3. Force the bootloader to run.

For this strategy to work, it is critical that a two-phase commit be performed on the EEPROM image.

It’s a twist on this method…
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1260909294

mmmm so that could work then… for the price of an extra 2K EEPROM or something (which sound like a darn cheap thing to me)

am i right ? can someone confirm the approach ?

  • days of hardwork of course :slight_smile:

can someone confirm the approach ?

The big pieces have been done by folks here: download something from the internet, write something to an external EEPROM, program the processor from external storage. But I think this is the first time anyone has wanted to bring all that stuff together.

A 2K EEPROM is not going to suffice: the entire sketch has to fit into the EEPROM. The part that downloads from the net will be much larger than 2K. I'd plan on one at least as big as the flash on the ATMega chip: you'll want a little more than the size of the sketch to hold checksum and other description info.

thank you guys for the feedback.

i need to sharpen my arduino skills first as such a feature i way too complicated for me for now.

however it’s good to know at least it’s doable + a course of action to actually implement it

another reflex i’m having before coding anything :
how can i automatically test this ? (unit test + functionality tests)

but myba such a question should go to a dedicated thread