[SOLVED] Set Low Fuse Bit, Now Can't Program over ISP

dc42:
That should have been exactly the right thing to do. Try doing it again, but also reduce REQUIRED_FREQUENCY in case 1MHz is a little high, given that you have the resonator still connected and a 1.5K resistor in series with the clock signal. As the Arduino you are using to generate the clock is also 3.3V, I think you can also safely try it without the 1.5K series resistor. What you are looking for is a signal on CLKOUT at a reasonable frequency.

So what you're saying is that I should lower the REQUIRED_FREQUENCY to a number until CLKOUT starts showing a steady clock? Right now, at 1MHz, the analyzer doesn't detect anything on CLKOUT at that speed.

Yes, try that and/or try removing the 1.5K resistor. I'm guessing that turning the clock on/off in loop() is what is actually causing CLKOUT to toggle. Maybe the clock signal is not strong enough to drive XTAL1 @ 1MHz given that 1.5K is on the high side (I suggested 100 ohms originally) and the resonator is still connected. At a lower frequency, the resonator impedance should be higher, judging from the impedance plot in the datasheet, which will result in a stronger signal on XTAL1.

Do you have a signal generator? Try pushing through some low frequency like 128 KHz until CLKOUT mirrors it. Or just modify the sketch that outputs a clock to get the same result.

Can you isolate /RESET from the rest of the circuit? Or, put it another way, is /RESET connected to any other devices?

If safe, you should be able to use an AVR Dragon (around $50) in high-voltage programming mode to recover, if the chip isn't actually damaged. High-voltage mode requires around 12V on the /RESET pin, which is why it needs to be isolated from other things (chips).

dc42:

I set REQUIRED_FREQUENCY (128000) and connected the logic analyzer to CLKOUT.

When connecting the source to XTAL1 nothing happens to CLKOUT. But when connecting it to XTAL2 the attached screenshot is the output.

EDIT: When D9 is connected to XTAL2, I ran this command "avrdude -c avrispmkII -p m328p -P usb -B250" and also -B500 and it still failed to initialize.

Nick:

The reset pin is connected to VCC through a 10k resistor. Would this pose issues?

Also, will I be able to use the existing ICSP header to reprogram it?

Aakash:
The reset pin is connected to a 10k resistor connected to VCC. Would this pose issues?

You would need to cut or remove that. As you can imagine.

Aakash:
Also, will I be able to use the existing ICSP header to reprogram it?

No. There are about 20 jumpers you have to run from the programmer to the chip. You would need access to most of the pins on the Atmega328.

Unfortunately for me, the latter won't be possible. I'll probably just send it out tomorrow and just get the resonator/avr replaced.

For future reference, what fuses should I be using in order to make the atmega328p use the 8MHz resonator?

The Uno has 0xFF as the low fuse in the boards.txt file, and it uses a resonator. I would be tempted to leave it at that.

Aakash:
I set REQUIRED_FREQUENCY (128000) and connected the logic analyzer to CLKOUT.

When connecting the source to XTAL1 nothing happens to CLKOUT. But when connecting it to XTAL2 the attached screenshot is the output.

EDIT: When D9 is connected to XTAL2, I ran this command "avrdude -c avrispmkII -p m328p -P usb -B250" and it still failed to initialize.

Very strange on several counts:

  1. XTAL1 is the oscillator input, XTAL2 is the output. So it should be much easier to get a clock by injecting a signal into XTAL1 than into XTAL2. Are you sure you have nothing apart from the resonator connected to XTAL1? Is the 1.5K resistor still in place, or did you remove it?

  2. Your photo suggests that you have a 128KHz signal on CLKOUT. However, you have the CKDIV fuse in place, according to your earlier post. So the CLKOUT frequency should be 1/8 of the input clock frequency, not equal to it.

  3. With a 128KHz clock, you should be able to program the device via ICSP, as long as the high fuse byte hasn't been changed to disable ICSP programming.

Aakash:
For future reference, what fuses should I be using in order to make the atmega328p use the 8MHz resonator?

I use AVR® Fuse Calculator – The Engbedded Blog in conjunction with the data sheet to work out the fuse bytes. For an 8MHz resonator I use a low fuse byte of 0xEE.

I now understand why your resonator isn't oscillating. I was reading the CLKSEL bits the wrong way round. You have your clock fuses set to low-frequency crystal oscillator mode, which is intended for a 32768Hz watch crystal. This may also explain why XTAL1 and XTAL2 are not behaving as I expected.

So it might be worth trying an even lower clock frequency.

Nick, do you know what is the maximum -B parameter that avrdude works with? Maybe -B250 is too high?

Could be, I programmed using the low-speed 128 KHz oscillator with that, but not with divide-by-8 set.

I don't know what its limits are, maybe divide 250 by 8.

I was reading the CLKSEL bits the wrong way round.

It is incredibly confusing the way they do that. If you "tick" the box in the fuse calculator, it sets the fuse to 0 (programmed). I think the reason is the default for EEPROM is to be 1 bits, so you "program" them by "setting" them to zero.

So if you uncheck all the boxes on the low fuse side, you get a fuse setting of 0xFF.

