flashing problem

[bogiton]

Has anyone managed to flash the compiled eep/hex files successfully onto the Chameleon?

If I run the ChameleonFirmwareUpgrade.bat script, while being in bootloader mode, I keep getting the following:

Checking memory from 0x0 to 0x7FFF...  Not blank at 0x1.
Erasing flash...  Success
0%                            100%  Programming 0x20 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x400 bytes...
[ X  ERROR
Memory read error, use debug for more info.
FAIL
Memory did not validate. Did you erase?
There was an error with executing this command. Maybe your ChameleonMini is not in bootloader mode?

If I try to add the --suppress-validation argument to dfu-programmer.exe the process seems to be finishing without errors, but the result is a dead Chameleon. And then, the only way to revive it is by running the supplied "BOOT_LOADER_EXE.exe" which displays the following:

old_driver_bootloader
Erasing flash...  Success
Checking memory from 0x0 to 0x6FFF...  Empty.
0%                            100%  Programming 0x20 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x400 bytes...
0%                            100%  Programming 0x5800 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x7000 bytes...
load_success!

[iceman1001]

Aha, you too!?!? I just spend hours with this.. not to mention cursing at it.

[iceman1001]

What more files do you have in the same folder as BOOT_LOADER_EXE ?!? ITS_A_CARD.hex doesn't seem to be enough

[ghost]

For the normal Rev.G you need to have the files Chameleon-Mini.hex and the Chameleon-Mini.eep in the same directory where the flash.bat is located.

[bogiton]

I think that the BOOT_LOADER_EXE file has the dfu-programmer as well as the required "original" hex files embed into it. So, it works standalone. The only thing required is for the Chameleon to be in bootloader mode with the libusb drivers loaded for it.

[bogiton]

Actually, my bad, it needs the following two files:

• myfile.bin (Probably the flash binary)
• myfilee.bin (Probably the EEPROM binary)

bootloader-files.zip

[iceman1001]

I don't know. I put the libusb0.dll and some of the warnings went away.

old_driver_bootloader dfu-old-driver: no device present.

[iceman1001]

you can create the first myfile.bin if you put the ITS_A_CARD.hex in the same folder https://github.com/iceman1001/ChameleonMini-rebooted/tree/master/Software/FlashTools

and run the bat file. The eeprom generation I havn't figured out yet.

[iceman1001]

oops.. I removed the libusb.file and my BOOT_LOADER_EXE.exe worked.. and i have the myfile.bin / myfilee.bin in same folder...

It feels we figured out something important here. When compiling the project, we can now get the myfile..

[bogiton]

Now that you mentioned it, when I had the libusb0.dll in the same folder, the flashing (with the BOOT_LOADER_EXE) wasn't working. I had to remove that dll in order to work.

[bogiton]

Ha, you found out fast enough! :) As for the EEP, maybe we can generate the myfilee.bin with the flash tools from the compiled Chameleon-Mini.eep file?

[iceman1001]

Could be. lets test.

[bogiton]

Yep! That worked! :) I created the myfilee.bin from the compiled Chameleon-Mini.eep (ihex format) and the myfile.bin from the ITS_A_CARD.hex. I copied those two files in the same folder as the BOOT_LOADER_EXE and run it. Flashing successful! And btw, the ITS_A_CARD.hex seems to be missing the DETECTIONMY command.

[iceman1001]

yes, It worked for me too!

I took some time looking at the generated bin files. It adds two bytes to the end of the file and scramble/encrypt/xor the whole file.

So we can update the flash.bat, to copy and rename. Give instructions to copy hex,eep file from compilation, and run flash, then copy to BOOT_LOADER_EXE folder, and run...

[iceman1001]

Bravo! We have now unlocked achivement, flash your own firmware onto device.

[iceman1001]

Someone wants to compile the official revE firmware and test? ;)

[bogiton]

Hehe, I was thinking of doing either that or try to compile the initial commit of your repo. Before the migration, just to see if it gives the same functionality as the "stock" flash files.

[iceman1001]

I just did flash this repo ;) However, since I don't know the functions before, that was maybe a pre-hasten idea. Never mind, why look back? Now that it can get some bug fixes from the offical revE and RevG

[iceman1001]

Added some draft wiki page for flashing on windows. I have no clue how the linux/osx based users will be able to flash given the need for BOOT_LOADER_EXE.exe. We would need source code for that file, or decompile it ourselfs.

[bogiton]

