Uploaded sketch not running after wireless programming [SOLVED]

[ltj]

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

[Felix]

Are you using a Moteino as target node?
How are you obtaining the HEX file that you are uploading?

[ltj]

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.

[Felix]

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.

[jarrods]

Itj,
Did you set the "

Code Select Expand

SPIFlash flash(8, 0xFFFF);

" to the correct ID? For that chip I believe it is 0x1F45 so it should be "

Code Select Expand

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) sketch that Felix provides. and try reprogramming the flash from serial just to see that it works. My guess is that "

Code Select Expand

flash.initialize();

" is failing but without serial connected your not getting that result of that function so it would be hard to tell.

[ltj]

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.

[ltj]

Just thought I killed two atmegas in trying to burn another bootloader  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.

[Felix]

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.

[ltj]

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?

[Felix]

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?

[ltj]

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.

[Felix]

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?

[ltj]

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.

[Felix]

Hehe .. glad you found the issue. Enjoying wireless programming?

[ltj]

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)