Atmega328pb xplained mini debugWire problem

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear AVR community, 

 

I have recently been working on several unusable Atmega328pb boards to see if they are salvageable. I have identified that the common problem for several of them is disconnecting the device without a clean break from a debugging session (using the mEDBG tool). I applied the following methods to fix the problem (that I could find through the forum):

- Creating a new debug session for a clean termination of the debug session. (does not work. tries to activate debugWire through SPI but SPI does not work either)

- Using the atprogram utility (to use the command dwdisable) to manually disable debugWire (does not work. the tool connects (says Firmware OK) but the actual command fails, saying that there is an error saying "debugger command activate physical failed")

- Providing an external clock to the device in case the board accidentally set the fuses wrong (does not work. it does not make the chip work with ISP to program or to change fuse settings)

 

I was wondering if there is any other method to try without using an additional external debugger/programmer. I was really hoping that the atprogram option would work, but unfortunately it does not. I appreciate any help and am sorry if I missed any other solution in the forum that was previously published. 

Last Edited: Tue. Feb 11, 2020 - 03:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mEDBG state information would be stored in the mega32U4; might try a re-program of mEDBG (mEDBG has had updates since RTM)

mEDBG Firmware Upgrade and Manual Bootloader Entry | ATmega328PB Xplained Mini

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Could it be that these boards are loading the ISP pins in some way? To switch back from dW to ISP mode it needs all the ISP pins available.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're welcome

nto wrote:
Is there any possible solution for this error?
Yes

Explore atfw.exe; try atfw options on the boards with failures.

If one loader, atfw.exe, isn't successful then try a different loader; DFU was added to AVRDUDE 6.3

There are other USB DFU loaders.

mEDBG is linked to a specific version of Atmel Studio; recommend operating with the most recent Atmel Studio unless you experience a failure that doesn't have a workaround.

 

P.S.

Once an AVR is in debugWIRE then stay in debugWIRE until done with debugWIRE; can program in debugWIRE in addition to debugging.

AVR ICSP is synchronous so will be faster to program than debugWIRE.

megaAVR 0-series UPDI is the follow-on to megaAVR debugWIRE.

 


Manual Upgrade | Atmel Studio 7 (atfw)

AVR Downloader/UploaDEr - News: AVRDUDE 6.3 released [Savannah]

Index of /releases/avrdude/

dfu-programmer

dfu-util download | SourceForge.net

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nto wrote:
Is it the case that the memory unit is locked for updates (for the bootloader)?
Can answer only by reading its fuse values.

nto wrote:
Any if that is the case, would there be a solution for it?
Yes by significant effort and work.

mega32U4 are JTAG enabled during manufacturing, mega328PB Xplained Mini has pads for a non-mounted AVR JTAG connector for mega32U4

 

ATmega32U4 - 8-bit AVR Microcontrollers

ATmega328PB Xplained Mini

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nto wrote:
Have you encountered an error like this before?
No

nto wrote:
And any possible ideas?
None at this moment (that's an odd failure, am uncertain on the sequence of defect -> fault -> failure)

nto wrote:
But even if that works, does it mean that I cannot use the on-board mEDBG for programming again?
Don't know the answer though am glad you've progressively worked the issue down to only one board.

Digital circuits are dependent on VCC/GND (stable, kinda low enough noise) and clock (crystal in this case for mEDBG) (no clock for asynchronous digital)

USB Vbus is typically noisy (that's relative) and sometimes unstable (wall warts are a personal bane)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Might re-try after switching the mega38pb into debugWIRE via ICSP (by Atmel-ICE)

nto wrote:
[ERROR]  ... [AVR in EDBG] ... TCF ...
TCF failure messages may be a catch-all.

Given the original issue for your thread, consider Microchip Tech Support (reason : mutual awareness of a possible mEDBG defect)

Microchip/Atmel support page | AVR Freaks

 


AVR-target Specific Vendor Commands | Embedded Debugger-Based Tools Protocols User's Guide

 

edit : typo

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Feb 26, 2020 - 08:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So close

https://web.archive.org/web/20190331101242/https://spaces.microchip.com/gf/project/ (3/4 page)

yet so far

https://web.archive.org/web/20190331101242/https://spaces.microchip.com/gf/project/avr_xp_mini/

 

Atmel Spaces survived for quite sometime after Microchip acquired Atmel though recently expired (there might be a thread here on Spaces EOL)

So, Microchip Tech Support

(was Spaces archived somewhere?)

nto wrote:
Do you know any way to re-flash the board with a random serial number?
No

 

edit :

fyi, one can self-archive web pages via Webpage archive

reason :

IPFS is the Distributed Web - why

[1/4 page, right column]

Today's web can't preserve humanity's history

[web page's lifetime]

...

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Feb 27, 2020 - 04:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(was Spaces archived somewhere?)

maybe behind a wall

Microchip SPACES

...

In order to access a project, you must be invited by a Microchip representative.
Please request an invitation to SPACES from your Microchip point-of-contact.

... 

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nto wrote:
Do you know any way to re-flash the board with a random serial number?

Read out the eeprom content of the mega32U4 with atmel-ice, modify the usb serial number, write it back again? 

Edit: look for the 20 characters starting with ATML

EditEdit: you could try something like this script: https://github.com/mraardvark/py...

I think it worked for SUFFER registers, but I have not tried editing serial numbers.  Of course if the serial number is so corrupted that HIDAPI won't connect, then it won't help... 

Last Edited: Thu. Feb 27, 2020 - 07:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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)? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Final update: I was able to fix the board!! The board is completely operational again as expected. Below, I will list what I did for those who would be interested:

  • The board's serial number (debugger [32u4], not the main 328pb chip) was corrupted. I verified this by inspecting the contents of the EEPROM of 32u4. 
  • I tried to fix the EEPROM hex file and rewriting to the 32u4 EEPROM but EEPROM programming did not work, threw verification error.
  • Then I disabled the "EESAVE" fuse of the 32u4 device. This allowed me to write to EEPROM without any verification error. 
  • However, the corrected hex file did not work. 
  • I picked another operational board and dumped its EEPROM contents into a separate hex file and flashed this hex file into the faulty board's debugger's EEPROM.
  • The operation was successful. My computer immediately recognized the device, and could see the device under Device Manager in Windows. 
  • Then, I went back to Atmel Studio, under tools, the device (with new serial number) was listed. But when I chose it, the Studio crashed again as before. However, when I went to "Device Programming" box under "Tools" menu, I was able to program the device through ISP! 
  • So, I deleted the project, created a new one. With the new one, Atmel Studio did not crash anymore. And I could use the device normally! I tested ISP and debugWire. Both worked as expected.
  • At the end, the device is working normally. It is just that I now have two devices with the same serial number (for the mEDBG), but I do not think it is crucial! 

 

Thanks a lot for all your help. I really appreciate it. All the boards are fixed now!  

Last Edited: Fri. Feb 28, 2020 - 06:12 PM