Can't program SMR4+ 328Ps

Hi - I am trying to reinstall the firmware on 3 of my Ambika SMR4+ cards after the data lights went out (it was all working fine until I put it in a case, oddly)…

But - my AVR ISP MkII won’t do it. In Atmel Studio 7 I can see the target voltages but get an error when trying to read device ID (Or do anything else):

“Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0x0, expected 0x00 (Command has failed to execute on the tool” etc.

Same error on all three lower cards (one of which has working firmware and data light). All jumpered to B. Both green lights on programmer. Programmer works fine on the mobo ISP pins and the 644P - I can read fuses, etc. on that so it doesn’t feel like a problem with the programmer.

Can anyone help?

Thanks, Simon

Sorry to BTT… but this one has got me stumped!

Given that the AVR ISP is proved working (on the Atmega on the mobo) and it fails on all the voicecards (could be a 6x error but the odds are low) I’m assuming that I’ve made some sort of error in the process… but I can’t see what.


Hmm, maybe you are plugging the cable in backwards?
When they all fail (and one of the cards is working as expected), it must be something simple like that.

assuming the programmer is fine and the chips themselves are fine as well, AFAIK this is what’s needed to get a working communication to AVR processors:

  • target processor is powered and power is stable

  • target processor is clocked (internally or externally with the clock signal/crystal present)

  • all ISP pins have a stable conductive connection to the corresponding pins on the programmer (check them individually if unsure). This comes down to: A) Cable is okay B) Cable is plugged in correctly and socket orientation is correct

  • the ISP clock speed doesn’t exceed 1/4 of the CPU clock frequency

You can check if all of these are okay.

Hi , have you set the Atmel studio to 328p into the Device programming window ?
This you had to do at first . Set also the clock to 115 KHZ.
Nomally it should works - i do it so without problems.

Thanks for the reply…

Cable is in right way round (I get red LED on the programmer if it’s the other way);

At least one of the voicecards has orange data LED and is working as expected when I try to program, so can confirm power, processor and clock all working at that one at least;

I’ve tried every ISP clock speed up to 125;

I’ve now tried all 6 voicecards and the result is exactly the same on all of them (the error reported above). When I try my exact same process on the mobo Atmega I get straight in and can read fuses, program, etc.

So… it’s almost certainly something fundamental I’m doing wrong but I cannot for the life of me figure out what it is!


To go a little further, I thought I’d see if I can get the same error when doing something wrong when connecting to the Atmega 644P on the mobo… when I select the wrong chip, not only will the ISP still read the device ID, it helpfully tells me that I’ve selected the wrong chip type!

Just to re-confirm - for the voicecards, I’m selecting Atmega 328P, I’ve tried all the frequencies between the minimum and 125 HHZ (including 115, Andre), the plug is definitely in the right way around (green lights on both sides of the ISP), the Ambika power is on and the same error repeats on all 6 voicecards.


That sounds very strange to my ears…
Do you have a chance to wire up a minimal example circuit (power, crystal, ISP connector) on a breadboard with one of the atmega328p’s?

Thanks TSG… I’m trying not to be dumb or lazy but I’m pretty green with electronics (as Andre will tell you!). I’ve got the SMR4+ schematic but I’d appreciate a description of the breadboard setup so I can avoid frying anything :slight_smile:

I’ve got breadboards, power, caps, resistors, etc. but I’m not yet very good at reading schematics. I’m learning (I hope) as I go!


Sorry I’m on the phone so I can’t draw a circuit for you. Does it help if I describe it?

Connect a crystal between the two XTAL pins. Then connect a 22p ceramic cap from each of the two crystal pins to GND.

Connect the two VCC pins to +5V. Connect the two ground pins to GND. Add a 100n ceramic capacitor between the two pins of both VCC-GND pairs.

Add a 10k resistor from the RESET pin to +5V.

For the ISP: you can copy the pin out from the voice cards schematic. Basically you need to connect GND, 5V, SCK, MOSI, MISO and RESET between the ISP pinheaded and the chip.

I hope that helps. Be sure to check that the programmer supplies the power. Otherwise you will need another 5V power source.

What you can also try: disconnect the voice card from the main board and just connect +5V and GND via jumper cables.
If you can now flash the firmware, you know that the problem is located on the mainboard. Else the problem is on (all of) your voice card(s).

Another note: In your first post you wrote that your Ambika was working until you put it in a case.
So it is very unlikely that the firmware is the problem at all. It is more likely that there is a bad solder connection somewhere (due to mechanical stress) or you shorted something while putting it in the case.

Ah I forgot that the ISP pins are also on the voice card pinheader. Maybe the corresponding pins on the main board are shorted. Good idea cj55!

Hmmm- have you power the ambika on and remove the SD-Ram card . ???
I had never problems , equal if i prog the 328 in the Ambika or separate . i think CJ55 had a good Idea . Remove one Card - ad ground an 5 Volt on it and try to flash it again . It must work -
There is simply the cristal , 2 Caps 18…22 pf and a 10 kohm - mothing more in the programmer !

I had an incredibly similar issue on one of my Ambikas.
While consolidating voice cards and adding some freshly built cards I noticed some indicator lights went out. I discovered that it was due to shunt jumpers failing to create continuity on the chip select headers.
The results of this seem to have been fatal to my microcontroller. I couldn’t communicate to it via ISP or by installing it directly into an Arduino Uno board.

I have now managed to re-program the errant voicecards - by connecting only headers containing the power, as suggested. For some reason, Atmel Studio wouldn’t VERIFY the chips once programmed (got an error about not recognising the ‘device context’) but the data lights are now back on.

Everything seems to be working as expected, but I haven’t been able to do a full test yet. The SD card is now reading correctly as well, so I’m assuming that is connected to the original issue.

Now I need to find the actual problem that caused the cards to lose their programming (or become locked and not initialise) in the first place. As advised above, it seems likely this is on the mobo and not a VC issue so I’ll have to run more tests to try and find a cold connection… this prob won’t be easy as it isn’t a full time issue.

Any tips on where to look to fit the symptoms are most defintely helpful!

Thanks for the time and input :slight_smile:


I think all voicecards, the SD card and the ISP connectors are coming together at the same pins on the motherboard. You should look there. I’m on the phone, so I can’t check but the schematic will tell you

Thanks, TSG - it looks like pins 1-8 of the 644P and the 74HC138N are the pinch points for those elements?

I’ll start there.


The labour of love continues :slight_smile:

Have just reprogrammed VCs #1 and #2 again… after reflowing all joints around the 644 and the 138N on the mobo. Still can’t reprog the VCs while they are fully connected - but this time I could at least verify them after I flashed them when connected to 5v power only.

Then I noticed this - I don’t think there was a Device #7 listed when I last looked at the setup screen for the cards?! Is this symptomatic of my problem, or did I just not spot it before?