Uploaded sketch not running after wireless programming [SOLVED]

[Felix]

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.

[KanyonKris]

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.

[48X24X48X]

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!

[Felix]

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?

[48X24X48X]

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?

[Felix]

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

[48X24X48X]

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?

[Felix]

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

[48X24X48X]

Hi Felix,

I think I know where I got it all wrong. 

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.

[48X24X48X]

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!