Does not respont during flashing about microupdi HOT 17 CLOSED

After several restarts of laptop with still connected device it is recognized as Bus 001 Device 005: ID 03eb:2145 Atmel Corp. ATMEGA328P-XMINI (CDC ACM) now. Really strange ... Will test as soon as my pcb arrived.

from microupdi.

Now I tried everything I could imagine, other bootloader to start with, other computer for flashing and so on but everytimes I had the same problem. When I start the script manually and flash via USBasp it works without problems. But it will be flashed with wrong IDs and with this "DFU bootloader also no port will be created.

So is there any way to flash with USBasp to get the same results like flashing automatically via Arduino Software?

from microupdi.

Sorry for being so slow to respond. I've sold quite a few microUPDI programmers, and I've yet to see others struggling with the issue you're facing.

I have two scripts here you can use to directly load the files using Avrdude. If you're installed the microUPDI flash addon to Arduino IDE, you already have these files somewhere:

https://github.com/MCUdude/microUPDIcore/tree/master/avr/firmwares/CLI%20flash%20script

from microupdi.

Thanks for your answer. Exactly this script I used for flashing the device and it worked. But as mentioned in the description the "usb device" will recognized as "Atmels DFU bootloader" and no port will be created in Arduino Software. Also the ID is wrong so that the software is not able to identify the programmer. Summarized this means that flashing via this script has not the same effect that flashing via the software. Maybe I have to do additional steps to get the same result. Also it is possible that I did something wrong but there is no issue shown during flashing with this script.

from microupdi.

So you're able to flash the microcontroller with the script, but it still doesn't show up as an mEDBG programmer?

The difference between flashing using the script or through Arduino IDE is that the script removes the stick Pro Micro bootloader and replaces it with a DFU bootloader that original mEDBG based boards ship with.

The bootloader does not need to be present for the application to work.

from microupdi.

yes, that is correct! The IDs after flashing with this script: 03eb:2ff4 Atmel Corp. atmega32u4 DFU bootloader
But for programming the Arduino software is asking for: 03eb:2145

from microupdi.

This is the original message with choosen programmer "Onboard ..." when I try to upload:
"avrdude: jtag3_open_common(): Did not find any device matching VID 0x03eb and PID list: 0x2145"

from microupdi.

Thanks for the details! I did the exact thing you did with the script, and I'm facing the same issue as you. It's stuck in the DFU bootloader for some reason. I'll see if I'm able to remove it from the hex file, as there aren't any need for it.

This is how I turned my microUPDI board into a working one:

• Open Arduino IDE and burn the Leonardo bootloader
• Then go back to the microUPDI firmware uploader and try to upload again
• Success! (hopefully)

from microupdi.

Thanks a lot for confirming the issue :-)

The described workflow I tried more that 20 times with the same result. I will do it again to get the complete error messages to post it here - maybe you have an idea when you see it.

from microupdi.

What happens if you try this flash this exact hex file with the script? You'll probably have to edit the script the get the file name right.

[mEDBG_UPDI_1.13_no_bootloader.hex.zip]

from microupdi.

Sorry, the DFU bootloader wasn't removed from that file! Try this instead:

mEDBG_UPDI_1.13_no_bootloader.hex.zip

from microupdi.

Even with this file the DFu bootloader was flashed. Before I flashed bootloader for Leonardo.

`avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9587 (probably m32u4)
avrdude: erasing chip
avrdude: reading input file "0xD8"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xD8:
avrdude: load data hfuse data from input file 0xD8:
avrdude: input file 0xD8 contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xFF"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xFF:
avrdude: load data lfuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xCB"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xCB:
avrdude: load data efuse data from input file 0xCB:
avrdude: input file 0xCB contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "../mEDBG_UPDI_1.13_modified_suffer.eep"
avrdude: input file ../mEDBG_UPDI_1.13_modified_suffer.eep auto detected as Intel Hex
avrdude: writing eeprom (1024 bytes):

Writing | ################################################## | 100% 15.24s

avrdude: 1024 bytes of eeprom written
avrdude: verifying eeprom memory against ../mEDBG_UPDI_1.13_modified_suffer.eep:
avrdude: load data eeprom data from input file ../mEDBG_UPDI_1.13_modified_suffer.eep:
avrdude: input file ../mEDBG_UPDI_1.13_modified_suffer.eep auto detected as Intel Hex
avrdude: input file ../mEDBG_UPDI_1.13_modified_suffer.eep contains 1024 bytes
avrdude: reading on-chip eeprom data:

Reading | ################################################## | 100% 4.97s

avrdude: verifying ...
avrdude: 1024 bytes of eeprom verified
avrdude: reading input file "../mEDBG_UPDI_1.13_no_bootloader.hex"
avrdude: input file ../mEDBG_UPDI_1.13_no_bootloader.hex auto detected as Intel Hex
avrdude: writing flash (32768 bytes):

Writing | ################################################## | 100% 229.27s

avrdude: 32768 bytes of flash written
avrdude: verifying flash memory against ../mEDBG_UPDI_1.13_no_bootloader.hex:
avrdude: load data flash data from input file ../mEDBG_UPDI_1.13_no_bootloader.hex:
avrdude: input file ../mEDBG_UPDI_1.13_no_bootloader.hex auto detected as Intel Hex
avrdude: input file ../mEDBG_UPDI_1.13_no_bootloader.hex contains 32768 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 152.68s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x69d2
0x00 != 0xff
avrdude: verification error; content mismatch

avrdude: safemode: Fuses OK (E:CB, H:D8, L:FF)

avrdude done. Thank you.
`

from microupdi.

Did you see my last post? I uploaded the wrong file by mistake. The one that are available now has the bootloader removed. Try this. You can also view it in a text editor to make sure the bootloader is completely gone. Look up Intel Hex on Wikipedia if you're struggling to read it.

from microupdi.

Sorry I did not see the correction - I will try again - thanks a lot!

from microupdi.

Now the flashing worked, the device has the correct naming, ID and will be shown in Arduino IDE as Port.
Just the mismatch is at an other adress now:

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x1127
0x20 != 0x28
avrdude: verification error; content mismatch

Then I tried to upload a "blink" to my bord with 3216 (attno.de) and it worked :-)

Thank you so much for your help - I am very happy now :-)

from microupdi.

Great to hear it's working! But since you're still getting a mismatch error I'm starting to believe your ATmega32u4 might have a worn or slightly corrupted flash memory. But if it works that's great!

I'll update the microUPDI core files to include the hex while without the DFU bootloader, so other users in the future won't have these issues.

from microupdi.

FYI a new version of microUPDIcore (v1.0.2) is now available, and it uses the hex file without bootloader as the main hex file when you flash it though Arduino IDE.

from microupdi.