Electronic – AVR unable to enter programming mode

avrcrystalfuse-bitsmicrocontrolleroscillator

I have an ATMega88PB on a PCB which won't enter programming mode after changing the fuse settings to EXTFSXTAL_16KCK_14CK_0MS. Prior to this, the AVRISP MkII was able to communicate with the microcontroller (I've since switched to an Atmel ICE which still isn't able to communicate).

In case there are any doubts that I have changed other fuse settings incorrectly, here is a screenshot of the fuses prior to programming.

I find this confusing because the oscillator appears to be running fine – if I had programmed the incorrect fuse setting (e.g. ext clk) then I would expect the oscillator to be disabled to save power. As you can see this isn't the case, with the oscillator running just slightly under 20MHz.

XTAL2 waveform:

XTAL1 waveform:

Here is the schematic for the oscillator circuit:

I've tried programming the device at every available speed and still haven't had any luck. I also tried feeding in a clock signal from a working AVR's CLK0 pin unsuccessfully, and have tried 18pF load capacitors in place of the 33pF indicated in the schematic.

What else can I try to get this microcontroller running again?

Best Answer

Your low fuse register is 0xD7. That equals 0b1101 0111 in binary.

Looking at the data sheet the lower 4 bits are responsible for the clock. This correlates to

CKSEL3 = 0, CKSEL2 = 1, CKSEL1 = 1, CKSEL0 = 1.

From the data sheet this is not a valid setting, but it may be set to a low frequency crystal. The two similar valid settings are 0b0100 and 0b0101, they are both for a low frequency oscillator. Try replacing the 20MHz crystal with a 32.768kHz crystal.

An expected frequency and actual frequency mismatch may result in the processor not starting.

If that does not work, you may have to use parallel programming to recover the chip. Parallel programming does not require a working crystal and provides a clock externally.

Here is a screen capture of the data sheet.

Related Solutions

Electronic – AVR self-programming

well... you can always execute a software initiated reset ala exploitation of the watchdog timer... and put data in eeprom to communicate to your bootloader code as to what you wanted it to do...

http://www.cs.mun.ca/~paul/cs4723/material/atmel/avr-libc-user-manual-1.6.5/FAQ.html#faq_softreset

Looking at page 272 of the ATMega168 manual (section 6: Entering the Boot Loader Program), the first line states:

Entering the Boot Loader takes place by a jump or call from the application program. This may be initiated by a trigger such as a command received via USART, or SPI interface.

So it would seem to me that definitively you can and must be able to call the bootloader functions from application code. As long as you are executing code that resides in the Boot Loader section of memory, SPM instructions can be executed, and therefore you should be able to self-program any time your application program jumps into the boot loader code.

Electronic – Using avr-gcc _delay_ms causes chip to freeze

I suspect the problem is not with your C code but with your Makefile.

The following lines in your Makefile produce an example.o object file.

main:
    avr-gcc -g -Os -Wall -mmcu=atmega328 -c ../src/example.c

The created .o file only contains the symbols and code from example.c, not the additional source required to actually make it run on a target system such as interrupt vector jump tables and code to initialise the BSS RAM segment to zeros, and load your initialised data sections.

You'll need to add an additional line something like this to run the linker and produce an output object suitable for download to the AVR part. Alternatively, use avr-ld, but you'll have to work out all the required linker options.

main.elf: example.o
    avr-gcc example.o -o main.elf

You can use avr-objdump --disassemble-all <filename> on both example.o and main.elf yourself to verify the different content of each file.

It's always a good idea to try to reduce your problem in steps to the most simple example possible. In this case, it would probably mean dropping into the AVR Studio software and creating a project running on the simulator using their managed build process. From there, you could them export the Makefile in use by their build process by using the 'Export Makefile' menu option. The generated makefile could then be compared with your version.

Actually, it's probably a good idea to use a Makefile similar to the one generated by AVR Studio because it has the correct rules already defined, you just have to set up some variables with regard to which objects need to be generated and the final target file name.

Best Answer

Related Solutions

Electronic – AVR self-programming

Electronic – Using avr-gcc _delay_ms causes chip to freeze

Related Topic