[solved] Custom ISP for ATMega328 initialization problem.

I wrote an custom ISP for Atmel 328. The ISP uses a DSP as a host since the ATMega 328 operates as a smart peripheral in my system. This lets the host processor update code without needing a special programmer or using the Arduino bootloader. The ATMega328 has an 8 MHz xtal and runs at 3.3V

I am using serial programming mode via SPI.

The programmer function is working very well and error free. It is also much faster than the ATMega328 based programmer I use in the Arduino IDE.

Everything works fine when I start with a preprogrammed device by using "Burn Programmer" in the IDE. This is only used to preprogram the fuses. The "programmer program" part is ignored.

The main reason this is important is that Atmel defaults to Clk/8 which is only 1 MHz.

Programming steps:

Step 1: Pull Reset High and wait 1 ms
Step 2: Pull Reset Low and wait 20 ms
Step 3: Issue Programming Enable Command

This is where things get ugly. If I examine the return in MISO I get FF FF FF FF when the part is factory fresh. It never returns 0x53 in the third byte as expected. If the part is preprogrammed, it works correctly.

So I figured maybe my SPI communications was too fast since the processor is running at 1/8 normal clock, so I slowed down the SPI clock by 1/8 and then even tried 1/16. My thought was that it should work. I could burn fuses and then start over with a new reset etc at a much faster SCK.

Slowing the SCK hasn't helped. This is why I am posting.

Any ideas?

Regards

Al

aclark:
This is where things get ugly. If I examine the return in MISO I get FF FF FF FF when the part is factory fresh. It never returns 0x53 in the third byte as expected. If the part is preprogrammed, it works correctly.

Remember that a Factory Fresh ATmega328p runs at 1 MHz using the internal 8 MHz RC clock and the CKDIV8 fuse which sets the clock prescale to 8. Because the clock rate is less than 12 MHz the low periods and high periods of the SCK pin have to be at least 2 CPU cycles each. That means 250 kHz is the fastest you can program a 1 MHz processor. For CPU clocks faster than 12 MHz the low and high half-cycles of SCK have to be at least 3 CPU cycles each.
You could speed things up by programming the fuses to turn off CKDIV8 to get the 8 MHz clock. Then you can re-start programming at 2 MHz.

Thx John.

I did think about this. I slowed the SCK down first by a factor of 8, then 16 from my 8 MHz setting.
I thought that SPI is now slow enough.

No joy. It didn't work.

My thought was to slow SPI, write the fuses, come out of reset again so that the fuses take effect and then program with the faster SPI. This would speed up programming.

On Monday, I think I will use a DSP to capture waveforms and compare.

I will post solution, if I solve it.

Al

aclark:
I did think about this. I slowed the SCK down first by a factor of 8, then 16 from my 8 MHz setting.
I thought that SPI is now slow enough.

8 MHz / 16 = 500 kHz. On a CPU clock of 1 MHz you have to slow down to 250 kHz (OR SLOWER). Each half cycle has to be at least two CPU cycles long.

I think this issue is now resolved although I am not sure exactly why it broke the first time,.

The SPI_CLK was set to 125kHz which is the same as the Arduino Programmer. I measured both to confirm.

The first command is 0xAC530000 (Programming Enable). On my blank devices, MISO returned 0XFFFFFFFF.

Differences:

The Arduino Programmer Pulls Reset Low for 20ms then High for 125uS, then resets again for 50ms to start the programming. Atmel stated that Reset Low for 20ms is sufficient.

My original program set Reset high for 1ms, then low for 20ms, then sent the programming enable command.

Revision to my programmer:

I modified the program to use the same double reset that the Ardunio programmer uses. I burn fuses which sets the clock to 8 MHz and then brings Reset high.

I reconfigure the SPI clock to 1MHz and go through the same reset process again. I then write the program. I also handshake using BSY/RDY instead of the brute force max delay method. This results in much faster programming time.

Al