avrdude for flashing the remote arduino (againt the local computer connected arduino running the flasher)

[benchuk]

Hi, I used the flasher precompiled from: https://github.com/nicolas-schurando/optiboot-nrf24l01-flasher
and still I was not able to make this work -I am not sure about the avrdude commands:
It seems when I try to set the eeprom address for the flasher – I am just overrding it or damagin it
using this:
avrdude -C “C:\Users\Ben\Downloads\avrdude\etc\avrdude.conf” -F -p atmega328p -P COM5 -c arduino -b 115200 -U eeprom:w:0x30,0x30,0x31,0x30,0x30,0x30:m

also I am not sure what it the right commad to run against the flasher – it also seems just to overwrite it:
I am using:
avrdude -C “C:\Users\Ben\Downloads\avrdude\etc\avrdude.conf” -V -p atmega328p -c stk500v1 -P COM5 -b 115200 -U flash:w:text.ino.standard.hex -vvvv

where :text.ino.standard.hex is exported from arduino IDE.
My flasher is on COM5 and the target is connected (and the flasher) to the RF modules.
tryied the traget on A0 and A1 pins and A1 and D10
still does not work
I think the problem is my avrdude commands….
Thanks.

[SergioUno]

Yes. avrdude is tricky bastard and can erase bootloader when you don't expect it. I hardcoded addresses, and it work now. You also can use dedicated sketch just to set up addresses. But don't upload it through SPI, use COM port, or your fresh bootloader will be erased.

[sextha]

Hi, guys. I have the same problem as @benchuk. When I run the command against the flasher to program the other arduino (the target one), I just get to overwrite the flasher with the .hex that was destinate to the other one, and any program is loaded on the other board connect via nRF24L01.

Please, @SergioUno can you give some other advice? The addresses seem to be written well in the flasher arduino's eeprom because I can see it on the monitor serial window of Arduino IDE. This appears:
SREG: 0x0000, MCUCR: 0x0000, our addr: 111
I could do this with avrdude commands without any error messages from avrdude.

Is it perhaps a problem with the configuration of fuses or upload.maximum_size or upload.maximum_data_size on boards.txt?
Maybe a problem during the creation of the bootloader .hex? Did you use Linux or Windows 10?
The .hex I could create, is 5 KB (4,67 KB exactly). Is it wrong?.

Please, I need some help with this issue.
Thank you

PD: My arduinos are both nano atmega328p

[SergioUno]

Hi @sextha
I use direct AVRDUDE comand against flasher, something like this:
avrdude -C “C:\Users\Ben\Downloads\avrdude\etc\avrdude.conf” -F -V -p atmega328p -c stk500v1 -P COM5 -b 115200 -U flash:w:text.ino.standard.hex
In this configuration AVRDUDE treats flasher as a programer. Don't forget -F key.
I use Win7.
.hex file contains some service information (I recommend google "Intel hex file structure"), so the actual data in .hex file is less. 5kb is ok.
I tested it with atmega328p.

[sextha]

Thanks for the help @SergioUno
I could test the command of avrdude but unsuccessfully. I connect directly by usb my pc to the arduino nano flasher like if I want to flash the arduino flasher. Is it neccesary a programmer between them?
Also I'm thinking about try to get a Windows 7 computer and try it there.
But I think the problem could be on the optiboot-nrd24l01 .hex creation with "make"
Is it normal to receive warning and errors about baudrate like "baud rate can not be checked"?
I use baudrate 57600 because it is the default baudrate for arduino nano atmega328p on boards.txt of arduino ide, and I forced this rate in the arguments on the "make" command. With 115200 I receive the errors and warnings too.
Something about fuses?
Perhaps about make-mingw32 that i installed on my windows (and adding to the path of cmd)??
Sorry for so much questions.
Thank you very much for your attention

[SergioUno]

I connect directly by usb my pc to the arduino nano flasher like if I want to flash the arduino flasher. - That is correct. Flasher kind of pretends to be a programmer for AVRDUDE. STK500 protocol is quite complex, you can see all commands and response if you add -v -v -v -v keys for AVRDUDE.

I'm thinking about try to get a Windows 7 computer - I doubt the problem related to the OS

• There are some warnings, that is Ok.
  Actually, I used this branch as a starting point https://github.com/nicolas-schurando/optiboot-nrf24l01 and then I modified it until it started to work.
  Baudrate on the bootloader side must be no more than 57600 if you use 8 MHz crystal or RC oscillator on a target. nRF connected by SPI, so the exact baudrate is not important until you keep it slow enough compared to the CPU clock. I use 8 MHz internal RC on my target.
  There can be some warnings about baudrate.
  Also check if omake.bat actually generate a new .hex file - did it?

