Reasons why an AVR would not ISP program

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

I have a number of units of a custom board with an ATMega32C1. For some reason a number of them will not accept programming. When reading the device signature I am reading only zeros. I am using an AVRISP mkII with Atmel Studio 6.

 

I have:

Checked the supply voltage around and during a device signature read with an oscilloscope and it is stable and nice at 3.3V.

Checked with the oscilloscope the reset, MISO, MISO and SCK and all of them toggle between 0 and 3.3V during a device signature read.

Looked at the solderings which are done in a professional factory and they do look perfect.

Checked that no components are missing and all components connected to the AVR are correctly oriented.

Loads of capacitance on the board and one 100nF next to the supply pin.

 

There is one signal used by the ISP that is shared with other functions on the board, it is the MOSI that goes trough a 4.7k resistor to the gate of a MOSFET.

The reset has a 10k pull-up and 100nF to ground.

I have not performed enough probing on the ISP signals to understand what they should look like and how they look when something i wrong, but since my signals are switching nicely between 0 and 3.3V, there should not be anything disturbing the programming or in my initial case, device signature read.

The boards that do work always works and the boards that do not work, never work. I haven´t been able to fix any of the non working boards or made any of the working ones go into "non-working-mode".

I use QFN version of the chip.

 

What could be the reasons for the AVR not accepting programming and what would I do to find out which reason there is that my AVRs are not accepting it? I am a bit desperate as I have no clue on where I continue to find the problem. Any help is appreciated.

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

AgwanII wrote:

The reset has a 10k pull-up and 100nF to ground.

Remove the 100nF capacitor to program.

 

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

As long as /RESET goes low, the capacitor shouldn't cause problems.  (Now, with debugWire I'd agree)

 

Just for fun, is there any difference if you cut the track or remove the MOSFET on one of the "bad" boards, and see if it helps?

 

What ISP clock rate have you used?  Have you tried slowing it way down?

 

You've 'scoped the signals.  If you 'scope them on the >>MKII<< end, do they still all look clean and square, especially MISO? (and SCK and MOSI at the target end)

 

Can you get your 'scope probe right on the QFN pad(s)? Still clean signals in?

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Wed. Sep 30, 2015 - 09:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Both of the above suggestions are good ones, and reasonable to try.

However I suspect an Atmel AVR ISP mkII can drive both a 0.1 uF/10K on the Reset\, and a 4.7K to Fet load without difficulty.

 

Two additional thoughts:

 

I think you have a 44 pin package.

It has THREE Vcc and an AVcc, ALL of which need to be connected to V+.

Likewise ALL four of the associated grounds need to be connected to Ground.

In the 44 Pin package the bottom pad on the TQFP should be connected to Ground.

(I don't know if the QNF version has a ground pad on the bottom or not...)

(I don't know the impact of not having this tied to Ground...)

If it has a ground pad, is it shorting out any traces that run under the micro?

 

Factory new chips should power up using the internal RC Oscillator.

Did you manage, once / ever, to program the Fuses to something other than the factory default?

If so, then other troubleshooting solutions apply.

Did the PCB manufacturer lot a test program post manufacture, and prior to sending them to you?

 

Were the boards totally manufactured by machine, with micros from a tape roll, or were any of the parts hand loaded?

If a human had a chance to mess up the process, it is possible that the micros do not have pin #1 aligned properly.

I don't know how well marked the M32's are, but on some of the Xmegas it can be very difficult to tell with 100 % certainty the chip's orientation.

 

You can certainly try applying an external clock to one of the Xtal pins in case the micro is somehow expecting a clock source that isn't there, but that seems a bit unlikely IF you never touched the Fuses.

It certainly can't hurt anything.

Further info can be found from Cliff's tutorial, here.

 

JC

 

 

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

Why does the reply window clear when moving back and forward in the browser? :( I had a long reply written here.

 

Brief conclusion: theuschs idéa of lowering the ISP clock speed was the solution. So simple solution, so stupid not to have done it allready. Sorry about that! But simple problems are always better than the problematic ones. Feeling stupid I can put asside in a few minutes and push on with the work, respinning the boards would have taken weeks.

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

The Moment Of Learning. A new AVR is running at 1MHz. The first programming session needs to set the InSystemProgramming clock freq to < 1/4 of the AVR clock. So one selects 125KHz and all is well.

 

Imagecraft compiler user