It seems weird to me that even if that BOOT_LOADER_EXE seems to be using dfu-programmer, the needed files for it are in binary format. As far as I have seen, dfu-programmer only accepts ihex files for flashing. Could this exe be (re-)extracting the ihex data from the supplied binaries, using also somehow those two bytes you noticed that the Createbin.exe utility is adding to them? Maybe we should first figure out what this Createbin.exe file does. By the way, decompilation is almost impossible for those two binaries (probably written in C++). We need someone with disassembling skills. Good thing is, though, that the avrdude utility, that Linux/OSX users can use, accepts both ihex and bin files for flashing. Haven't tested what happens if I try to flash those myfiles using another tool like avrdude.

[iceman1001]

Don't know. SInce it uses two files to compile, and the orignal hex is only one file. Try and see what happens on a linux?

Someone with IDA pro skills can do their magic :) when it comes to decompilation. That even I manage but understanding whats going on from the deadlisting is not my cup of tea.

[iceman1001]

ok, I chatted with manufacturer, the createbin does apperantly a AES encryption. The software was developed (gui, code) by a external developer. Sad part of story, the developer seems to have forgotten which key was used.

Still, if its encryption, it needs to be decrypted somewhere. If there is a decryption, the key must be there too. If its just a MAC, then the private key doesn't need to be there in order to verfify key. This suggest that the aes key would exist inside createbin (fix array) and that testing all possible contingency 16bytes with AES to encrypt a normal bin to see if one candidate key would generate the same myfile.bin file. Its not a huge program createbin (64kb)..

[gurubook]

I passed an all zero file to CreateBin.exe and the resulting myfile.bin has 256 byte block of repeating apparently random data. I think about super duper xor encryption, but does not seem the case, and than you say AES was used. It make sense as xmega has AES 128 hardware implementation, and the repeating patter tell us that ECB mode was used, apparently with constant IV. I'll too will try to put an eye on it as soon as i have some free time next week.

[iceman1001]

AES with padding also fits the two extra bytes. In order to fit a aes blocksize of 16bytes. Using PEiD on createbin.exe also confirms AES.

Since the myfile.bin is completely encrypted and padded with 2bytes, the key is not added to the file.

PEiD also shows that BOOT_LOADER_EXE.exe uses AES.

So createbin encrypts -> boot_loader_exe decrypts and flashes. Would explain why the dfu-programmer doesn't work at all.

[iceman1001]

Createfile.exe is called with two params.

myfile.bin bin

The second param allows bin or txt where text generates a file with hex strings of the file instead .

[bogiton]

Running Createbin.exe txt on an empty file (0 bytes) returns this: 0x0D,0xD5,0x33,0x0B,0x67,0xB5,0xE1,0xA9,0xC4,0x46,0xEC,0xA1,0xE5,0xFE,0x1D,0x3A,

Since we are stuck for the time being with these utilities, I updated the flash.bat script to work with those two (+avr-objcopy.exe), having the eep and hex files as input.

flash.zip

[iceman1001]

nice. I pushed it, why don't you make a pull request (PR) and use github for what its built for?

[bogiton]

Indeed, I will next time. Maybe we should also copy the BOOT_LOADER_EXE.exe into the /Software/FlashTools/ directory? To have there everything needed for flashing.

[iceman1001]

Its under a differnt folder, Win32, We would need a better structure of files. Many binaries which we don't have source code for. Maybe a wget/curl script which downloads all needed binaries.

[WolfgangMau]

ok, I probably bricked my chameleon :-D I was playing with dfu-programmer:

dfu-programmer atxmega32a4u erase Checking memory from 0x0 to 0x7FFF... Not blank at 0x7FF1. Erasing flash... Success Checking memory from 0x0 to 0x7FFF... Not blank at 0x7FF1.

then I tried to flash the ChameleonMiniRDV2.0_ATxmega32A4U.hex

dfu-programmer atxmega32a4u flash ChameleonMiniRDV2.0_ATxmega32A4U.hex Bootloader and code overlap. Use --suppress-bootloader-mem to ignore

dfu-programmer atxmega32a4u flash ChameleonMiniRDV2.0_ATxmega32A4U.hex --suppress-bootloader-mem Hex file error, use debug for more info.

with more debug:

dfu-programmer atxmega32a4u flash ChameleonMiniRDV2.0_ATxmega32A4U.hex --suppress-bootloader-mem --debug 300 target: atxmega32a4u chip_id: 0x2fe4 vendor_id: 0x03eb command: flash quiet: false debug: 300 device_type: XMEGA ------ command specific below ------ validate: true hex file: ChameleonMiniRDV2.0_ATxmega32A4U.hex

