Unable to program brand new '328P chips

[nikone]

for program the chip you use terminal or arduino ide?
hi niko

[majenko]

for program the chip you use terminal or arduino ide?
hi niko

Either.  They both give the same result.

[pito]

I have to use ie -B 1200 for programming new chip's fuses to the external crystal mode (they are set to 1MHz internal clock and therefore very slow programming clock), otherwise no luck.. (and not only the 328p, but all atmega chips I would say).. Only flash new fuses with that speed (I am using usbasp programmer), it takes few seconds. Do not use it with flash programming as it takes ages then  
p.

[majenko]

Ooooh... worth a try...

[majenko]

Hmmm... No go...

If I change the avrdude command's baud rate, then it can't communicate with the ArduinoISP sketch as that runs at 19200.  If I change the ArduinoISP sketch to match, then it is exactly the same as before.

However, you might be on to something anyway.  I will look at slowing down the ArduinoISP's communication with the chip if it's possible.

----

It's already running at F_osc/128, so that's the slowest it will go.  Hmmm...  tricky...

Is it possible to switch oscillators on the fly on an Atmel chip?  If I could switch my running Arduino to a lower speed it might compensate.  I don't want to brick this good chip by playing with fuses though.

[nickgammon]

I programmed a "fresh" chip as described here:

http://www.gammon.com.au/forum/?id=11635

[pito]

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  

[majenko]

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

-B is different:

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

It is ignored on the ArduinoISP sketch, as it just uses SPI at F_osc/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.

[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.

[majenko]

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

[pito]

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..

[majenko]

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:

Code: [Select]


#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;
}


[nickgammon]

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

Code: [Select]


// 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


[majenko]

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.

[pito]

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