I've just read the avrdude command line options and I'm not sure that -B has any effect for atmega328p ICSP because it appears to be releveant to JTAG only. I also found the following:

-i delay
For bitbang-type programmers, delay for approximately delay microseconds between each bit state change. If the host system is very fast, or the target runs off a slow clock (like a 32 kHz crystal, or the 128 kHz internal RC oscillator), this can become necessary to satisfy the requirement that the ISP clock frequency must not be higher than 1/4 of the CPU clock frequency. This is implemented as a spin-loop delay to allow even for very short delays. On Unix-style operating systems, the spin loop is initially calibrated against a system timer, so the number of microseconds might be rather realistic, assuming a constant system load while AVRDUDE is running. On Win32 operating systems, a preconfigured number of cycles per microsecond is assumed that might be off a bit for very fast or very slow machines.

So I suggest you try adding e.g. -i 100 or -i 500 or even more to the avrdude command line, while driving it with that 128kHz clock.

Interesting. I found the -B250 helped when I was testing, however your suggestion of the -i option may well work. I note it says "For bitbang-type programmers ...".

I think the AVR ISP programmer is a hardware programmer rather than a bitbang one, but it's worth trying.

If he's using AVRISP MkII then I agree, the -i option is unlikely to work. The AVRISP spec says that the SCLK frequency can go down to 50Hz, but maybe avrdude can't adjust it, or has limited range?

It might be better to use the AVR Studio interface instead, because that provides direct control of the frequency according to the manual at http://www.atmel.com/Images/avrispmkii_ug.pdf.

It's making more sense to me now:

  • with 128kHz applied to XTAL2 you are getting 16KHz on CLKOUT
  • so you need to program it with SCLK not exceeding 4KHz
  • so -B 250 is barely enough cycle time, if avrdude does use the -B parameter to set the SCLK rate of the AVRISPmkII

So try with 128KHz applied to XTAL2 again, but this time:

  • try avrdude with a -B parameter greater than 250
  • try using AVR Studio, with the SCLK frequency in the user interface set to 4KHz or even lower.

If that fails, try with 32768Hz or so applied to XTAL1 or XTAL2 (whatever gives you a clean CLKOUT signal) and use SCLK <= 1kHz in AVR Studio. The docs say you can't program the flash below 2KHz, but you can do a chip erase.

Aakash:
EDIT: When D9 is connected to XTAL2, I ran this command "avrdude -c avrispmkII -p m328p -P usb -B250" and also -B500 and it still failed to initialize.

This was the result?

avrdude: stk500v2_command(): command failed
avrdude: stk500v2_program_enable(): bad AVRISPmkII connection status: Unknown status 0x00
avrdude: initialization failed, rc=-1

I believe that error has nothing to do with how the target is clocked but is the programmer refusing the -B command (you may need a space between the -B and the value).

To get an extra slow SCK you may need to use something else for programming. Do you have an Arduino board?

I find the slow clock setting on a USBasp often does the trick whenever things get a bit stubborn. For $5 or so on ebay, I think one of these is a reasonable investment for anyone who does more than the most infrequent ICSP programming.

dc42:
It's making more sense to me now:

  • with 128kHz applied to XTAL2 you are getting 16KHz on CLKOUT
  • so you need to program it with SCLK not exceeding 4KHz
  • so -B 250 is barely enough cycle time, if avrdude does use the -B parameter to set the SCLK rate of the AVRISPmkII

So try with 128KHz applied to XTAL2 again, but this time:

  • try avrdude with a -B parameter greater than 250
  • try using AVR Studio, with the SCLK frequency in the user interface set to 4KHz or even lower.

If that fails, try with 32768Hz or so applied to XTAL1 or XTAL2 (whatever gives you a clean CLKOUT signal) and use SCLK <= 1kHz in AVR Studio. The docs say you can't program the flash below 2KHz, but you can do a chip erase.

Yep! That worked. I set the clock source (D9) from the Arduino to 128KHz and connected it to XTAL2. After that, I went into AVR Studio and set the rate to 4.209KHz (or something very close) and the connection was very unstable. Though, I was able to set the fuses back to factory state after trying to write them a few times. Now it's working without the external clock source!

I'll try to write the low fuse to use the resonator tomorrow, or sometime soon, but correctly this time :slight_smile:

Thanks a lot dc42, and all!

Good work dc42 for sticking with it. At least the OP doesn't have to replace his chip. :slight_smile:

Aakash:
Yep! That worked. I set the clock source (D9) from the Arduino to 128KHz and connected it to XTAL2. After that, I went into AVR Studio and set the rate to 4.209KHz (or something very close) and the connection was very unstable. Though, I was able to set the fuses back to factory state after trying to write them a few times. Now it's working without the external clock source!

I'm glad you got it working. 4.2KHz was a little too high, that might be why it was unstable. Anyway, you should be back to using the internal oscillator divided by 8 now.

You might want to try a fuse setting that leaves CLKOUT enabled, such as 0xAE or 0xBF instead of 0xEE or 0xFF. That way you can easily check with your logic analyser that the resonator is oscillating.