Unresponsive AtMega6450A in ISP Programming Mode

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

I have a self-designed PCB using an AtMega6450A which will not program. I am using the AVRISP programming module and Atmel Studio 7.

 

I have several of these PCBs, some program OK, a few don't. The problem scenario is as follows. Starting with a virgin 6450A soldered to the board, I can successfully read the voltage (5.1 volts) and the device  signature. Next, I program various fuses (EESave, CLK/8, ClkOut, etc.), but I am still running  on the internal oscillator. All of this works fine. The fuses verify, the signature reads flawlessly as many times as I care to query it. Next, I engage the external crystal (7.3728 MHz), which is also part of the PCB assembly, by selecting the appropriate oscillator option fuse. This is Ext. Crystal Osc 3-8 MHz with the longest start-up time option (65msec). On 2 out of 3 of my PCBs this works fine and I can proceed to change the interface speed and program the Flash without an issue. However, on 1/3 of my PCBs the ISP communication with the chip stops right here.

 

The device signature always reads back as FFFFFF and Studio 7 posts the error window reading: "Unable to enter programming mode. The read device ID does not match the selected device or any other supported devices."

 

I know about the problem where the oscillator is mis-selected and  the IC becomes unresponsive to Studio. This is NOT that problem. The crystal is oscillating very nicely on my O-scope. Plus, I programed the Ext Clock Out fuse (having experienced various clock issues in the past) and the oscillator clock appears on the designated Clk Out pin ( Pin 9) - even though Studio can't read the signature. So, I know I have a viable clock.

 

The boards were soldered by a very competent craftsman, and I have partially assembled them to make sure the 6450A is working before committing too many other components to the PCB. So, the 6450 is virtually unconnected to any external hardware except the ISP connector ( a 2x3 header) and the crystal and associated caps,  0.01 bypass caps at each Vcc & Gnd pin pair, and two 2.2 uF tantalums near to the 0.01 ceramic bypass caps. AVcc (pin 100) is connected to 5 volts, Aref (pin 98) is bypassed to ground with a 0.01 ceramic cap. I have buzzed out the ISP/SPI connections and looked at these signals on the O-scope. None seem to be dead or stilted.

 

I suspect there is something unique with the ISP interface on the 6450A. Perhaps a control/GPIO pin I am not connecting, perhaps a fuse setting that is not appropriate, maybe a spate of bad 6450's coming thru the distribution channels ( the came from DigiKey).  There are several other questions posted on this topic. I have studied them, but it seems they were resolved as simple hardware problems (bad connections and the  like).

 

Have any Freaks experienced this, or similar, syndrome with the 6450A, or other AtMega models, and how did you resolve the problem? Also, any suggestions will be greatly appreciated.

 

Thanks

 

 

 

 

Last Edited: Sat. Feb 4, 2017 - 09:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First, I would check the schematics, if there are other devices on the same SPI pins, that might interfere in the communication with the programmer.

If this is not the case, you might want to change the SPI clock period for the programmer, if you have a 7,3MHz crystal and the CKDIV8 fuse bit is programmed, the mcu might be too slow - less than 1MHz clock.

Also check the reset pin for proper pull-up and no big capacitor to either supply.

Good Byte!

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

2 things I would check:

 

Make sure that the ISP frequency is set to 250Khz or even 125KHz.

 

What's connected on the reset line? Some people have the obsession of putting large cap to ground in the order of uF. (I see mentioned above already)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

volbus: There are no other connections to the SPI pins. The PCB runs from the 6450 to the 6-pin ISP header are approx. 2.0 inches. The ribbon cable to the AVRISP pod is 7 inches.

 Also, I have tried every low interface speed ( down to 2.x KHz and up). Same error as described in original post. I cannot get even one "wrong" response, always the same FFFFFF.

 

No capacitors (of any value) on the RESET line. You mention "proper pull-up". According to the data sheet there is no external pull-up required. Nonetheless, based on your comment I attached a 1K pull-up to Vcc (5 volts). No change, same exact error scenario. Still, please let me know what you mean by "proper pull-up".

 

Thanks for your help.

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

John: I have tried every selectable interface frequency in Studio 7. Same result for each: signature reads 0xFFFFFF.

 

No reset line obsessions here, as naked as a jaybird. Reset line runs to the ISP connector and to an uninstalled pushbutton switch. I see full swing activity on the reset line when I invoke the Read Signature command in Studio 7.

 

Also, I tried varying Vcc with an external supply. 2.0 up to 5.4 volts. No difference in the error scenario whatsoever.

 

Also, went back and checked the other PCBs with the same programming pod and cable. Both of them work perfectly in terms of programming operations at 7.37 Mhz, 5.1 volts, etc. Device Signature read is perfect no matter how many times I read it. Flash programs without a problem.

 

My guess is that I have somehow inadvertently programmed a fuse which is causing this problem. Do you have any idea which fuse(s) would cause such a scenario?

 

Also, is it possible that I am able to see the crystal osc. clock on the External Clock pin ( pin 9), but that internally the processor is not actually connected it to it due to a fuse issue (e.g. wrong fuse inadvertently programmed)?

 

Thanks for all of your help. I am ready for any further advice or suggestions you can offer.

 

 

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

Proper pull-up is 10..100kΩ (47kΩ is a good value). As far as I know, the ISP programmer checks the voltage on the Reset pin and then tries to pull it low. So, if the Reset pin is not high when the programmer is still idle (has not taken control of the line) I think it will issue an error. Same if it cannot pull the Reset pin low.

Are you sure you haven't disabled the serial downloading on a first try? Or the reset pin?

Can you still try with a new board? Just to enter programming and read the fuse bits. Does this work?

FFFFF means continuous high level, already checked for a shortcircuit to Vcc?

Good Byte!

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

I have just downloaded the data sheet for the chip and it doesn't seem to have any particular programming requirements.

 

Maybe you could swamp the XTAL1 pin with an external 1MHz clock and retry ISP or you could try using JTAG, if you have one, and have a JTAG connctor.

 

The other thing you could try is to replace both the XTAL and particularly the caps on a bad board just in case they are of the wrong value.

 

All guess work of course. blush

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

volbus: I have scoped the output signal ( MISO Pin 22 ) and see that it normally sits at ground. When I issue the Read Signature command via Studio 7, two 5 volt pulses appear. They are unequal in width and 5 volts in amplitude. They occur within a 1.5 milli-sec period; however, I can't tell how soon they occur after I issue the command. MISO is low at all other times.

 

Wouldn't this imply that processor is running? Or, is the programming function handled by other on-chip logic outside of the processor function itself?

 

I'm coming to the conclusion that, however it may have happened, either the SPIEN fuse is "disabled" or one of the write/protect fuses is "set". I did intentionally disable the JTAG Enable function via the fuses because I am using those pins in my application and I have no intention of using the JTAG programming function. I recall that, before the processor stopped working, I verified the fuse settings and they were in agreement with my intentions.

 

Thanks for all of your help thus far. If you have any other ideas, or know where I can get some direct help from Atmel, I would appreciate it.