jeelabs / esp-link

esp8266 wifi-serial bridge, outbound TCP, and arduino/AVR/LPC/NXP programmer
Other
2.86k stars 727 forks source link

Atmega 328pb flashing fails #439

Open toammann opened 5 years ago

toammann commented 5 years ago

Hi, i tried to flash a Atmega328pb. The MCU runs at 12MHz. I used the MiniCore opiboot Botloader at 56700 Baud. The upload to the MCU in the Arduino IDE with a FTDI USB-Serial-Converter works as expected (I checked the fuses and I think everything is right).

Unfortuneately I can not upload a hex file to the microcontroller via esp-link. Uploading via HTTP-Post (./avrflash) fails with the errormessage: "Error checking sync: Bad programmer signature: 0x1e 0x95 0x16". The 328pb is not supported by the bulitn programmer?

I tried avrdude via port 23 and 2323 with several Baudrates of the optiboot booloader. Sometimes the flash succeeded but most of the time i got a timeout error:

avrdude -Cavrdude.conf -v -patmega328pb -carduino -Pnet:192.168.178.47:2323 -b57600 -D -Uflash:w:Blink.ino.hex:i

avrdude: Version 6.3, compiled on Feb 17 2016 at 09:25:53 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch

     System wide configuration file is "avrdude.conf"

     Using Port                    : net:192.168.178.47:23
     Using Programmer              : arduino
     Overriding Baud Rate          : 57600

avrdude: ser_drain(): read error: Falscher Parameter.

avrdude: ser_drain(): read error: Falscher Parameter.

avrdude: ser_drain(): read error: Falscher Parameter.

avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x56 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x56 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x56 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x56 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x56 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x56 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x56

The evaluation Board i am using is the following. https://www.pololu.com/category/239/a-star-328pb-micro

Is there anything else i can try? Many Thanks!

Blimpyway commented 5 years ago

First, if avrdude can flash the uC using ftdi adapter then is not a problem with recognising the avr's device signature and is a communication and/or synchronisation problem. There is nothing in esp-link which does the flashing, esp-link is just a tcp/ip serial port extender for avrdude or whatever program needs to use that link.

One mistake I've made when I tried to flash arduino via esp-link was to have a client/webpage in a different window still communicating with esp-link + arduino which of course disrupts the avrdude's flashing which is happening on the same serial device.

Another possible issue is you do not have proper reset line connected between esp-link and arduino. In order to enter boot loader arduino has to be reset just before the flashing. On ftdi or direct serial link, avrdude uses DTR line to reset arduino, in a tcp/ip connection there are tx/rx only virtual lines. That's what 2323 port is used for - whenever somebody opens port 2323 on esp-link, esp-link resets the arduino.
If you try to flash using port 23 you have to reset arduino manually.

And last important thing is the baudrate. TCP-IP socket connection has no way to configure a baudrate. Whatever baudrate you use when you flash the uC directly with a ftdi (or any usb-serial) adapter, the same baudrate (parity, stop bits, etc..) has to be set in esp-link's configuration web page. That's where you have to set the baudrate between esp and arduino. Avrdude can not do it.

A slightly inconvenient consequence is if your application program needs a different baudrate you have to change it in esp-link web gui before and after each flashing.

PS when I said "there is nothing in esp-link which does the flashing" I was referring to avrdude flashing remotely using tcp/ip, not the http/internal esp-link flasher method using avrflash script.

toammann commented 5 years ago

Hi, many thanks for your reply. There were some information i did not know so far.

have a client/webpage in a different window still communicating with esp-link + arduino

That´s a good hint. I made sure to close all other data connections to esplink. Still no luck

not have proper reset line connected between esp-link and arduino

The reset conneciton should be fine. I can see the MCU reboot if i start the avrdude command (optiboot lights up the debug led 3x). I can also verify the reboot by hitting the "Reset uc" button (the led flashes)

I made sure to select the correct Baudrate in esp-link. One thing i noticed is that the programming workes for first time afther the bootloader was burned on the Flasy memory of the microcontroller (so there is only the bootloader on it). The MCU is reboot all the time (again debug led is blinking three times). In this configuration the avrdude flash over esp-link works.

I think something must be corrcupted with the timing of the reset pulse. I tried both: Direct connection of the esp-link reset pin (gpio0) and the "arduino like" connection over DTR and a 100nF Capacitor

toammann commented 5 years ago

A Ardunino nano with 8MHz crystal works with avrflash and avrdude with the same hardware setup :/

Blimpyway commented 5 years ago

I tested esp-link flashing of 16Mhz crystal pro mini clones with registers configured to run at 8MHz internal oscillator. I needed the lower frequency for 3.3V operation but crystal 8Mhz pro minis are quite rare. I had to use the optiboot bootloader instead of the originals.

The point is - does 8MHz internal oscillator suits you?

Blimpyway commented 5 years ago

Aand one last thing I had to do to prevent esp-link interfering my pc based program talking with arduino is I had to disable esp-link's debugging messages. But if they do not screw flashing the nano I assume the settings are right.

toammann commented 5 years ago

The arduino nano ist a 328p. So it is a different microcontroller (not the 328p, just mentioning for clarity) I also tried the 328pb with the internal 8MHz LC oscillator, again using the optiboot bootloader compiled by MiniCore for 8MHz. Still no success.

I found a workaround which works for me. If I press the "Reset Microcontroller Button" on the esp-link webinterface several times randomly during the avrdude attempts the flashing starts after several tries. So this is not nice but it works for me now.

I am still thinking it is a timing issue between the reset of the MCU and the UART commands. Maybe I will check if the timings of esp-link are diffrent from the FTDI-Device some day.

blkqi commented 5 years ago

Not a solution, but I ran into the same thing and ultimately switched to avr-link for flashing the uC.

toammann commented 5 years ago

Hi, thanks for your comment. I am not satisfied with this "workaround" eigther. In the newer esp-link release is a linux bash skript for avr devices included (avrflash). Similar to megaflash.

There is one issue in the issue list where the "sync problems" are discuessed with some atmega device. The solution turned out to be the megaflash skript which (i think) was written due to the sync problems.

I tried both the avrflash.sh and your suggested solution using avr-link. I had no success with the two. But the error message changed (it is the same on both tools).

No response in state init(0)

error

blkqi commented 5 years ago

This new symptom looks definitely like a new issue. I would make positive that you are picking up from where you left off.

uzi18 commented 5 years ago

It is possible, minicore was not tested before, need to find time to check this

staviq commented 3 years ago

I can confirm that after a lot of debugging i came to the conclusion that esp-link flashing is not compatible with minicore.

After i swapped my quartz to 16M and reflashed bootloader to a stock arduino nano, everything suddenly started working.

uzi18 commented 3 years ago

Need to check bootloader compatibility but noone said they are

staviq commented 3 years ago

noone said they are

That is totally understandable, just saying in case anybody else finds this in the future.

Would be really nice if it worked tho :)

uzi18 commented 3 years ago

Have done some tests with optiboot used there, but only with mega board and with some stoppers, maybe have somewhere needed changes