Reprogramming atmega1284 MCU via OTA firmware...

Hey again everyone,

So I've ran into a snag with our firmware reprogramming sketch. It never seems to actually do the reprogramming part...

The connection (via cellular) is solid, the hex file gets pulled down in chunks and then- seemingly, the unit just restarts.

I'm hoping this is something silly, that's either forcing a reset or isn't completing a step along the path.

Would much appreciate a look at this code, any and all help would be appreciated. The furthest I get in the flow is down to:

Serial.println(F("Updated Metadata"));

...and then the unit seemingly restarts. Cheers.

program.ino (11.7 KB)

That code has no loop and not setup so it's not a complete sketch.

From the excerpt I see in the file I would expect the processor to reset after that line because immediately after it in the flow I find a delay(10000) which waits for ten second, the highest watchdog wait period is 8s, guess what the processor does.

Hey Pylon,

Thanks for posting up.

I'm sorry- I posted that up late and forgot to mention that indeed, the sketch is part of the much larger sketch that that file lives in.

The call made from the primary is to the first function in that ino file, and from there it goes through it's procedures.

...that's good to know that the WDT has that timeout and the unit should restart, seemingly then it's doing what it supposed to, except that when the unit reboots- the new firmware isn't booted from.

I verified last night that the hex file does work, and writes properly through AVRDude.

As a side note, in a previous thread- Pert had helped me identify that I should set a fuse in the boards.txt to not allow the EEPROM chip to be flashed when uploading our sketches via programmer (AVR ISP MkII), as this was causing an issue with the serial number logged in EEPROM being overwritten every time I uploaded a new build of the sketch...

...is this something similar potentially or related?

I figure the process is downloading the hex file in chunks, verifying those chunks, and then writing the firmware to the primary storage and rebooting.

Any and all help is much appreciated; I've got some traction on why the system keeps looping on the download but the reasoning why the new firmware isn't being booted from escapes me.

Bump. Hoping someone might shed a bit of light here... I'm still stuck watching the unit reset and not boot from the new firmware.

I don't understand. This is somehow mcu specific, but I do not see what mcu type it is. It should be in the title to attract experts for that type

Juraj:
I do no understand. This is somehow mcu specific, but I do not see what mcu type it is. It should be in the title to attract experts for that type

Very fair point, I entirely forgot to add it was for the atmega1284.

I've adjusted the title accordingly as well...

I couldn’t view your code (on a mobile), but did your code work on another cpu than the 1284? (better to post inline, or as a text file)
If yes, then keep in mind the larger FLASH memory of the 1284 requires the uploader to page the binary with added hex ‘sentences’ which are not used for smaller footprint chips.

I am in the mcu world only one year, but as far as I know an 8-bit Atmega can rewrite it's own flash only from bootloader section. Your sketch uses some library and a special bootloader, you didn't mention? And how can a program run if the memory locations with it's instructions are changed?

to Watchdog: you do not need isr. for restart call wdt_enable(WDTO_15MS); and it will restart in 15 ms. if you don't need the 'watching' function, do not activate it before and you do not need to feed it

lastchancename:
I couldn’t view your code (on a mobile), but did your code work on another cpu than the 1284? (better to post inline, or as a text file)
If yes, then keep in mind the larger FLASH memory of the 1284 requires the uploader to page the binary with added hex ‘sentences’ which are not used for smaller footprint chips.

Frustratingly, I would not know.

This code is part of a sketch that is a good deal larger, the code gets invoked by the main sketch at some point and runs through the code attached.

All of it, was written by our former firmware team- who quit on us and dumped everything in my lap and this is the last thing I haven't figured out how to make work.

As to the other note, the code does pull down in chunks from Firebase, which is what I'm thinking you mean by paging the binary, this is a grab of one of the "messages" in the "mailbox" which the code pulls from:

{"c": 0, "s": 14, "d": "p", "p": "{\"ps\": [598, 599, 600, 601, 602, 603, 604, 605, 606, 607, 608, 609, 610, 611, 612, 613, 614, 615, 616, 617, 618, 619, 620, 621, 622, 623, 624, 625, 626, 627, 628, 629, 630, 631, 632, 633, 634, 635, 636, 637, 638, 639, 640, 641, 642, 643], \"pd\": \":10256000684440E060E082E49AE00E942D356AE031\\n:1025700070E080E090E00E94684482E49AE00E946B\\n:10258000C13502E41AE0F80162817381072E000C64\\n:10259000880B990B0E948C4C4B015C0160933E0AA6\\n:1025A00070933F0A8093400A9093410AF801648136\\n:1025B0007581072E000C880B990B0E948C4C6B01C7\\n:1025C0007C0160933A0A70933B0A80933C0A909393\\n:1025D0003D0AF80166817781072E000C880B990B64\\n:1025E0000E948C4C2B013C016093360A7093370A91\\n:1025F0008093380A9093390AA5019401C501B4016A\\n:102600000E94F14D69837A838B839C83A701960195\\n:10261000C701B6010E94F14D9B01AC0169817A812D\\n:102620008B819C810E94224B69837A838B839C835C\\n:10263000A3019201C301B2010E94F14D9B01AC01C3\\n:1026400069817A818B819C810E94224B6093220A4E\\n:102650007093230A8093240A9093250A0E94644E63\\n:102660002B013C0120E030E040E85AE30E94F14DAC\\n:1026700060931A0A70931B0A80931C0A90931D0A98\\n:10268000A3019201C501B4010E94E24B0E948E4B4E\\n:102690006093320A7093330A8093340A9093350A18\\n:1026A000A3019201C701B6010E94E24B0E948E4B2A\\n:1026B00060932E0A70932F0A8093300A9093310A08\\n:1026C00081E00F900F900F900F90DF91CF911F91AD\\n:1026D0000F91FF90EF90DF90CF90BF90AF909F90C1\\n:1026E0008F907F906F905F904F9008950E9493120B\\n:1026F000882331F06BE077E18EED96E10C94272E84\\n:1027000008954F925F926F927F928F929F92AF92B5\\n:10271000BF92CF92DF92EF92FF92CF93DF9382E44A\\n:102720009AE00E94C135C2E4DAE06A817B81072E1B\\n:10273000000C880B990B0E948C4C2B013C01609380\\n:102740003E0A70933F0A8093400A9093410A6C813D\\n:102750007D81072E000C880B990B0E948C4C4B013D\\n:102760005C0160933A0A70933B0A80933C0A909311\\n:102770003D0A6E817F81072E000C880B990B0E9409\\n:102780008C4C6B017C016093360A7093370A8093FE\\n:10279000380A9093390AA3019201C301B2010E9441\\n:1027A000F14D2B013C01A5019401C501B4010E942A\\n:1027B000F14D9B01AC01C301B2010E94224B4B01C0\\n:1027C0005C01A7019601C701B6010E94F14D9B0172\\n:1027D000AC01C501B4010E94224B6093220A7093A0\\n:1027E000230A8093240A9093250A0E94644E20E0D5\\n:1027F00030E040E85AE30E94F14D60931E0A709366\\n:102800001F0A8093200A9093210ADF91CF91FF90B5\\n:10281000EF90DF90CF90BF90AF909F908F907F9080\\n:102820006F905F904F900895A89561E083E00E94BB\\n:102830007F4581E00895CF930E94141461E085E5FF\\n\"}", "t": "q"}

Juraj:
I am in the mcu world only one year, but as far as I know an 8-bit Atmega can rewrite it's own flash only from bootloader section. Your sketch uses some library and a special bootloader, you didn't mention? And how can a program run if the memory locations with it's instructions are changed?

to Watchdog: you do not need isr. for restart call wdt_enable(WDTO_15MS); and it will restart in 15 ms. if you don't need the 'watching' function, do not activate it before and you do not need to feed it

There is a secondary flash storage on the hardware that the firmware download should be writing to... you may be right though, that a particular bootloader with instructions to boot via copying the flash contents to the primary stoarge- would be necessary in order to complete the loop.

I don't see any particular libaries called upon in the main sketch that could allude to this:

#include <FiniteStateMachine.h>
#include <HardwareSerial.h>
#include "Adafruit_FONA_3G.h"

#include <PString.h>
#include <Wire.h>       
#include <avr/sleep.h>                            // Power saving sleep functions
#include <avr/wdt.h>                              // Watchdog Timer
#include "EEPROM/src/EEPROM.h"                    // Read / write BLE setup info to EEPROM
#include <SPI.h>
#include <SPIFlash.h>

SPIFlash is The library

Juraj:
SPIFlash is The library

Correct! Digging a bit deeper- looks like the bootloader we're using is the DualOptiboot:

This is what the MoteinoMEGA section of the boards.txt looks like currently:

MoteinoMEGA.name=MoteinoMEGA
MoteinoMEGA.upload.tool=arduino:avrdude
MoteinoMEGA.upload.maximum_size=130048
MoteinoMEGA.upload.maximum_data_size=16384 
MoteinoMEGA.upload.speed=115200
MoteinoMEGA.upload.protocol=arduino 
# This line added 
MoteinoMEGA.bootloader.tool=arduino:avrdude
MoteinoMEGA.bootloader.low_fuses=0xDE
MoteinoMEGA.bootloader.high_fuses=0xD6
MoteinoMEGA.bootloader.extended_fuses=0xFD
#MoteinoMEGA.bootloader.extended_fuses=0x05  Didn't need this! 
MoteinoMEGA.bootloader.unlock_bits=0x3F
#MoteinoMEGA.bootloader.lock_bits=0xCF   Programmer expects 0x0F
MoteinoMEGA.bootloader.lock_bits=0x0F
MoteinoMEGA.bootloader.file=DualOptiboot_V5.0_atmega1284p_BlinkD15.hex
MoteinoMEGA.build.mcu=atmega1284p
MoteinoMEGA.build.f_cpu=16000000L
#MoteinoMEGA.build.f_cpu=10000000L
MoteinoMEGA.build.core=arduino:arduino
MoteinoMEGA.build.variant=MoteinoMEGA
MoteinoMEGA.build.board=AVR_MOTEINOMEGA

...Anyone have some background on using the DualOptiboot bootloader? I feel like we might be just a fuse setting away from it working...

Going through the AVR fuse programmer- BOOTRST is enabled on the highfuse found above...

I'm trying to see if anyone else was experiencing similar issues.

Any help would be appreciated!

bolteon:
I'm trying to see if anyone else was experiencing similar issues.
Any help would be appreciated!

modify the title again