Hello,
tldr: Using the avr_boot board package, my system will load firmware from an SD Card once and only once, provided that a chip erase was performed prior to that. I am unable to update my firmware with future revisions once this has occurred, defeating the purpose of being able to flash firmware from an SD Card. 
Introduction:
I'm running into an odd issue and I'm getting the sense that I'm missing something obvious here.
I am working on a system for a client that is using an ATMega1284P. I've gotten the project running smoothly using the MightyCore Board Package. The last bit of functionality I need to get working is the ability to load new firmware onto the board via an SD Card. My client wishes to give these initial boards to a handful of beta testers around the country and he wants to be able to send them SD Cards for future updates.
System Setup:
System Parameters:
Board Package: avr_boot
Processor: ATMega1284P
SD CS Pin: "8"
BOD: "4.3V"
Pinout: MightyCore, Bobuino Variant
Bootloader: avr_boot (loaded from arduino IDE Board Manager, per these instructions
GitHub - zevero/avr_boot at gh-pages)
I've made a simple change to the avr_boot boards.txt file per this suggestion on the github issue forum. This change has allowed me to both burn the bootloader and compile my code using the avr_boot board package. Prior to this change, I would have to switch board packages when burning bootloader and compiling.
By default the ATmega1284P standard variant requires Mighty 1284P to be installed:
GitHub - JChristensen/mighty-1284p at v1.6.3
That is the cause of the error you got.
You can easily modify avr_boot to reference the MightyCore variant by simply changing line 384 of boards.txt from:avr_boot_atmega1284.menu.pinout.standard.build.variant=mighty-1284p:standardto:
avr_boot_atmega1284.menu.pinout.standard.build.variant=MightyCore:standard
Procedure and Observations:
-
Using an Arduino as ISP and within the Arduino IDE, I burn the bootloader onto the device. the IDE confirms the bootloader upload completed successfully and I probe the pins and confirm that a full chip erase has occurred(non of the old code is running)
-
I created a very simple sketch for test purposes. the sketch performs two functions. It creates a text file on the SD Card so that I can confirm that the SD card is wired correctly and the processor is capable of performing read/write functions. It also beeps a piezo speaker on the PCB to indicate the end of code has been reached.
I compile two different versions of this sketch, one that creates a file called "singlebeep.txt" and beeps the speaker once, and another that creates a file called "doublebeep.txt" and beeps the speaker twice. -
After compiling each sketch variant, I navigate to the directory located in "AppData\Local\Temp\arduinobuild_######" and copy the bin file labeled "SketchName.ino.with_bootloader.bin". I rename each bin file so that I know which one is the "SingleBeep" and which one is the "DoubleBeep".
-
Per these instructions, I make a copy of the "Single Beep" bin file, place it the root directory of my SD Card, and rename it "FIRMWARE.BIN". At this time this is the only file on the SD Card.
-
I insert the SD Card into my Board and power up the device. A small period of time passes and eventually I hear a single beep. I power down the device, remove the SD Card, and when I check the contents of the SD Card I can see that the root directory now also contains "SingleBeep.txt", indicating that the bootloader has successfully flashed the firmware to my chip. So far, so good
-
I erase the contents of the SD Card and put the "double beep" firmware in the root directory. Like last time, I rename this file "FIRMWARE.BIN". I make sure the board is powered off first, and then I insert the SD Card into my board.
-
I power on my board, and immediately I hear a single beep. There is no small time delay. Checking the SD Card on my PC I confirm the existence of a text file named "SingleBeep.txt". This indicates that first firmware file is still the one present on the chip and that the bootloader did not load the new code.
Additional Procedure Variations:
-
I've attempted to use the the compiled hex file that does not have the bootloader, the ones named "SketchName.ino.hex". I have to use the hex2bin tool in order to convert it to the binary format that the bootloader needs. Alas, the same issue occurs when using these compiled files as well.
-
I've probed the CS line on the processor during these test procedures using a modified sketch file that does not include writing text files to the SD Card. I did this to avoid ambiguity as to what is accessing the CS line, my bootloader or my sketch.
I can confirm the CS line triggers when the board is brought out of reset. This occurs in all stages of the procedure; when there is a fresh burn of the boot loader, when the single beep firmware file is loaded on the SD Card and when the double beep is loaded on the SD Card. This almost seems to indicate to me that the bootloader is not being affected by the flashing process. but I'm not sure if that assessment is correct
Evaluation:
-
The Good:
-
The bootloader appears to be loading correctly.
-
The PCB is able to access the SD Card and perform read/write functions
-
I can flash firmware from the SD Card following a successful burning of the bootloader onto my chip.
-
The flashed sketch runs consistently afterwards.
-
I purchased a development board from MCUDude on tindie to try and evaluate this issue on a different system. I can confirm this issue persists on the barebones system as well. https://www.tindie.com/products/MCUdude/dip-40-arduino-compatible-development-board/
-
The Bad:
-
The firmware is only being flashed from the SD Card once.
-
The Ugly:
-
I'm not skilled enough(yet) to evaluate the bootloader hex files or the compiled sketch files to further address the issue. I could use some skilled guidance in this regard.
-
I am unable to use a different board pinout other than the MightyCore, Bobuino variant pinout. My client has 100 boards already built and is hoping to avoid a re-spin of boards(I inherited this project). If I can definitively prove that a re-spin of boards in the only way this can be made to work that would be fine, I'll just need to be convincing about it
Hypotheses:
-
Perhaps the bootloader is getting overwritten or altered when the first Firmware file is being flashed from the SD Card?
I have the ability to read the hex files on the chip using an Atmel ICE programmer and the Atmel Studio IDE, but I lack the knowledge to effectively evaluate the read hex file. -
Perhaps some fuse settings are being altered as a result from the firmware file being flashed from the SD Card?
Similarly to Hypothesis #1, I can read back what's on the chip but I am unaware of how to evaluate the read hex file to determine if the fuses are indeed being altered. -
???I'm open to suggestions as to what might be causing this issue.
I would appreciate any guidance or thoughts on this issue. I've hit the limits of my understanding and having some extra eyes on this would be really helpful. Thank you for your time and consideration.
Best Regards,
Chris B