dfu.c:414: dfu_device_init( 1003, 12260, 0x7fff59f5e6e0, true, false ) dfu.c:431: found device at USB:11,0 dfu.c:663: Found DFU Inteface: 0 dfu.c:293: dfu_abort( 0x7fff59f5e6e0 ) dfu.c:844: -EPIPE: a) Babble detect or b) Endpoint stalled 0xffffffe0 (-32) dfu.c:204: dfu_get_status( 0x7fff59f5e6e0, 0x7fff59f5e5f8 ) dfu.c:230: ============================== dfu.c:232: status->bStatus: errSTALLEDPKT (0x0f) dfu.c:233: status->bwPollTimeout: 0x0000 ms dfu.c:235: status->bState: dfuERROR (0x0a) dfu.c:236: status->iString: 0x00 dfu.c:237: ------------------------------ dfu.c:688: State: dfuERROR (10) dfu.c:252: dfu_clear_status( 0x7fff59f5e6e0 ) dfu.c:204: dfu_get_status( 0x7fff59f5e6e0, 0x7fff59f5e5f8 ) dfu.c:230: ============================== dfu.c:232: status->bStatus: OK (0x00) dfu.c:233: status->bwPollTimeout: 0x0000 ms dfu.c:235: status->bState: dfuIDLE (0x02) dfu.c:236: status->iString: 0x00 dfu.c:237: ------------------------------ dfu.c:688: State: dfuIDLE (2) intel_hex.c:337: Address offset set to 0x0. atmel.c:1295: atmel_flash( 0x7fff59f5e6e0, 0x7fff59f5e5a8, false, false ) atmel.c:1158: atmel_flash_prep_buffer( 0x7fff59f5e5a8 ) atmel.c:1335: Flash available from 0x0 to 0x7FFF (64kB p. 0 to 0), 0x8000 bytes. atmel.c:1339: Data start @ 0xFFFFFFFF: 64kB p 65535; 256B p 0xFFFFFF + 0xFF offset. atmel.c:1343: Data end @ 0x8FEB: 64kB p 0; 256B p 0x8F + 0xEB offset. atmel.c:1348: Totals: 0x8FED bytes, 4278190225 256B pages, 4294901762 64kB byte pages. atmel.c:1353: ERROR: Data exists outside of the valid target flash region. Hex file error, use debug for more info. commands.c:360: Error writing memory data. (err -1)

ps ... I'm working on Mac OSX

update: downloaded me a windows7 virtualbox-image from microsoft installed dfu-driver (re)flashed the chameleon successfully but it seems not to work like before anymore can not set anything within the Chameleon-Gui even if it 'says' it is connected this was possible before

OK ... not the way it should be, but seems to work: I have renamed the ChameleonMiniRDV2.0_ATxmega32A4U.hex to Chameleon-Mini.eep and the ITS_A_CARD.hex to Chameleon-Mini.hex executed flash.bat ... and was able to enable all slots within the GUI again. this is probably total mess ... but the pm3 can now at least detect mf again (1k & 4K) set mfu is not possible anymore (GUI-error) random uid for mf is also not possible anymore

I suppose the eep is for the settings, but the ChameleonMiniRDV2.0_ATxmega32A4U.hex seems not to have the ultralight- and random-uid-feature ;-) but I'm glad that my chameleon is working again - with limited features ;-)

[iceman1001]

Aha, the rename of the hex file to eep, is just wrong. eep == eeprom So you didn't do the right process.

Either: ChameleonMiniRDV2.0_ATxmega32A4U.hex -> Chameleon-Mini.hex or ITS_A_CARD.hex to Chameleon-Mini.hex

These hex files is ok to flash with the avrp-mkII.
if not, you need the BOOT_LOADER_EXE way to do it.

Those scripts generates two BIN files. myfile.bin (old hex) and myfilee.bin (old eep)
and flashes to the device. Follow instructions on Wiki.

---

Now, the dfu-programmer software, have you had any success with that??? I didn't.

[WolfgangMau]

hehe ... dfu-programmer bricked my device ... but now I know how to 'reload' it ;-) since the BOOT_LOADER_EXE (or the bootloader himself) seems to do some magic while uploading even if I convert the working binaries back to hex (since dfu-programmer can only handle hex-files at flashing-mode) it will not work out.

