Atmega328pb xplained mini debugWire problem

Log in or register to post comments
Go To Last Post
7 posts / 0 new
Author
Message
nto
nto's picture
Level: New Member
Joined: Tue. Feb 11, 2020
Posts: 3 View posts
#1
Posted by nto: Tue. Feb 11, 2020 - 03:04 AM
  • 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. 

Tags:

Tools, In-System Debuggers and Programmers, mEDBG, Atmel Studio, atfw, avrdude, debugWIRE, atmega328pb, ATmega32U4
Last Edited: Tue. Feb 11, 2020 - 03:41 AM
Top
gchapman
gchapman's picture
Level: 10k+ Postman
Joined: Tue. Jan 9, 2007
Posts: 11701 View posts
Location: Arlington, Texas, u.S.A.
Posted by gchapman: Tue. Feb 11, 2020 - 04:39 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

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98173 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Feb 11, 2020 - 09:35 AM
  • 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.

Top
nto
nto's picture
Level: New Member
Joined: Tue. Feb 11, 2020
Posts: 3 View posts
Posted by nto: Wed. Feb 12, 2020 - 03:08 AM
  • 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? 

Top
gchapman
gchapman's picture
Level: 10k+ Postman
Joined: Tue. Jan 9, 2007
Posts: 11701 View posts
Location: Arlington, Texas, u.S.A.
Posted by gchapman: Wed. Feb 12, 2020 - 04:11 AM (Reply to #4)
  • 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

Top
nto
nto's picture
Level: New Member
Joined: Tue. Feb 11, 2020
Posts: 3 View posts
Posted by nto: Wed. Feb 12, 2020 - 11:18 PM
  • 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?

 

Top
gchapman
gchapman's picture
Level: 10k+ Postman
Joined: Tue. Jan 9, 2007
Posts: 11701 View posts
Location: Arlington, Texas, u.S.A.
Posted by gchapman: Thu. Feb 13, 2020 - 01:30 AM (Reply to #6)
  • 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

Top