Unable to program brand new '328P chips

I do not know what speed the "-B1200" setting actually means (most probably the programming clock speed generated by the programmer in "bauds", this is not the speed of UART communication), but any higher speed does not work with my usbasp programmer with brand new chips (the chip is not recognised). After flashing the right fuses at that -B1200 speed, the chip gets recognised properly and I can flash him normally (I can confirm this procedure with atmega8, 32, 32L, 328p, 1284p).
You cannot switch the oscillators on the fly.. You may brick the chip when you deselect "Serial program downloading SPI" option - see the flags:

http://www.engbedded.com/fusecalc

PS: no warranty of any kind :astonished:

Ah, I misread you. I was using -b which is the serial comms baud rate.

-B is different:

-B Specify JTAG/STK500v2 bit clock period (us).

It is ignored on the ArduinoISP sketch, as it just uses SPI at Fosc/128.

If only I could slow that down... Well, I could replace all the SPI calls in the sketch with my own bit-banging routines I guess.

I see, you are using the arduino as the programmer for a new chip.. If the arduino is at 16MHz and SPI is /128 it could be too high (125KHz), sure. It would be better to go down to ~1kHz for the new chip fuses reflash.

Hmmm... A job for tomorrow then... write a slow bit-banging SPI library. Fun.

For example the usbasp programmer ($3.80 at ebay incl shipping costs) had a switch for "slow clock" setting specifically for programming chips set to a low fcpu (ie 1MHz). The newest driver has got the -Bxyz option for that, so I must not tackle the switch anymore..

Well, I think I have a bit-banging SPI implementation now, but it still doesn't work - exactly the same results, just slower.

This is my bitbanging code - if you someone could just make sure that it is doing what I hope it is - it should be the equivalent to SPI mode CHPA=0 and CPOL=0:

#define SPI_DELAY 10

uint8_t spi_send(uint8_t b) {
  uint8_t reply;
  uint8_t outgoing;
  uint8_t bits;
  pinMode(MOSI,OUTPUT);
  pinMode(MISO,INPUT);
  pinMode(SCK,OUTPUT);
  digitalWrite(SCK,LOW);
  reply = 0;
  outgoing = b;
  for(bits=0; bits<8; bits++)
  {
    digitalWrite(MOSI,outgoing&0b10000000?HIGH:LOW);
    outgoing = outgoing << 1;
    delay(SPI_DELAY);
    digitalWrite(SCK,HIGH);
    reply = reply << 1;
    reply |= digitalRead(MISO)==HIGH ? 1 : 0;
    delay(SPI_DELAY);
    digitalWrite(SCK,LOW);
  }
  return reply;
}

This is my bit-banged SPI code which works successfully programming various chips:

// bit banged SPI pins
const byte MSPIM_SCK = 4;  // port D bit 4
const byte MSPIM_SS  = 5;  // port D bit 5
const byte BB_MISO   = 6;  // port D bit 6
const byte BB_MOSI   = 7;  // port D bit 7

// for fast port access (Atmega328)
#define BB_MISO_PORT PIND
#define BB_MOSI_PORT PORTD
#define BB_SCK_PORT PORTD
const byte BB_SCK_BIT = 4;
const byte BB_MISO_BIT = 6;
const byte BB_MOSI_BIT = 7;

// control speed of programming
const byte BB_DELAY_MICROSECONDS = 4;

...


// Bit Banged SPI transfer
byte BB_SPITransfer (byte c)
{       
  byte bit;
   
  for (bit = 0; bit < 8; bit++) 
    {
    // write MOSI on falling edge of previous clock
    if (c & 0x80)
        BB_MOSI_PORT |= _BV (BB_MOSI_BIT);
    else
        BB_MOSI_PORT &= ~_BV (BB_MOSI_BIT);
    c <<= 1;
 
    // read MISO
    c |= (BB_MISO_PORT & _BV (BB_MISO_BIT)) != 0;
 
   // clock high
    BB_SCK_PORT |= _BV (BB_SCK_BIT);
 
    // delay between rise and fall of clock
    delayMicroseconds (BB_DELAY_MICROSECONDS);
 
    // clock low
    BB_SCK_PORT &= ~_BV (BB_SCK_BIT);
    }
   
  return c;
  }  // end of BB_SPITransfer

Nope, still no joy.

I see the SCK line clocking. I see the MOSI line sending data. There is nothing on the MISO line. It's like the chip is just sat on a park bench somewhere whistling a happy tune all by itself ignoring everything that's going on around it. In a world of its own.

Do you have:

  1. Xtal connected to the brand new 328p?
  2. Vcc connected?
  3. double check wirings..
  4. decoupling capacitors?
    p.

pito:
Do you have:

  1. Xtal connected to the brand new 328p?

