1
\$\begingroup\$

I've have already used Arduino as ISP Programmer to load codes to Atmel chips like ATmega328p and ATmega8 quite a few times without any problem.

On my last project though, I decided to use an Atmel ATtiny1634 microcontroller with QFN package instead of the bigger chips I used before. The soldering was ok, and the board has an ICSP header (MOSI, MISO,...) for the connection with the Arduino to program the chip.

I loaded the ISP Programmer sketch into the Arduino and connected it to the board. I use avrdude in Cmd Prompt for setting fuses and loading the code, so I wrote the following line to check if the communication was ok:

enter image description here

The device signature was correctly readed and so were its fuses. According to the datasheet information, I had to change lfuse to 0xFF because I am using External Crystal Oscillator >8MHz, so I wrote the next line for changing the lfuse:

enter image description here

Apparently the lfuse change was successful because at the end it reads "Fuses OK (E:FF, H:DF, L:FF), as it should. Then I wrote the same line I did at first to check if everything went ok, but that's what I got:

enter image description here

The programmer (Arduino) simply cannot read the chip anymore, as it gets 0x000000 invalid signature.

I wonder if there is any issue with the lfuse I sent to the device (0xFF) and also if there is any way to maybe reset the chip or reestablish connection to find out what happened.

The circuit of the microcontroller is down bellow, with the ICSP header, Crystal Oscillator, Power and the other I/O connections of the project:

enter image description here

Thanks in advance for any help!

UPTADE

As @Kevin White corrected, I expressed myself badly when I said External Crystal Oscillator. I saw on the datasheet it has the option of External Clock Source and Crystal Oscillator or Ceramic Resonator.

According to the CKSEL and the lfuse tables, the proper fuse value for Crystal Oscillator >8MHz is 0xFF:

enter image description here


enter image description here

Is that right or am I misinterpreting those tables?

SOLVED

Yes, I was misinterpreting those tables. Beyond the table about the clock frequency range, there is another table that relates the CKSEL bits with the SUT bit of lfuse. By setting lfuse to 0xFF I was selecting SUT=1, which sets the external ceramic oscillator, and not the external crystal. The correct lfuse value for my situation is 0xED. I'm stating to get familiar with the datasheet and its "hidden" information.

\$\endgroup\$
  • \$\begingroup\$ You may need to inject a clock if that on the boards is not working, additionally if there is default clock division you may need an ISP modified for an ultra low ISP clock, check Arduino circles as people make that mistake there from time to time. \$\endgroup\$ – Chris Stratton Dec 9 '19 at 1:27
2
\$\begingroup\$

You are not using an external "Crystal Oscillator", you have an external crystal.

An external oscillator is an active device that produces a signal by itself, a crystal (or a resonator) is a passive component that is a resonant element to control the frequency of the oscillator internal to the AVR.

This is a fairly common error that people make that is not helped by the nomenclature Atmel/Microchip uses.

The solution to "unbrick" the device is to provide an external clock to the controller X1 pin to allow the fuses to be reprogrammed with the correct value.

There are many ways to provide the clock and even an Arduino can do it as a wide range of clock speeds are acceptable provided it is at least 4x the speed at which the programmer operates.

Here are a couple of links to help you on your way:

Recovering a bricked AVR Unbrick bricked AVRs

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.