SOLVED: debugWire with PLL works, not with 20 MHz crystal

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

Hello all,

 

I have an atTiny85, that can happily switch back and forth between debugWire and ISP as it should; when using the internal PLL clock (16K CK/14CK + 64 ms). I have added a 20 MHz crystal with 2x 22 pF capacitors, changed the fuses (external osc, 8+ MHz, slow start) and everything seems to work fine, the timing of my application corresponds to the 20 MHz speed. 

 

However, when I want to switch to debugWire and go through this process in Atmel Studio 7, after toggling target power it says that "Setting debugwire fuse seems to have failed, check your clock and fuse settings". At this point it goes neither into debugWire or ISP mode, seems to be locked in some sort of "limbo" without any communication with the device. If I try debugWire it attempts to set it up from scratch trhough ISP, but ISP does not work ("Got 0xC0 expected 0x00). The application still works on the MCU with the correct timing. Have two '85 locked in this state already, it's not a productive day. :)
 

I have tried to connect to the MCU without the 10 kOhm pullup to Vcc, and there is no capacitors on the reset line. Here is the weirdest part: running out of ideas I connected the reset through the 10k resistor to ground (I don't know why), and it connected to debugWire, could even go back to ISP... To me, this does not make sense. There is nothing connected to the MCU except the Atmel-ICE and an oscilloscope probe so I can see if the application timing is correct.

 

- Is there a special trick to use debugWire with an external crystal / at 20 MHz?

- How could connecting reset to the ground through the resistor enable DW? What is the logic in that?

- Since DW is asynchronous, how does it know what is the speed it should use? (I have no F_CPU in the code)

- Is there a maximal speed for DW?

Would be grateful for any ideas or explanations, I have run out of them.

 

EDIT: I could make DW work with a 16 MHz crystal on a breadboard, but not 20 MHz. As the commenters said, a PCB-version helped.

 

 

Thanks, G.

Attachment(s): 

This topic has a solution.

Control engineer and fart expert.

Last Edited: Fri. Nov 3, 2017 - 01:10 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

20MHz operation in a breadboard is bound to be flacky!  I also do not see a bypass cap across the power pins of the chip, 100nf is typical, and yes it is needed!

I also find it strange you have placed the power board in the bb and then used jumpers to the power rails, when the board is designed to just plug into the power rails!

 

max speed?   Not that I know of, I have used DW successfully on many chips, but always on a pcb, never on a bb.

 

Jim

 

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

Thanks for the reply Jim.

 

My logic was that it 20 MHz works with the application running (A/D -> control engineering stuff -> PWM), then DW should too; but point taken and issue noted.

 

I'll try the bypass cap and report back!:)  As for the power board - there are pins of the bottom that prevent me to plug it in a sensible way on this board, so not all that well designed;)

Control engineer and fart expert.

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

Invest in some 100nF capacitors.

Place your power supply on the breadboard as Nature intended.   

Mark your positive and negative bus with red and black marker pen.  

Use red and black jumper wires.

Use 10k pull-up on Reset line.

 

I see little point in wasting 2 pins of an 8-pin chip for a crystal.   But I would expect 20MHz to work ok.

You can get 16MHz with the PLL.    And 64MHz for the Timers.

 

David.

Last Edited: Wed. Sep 27, 2017 - 03:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Must be a pretty fast control loop project!  For projects like that I use a AVRdragon for prototyping and DW debugging, or design a prototype pcb for small AVR's as with so few pins and I/O's the risk and cost is minimal. 

 

Report back how it goes.....

Sounds like a fun project.

 

Jim

 

 

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

Thank you gentlemen for the replies.

Dave: I will try to tidy things up and use a better source, if no better idea comes along - but I suspect the issue is not the color of the wires :-) The 10 k resistor was there (DW should not need it anyways!), and unfortunately the 100nF capacitor did nothing to remedy the situation. I do need 20 MHz and precision timing as this is a complex control engineering project, squeezing every drop of performance out of the tiny85. The tiny85 at 20 MHz is given, the pins do not matter - 3 are enough.

 

Jim: It is a SISO control loop for active vibration control, not that fast but quite complex - it will use model predictive control (MPC), something like this. Thus I'm pushing the chip to its limits. The cap unfortunately did not help, I had a 100 nF Polyester one lying around to try.

Control engineer and fart expert.

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

Pretty cool!  I would still move away from the BB onto a prototype pcb, I see the original project paper used an arduino and proto shield. 

Bread boards are just flacky!  It's hard to troubleshoot s/w when the h/w is unstable.   Time spent building good h/w is time well spent.

Thanks for the link!

Jim

 

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

+1 for the breadboard possibly the source of the problem.  I bet you'd have problems with a 16MHz crystal on a breadboard as well.

 

If you can't solder up onto a proto-board, you may at least try reducing the caps from 22pF to 18pF or even lower.

 

- Since DW is asynchronous, how does it know what is the speed it should use? (I have no F_CPU in the code)

I'm no expert (starting to fool around with dwdebug), but I believe that comms is initiated by the debugger by means of a line break, and the target responds to that with a sync byte.  The debugger listens to the sync byte to determine the baud rate at which it is running.  Default is 1/128 of system clock.  If you're running at 20 MHz, then that would be 156.25 kbps

 

The dwdebug tool I mentioned starts at 150 kbps and with a 50 ms break.  Curiously, the source code has this:

  int baudrate = 150000; // Start well above the fastest dwire baud rate based
                         // on the max specified ATtiny clock of 20MHz.

Which is incorrect.  I don't have a 20 MHz crystal here to try, but next time I have one handy I will.  I expect it won't work unless I change the starting baud rate to be >= 156.25 kbps.

 

I don't know what debugger you're using, nor how AS talks to it, specifically what starting baud rate it tries.  If it, too, starts at 150 kbps then it might explain the problem.

 

- Is there a maximal speed for DW?

Not inherently, at least to my knowledge.

 

It's an open-drain bus, so the speed will be limited by the pull-up, the driver strength when sinking, and (perhaps most importantly), the bus capacitance.

 

That may be the problem in your case.  A breadboard will have a lot of stray capacitance. 

 

I have no explanation for why it worked when pulling >>down<<.  It shouldn't work at all, being an open-drain bus.  Put a scope on /RESET under different pull-up/pull-down resistors, see what happens.  Look for clean edges.  Note that the scope probe will add capacitance to the bus, so this won't be a definitive test.

 

The dW specs are not public, but we can possibly assume that the VIH and VIL thresholds on the bus are match those indicated in the datasheet, so 0.2VCC and 0.9VCC.

 

Assuming the dW hardware takes a single mid-bit sample, at 156.25 kbps the bus must reach 0.9V after no more than 3.2 us after a rising edge.

 

0.9VCC represents about 2.3 TC [ln(1/(1-0.9))], so the TC of the bus must be 3.2/2.3 = about 1.4 us.  With a 10K pullup and the internal 60K pull-up on /RESET, the effective pull-up is 1/(1/10+1/60) = about 8.5K, so the maximum bus capacitance is 1.4E-6 / 8.5E3 = about 164 pF.  While that may seem like a lot, on a breadboard with lots of flying wires you might find that it is realistic.

 

Try a stronger pull-up, but if the programmer's driver (or the target's) isn't strong enough it might not work for that reason.

 

