Issue with DebugWire on ATMega32U2

Log in or register to post comments
Go To Last Post
7 posts / 0 new
Author
Message
clpalmer
clpalmer's picture
Level: Resident
Joined: Thu. Oct 26, 2006
Posts: 744 View posts
Location: Vancouver, BC, Canada
#1
Posted by clpalmer: Thu. Feb 28, 2013 - 09:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Having an issue getting any communication after enabling debugwire on an ATMega32U2 chip via a Dragon.

Before enabling it, ISP communication was no problem with AVR studio. Avrdude seemed to have an issue, but AVR studio could read/write fuses, write flash, erase, no problems. Then I had to go click the 'start debugging' and after that I can't connect at all.

The chip has an external 16MHz crystal connected and after setting the clock fuse as such, communication was still fine and since ISP programming was working at 4MHz, I assume the chip was indeed running at 16 MHz as expected.

The reset line has nothing else connected on the target board and is pretty well just a 2 or so inch trace between the 6-pin header and the chip. I've tried with both a 10k pullup to VCC (5V) and no pullup with no success.

I assume the reset line must be connected properly or ISP wouldn't have worked. I've also verified w/ a multimeter that reset connects only to the chip and no other pins on the target board so there should be no interference.

Anyone have any other ideas or am I headed for the iron to try and remove the TQFP?

*EDIT* Also, the Dragon can successfully debug a mega88 chip over debugwire, so that piece should be working as well.

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

Tags:

AVR Microcontrollers, megaAVR and tinyAVR, ATmega8, ATmega88
Top
Brutte
Brutte's picture
Level: Raving Lunatic
Joined: Thu. Oct 5, 2006
Posts: 3231 View posts
Location: Poland
Posted by Brutte: Fri. Mar 1, 2013 - 12:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My vote is for RSTDSBL programmed.

SPIEN is not accessible through ISP, dW or SPM so there is no way to change it the way you describe.

Or you have enabled some odd reset clock source (apply external one to test). Do not be mislead ISP is synchronous - Atmel implemented it in such stupid way that uC still requires second clock source for ISP to work!

No RSTDISBL, no fun!

Top
clpalmer
clpalmer's picture
Level: Resident
Joined: Thu. Oct 26, 2006
Posts: 744 View posts
Location: Vancouver, BC, Canada
Posted by clpalmer: Fri. Mar 1, 2013 - 01:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Odd though it would decide to program itself... The last thing I did was tell AVR studio to start a debugging session at which point it used ISP to enable DW. It wouldn't have decided to also set reset disable.

Is a 2-3" 9mil PCB trace after the 3 or 4" isp ribbon connector an issue? Wouldn't have thought so.

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

Top
Brutte
Brutte's picture
Level: Raving Lunatic
Joined: Thu. Oct 5, 2006
Posts: 3231 View posts
Location: Poland
Posted by Brutte: Fri. Mar 1, 2013 - 11:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Is a 2-3" 9mil PCB trace after the 3 or 4" isp ribbon connector an issue?

I have no idea, I do not debug tinys. But I do use a parallel printer cable for ISP programming sometimes. It is 2m long and never had any issues.

Quote:
It wouldn't have decided to also set reset disable.

I have heard one can erase signature bytes of AVR by mistake. Why not RSTDSBL?

Did you verify it is not the odd/missing reset clock source that makes trouble?

No RSTDISBL, no fun!

Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 29915 View posts
Location: Wormshill, England
Posted by david.prentice: Fri. Mar 1, 2013 - 08:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AS6 + Dragon + ATmega32U2 + debugWIRE should work fine.

1. check there is no capacitance on the dW line.
2. start a Debug session in AS6.

Note that AS6 generally tells you if debugWIRE is not working when it enables DWEN

David.

Top
clpalmer
clpalmer's picture
Level: Resident
Joined: Thu. Oct 26, 2006
Posts: 744 View posts
Location: Vancouver, BC, Canada
Posted by clpalmer: Sat. Mar 2, 2013 - 11:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All I can attribute it to was interference on the SPI lines while I was programming the chip. The lines are multi-purpose and I missed a couple pullups to disable the other chips that drive the lines so it's possible that during programming, the other chips were interfering and somehow the RSTDISBL fuse accidentally got programmed.

In any case, removed the other chips and replaced the AVR and no issues now with DW or programming. avrdude is happy as well.

Hopefully after replacing the other chips w/ the pullups in place, it'll still work.

Thanks for the ideas :)

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

Top
crispytronics
crispytronics's picture
Level: New Member
Joined: Wed. Aug 21, 2013
Posts: 1 View posts
Location: San Diego, CA
Posted by crispytronics: Wed. Aug 21, 2013 - 08:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had this same issue this morning using an ATmega328P with AVR Dragon. According to Atmel, "when the DWEN fuse is enabled the SPI interface is overridden internally in order for the OCD module to have control over the RESET pin. The debugWIRE OCD is capable of disabling itself temporarily (using the button on the debugging tab in the properties dialog in Atmel Studio), thus releasing control of the RESET line. The SPI interface is then available again (only if the SPIEN fuse is programmed), allowing the DWEN fuse to be un-programmed using the SPI interface."

If you are using Atmel Studio 6, simply select "Disable debugWIRE and Close" from the "Debug" menu.

Top