[FORUM] Flashing the RevE rebooted

[Kogelvis]

I hope this is the right place to ask...
I've recently bought a Chameleon RevE rebooted from Lab401. I want to use this device to emulate a Mifare Classic 1K card but with a 7 byte UID. The stock firmware didn't support this so I've followed the wiki on how to compile my own firmware and flash it onto the device.

I use an up to date arch-linux system to compile the firmware and this completes without issues.
If I try to flash it onto the device using linux I'm presented with the issues mentioned in issue #93
Specifically "Checking memory from 0x0 to 0x7FFF... Not blank at 0x7FF1." when trying to erase the device. And "[Device is write protected." when trying to flash it anyway.

At this point the device became unusable and being unable to flash it with linux I've restored the device as documented on the wiki using a Windows 10 setup.
I've also tried flashing the new firmware using Windows via the flash.bat method using the .eep and .hex file compiled on my linux machine. When trying this I'm presented with the same problem stated in issue #173 being: "Bootloader and code overlap."

I've noticed an article on the wiki explaining how to fix this using Atmel Studio and an AVRISP mkII.
I can't use this method because I have not ordered an AVRISP mkII yet.

So far I've been able to restore the device with the latest firmware downloaded from the lab401 site, this is the following version: "ChameleonMini-rebooted v1.3 (Iceman: 7420671)"
Now I've checked the source code for that specific release but sadly it is compiled without 7 byte UID support.

My question, is there a way to get the latest firmware on the device using linux or windows and not be presented by the mentioned issues or is using an AVRISP mkII the only way to get it on the device?

[Kogelvis]

Happy new year!

A small update, allthough I didn't find a way to flash it onto the device using the mentioned tools I've since ordered (and received) an AVRISP mkII. Using this and Atmel Studio I was able to flash a freshly compiled firmware onto the device.

[dealaddict]

@Kogelvis Can you please share the eep files you used to reflash with avrisp. The one I got from here for some reason it isn't flashing mine properly. Would really appreciate if you can send me both of those files I need for atmel device programmer

[Kogelvis]

Of course! I hope they are of some use to you!

ChameleonMini.zip

[iceman1001]

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

[TheDuchy]

I +1 this issue as I have the same problem as @Kogelvis, but I don't have a Windows machine I could use nor I have an external flasher. :/

[michal25]

I have exact the same problem as @Kogelvis and i have no windows machine (only Linux). Is it here some possiblity to unbrick the Chameleon device under Linux machine? https://github.com/iceman1001/ChameleonMini-rebooted/wiki/Getting-started#no-more-light-go-back-to-stock (but only windows).

[michal25]

The problem starts here...
https://github.com/iceman1001/ChameleonMini-rebooted/wiki/Flashing-Linux-(Unix)
sudo dfu-programmer atxmega32a4u erase --force
Erasing flash... Success
Checking memory from 0x0 to 0x7FFF... Not blank at 0x7FF1.

The problem not start with firmware version. It starts with first step - erasing flash and checking memory with dfu-programmer.

[ca1e]

I have the same problem after flashing. i compiled the latest code on ubuntu and flashing on windows10.
first i got "Bootloader and code overlap.",and when i try again i got:
"Checking memory from 0x0 to 0x6FFF... Not blank at 0x1."
debug info:
Region is NOT bank.
First non-blank address in region is 0x0.
Flash NOT blank beginning at 0x0.
Not blank at 0x1.

[michal25]

The problem has been discussed here..
#11

And possible explanation is here
exander77/ChameleonMini-rebooted-bootloader@0578952

But I can't find the right parts in the Chameleon code.

[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.

[securechicken]

Duplicate of #173 - Please keep following in #173 if need be.