I know such behavior from a former project on a 328p... the russian guy was using a homebrewed bootloader which did some magic while flashing, so only his bootloader could handle the hex in a correct way (to prevent chinese cloners) ... so, there was no (simple) way around ... if the bootloader was missing or not his one, his public downloadable firmware was not working.

so, the magic might be totally different here, but something unknown seems to happen inside the BOOT_LOADER_EXE - as already mentioned by you or some other guy in this issue

[iceman1001]

Yeah, basically, the createbin and BOOT_LOADER_EXE does that. We think it encrypts with AES+padding into the *myfile.bin** files and boot_loader decrypts it. We know that the device can be flashed with AVRP-mkII with hex-files and get working device, so encryption on device is out of question.

It took us some time to get some different files. Once we have the bin-file which was distributed from manufacture to retailer, it is easy to get a square one device again.

but once we started fixing the firmware, the bricks started to happen. We don't seem to get a correct eeprom file. When I compile I get a 44bytes file, but the original one is 40bytes. And this is also a complain when trying to flash, and if I force it, I brick it.

[WolfgangMau]

hmm ... if you flash it with a ISP-device ... the bootloader should not be present anymore?! that was at least the behavior on a m328p but of course th xmega may behave totally different

I guess this could be a nice playground for half the price: atxmega32a4u breakoutboard should be enough for testing firmware and gui

or even this one (has a cp210x on it - so probably no DFU functionality)

[jackkleeman]

@iceman1001 what eep should I use to flash ChameleonMiniRDV2.0_ATxmega32A4U.hex ??

[iceman1001]

Not sure, I just used the avpr-mkII together with the atmel studio 7.0, which generated a eep file for me when I pointed to that hex-file.

[jackkleeman]

I am using the same device with the same software. Where is the option to generate an eep from a hex??

[iceman1001]

I don't have that tool installed now, but somewhere under device programming form... From production hex file??

[jackkleeman]

It only allows from production elf files...

[jackkleeman]

Can you please share the MF Classic patch code with me? If I had that then I wouldn't need to try to flash any of the compiled hex files

[prensel]

I have tested on both Linux and Windows systems and at this point i'm thinking that the standard Atmel bootloader is replaced with a modified version and not working with the standard dfu-programmer of avr-dude tools. Hence the 'special' boot_loader_exe is needed.

[bogiton]

Indeed. Actually, the boot_loader_exe file seems to be using the dfu-programmer internally, possibly also modified to handle the modified bootloader. On the other hand, since iceman already managed to flash it using the AVRISP-mkII device in Atmel Studio, I believe that the same can be achieved with the avrdude under linux, instead of the flip2 "device".

[prensel]

When using a device like an in-circuit-serial avrisp programmer your not using the usb bootloader so that should always work. Since avrdude and dfu-bootloader need to have a working usb bootloader we're stuck at that point unless there's a way to upload the standard atmel usb bootloader using a device like the avrisp.

[bogiton]

Admittedly that is a very good idea. As far as I can see, there are lots of USB DFU bootloader implementations for XMEGA and even for the atxmega32a4u specifically. Also, right after your suggestion, I noticed this batch script https://github.com/iceman1001/ChameleonMini-rebooted/blob/master/Firmware/Atmel%20DFU%20Bootloader/GenerateBootloader.bat which was apparently used to generate the bootloader of the rebooted version.

[iceman1001]

Is this the final piece of the puzzle? We had it all the whole time? haha, there was so much to focus on, so I never looked and thought about this batch file. So we should be able to generate correct hex->bin->for flash files :)

[bogiton]

I believe we are getting close! :) But we still need the "Atmel-DFU-Bootloader\atxmega32a4u_104_PA6.hex" file that this script requires. Have you seen this anywhere?

[iceman1001]

Found some binaries bootloader. Not PA6, but it may work anyway

AVR1916_1.zip

[iceman1001]

And a reference to srec_cat which is also used http://srecord.sourceforge.net/

[prensel]

i have found some other documents about this regarding dfu-programmer. will look into it today. maybe by generating a modified dfu-programmer that will 'talk' to the mini that takes the plain .hex and .eep files might make it a lot easier to upload new firmware without having an external icsp.

[iceman1001]

Having a way of flashing in Linux / Windows would be great, without the need of extra hardware would be even greater!

[iceman1001]

Im stupid... if we only looked at official chameleon mini repo we would have found https://github.com/emsec/ChameleonMini/blob/master/Firmware/Atmel%20DFU%20Bootloader/bootloader-atxmega128a4u-104-PA6-SPM.hex