вторник, 20 января 2015 г.

Incorrectly flashed atmega328p back to life

Hi,

I'm new to microprocessor programming and all the related stuff (bootloaders, fuses, ISPs, etc.), so I faced a newbee issue.

Symptom:

I was trying to flash atmega328P with bootloader that will suport 8MHz internal clock (so that I don't need an external oscillator) and can be futher optimized in terms of power consumption. I did everything correctly in terms of wiring USBasp programmer (I was using the following instructable), but then unintentionally (I just knew that LilyPad bootloader would also work) I programmed LilyPad's bootloader which also means LilyPad's fuses, which also means (as I later discovered) usage of external oscillator (nice tool to decode fuses).

So, that brought me all the way to "Yikes invalid signature 000000" with usage of -F option in avrdude, or "avrdude: error: programm enable: target doesn't answer. 1" without it. Different "-B" options (-B250, -B5, etc.) didn't work for me. Chip is just completely silent.

And also "avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0xfc" when I try to talk to the MCU via Serial ports with help of FTDI chip. At least I could see that chip is not dead comletely, it's replying something. Probably abrakadabra and maybe it could be decoded by using a proper avrdude settings, but I tried different baud rates and other settings and nothing worked.

Cause:

MCU just expect an external clock source and just doing nothing without it.

Resolution:

Connect an oscillator. But what if you don't have a spare one? Do it like me:


This is a wireless NRF24L01 board and it has an oscillator on it, just connect board ground (yellow on the photo and PIN1 on this wireless board) to your MCU ground and oscillator lines (green and white) to PIN9 and PIN10 on your atmega328P.

This fixed everything for me, Chip is alive and I can see all fuses, so I was able to reprogram them.

Although it's a little bit ackward - because oscillator is 16Mhz and LilyPad bootloader expects 8Mhz.

Hopefully this post will save some time for someone who faced the same issue.

UPDATE:
Looks like this is only a one part of the puzzle, the other one is protocol issue which I also mentioned above, it is still present after a correct bootloader is flashed.

Apparently the issue is with not very accurate internal oscillator - it just doesn't work with high baud rates for programming. There is a very good and detailed explanation on how to fix this by re-compiling a bootloader to use slower upload speed, I do not have necessary tools to do that, so I do think I'm going to do that, I think for me it's OK to load firmware via the ISP


I was able to confirm that it's working and chip is perfoming properly using its internal oscillator. Then I can install a code that will programmaticaly set slower baud rate if I need to talk to the firmware onboard the atmega chip.

Комментариев нет:

Отправить комментарий