Hi there,
I was just trying out the awesome wireless programming feature today, and finally thought I got it right. But unfortunately the newly uploaded sketch is not running on the remote node after programming. Everything seems to work ok, and I've monitored the serial output from the node which ends in success and "rebooting"...then nothing. Same scenario with various sketches of varying sizes. I can upload a new sketch to the board using ftdi afterwards no problem. It sounds a bit like the problem lies somewhere around the bootloader and the flash chip, but I can't really narrow it down. Any suggestions? :)
I should mention that the flash chip is an 8Mbit atmel AT25DF081A. But from the datasheet it should be a drop-in alternative to the stock Moteino flash chip.
Cheers,
Lars
Are you using a Moteino as target node?
How are you obtaining the HEX file that you are uploading?
Yes I'm using a Moteino as target. The hex is obtained by compiling a sketch either directly in Arduino or using the SublimeText Arduino plugin. The file is then digged out of some obscure tmp folder :)
Thanks.
Ok, that looks good then.
Since you're not using a known working flash chip, please check for differences in the datasheets. Not sure what else to suggest.
You have to verify the data is being written to the chip correctly. Maybe remove the rebooting and after the transfer is done check the content of the flash to see it's there.
Itj,
Did you set the "SPIFlash flash(8, 0xFFFF);" to the correct ID? For that chip I believe it is 0x1F45 so it should be "SPIFlash flash(8, 0x1F45);". Second I would try running the example SPIFlash_readwrite (https://github.com/LowPowerLab/SPIFlash/blob/master/Examples/SPIFlash_ReadWrite/SPIFlash_ReadWrite.ino (https://github.com/LowPowerLab/SPIFlash/blob/master/Examples/SPIFlash_ReadWrite/SPIFlash_ReadWrite.ino)) sketch that Felix provides. and try reprogramming the flash from serial just to see that it works. My guess is that "flash.initialize();" is failing but without serial connected your not getting that result of that function so it would be hard to tell.
Thanks for the replies.
@Felix: I'll scrutinize the datasheet for any subtle differences ;)
@jarrods: Thanks, I ran into exactly that issue a bit earlier. But the id was updated to 1F45 when running the wireless programming. The wirelessProgramming_node sketch ran fine and without errors (being reported) in the console.
Next step is to burn a dualoptiboot with the debug flag set to a moteino and see what comes out.
Just thought I killed two atmegas in trying to burn another bootloader :P They process was sketchy and they ended up being in a rather uncertain state. Luckily it was only because I forgot to assert pin 10 (RFM69 CS). I programmed them without the radio initially.
However, after a bit of thinking it crossed my mind that the bootloader must have recognized the new flash image somehow. Otherwise the original sketch should have been left alone and working. So the problem seems to be the flash image data *after* the FLX:XX: preamble. It even seems to erase the 32K block in the end, since a new sketch can be loaded no problem afterwards. I'm a software guy and sometimes struggling with all the low-level stuff, but I suspect the two flash chips have slightly different memory architectures. Can anyone help here? I've gone through the two datasheets but can't find any non-compatible stuff on the command side.
Thanks again.
I would start with baby steps. Remove the reboot from the WirelessHEX library (last step after WP is done). Then just read in the first say 256 bytes of the FLASH array. See my example sketches for that (look for the "d" command). Then compare that dump with the content of your HEX.
OK. Tried to remove the reboot. After uploading a new hex to the target I dumped the first 256 bytes using using the 'd' command in the example sketch. From what I can see, everything after the first 10 bytes (first 10: 46.4C.58.49.4D.47.3A.13.2.3A) matches the data parts of the hex file. It would probably be a bit foolish to assume the rest is just fine, but if we do so, is it possible the problem lies with the bootloader reading the data?
The bootloader should flash the atmega with the hex dump then erase the first 32K block.
Is the HEX still there if you leave the reboot in place?
Can you include the first 15-20 bytes in here so I can look at the preamble?
Did you verify that you're running the latest WirelessHEX code from github?
Your help is much appreciated.
Yes, it seems like the bootloader reaches the erase part. After a reboot all bytes are 0xFF again.
Here's the complete 256 byte dump formatted in 16byte chunks (except first line of course):
46.4C.58.49.4D.47.3A.13.2.3A.
C.94.6F.1.C.94.97.1.C.94.97.1.C.94.97.1.
C.94.97.1.C.94.97.1.C.94.97.1.C.94.97.1.
C.94.97.1.C.94.97.1.C.94.11.5.C.94.98.5.
C.94.97.1.C.94.97.1.C.94.97.1.C.94.97.1.
C.94.97.1.C.94.97.1.C.94.97.1.C.94.97.1.
C.94.97.1.C.94.97.1.C.94.97.1.C.94.C9.1.
C.94.97.1.C.94.97.1.C.94.97.1.C.94.97.1.
C.94.97.1.C.94.97.1.C.94.97.1.C.94.97.1.
C.94.97.1.C.94.97.1.C.94.97.1.C.94.97.1.
C.94.97.1.C.94.97.1.C.94.97.1.C.94.97.1.
C.94.97.1.C.94.97.1.C.94.97.1.0.0.0.0.
24.0.27.0.2A.0.2D.0.30.0.0.0.0.0.25.0.
28.0.2B.0.2E.0.31.0.0.0.0.0.23.0.26.0.
29.0.2C.0.2F.0.4.4.4.4.4.3.4.5.2.2.
2.2.4.3.2.2.2.2.6.6.6.6.6.6.4.4.
2.2.2.4.4.8.2.
The code I'm using was pulled from github just days ago.
Everything looks good... if the bootloader erases the image it means it finds the valid HEX image and reflashes the unit, then finally erases the first 32K. So .. is it possible the HEX is invalid?
You nailed it, Felix. Faulty toolchain script. I feel so stupid. The coin shoud've dropped when I noticed the blink sketch I was trying to upload was way bigger than usual ;) Thank you so much.
I can hereby confirm also, that the Atmel/Adesto AT25DF081A flash chip and it's siblings works like a charm on the Moteino without any code modifications.
Hehe .. glad you found the issue. Enjoying wireless programming?
Quote from: Felix on January 19, 2014, 04:41:53 PM
Hehe .. glad you found the issue. Enjoying wireless programming?
Indeed :) Great implementation if I may say so, and easy to get around and poking at stuff.
Already wondering about a "pull" version for battery operated nodes. Any thoughts on that yet? (I may have missed a post)
There's no magic bullet. You have to worry about battery life which means the radio has to sleep. But has to listen as well. There have been other discussions with Kris on this forum about how to go about doing that. Things like wait the HEX at the gateway until the node wakes up and asks if anything needs to be delivered. Alternative implementations are possible.
ltj, I have the process mapped out for "low power" wireless programming but have yet to code it. The basic idea is: remote node sleeps a lot to save power, when it wakes up it reports data (ie current temperature) then listens for a little while for commands from the gateway, such as "ready to send you a new sketch".
To accomplish this I planned to use the same wireless programming protocol Felix developed, just add some commands to let the remote node(s) know there is a new sketch available.
Since I use a Raspberry Pi connected to a Moteino as my gateway system, I plan to store the new sketch (hex file) on the Pi and pass it through the gateway Moteino to the remote node.
Hi Felix,
Sorry for digging out an old post.
I'm currently using your dual optiboot bootloader and SPIFlash library for wireless bootloading but using an RFM95.
But, I managed to store the firmware image according to the dual optiboot format, it doesn't seems to bootload itself to this new firmware image (simple blink LED sketch). But, it sure managed to wipe them out clean after going into the boot mode.
Flash is working as I tested with the example from the SPIFlash library.
Here's a screenshot of the serial flash content of the firmware image.
I'm only afraid that what I write into the flash is incorrect in terms of the format.
Compared to the hex file, everything is the same except the ":" is removed from each line.
Any help would be great!
If the 10byte signature (including the two count bytes) is there it should pick it up, reflash the image and delete the first 32K block in the FLASH chip. That's the sequence anyway.
Are you using a genuine Moteino?
Hi Felix,
Thanks for the reply.
Unfortunately, I'm using a custom board fitted with a RFM95 running at 3.3V @8MHz.
I did recompile your dual optiboot for this purpose. The only different is the F_CPU and baud rate to 57600 bps (will not work at 115200 bps). It works great on the serial upload but only fails using bootloading from the serial flash.
I did get the image format right?
The ":" from each line in the Intel hex format must be removed right?
Correct, no colons.
I don't know how you're loading the image on the flash but from what you're saying it sounds like you're not using my WirelessHEX library.
Your image needs to be processed and CRCs removed before loading on the flash memory.
This is illustrated in my library so I will not repeat and explain that in this forum: https://github.com/LowPowerLab/WirelessProgramming/blob/master/WirelessHEX69/WirelessHEX69.cpp
Hi Felix,
I'm using a very plain communication protocol. It does get the image transferred completely though.
But, I can confirm the image is correct (in the screenshot I showed earlier).
I was using your older dual optiboot (after fixing the PB3, PB5, PINB & changed them to PINB3, PINB5 and PORTB in optiboot.c).
I think maybe I should try the latest version. Running them on Arduino 1.0.5 IDE is okay right?
Looking at your image again it's obvious the image you have is wrong. You are just raw copying the hex image which includes the intel hex headers and CRC bytes, and this is all big endian. You will need way more than just raw copy, you need to essentially dehexify the image before it's ready to dump in your atmega flash memory. That's exactly the purpose of the WirelessHEX69 library, look there for details how that is done: https://github.com/LowPowerLab/WirelessProgramming/blob/master/WirelessHEX69/WirelessHEX69.cpp
I suggest you also check the intel hex format spec: http://en.wikipedia.org/wiki/Intel_HEX
Hi Felix,
I think I know where I got it all wrong. :D
The firmware data that should be flashed into the serial flash should only consists of the "raw data section" which is usually 16 bytes like you have mentioned. These 16 bytes are represented by 32 characters in ASCII which I need to convert to binary and hence 16 bytes only. So, basically I need to write these 16 bytes per line into the flash. There could lines containing less "raw data section" like 2 bytes too. For line containing 0 "raw data section", nothing should be written into the flash.
Sorry for all the trouble.
Other than that, I think PBx is depreacted in newer AVR distribution. PINBx should be used instead.
Hi Felix,
Got it working after using the "raw data section" and converting 2-byte to 1-byte.
I will be trying with a binary file after this to speed things up as the RFM95 is way much slower than a RFM69. :)
Thank you again!