[BUG] Flash problem with last relase

[BreakSecurity]

.---------------------------------------------------.
| |
| ChameleonMini RevE Rebooted flasher utility |
| Iceman fork |
| |
`---------------------------------------------------'

Creating the EEPROM binary...
Write done!

Creating the Flash binary...
Write done!

Flashing the files onto the "ChameleonMini RevE Rebooted"...
old_driver_bootloader
Erasing flash... Success
Checking memory from 0x0 to 0x6FFF... Empty.
0% 100% Programming 0x40 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] Success
0% 100% Reading 0x400 bytes...
Bootloader and code overlap.
Use --suppress-bootloader-mem to ignore

If there are no errors above, flashing the firmware should be finished now. Enjoy!

[evazzoler]

This happens to me, too.

[BreakSecurity]

Any hints on how to adjust the size of the fw? @ShinHub

[bogiton]

@BreakSecurity You could try removing some of the configurations you won't be needing from the Makefile and then re-build the firmware.

[0ki]

Yeah, the release 40af5ba of 21st of November is broken and consistently gives the overlap error.

I was able to fix by flashing the original firmware using the standard flashing procedure.

Afterwords I tested other iceman releases and they work.
165f7e5 from 22nd of September works.
f463cd6 from 7th of November works as well.

This last release should be pulled.

[iceman1001]

Thanks for informing. I don't have much time for this repo but as it seems like last release of the firmware made the chameleon unstable, I have removed that offending release, but nevertheless this indicates that the currect source code isn't stable either. @grspy

[securechicken]

I have been testing this.
Most of developments I have made before were tested on a unlocked bootloader, and makefile flashing on GNU/Linux, so I never encountered this issue before trying to reproduce it from Windows, based on this issue.

It appears the default config in Makefile now produce a too big firmware for the custom dfu-programmer in BOOT_LOADER_EXE Windows sh*t. As so, some (application and/or bootloader) memory sections are overwritten by the tool, but it does not finish the process, and as a result the device is bricked... The issue will not appear using make dfu-prog on GNU/Linux with dfu-programmer 0.7.2, on an unlocked OR factory bootloader.

To fix, you will have to thoroughly follow the steps in this wiki page, and unfortunately go up to AVRISPmkII programming if need be (the wiki page here, have been adapted to describe the process more than it was before).

As for the repo, I have a dirty temp fix PR, which only is some tuning and comments in Makefile, to get sure we get a smaller firmware that will not trigger the bug in BOOT_LOADER_EXE. The wise long-term fix would be to rewrite a flashing script for Windows and wiki pages, to get sure we only use dfu-programmer >= 0.7.2 and @slurdge Python crypto tools to flash, and never rely on this BOOT_LOADER_EXE blackbox anymore.