Minimise the bus capacitance by keeping the wires as short as possible, and lose the bread board if you can.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Thu. Sep 28, 2017 - 12:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gergelytakacs wrote:

The cap unfortunately did not help, I had a 100 nF Polyester one lying around to try.

 

The cap is always important even if it doesn't SEEM to help, you should use a ceramic type.

 

 

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

A thought or two:

 

Check carefully your ATTiny's markings.

Do you have an Tiny85 or a Tiny85V?

The V model is only spec'd to 10 MHz.

 

It looks like you are running at 5 V, that is good, as the V model is only spec'd at 20 MHz when running on 4.5 - 5.5 V

 

The Tiny85 has its V+ and Ground pins on opposite sides and ends of the micro..., like old TTL chips!

In any event, put a 0.1 uF cap from the V+ pin to ground.

For now, also put a 1 uF or other small electrolytic cap from your V+ to Ground.

 

It looks like you have already shortened the Xtal caps leads, good job!

If you can shorten them a little bit further, it wouldn't hurt, but I think the 20 MHz Xtal on the breadboard is fine.

 

Did you put your O'scope lead directly on one of the Xtal pins to measure the clock freq?

That is generally a bad idea.

It will load the Osc and it will both be off frequency, and can stop the clock.

 

I'd suggest you carefully recheck your ground connections, for the micro, the power supply, and the debugger's connections.

This can be an easy point of failure for such setups.

 

I've not used DW, so no comments on that, except to ask if that is one of the debug protocols that one has to specifically disable to get back to normal mode of operation?

 

Regarding the breadboard power module:

Agreed, breadboards come in different shapes and sizes, particularly regarding the power rails.

So some modules won't fit correctly on some breadboards.

 

It looks like you are using one end of the breadboard.

If you have any wires, (including your master ground...), that are on the "far side" of the breadboard, did you remember to jumper the power rails in the middle of the rails?

On many / most, the power rails are split 1/2 down the rails.

 

Breadboarding is fine, IMHO, in spite of the naysayers above!

 

Below is one of Atomic Zombies video circuits, high speed, on a distributed breadboard system, and a much smaller one of my boards.

 

Good luck with your project.

 

JC

 

JC

 

 

 

 

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

SOLVED.

 

Thanks for all the good advice. I am responding now, as I just got the PCB printed (my very first:) and the application tested.

 

Those who claimed that a PCB instead of a breadboard should help are right.

 

I can switch back-and-forth from ISP/DW when I use the ATTiny on a PCB with a 20 MHz crystal, that was the issue. Making the breadboard a bit more tidy did not help, but switching to a 16 MHz crystal did. So all in all, you can use debugWire with a 16 MHz crystal on a breadboard, but - for me at least - a 20 MHz crystal and a breadboard was an issue.

 

Control engineer and fart expert.