I m using a number of arduino based building automation devices to control relays, sensors etc. They are all connected by rs485 over a cat5 cable that also supplies the required power. I would be interested to also use the same comms channel to remotely upload new versions of sketch. Anyone has any ideas if its possible? I could get the arduino to reset on command but then how do one upload a sketch from essentially a serial port?
Anyone has any ideas if its possible?
It is possible but you would have to write your own boot loader to do this.
but then how do one upload a sketch from essentially a serial port?
That is what happens normally with an Arduino.
Watcher:
I m using a number of arduino based building automation devices to control relays, sensors etc. They are all connected by rs485 over a cat5 cable that also supplies the required power. I would be interested to also use the same comms channel to remotely upload new versions of sketch. Anyone has any ideas if its possible? I could get the arduino to reset on command but then how do one upload a sketch from essentially a serial port?
How much support is on each of the devices?
I am implementing a similar process, I am using ATMega2560's and have onboard FLASH. to do an upgrade I send a new binary which the Mega writes to flash. The binary is CRC'd and version checked. If these tests pass the Mega sets a signature in EEPROM, then Resets. The modified bootloader checks the signature and reprograms itself.
Chuck.
Check out my Kickstarter Project Memory Panes an expansion RAM Shield for Mega2560's. It adds 1MB of RAM for those projects where 8KB is not enough.
Thanks for your reply.
Each device consists of a Leonardo or Mega (according to the needs of each task) a serial EEPROM, a MAX485 transceiver and additional circuitry again according to the specific task of each device (sensors, RTC, etc)
All data transfer on the RS485 channel is CRC checked and verified before any commands are executed.
Sorry for resurrecting this 3 yo thread but decided to chase this topic again now that I am redesigning the PCB of the system (see OP for system details)
So I will be adding a flash memory chip for the purpose of saving the received compiled sketch, then reset the arduino and perform a new sketch upload from flash memory.
I would be looking for some advice both on the choice of flash memory chip as well as anything that would help me avoid mistakes..
I am considering AT45DB041D which is a serial interfaced flash memory chip.
Is it a good choice?
or is there another type/version more suitable for this purpose?
I can easily save the received (over RS485 serial) hex file but how do you then upload the hex file to arduino program memory?
Is there suitable bootloader already available?
Any advice or thoughts is appreciated !
Thanks!
The concept is sound, first step would be to sketch out a serial protocol with the commands to:
a) Erase SPI flash
b) Write a hex record to SPI flash
c) Program AVR memory from SPI flash
d) Reset the processor
a) is easy, b) is all ascii and you can use the checksum in the hex record for validation. d) is easy but the must difficult part will be the code for c) since it will need to replace or co-exsist with the current bootloader.
I would not spend too much time looking at the serial bootloader as it deals more with the STK500 protocol, just read and understand the processor datasheets where they explain insitu programing of the device flash.
You’ll probably also need some kind of error recovery, for example, what happens if power fails during step c? That leaves you with corrupted AVR flash so that needs to be considered. Perhaps nothing more than erasing SPI flash when programming is complete and your replacement bootloader, when powered up/reset, looks for a valid memory image in SPI flash and writes it to the AVR if found.
The SPI flash isn’t at all critical, it only needs to match the AVR flash size. The only thing to keep in mind is that 5v SPI flash is obsolete so in order to keep costs down, you’ll need level translation to 3.3v. You can get 5v fram large enough to work but you’ll pay probably 5x more than plain old SPI flash.
Thanks for the input avr_fred.
I already have available 3.3v so its not a problem for the spi.
I agree that "c" is ghe most difficult part....and its what puzzles me.
I would not spend too much time looking at the serial bootloader as it deals more with the STK500 protocol, just read and understand the processor datasheets where they explain insitu programing of the device flash.
I even thought of adding a second mpu onbiard to handle the programming of the main mpu. But id like to avoid this if possible.
So you are proposing to develop another bootloader?
Yes and no.
I’m only agreeing with your original concept - which includes developing a piece of code that permanently resides in high memory that transfers a program from external SPI memory to the device program space. Call it whatever you desire although bootloader would be appropriate.
Can it be done? Of course. Can you do it? I don’t know. What research have you done? I guess not much as this pops up in the second Google link for “load avr memory from external flash”:
Other than the (unsurprising) lack of Mega support, it looks like it provides bits (c) and (d) in my post above.
ChipBoot bootloader supports rs485, and it works.
DrAzzy:
ChipBoot bootloader supports rs485, and it works.
Is there a link available? Couldn't google it..
Sorry, its chip45boot2
DrAzzy:
Sorry, its chip45boot2
Looks very interesting . I will sure give it a try!
Is it compatible with the arduino pinout etc?
Bootloader doesn't care about the pinout used by the sketch - I think they use UART0 for upload just like the Arduino boards do.
My 2 cents.
Chip45 describes a serial bootload firmware and an uploader (chip45boot2 GUI) that can update the firmware over half-duplex serial.
The Chip45 bootload firmware does not look compatible with the avrdude uploader that Arduino uses so the hex file built from your source will be needed. Neither the Chip45 uploader or bootload firmware show anything that looks like a multi-device bus address so it seems likely that all the devices except the target need to be powered off during firmware upload.
XBoot is another option which uses the AVR109 protocol which works with avrdude (I used it on one of my 1284p boards).
XBoot and avrdude do not have any addressing to deal with selecting a target on a multi-device bus, so all devices except the target need to be disabled (e.g. disconnected from the bus, held in reset, or powered off).
There are some nice things about the serial bootloader on Arduino Uno over RS232 which I for one don't want to lose. The main thing is that no matter how messed up my firmware I can just bootload over the top of it (it's not an Arduino thing it is just how avrdude and optiboot work with the DTR capacitor trick).
For a multi-device bus, the only thing that made any sense to me was to put the DTR capacitor trick into a bus manager and let the manager control the connection of devices/host to the bus. The managers share their state through an out of band channel. When the host opens its serial port the manager can see the DTR (or RTS) line go active ( LOW) and if the bus is available it will send a bootload address via the out of band channel to reset the target and lock out the other devices so avrdude has a point to point connection with the target. The main serial channel I use is a full duplex link but I suspect it could be made to work with a half duplex link. I can't think of any firmware errors that will lockup this bus and not cause Arduino Uno problems (e.g. forget what they are, but one is if bootloader does not clear the watchdog).
As a side note, I have been researching the use of SAMD21 and SAMD51 with the BOSSA uploader. I think they will work also, the bus manager needs to know to double tap the bootload pin.
Thanks Ron for the clarifications and input.
What exactly is this "bus manager" you mentioned ? A second micro controller?
Yep, the bus manager is just a microcontroller. The most recent version I use is a 328pb (on RPUadpt^6) which has two I2C ports, before that, I was using a 328p and connecting the I2C to the target. With the 328p I would have to load software on the target to have a roundabout way to send commands by way of I2C to the manager (e.g. how to respond to a host connection), but now a host (Raspberry Pi or other SBC) can just tell the manager directly on the second I2C port.
@Watcher, I suspect you can make your own boards, so if you wanted to try the setup I suggest using the boards RPUno and RPUadapt. The BOM's and software I have been using are on Github. OSHPark is where I have been getting my boards.
RPUno OSH Park ~
RPUadpt OSH Park ~
I recommend a Raspberry Pi (other SBC may also work) with logic level UART interface. or something like AF's FTDIfriend.
I need to update my Raspberry Pi shield (RPUpi) after doing the one I am now working on but there are some notes in the repo on how I set up its Linux.
@Watcher, I suspect you can make your own boards, ...
Yes I ve been making my own boards for some time now. I also use a small reflow oven for production of 2+ boards at the same time.
The BOM's and software I have been using are on Github.
Thank you very much! Looks very interesting.
Are the schematics available as well? OSHPark seems to post just the PCBs.
My Eagle files are on Github.
I put them in a separate repository because I did not want my main repository (e.g. RPUno) to be described as Eagle by Github, I wanted it to say C. I did put PDF's and png images of the schematics in the main repositories (in the Hardware/Documents folder). I am trying to learn KiCAD but have not got far enough yet.
Thanks for sharing!
I am also into learning kicad since Eagle has changed hands but am still far behind!