[sextha]

Thanks again @SergioUno
Same situation.
-Yes, a new hex file is generated every make execution.
-I use 57600 baud rate. Both, the flasher and the program are arduino nano atmega328p so I am not using a high baud rate that could be problematic.
-I used https://github.com/nicolas-schurando/optiboot-nrf24l01 too but I didn't modified anything. Which changes did you do? Can you let me see those changes?
Thank you friend.

[SergioUno]

I hard coded addresses of nRF
I use AVRDUSESS as a shell for avrdude 6.1
Here is an example of parameters line which it generate
-c stk500v1 -p m328p -P usb -b 57600 -F -U flash:w:"C:\Users\USER\S\HEX files\R.hex":a
You can use the same, or just call avrdude from cmd.
This shouldn't erase firmware in Flasher. Is this your problem?
And reset target just before you press upload button on a programmer. Target must be in bootloader at this time. Also be sure that you use the same baudrate in flasher and in avrdude.

[sextha]

Thanks again @SergioUno
I continue at the same point, and yes, my problem is that the flasher is erased in every try to flash the target, and nothing happens on the board to be flashed.
Of course, I reset target more or less at the same time or a bit before I press upload button on the programmer, to be at the bootloader time.
The adresses were hard coded on optiboot.c (for the target) and on the sketch of the flasher some days ago.
I have checked baudrate on avrdude, optiboot on the target and also on the sketch of the flasher and on the boards.txt file.
There is no difference between avrdude or avrdudess.
The only difference I can see between my situation and yours is that I can't select "-P usb" on AVRDUDE. I need to select "-P COM8" or any other COMX because it doesn't detect arduino-nano-flasher connected by usb unless you choose COM8. That is the same on Arduino IDE.
I have no idea where could be the error: optiboot on the targer, sketch uploaded on the flasher or the interaction with avrdude or arduino ide...
Do you see any other problem?
thanks!

[benchuk]

@SergioUno The problem is that when using USB the USB driver rests the board, then the bootloader is reloading and when the bootloader sees data it just overwrites the current program (the flasher) instead of the flasher forwarding you data, to avoid this my solution was to add a 10μF capacitor between the arduino GND and RESET pins - this will prevent the board from resetting when flashing using avrdude or the arduino IDE, when you will want to update the flasher program just disconnect the capacitor or use the reset button with the right timing (reset then start the program upload - it takes some practice to get the timing right)

[benchuk]

you can ignore the led it is just for testing.

[benchuk]

