Question regarding the binary file upload

[Wellhamster]

Thanks a lot for the great work! I have been trying to upload the program to the eeprom. In my case the I2C lines are connected to a pin of the mcu. I do this to disable I2C to reduce power consumption (battery power application). I changed the bootloader that I2C communication works. But...
I tried using the miniboot_uart_to_eeprom_uploader.hex but I doesn't seem to work in my case. Could you provide the sketch of the program?
Thanks

[mihaigalos]

What do you mean you use only one line for the I2C communication? I2C requires 2 lines : SDA and SCL. Have a look at the Drivers repo for the EEPROM driver. You can find the sketch there.

[Wellhamster]

Thanks for your answer. Two lines pulled up via two resistors to Vcc. But in my case connected to one of the atmega pins. I found the hex file but I have trouble using it. Might be my lack of knowledge :-D I would like to adapt the miniboot_uart_to_eeprom_uploader program to my case.

[mihaigalos]

No ideea what you are talking about. You need 2 lines connected to the atmega : SDA and SCL, not one. In the above link, look at src/ and the files inside. I cannot help you if you do not know what you are doing.

[Wellhamster]

I think I was not clear on the problem I have. I use 3 lines to get the I2C communication to work. Two lines are SDA and SCL and a 3. line that pulls SDA and SCL high and powers the EEPROM. (similar to this: http://forum.arduino.cc/index.php?topic=296269.0)
Every time when I want to use I2C I pull the 3. line (used to call it power line) high and afterwards start the I2C communication with the eeprom. That is also what I changed in the bootloader code in io.h and init.h.
The problem that I face now is that I haven't been able to get the program and the header written to the EEPROM. When I unterstand the purpose of the "miniboot_uart_to_eeprom_uploader" sketch correctly, its purpose is to write the header into the eeprom followed by the application... And I could not find the sketch where I can make the changes that are necessary (pull the 3. line high etc.).
Thanks for your help!

[mihaigalos]

I see. Did you look into src/examples/e2prom.ino ?

[Wellhamster]

Yeah. I changed the sketch to adapt for my case and I was able to upload the binary to the EEPROM. Currently, I use a simple sketch for testing. But starting the sketch from the eerpom is still not working... The status LED blinks a few times, turns off and starts blinking again before it remains on. I'll try to track down the error that I do somewhere along. I checked the Fuses and I thing there that is ok. Size of miniboot.elf is 1942bytes with bootloader_start_address: 0x7800. I'll check next if I make the error somewhere with the timestamps. Thanks for pointing at the eprom.ino.

[mihaigalos]

The blinking of the led is fine, indicating pages are read from the i2c, checked for CRC and written to the internal flash of the MCU, as implemented here and here.

• What fuse settings are you using? I'm using a board with an external crystal at 16Mhz with clock divider /8, and the following fusebits: Ext, Hi, Lo : FE DA EF Lock: EF for <=3.3V.

• It would also be nice to dump the contents of the EEPROM over UART and see what is there.

• Most people do not get the metadata right in the external EEPROM. Please follow the miniboot instructions to the letter, otherwise you will not be able to reflash. In particular, be sure to update the CRC checksum, but I guess you already did that correctly since the led is blinking. EDIT: Since there is only one led blinking for both checking the CRC and indicating page writes, it is impossible to distinguish the checking from the writing part. So make sure the CRC is correct in the metadata part, as described in the readme.

• And of course the metadata needs to be updated for the timestamp. This is to prevent reflashing if the code had been previously flashed. Again, the readme is your best friend here.

• Make sure the sketch does not overflow into the bootloader section, watch out for big sized sketches at around ~30kB (2kB required for miniboot).

[mihaigalos]

I've improved the readme (commit 5b4377bed556314a5da45dcedc49b7a77f5546fc) to make it clearer that one really needs to update the metadata before they are able to successfully use miniboot. Since I assume you were not using YAT, you didn't get promted to fill in the metadata fields.

[Wellhamster]

I use the Atmega328p with the internal RC Oscillator and 3.3V supply voltage.
Fusebits:

• Lo: D2
• Hi: DA
• Ext: 06 (BOD 1.8V)
  Lock: FE

I do the following:

1. I use the arduino IDE to generate a HEX file and use a Hex2Bin converter to get the binary file. (Size ~2kB)
2. Upload the e2prom.ino and switch to YAT where I follow the instructions.
3. Timestemps: timestamp application < timestamp of write (every time I use new timestamp to avoid problems with old timestamps)
4. The CRC32 checksum is generated with the online-tool (like you recommend in readme)
5. Length: I used the size of the binary file
6. Switch to binary mode and send the file (300 bits per second)
7. Burn the miniboot bootloader

I'll check later on the EEPROM content

[mihaigalos]

While you're at it, check both the contents of the I2C eeprom and the contents of the atmega eeprom. After each reflash, miniboot stores the timestamp from the i2c eeprom in the atmega eeprom. Next time the device boots, a diff between the two is performed. If it is 0, no reflash occurs.

[mihaigalos]

Your Lock fuse looks wrong (is: 0xFE should be: 0xEF). The current value, 0xFE means "Mode2: further programming disabled".

[Wellhamster]

First of all, thanks a lot for your help!
I checked the fuses again and I think that is not the issue.
The internal EEPROM was empty and the i2c eeprom had the header stored correctly. I'll try to calculate the CRC32 checksum. I'm still confused about the program size, because the arduino IDE shows 2030 bytes. The hex is 5724 bytes and the bin file is 2670 bytes, which does not match with the value the IDE showed. Do you think the error could be somehow related to how I generated the bin file?

[mihaigalos]

The size required in the metadata needs to be size of the bin. It is the only thing relevant here, since miniboot writes exactly size amount of bytes to the atmega flash.

I think you're nearly there, you should have a successful reflash very soon! :-)

[mihaigalos]

I think there is only one way to generate the bin, the way described in the readme:

avr-objcopy.exe -I ihex application.hex -O binary application.bin

[Wellhamster]

It finally works :-) Thanks a lot for your advice and helping me getting it to work. The issue was related to how I build the binary file...
If you like you can add a simple binary file for other people for testing purposes. The attached files contains a file that starts Serial communication (9600 baudrate) and sends something.

Serial_communication.zip

[mihaigalos]

Glad you finally got it running. I've improved the readme, since I also think the previous wording was poor and misled you. A compiled *.hex and *.bin is of no use on a source-sharing website.

Can you please specify how you've built the binary and why it didn't work? That way other people can benefit too.

[Wellhamster]

What did not work:

• Export the *.hex file using the arduino IDE.
• Convert *.hex to binary using tools like hex2bin
  The size of the binary file was too big...

What worked:

• Export the *.hex file using the arduino IDE.
• use: avr-objcopy.exe -I ihex application.hex -O binary application.bin
  This way the size of the binary matched the size the IDE showed after compiling.