Yes.

  1. Vcc connected?

Yes.

  1. double check wirings..

Yes.

  1. decoupling capacitors?

Yes.

As I say, it works perfectly with a '328P taken off another UNO board.

..the black-box situation ]:slight_smile:
PS: any news with multi-uart for retro?

..the black-box situation

If I rip all the pins off then I have one of those, yes :stuck_out_tongue:

I haven't touched retro for a while - kind of got behind with it. The multi-uart code I was working on didn't work too well - something strange with interrupts. The last time I tried running Retro on my setup it wouldn't boot :frowning: I need to get back on it sometime - at the moment my Eurocard Computer is running the Max32 bootloader so it's kind of like a glorified Arduino :slight_smile:

.."I haven't touched retro for a while.." There is a lot of news (ie spi, ethernet..) so maybe you might try to boot it again and join us - a lot of challenges there :wink:

pito:
I see, you are using the arduino as the programmer for a new chip.. If the arduino is at 16MHz and SPI is /128 it could be too high (125KHz), sure. It would be better to go down to ~1kHz for the new chip fuses reflash.

Factory-fresh chips should be running at 1MHz, so as long as the SPI clock is below 250kHz it ought to be ok.
You could always try using the clock pre-scaler, which can reduce the system clock by up to 256x. eg:

  CLKPR = (1<<CLKPCE); // enable clock divider
  CLKPR = (1<<CLKPS0); // divide f_cpu by 2

There's always the possibility the new chips are genuinely dead for some reason. A way of ruling out programming problems, albeit high-risk, would be to set the fuses of the working ATmega328p to their factory defaults and then try reprogramming it. Something like this:

avrdude -c arduino -p atmega328p -P COM4 -b 19200 -e -u -U efuse:w:0xff:m 
avrdude -c arduino -p atmega328p -P COM4 -b 19200 -e -u -U hfuse:w:0xd9:m
avrdude -c arduino -p atmega328p -P COM4 -b 19200 -e -u -U lfuse:w:0x62:m

(making sure to reset the clock-related fuses last)

majenko:

pito:
Do you have:

  1. Xtal connected to the brand new 328p?

Yes.

If the chip is using its internal clock, as it should be if it's brand new, there's no need to connect an external crystal. OTOH, having a crystal there shouldn't disturb SPI communications. Majenko, could you post a photo of your setup?

A way of ruling out programming problems, albeit high-risk, would be to set the fuses of the working ATmega328p to their factory defaults and then try reprogramming it.

No thanks :slight_smile:

I don't want to brick a good chip.

You could always try using the clock pre-scaler

I'll give that a go.

could you post a photo of your setup?

Sure, here it is. Decoupling caps and crystal load caps are all SMD on the reverse side.

I'm not familiar with that PCB - I assume it does all the power routing. The brown reset wire doesn't seem connected - is it connected on the underside of the PCB? Anyway you already said that it works with a chip pulled out of an Uno, so it must be ok.

The only thing I can think of left to try is Nick Gammon's board-detector sketch That would rule out any strange avrdude problems. He also suggests some breadboard layouts for different clock configurations, in case your chips are configured to use an external clock for some strange reason.

Nice program :slight_smile:

Yes, the brown wire is connected underneath the board. I am very well acquainted with these boards, since I designed them.

The board detector program detects a known good chip fine. With one of the new chips, it doesn't detect it at all.

Incidentally, the crystal is oscillating.

I am starting to lean towards these chips being DOA.

The only effect enabling the clock divider has is to halve the serial baud rate :frowning: Still not programming.

I will have to have a go at making one of those high voltage parallel programmer doohickeys and see if that can find the chip...

majenko:
The board detector program detects a known good chip fine. With one of the new chips, it doesn't detect it at all.

If my board detector is set up to detect a known good chip, and then you insert a "factory fresh" one and nothing happens, sounds like it might be dead. After all, I tested it on factory chips.

You could slow down the SPI in the board detector, but I haven't needed to do that yet.

Right. The guys at Farnell have kindly sent me a couple of new '328P chips. I'm about to see if they work.

I'll type as I do it so you can see exactly what I am doing. I haven't even opened the envelope with the chips in.

Right, first things first, on goes my trusty wrist strap. I'll put down the cat (put it on the floor that is, not take it to the vets), and stop rubbing my hair with this baloon, and grab me an Arduino.

Right, that's the Board Detector loaded, and the programming shield plugged in. Now to open the envelope...

The antistatic packaging is good - a bag and a tube...

Slide one chip out of the tube on to my wooden desk, grasp it by both ends (not the legs) and slot this bad boy in.

Plug in Ardy, open the serial monitor...

Atmega chip detector.

Just to test, grab second Ardy, pop the chip, slip that in to the programming shield, and voila - it works.

$^*("£()%