@SergioUno btw instead of giving the avrdude the address on the command line of the remote and local I am doing this in the flasher program (the uploading new sketch every time a need to burn new station) currently this works better for me (using the eeprom lib:
local station address
EEPROM.write(0, 48);
EEPROM.write(1, 48);
EEPROM.write(2, 48);
remote
EEPROM.write(0, 48);
EEPROM.write(1, 48);
EEPROM.write(2, 49); // for example

[SergioUno]

@sextha I think I know why your flasher is being overwritten. I used standard optiboot on my flasher, and by default it works on 115200. Then I set up flasher program to use 57600.
When I start flaser, programmer reset board, and optiboot expect to see new firmware on 115200, and PC tries to send on 57600, so they don't hear each other. After 1 or 2 seconds optibot passes control to the main program, which is actual flasher. I suggest you remoove bootloader from flasher, it will work much faster as it won't be interrupted by a bootloader.

[sextha]

@benchuk I have tried with the capacitor between RESET and GND and it doesn't work. Even I tried changing capacitor's polarity (first negative stick on gnd and later on reset).
@SergioUno I have tried both of your ideas. First with optiboot at 115200 on the flasher and flasher program on 57600 and avrdude on 57600 and it didn't respond. It said that there aren't communication with stk500 programmer:
"avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00"
Erasing the chip (arduino with flasher program) to delete bootloader and not have it, and uploading only the flasher program; have the same unsuccessful result.
No having bootloader on the flasher arduino or having but with different baud rate, have the same result:
-With capacitor between GND and reset, it fails and a message about programmer not responding is received.
-Without capacitor, the flasher is flashed with the program expected to be flashed on the target

I going to tried with arduinos UNO instead of arduino nano in case of some nano's usb chip incompatibilities.

[sextha]

Some other questions:
You said me that some warnings about baudrate during bootloader generation wasn't bad, but using "make" command to create the optiboot_atmega328.hex it responds this:

C:\Program Files (x86)\Arduino\hardware\arduino\avr\bootloaders\optiboot-nrf24l01>make OS=windows ENV=arduino FORCE_WATCHDOG=1 RADIO_UART=1 SUPPORT_EEPROM=1 LED_DATA_FLASH=0 LED_START_FLASHES=0 BAUD_RATE=115200
process_begin: CreateProcess(NULL, sh baudcheck.tmp.sh, ...) failed.
make (e=2): El sistema no puede encontrar el archivo especificado.
Makefile:627: recipe for target 'baudcheck' failed
make: [baudcheck] Error 2 (ignored)
../../../../tools/avr/bin/avr-gcc -g -Wall -Os -fno-inline-small-functions -fno-split-wide-types -mmcu=atmega328p -DF_CPU=16000000L  -DRADIO_UART=1 -DBAUD_RATE=115200 -DLED_START_FLASHES=0 -DBIGBOOT=1  -DLED_DATA_FLASH=1   -DSUPPORT_EEPROM -DFORCE_WATCHDOG '-DVIRTUAL_BOOT'   -c -o optiboot.o optiboot.c
optiboot.c:264:2: warning: #warning BAUD_RATE error greater than -2% [-Wcpp]
 #warning BAUD_RATE error greater than -2%
  ^
optiboot.c:795:2: warning: #warning Make sure pin config matches hardware setup. [-Wcpp]
 #warning Make sure pin config matches hardware setup.
  ^
optiboot.c:796:2: warning: #warning Here CE = PIN9 (PORTB1) [-Wcpp]
 #warning Here CE  = PIN9  (PORTB1)
  ^
optiboot.c:797:2: warning: #warning Here CSN = PIN10 (PORTB2) [-Wcpp]
 #warning Here CSN = PIN10 (PORTB2)
  ^
optiboot.c:313:20: warning: 'flash_led' declared 'static' but never defined [-Wunused-function]
 static inline void flash_led(uint8_t);
                    ^
In file included from optiboot.c:806:0:
nrf24.h:217:16: warning: 'nrf24_rx_new_data' defined but not used [-Wunused-function]
 static uint8_t nrf24_rx_new_data(void) {
                ^
../../../../tools/avr/bin/avr-gcc -g -Wall -Os -fno-inline-small-functions -fno-split-wide-types -mmcu=atmega328p -DF_CPU=16000000L  -DRADIO_UART=1 -DBAUD_RATE=115200 -DLED_START_FLASHES=0 -DBIGBOOT=1  -DLED_DATA_FLASH=1   -DSUPPORT_EEPROM -DFORCE_WATCHDOG '-DVIRTUAL_BOOT' -Wl,--section-start=.text=0x7900 -Wl,--section-start=.version=0x7ffe -Wl,--relax -nostartfiles -nostdlib -o optiboot_atmega328.elf optiboot.o
../../../../tools/avr/bin/avr-size optiboot_atmega328.elf
   text    data     bss     dec     hex filename
   1654       2      70    1726     6be optiboot_atmega328.elf
../../../../tools/avr/bin/avr-objcopy -j .text -j .data -j .version --set-section-flags .version=alloc,load -O ihex optiboot_atmega328.elf optiboot_atmega328.hex
..\..\..\..\tools\avr\bin\avr-objdump -h -S optiboot_atmega328.elf > optiboot_atmega328.lst
rm optiboot.o optiboot_atmega328.elf

C:\Program Files (x86)\Arduino\hardware\arduino\avr\bootloaders\optiboot-nrf24l01>

Am I creating the optiboot hex file correctly?
PD: I have tried with 57600 baudrate too

[benchuk]

@SergioUno I am using the flasher from:
https://github.com/nicolas-schurando/optiboot-nrf24l01-flasher
BAUD_RATE is set in this file: https://github.com/nicolas-schurando/optiboot-nrf24l01-flasher/blob/master/uart.ino
when flashing to a remote station I am using avrdude with this bad rate.... (and the capacitor)
if you still get warning that could be ok - because the remote station is not respoding
that could be for many reason (remote station is too far or not working or rf timing are bad)
to make sure the local station is working ok and trying to forward the packets to the remote arduino
I added to the code on the above project (https://github.com/nicolas-schurando/optiboot-nrf24l01-flasher) so led blinking to see if the code is runinig and that I am getting to the right place and that the local sation is trying to tx the packtes. attached is a modified version of the flasher with led on pin 7 and baud rate of 57600 if i am correct...
optiboot-nrf24l01-flasher.zip