LED not showing after flashing upgraded firmware

[Suhas-13]

LED not showing after flashing upgraded firmware

[timokasper]

Hi, so if it shows up in bootloader as atxmega the USB connection is fine ;and the device is still OK, just the correct firmware missing. so the problem will be the flashing / getting started procedure. How to you know "it flashes successfully" - it rather seems it is NOT flahes successfully, please give more details what exactly you are doing there. I am also confused as first (in an email) you wrote you are using MacOS... and now you wrote here you are using Windows.. so what is true? Have you maybe set the fuses wrong...

[Suhas-13]

Thanks for the reply.

To clarify, I tried flashing it on windows and macos. In both cases I thought the flash went through as it said flashing successful or something along those lines at the end. However, on windows after flashing the device would no longer show up in device manager. On MacOS after flashing it would still show as DFU X.

On MacOS I used avrdude to flash as per the instructions. On Windows, I couldn't find the dfu-programmer v0.7.2, so I used v0.8 instead. Could that maybe be the issue?

I tried using a few different data cables and even a new one, so I'm pretty sure that isn't the issue.

I'm not really sure about the fuses. I just copied the command from this page: https://cdn.statically.io/gh/emsec/ChameleonMini/master/Doc/Doxygen/html/Page_GettingStarted.html to flash with avrdude. Is there a way I can diagnose this?

[timokasper]

Maybe the dfu-programmer is the cause... another option would be to download winavr https://sourceforge.net/projects/winavr/ it contains avrdude and that should work (tm) - could you try that and report? Thanks.

[Suhas-13]

Will try that. Thanks. Should I use the same command specified for avrdude on mac/linux?

[Suhas-13]

I tried the same command and got an error that the programmer id "flip2" couldn't be found. Should I be using something else for that value?

[Suhas-13]

This is the output when runnning with v0.8 by the way:

Checking memory from 0x0 to 0x1FFFF... Not blank at 0x1.
Erasing flash... Success
Checking memory from 0x0 to 0x1FFFF... Empty.
0% 100% Programming 0x40 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] Success
0% 100% Reading 0x800 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] Success
Validating... Success
0x40 bytes written into 0x800 bytes memory (3.12%).
Checking memory from 0x0 to 0x5FFF... Empty.
0% 100% Programming 0x6000 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] Success
0% 100% Reading 0x20000 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] Success
Validating... Success
0x6000 bytes written into 0x20000 bytes memory (18.75%).
Flashing the firmware to your ChameleonMini is finished now.

[timokasper]

well... one more idea, can you please try to use the program "flip"? https://www.microchip.com/en-us/development-tool/flip ? I remember faintly that the program is really horrible (...) but ahen selecting the correct device atxmega128a4u and connect via usb it had worked in the past... I cant remember which version but i remember there was one page for the .hex, then another for the .eep, and then finally there was some ja error message in this "flip" but that was no problem the chameleon was still flashed correctly...

[Suhas-13]

I tried using this fork: https://github.com/mariusgreuel/avrdude

and it still doesn't work, but this is the output I get.

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9746 (probably x128a4u)
avrdude: Note: application memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file Chameleon-Mini.hex for application
with 24444 bytes in 1 section within [0, 0x5f7b]
using 96 pages and 132 pad bytes
avrdude: writing 24444 bytes application ...

Writing | ################################################## | 100% 1.85 s

avrdude: 24444 bytes of application written
avrdude: verifying application memory against Chameleon-Mini.hex

Reading | ################################################## | 100% 2.03 s

avrdude: 24444 bytes of application verified
avrdude: reading input file Chameleon-Mini.eep for eeprom
with 51 bytes in 1 section within [0, 0x32]
using 2 pages and 13 pad bytes
avrdude: writing 51 bytes eeprom ...

Writing | ################################################## | 100% 0.06 s

avrdude: 51 bytes of eeprom written
avrdude: verifying eeprom memory against Chameleon-Mini.eep

Reading | ################################################## | 100% 0.04 s

avrdude: 51 bytes of eeprom verified

avrdude done. Thank you.

I wonder if it's a driver issue. The driver on there as per Zadig is libusb v1.2.6.0

I'll try the flip program now.

[Suhas-13]

I'm trying Flip, but there doesn't seem to be an option to add an eep file. I could only include the .hex file.

[ceres-c]

Might be wrong right now, but when I had similar issues in the past I solved them flashing with an external programmer

I also had to change MCU once, but that time I wasn’t getting signals on the pins IIRC

[timokasper]

For Flip, you have to click first program the .hex (after choosing the controller and connecting to USB). Next click on SELECT EEPROM. You are right, in the file dialog appearing it only shows .hex files... so you have to type *.eep in the file name in order to make .eep files visible; then choose the .eep file and Make sure to uncheck the Erase and Blank Check boxes - otherwise the program memory will be erased. Then click RUN again, and there should be 2 green lights (program verify); unplug Chameleon, done.

[Suhas-13]

It worked! Thanks so much for the help.