AVR Freaks

Thank you very much gchapman. This actually saved most of the boards!!

• If the board was in bricked condition (recognizable by the Studio but not able to use debugWIRE or ISP), just a firmware upgrade restored the board.
• If the board was not recognizable by the computer at all (USB errors or no connection at all), after a forced bootloader entry, i.e. short circuited the BOOT pads), the firmware upgrade worked, and the board was restored. 

Just another question, in some boards (2-3 of them where the boards are not recognizable by the system through USB), this forced bootloader worked but the firmware upgrade resulted in the following error: "CoreException thrown during firmware upgrade. Blank check failed at address 0x00. The firmware might be left in an unstable state.". Is there any possible solution for this error? 

I could not see any options in atfw.exe, specific for boards with failures (except maybe --all option, which did not work). 

I tried the DFU loader but it gave the same error as atfw.exe. These loaders both say that the blank check fails on the target memory. For DFU loader, I tried --force, --suppress-validation options to force the flash operation but it always gave the same error: blank check fails. With DFU, I also tried to erase the chip first but that also did not work. Is it the case that the memory unit is locked for updates (for the bootloader)? Any if that is the case, would there be a solution for it?

Thanks again for your suggestion and sorry for my late response. I have been waiting to get a hold of an Atmel-ICE device to connect to the embedded debugger (mEDGB) through JTAG. I just did this today. After doing this, I could actually fix almost all of the remaining boards, as I could update the mEDBG firmware with Atmel-ICE through JTAG. And then, the devices started performing regularly. I did not get the blank-check error anymore.

There is just one board left that I could not fix. I know it is not really a big deal at this point but I am just curious, and would like to just learn. I could update the embedded debugger in this board. I could access/read/write/verify its (atmega32u4) Flash with Atmel-ICE without any issue. Then, I connect the device normally and Atmel Studio can actually list the mEDBG tool as available (can verify this with atprogram command utility as well). But when I try to download code into the device, Atmel Studio says that it cannot connect to the tool (but the tool is still listed in Atmel Studio and it does not seem to be disconnected). The interesting point starts after this. The sample project I have used becomes corrupted after this point. I cannot access the "Tools" tab for this project anymore, Atmel Studio throws an error (kind of a memory read error, but not the device memory). And the error persists even if I connect an operational board. The only thing I can do is to remove the project, delete its files from the file system, restart Atmel Studio, and start a new project from scratch. Have you encountered an error like this before? And any possible ideas? The next thing I will do is to see if I can program the faulty board through ISP with Atmel-ICE. But even if that works, does it mean that I cannot use the on-board mEDBG for programming again? 

I appreciate your help. 

UPDATE: I just tried programming the atmega328pb with ISP using Atmel-ICE and it actually worked for this device. After that, I tried to connect the device and program through mEDBG again but same error. It seems like atmega328pb on the board is not corrupted and operable. 

By the way, here is the error I receive from the Studio right after the device is connected (on the Studio console): [ERROR] Failed to create the connection com.atmel.avrdbg.connection.cmsis-dap with the given props., ModuleName: TCF (TCF command: Tool: setupTool failed.)

Unfortunately it did not work, but I found something that could be a solution. In this thread (https://www.reddit.com/r/avr/comments/7f4rya/problem_with_writing_to_atmega327pb/dq9n6bh/), the author describes the same problem and shows a solution. He says the solution was to re-flash the board with a random serial number. The post provides a project link from microchip but unfortunately the link is gone. Do you know any way to re-flash the board with a random serial number?

Some updates on what I observed:

1 - After inspecting the contents of 32u4 EEPROM, I could actually verify that the contents are corrupted. I compared it with the EEPROM contents of a regular board, and apart from the first two lines (hex file), everything else is the same. Then, I looked into the first two lines, and saw that they contain the serial number. Then I compared the contents with the correct serial number (the one on the back of the board). There was a single digit that was wrong. Then I changed the downloaded EEPROM file, corrected the digit (along with the checksum at the end of that line). I tried to update the EEPROM with the updated file, but it did not work (EEPROM verification failed). 

2 - Then I used AVR DUDESS to erase the contents of the EEPROM. After that EEPROM contents were not completely erased but kind of more corrupted. Right now, when connected to Atmel Studio (or command line atprogram list utility), the device's serial number just says "ATML2". It is because after that point, the content is "00". 

3 - When I select the ATML2 as the tool in Atmel Studio, Studio crashes (different than before) and automatically restarts. 

4 - I cannot update the contents of EEPROM through AVR DUDESS or Atmel Studio Device Programming. It constantly says the EEPROM contents cannot be verified.

5 - The device fuses seem to be OK. And the 32u4 Flash seems to be working fine (I can erase and re-flash firmware into it without any problem).

So, my current question becomes. is there a way to force updating the EEPROM contents (this is again for the debugger - 32u4)?