Hello Moteino community!
I'm trying to bitbang my genuine moteinos using a FTDI232 programmer via the dedicated 6-pin header on the moteino's PCB.
All run smoothly for untouched moteinos but I played with some of them (bootloader section and fuses) using an USBASP (ISP) and since serial programming is KO (avrdude's "programmer is not responding" error). Fortunately, there are not lost and I can still do everything via ISP using my USBASP (load program, bootloader, change fuses).
Here is what I did:
- I loaded them with the DualOptiboot_V5.0_atmega328_BlinkD9.hex (https://github.com/LowPowerLab/DualOptiboot/blob/master/DualOptiboot_V5.0_atmega328_BlinkD9.hex) bootloader:
// Unlock the bootloader section
avrdude -c usbasp -p m328p -U lock:w:0x3f:m
// Flash the bootloader
avrdude -c usbasp -p m328p -U flash:w:DualOptiboot_V5.0_atmega328_BlinkD9.hex
// Lock the bootloader section
avrdude -c usbasp -p m328p -U lock:w:0x0f:m
- Then I checked flash hex dump to match the bootloader content:
// Dump flash
avrdude -c usbasp -p m328p -U flash:r:flash.bin:r
// Convert binary to Intel Hex, see https://pypi.python.org/pypi/IntelHex
bin2hex.py flash.bin flash.hex
- I also checked fuses are those expected, ie. LOCK:0x0F EXT:0x05 HIGH:0xDC LOW:0xDE
// Check fuses
avrdude -c usbasp -p m328p -U lock:r:/dev/stdout:h -U efuse:r:/dev/stdout:h -U hfuse:r:/dev/stdout:h -U lfuse:r:/dev/stdout:h
Moteinos from my point of view looks fine, I don't understand why I can't bitbang them anymore.
I read and understood Felix's post (https://lowpowerlab.com/forum/moteino/burning-optiboot-dualoptiboot-bootloader-(solved)/15/) about optiboot bootloader but I can't find a reason to my problem.
Do you have some idea hints of what the problem can come from?
Thanks in advance for your help!
Nicolas
Is the usbasp doing ISP or regular serial programming?
IOW how is this wired to the Moteino?
Hi Felix and thanks for your answer!
Actually, there is no problem with usbasp/ISP programming, only with FTDI/serial programming.
Anyway, I attached a photo of the ISP programmer (https://ibb.co/n0CG0F) I built + schematic (https://ibb.co/jN1WZa) with wiring between usbasp and moteino (design is based on information I gathered on this forum). I also attached a photo of FTDI232 adapter (https://ibb.co/hJopLF) connected to moteino via pogo pins. I use the first one to install bootloader + fuses and the latter to (re)program moteino when I want (firmware update or just repurpose it for another use case).
Note: as I read in the forum, you and other people often advice to buy a genuine Atmel programmer to do all kind of stuff on there uc without worrying about compatibility. So I just bought an AVR Dragon for 60 bucks, hoping it worth it!
(https://thumb.ibb.co/n0CG0F/IMG_1958.jpg) (https://ibb.co/n0CG0F)
(https://thumb.ibb.co/jN1WZa/programmer.png) (https://ibb.co/jN1WZa)
(https://thumb.ibb.co/hJopLF/IMG_1959.jpg) (https://ibb.co/hJopLF)
Just a thought, but what command line are you using with avrdude? (I presume you're trying to program by sending serial data over the FTDI cable to the bootloader on the Moteino). The reason I say this as you may have the wrong -c option which doesn't toggle the DTR to issue a reset. You should use the -c wiring option instead, that does toggle DTR (make sure you have the latest avrdude). This is how Arduino works, I'm assuming here the Moteino uses the same method.
Mark.
Hello Mark,
Thanks for you answer!
Quote from: perky on July 10, 2017, 09:00:22 PMJust a thought, but what command line are you using with avrdude?
Actually, I'v always used the Arduino IDE and/or platformio to program my moteinos. Both ran correctly until now.
But you're right, I will set verbose flags on both tools and see what kind of avrdude commands they run (actually I did not retried with arduino). Maybe it's just wrong avrdude configuration for the target I specified.
Quote from: perky on July 10, 2017, 09:00:22 PMThe reason I say this as you may have the wrong -c option which doesn't toggle the DTR to issue a reset
The -c option looks to be about programmer selection in avrdude's documentation, no?
$ avrdude -\?
Usage: avrdude [options]
Options:
...
-c <programmer> Specify programmer type.
Hello there,
Actually, I'v made some progress but still no resolution yet.
Since I got an avrdragon, bootloader and fuse programming behaves a better way: read/write fuses and flash via avrdude is far more stable and predictable than with my chinese USBAsp. It's worth the fifty bucks!
I ended with the following commands:
# Prepare the m328p fuses and unlock write on the bootloader section
$ avrdude -c dragon_isp -p m328p -e -U lock:w:0xFF:m -U efuse:w:0xFD:m -U hfuse:w:0xDC:m -U lfuse:w:0xDE:m
# Burn the bootloader taken from github.com/LowPowerLab/DualOptiboot and the re-lock the bootloader section
$ avrdude -c dragon_isp -p m328p -e -U flash:w:DualOptiboot_V5.0_atmega328_BlinkD9.hex -U lock:w:0xCF:m
# Read the entire flash as Intel Hex, including bootloader part at the end, to check everything is ok
$ avrdude -c dragon_isp -p m328p -U flash:r:flash.hex:i
But I still can't upload my programs with FTDI. I have a dummy led9 blink program that I built and upload using platformio (it uses avrdude underneath). Everytime I try to upload the hex file, a sync seems to occur between moteino and my FTDI programmer (led9 on moteino + FTDI programmer blinks several times together), but then, nothing happen and avrdude start complaining about "programmer not responding".
Here's what happen in details:
$ pio run -t upload
[Wed Jul 12 23:04:09 2017] Processing moteino (platform: atmelavr; board: moteino; framework: arduino)
--------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
Collected 28 compatible libraries
Looking for dependencies...
Project does not have dependencies
Looking for upload port...
Auto-detected: /dev/cu.usbserial-A4010T2I
Uploading .pioenvs/moteino/firmware.hex
# here, moteino + programmer both blink, then nothing, and few seconds after avrdude starts complaining
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
...
I will double-check platformio target configuration (which is default anyway) and also try to upload the program using Arduino IDE to understand what changed in the meantime. But moteino blinking tell me resolution is close!
Problem solved! ;D
Actually, this was the baud rate that was wrong: it was set to the default value 57600 bauds.
I just added the avrdude's -b option with 115200 bauds as value and everything started running like a charm!
Here is the avrdude command I now use to bitbang my moteinos:
avrdude -v -p m328p -b 115200 -P "/dev/cu.usbserial-A50285BI" -U flash:w:firmware.hex:i
If you use platformio (http://platformio.org/) as your development framework, just add upload_speed = 115200 to your platformio.ini (see upload_speed (http://docs.platformio.org/en/latest/projectconf/section_env_upload.html#upload-speed) documentation)
Note for future readers: this post (https://lowpowerlab.com/forum/moteino/burning-optiboot-dualoptiboot-bootloader-(solved)/) from this forum was very helpful and contains valuable information to better understand your Moteino (and the 328p)!
Thanks to Felix and others for their help :)
Nice! I'm curious as to how this is issuing a reset to the bootloader, unless you're somehow manually resetting it? The '-c wiring' option is supposed to toggle DTR .Yes you're right, it defines the programmer, and the programmer is a trivially simple serial one but with a DTR toggle. If you are having to manually reset, adding the -c wiring option might mean you don't have to (note you should use the avrdude.exe in the latest arduino IDE installation along with the latest .conf file as previous versions of avrdude do not have the -c wiring support).
Mark.