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

benchuk commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

you can ignore the led it is just for testing.

benchuk commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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

benchuk commented 6 years ago

the blink code is remarked by the way

sextha commented 6 years ago

@benchuk Thanks for a so fast answer. Yes I'm using flasher from: https://github.com/nicolas-schurando/optiboot-nrf24l01-flasher too. I will try your modified version of the flasher with led on pin 7 and baud rate 115200 (not 57600, I have see it on uart.ino in your modified version). Also I could see how you write in the eeprom local station address on the modified version. I do it in a different way. At the momment I am hardcoding remote station address on optiboot.c of https://github.com/nicolas-schurando/optiboot-nrf24l01 changing this:

 addr[0] = eeprom_read(0);
 addr[1] = eeprom_read(1);
 addr[2] = eeprom_read(2);

to this other:

addr[0] = 0x30;
addr[1] = 0x30;
addr[2] = 0x30;

before do "make" command with options SUPPORT_EEPROM=1 RADIO_UART=1 FORCE_WATCHDOG=1 LED_START_FLASHES=0 LED_DATA_FLASH=0 BAUD_RATE=115200.

Do you hardcode the address on remote station on optiboot.c or with a sketch uploaded before wireless flashing?? Thank you so much

benchuk commented 6 years ago

@SergioUno With a sketch uploaded before wireless flashing where the sketch is writing it's own address to the eeprom on setup like you saw on the flasher sketch. for me the avrdude set address did not work (I probably used a wrong command line - but never had the time to debug that). Note it takes some time to make it work - you might need to restart the remote station manually to get the timing right (reboot when you see the - "avrdude.exe: stk500_recv(): programmer is not responding" - error message on the local station)

sextha commented 6 years ago

@benchuk It continues not working. With your edited version of the flasher and led on pin 7, the flasher tries to connect to the remote station for programm: led 7 is blink on every try (10 times in total). So I think problem is on the other side. I have the arduino with a sketch that writes its address in EEPROM on setup and on the loop, blinks built-in led every 100 ms. And optiboot-nrf24l01 burned on it. I try to program it over the air with blink example (blinking every 1000ms, so I could know if it has been program correctly). Could you send me your optiboot_atmega328.hex? Probably it isn't creating itself well. I need it for atmega328 and FORCE_WATCHDOG=1, RADIO_UART=1, SUPPORT_EEPROM=1 and LED_START_FLASHES=0 like readme file indicates Thank you!

benchuk commented 6 years ago

@SergioUno please try this one - hopes it is the right one... optiboot_atmega328.zip

sextha commented 6 years ago

@benchuk that file is generated by yours or have you sent me the file contained in optiboot-nrf24l01 project? I have checked their content and they are the same... And it doesn't work. About writing addresses on the eeprom, I have been able to find that for a correct eeprom writing to set the address the correct comand in avrdude is (and also to read/write fuses): avrdude -p atmega328p -P COM7 -c arduino -b 19200 -U eeprom:w:<data you want to write in eeprom>:m You can also use -c stk500v1. The most important is to have connected the arduino through the programmer and set 19200 as baud rate because stk500 works at this speed.

So after all this, I think: -code on flasher is ok (is the same you used) and connections and capacitor too. -I don't know if I am generating correctly optiboot hex file because mine is bigger than yours and than the attached on the original optiboot-nrf24l01 project. I have used yours that is ok, and it continues not working. -Problem with high fuse on arduino UNO and arduino nano to indicate bootloader size?? -It seems no problem with baudrate (115200 on bootloaders and sketcks).

Any idea about optiboot bootloader with nrf24l01 support and the hex file?? Thank you for your help!!!

PD: I have edit the post deleting what i wrote about eeprom and fuse writing and putting how i solved the problem

sextha commented 6 years ago

Congratulations!! I have been able to make it works. With the command I said in previous post I have been able to set address in eeprom and set fuses. Also I have burnt my own-generated optiboot-nrf24l01 with avrdude and the same command. The fuses are: HFuse: 0xDA LFuse: 0xFF EFuse: 0xFD. HFuse is 0xDA and not 0xDE because my optiboot needs 2 KB space.

So, after all I think that the result is that bootloader, eeprom and fuses better being loaded with avrdude, a programmer and 19200 baud. And flashing over the air better with avrdude. Arduino IDE doesn't work well in all this stuff.

Next days, I tried to add this to the original project (nicholas-schurando version)

benchuk commented 6 years ago

Great job!!!! I am not too great with fushes and what they do, why do you think it is related? Bud rate seems to me like a parameter with importance. Also using eeprom command from avrdude or from sketch is probably the same. BTW I am always using avrdude and never the IDE upload

benchuk commented 6 years ago

These are my avrdude commands : avrdude -C "C:\Users\Ben\Downloads\avrdude\etc\avrdude.conf" -b 19200 -c usbtiny -p m328p -v -e -U efuse:w:0xFD:m -U hfuse:w:0xDA:m -U lfuse:w:0xFF:m -F

avrdude -C "C:\Users\Ben\Downloads\avrdude\etc\avrdude.conf" -b 19200 -c usbtiny -p m328p -v -e -U flash:w:optiboot_atmega328_without_watchdog.hex -U lock:w:0x0F:m

I think it really did not work for me.as well without the DA fush but I am not sure why

benchuk commented 6 years ago

Btw what is your project? I am building an home automation project if by mistake your are toomaybe we can combine efforts, in any case Iam goining to upload all my code for the project to github as open source. In home automation OTA is a very important feature Also note that there.is a next setp, the rf24 lib that the boot loader uses do not allow for the sketch that uses that bootloader (the code that the bootloader will call to run) to use any rf24 lib. I am using modifed version of the MIRF lib that is modified to the same rf24 channels and other configuration (some registers of the rf24) that made both work, the boot loader on otA mode and the running code that also using the rf24

sextha commented 6 years ago

@benchuk Hi!! Thank you for your words and sorry for answering so late.

I am not to great with fushes and what they do, why do you think it is related? Fuses are very important when you make changes on bootloader, clock frequencies, etc. You can read about this here, it is very well explained http://www.martyncurrey.com/arduino-atmega-328p-fuse-settings/

Bud rate seems to me like a parameter with importance. Of course. It is the speed used in SPI, so it is the speed which data is received by nrf24l01 and written in flash.

Also using eeprom command from avrdude or from sketch is probably the same. Yes.

_These are my avrdude commands : avrdude -C "C:\Users\Ben\Downloads\avrdude\etc\avrdude.conf" -b 19200 -c usbtiny -p m328p -v -e -U efuse:w:0xFD:m -U hfuse:w:0xDA:m -U lfuse:w:0xFF:m -F

avrdude -C "C:\Users\Ben\Downloads\avrdude\etc\avrdude.conf" -b 19200 -c usbtiny -p m328p -v -e -U flash:w:optiboot_atmega328_without_watchdog.hex -U lock:w:0x0F:m

I think it really did not work for me.as well without the DA fush but I am not sure why_ Try to not use -e, and stk500 (or others program protocols) instead of usbtiny. Fuses value are different depending on the size of your bootloader and the model of your arduino board although you uses the same atmega328p too. Read the link about fuses I have tell you.

Btw what is your project? Mine is an academic project. It is pretty big and we are some people working on it at the same time. Everyone in a different part. But not domotic, they are devices that need to be programmed without wires to get more convenience, because we are interested in not to have external connections. Arduino boards are inside of the devices.

the rf24 lib that the boot loader uses do not allow for the sketch that uses that bootloader (the code that the bootloader will call to run) to use any rf24 lib. I am using modifed version of the MIRF lib that is modified to the same rf24 channels and other configuration (some registers of the rf24) that made both work, the boot loader on otA mode and the running code that also using the rf24 OK, I have no idea about this. I will think about that when I need continue in that way.

benchuk commented 6 years ago

@sextha Cool thanks 😃 Following our chat here I have made a small tutorial to help other people on the future You can check it out if you like https://youtu.be/8xJqVeZkEw8 It comes with a blog https://www.2bitornot2bit.com/home/arduino-bootloader-with-ota-over-the-air-support-over-rf24

benchuk commented 6 years ago

@sextha have you changed the baud rate on the programs as well (bootloader or flahser)? or only on the avrdude command line?

sextha commented 6 years ago

@benchuk Flasher and bootloader, both on 115200. Avrdude command line also on 115200 when flashing over-the-air. Avrdude command line on 19200 when setting net address on remote's or adapter's eeprom. PD: Interesting blog and good tutorial. Awesome!

tuanpi commented 6 years ago

Hi Your OTA support over RF24 is very interesting. I'am trying OTA by following your path in https://www.2bitornot2bit.com/blog/arduino-bootloader-with-ota-over-the-air-support-over-nrf24l01 but without success.

I use 2 Arduino Uno to transmit (Arduino local station) and receive (Arduino remote station). CE -> PIN9, CSN -> PIN10, capacitor like instructions.

Arduino remote station: I burn bootloader "optiboot_atmega328.hex" from https://github.com/nicolas-schurando/optiboot-nrf24l01/tree/master/avr/bootloaders/optiboot-nrf24l01 I use two command in cmd win10:

C:\Program Files (x86)\Arduino\hardware\tools\avr\bin>avrdude -C "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf" -b 19200 -c arduino -p m328p -cstk500v1 -PCOM3 -v -U efuse:w:0xFD:m -U hfuse:w:0xDA:m -U lfuse:w:0xFF:m -F

C:\Program Files (x86)\Arduino\hardware\tools\avr\bin>avrdude -C "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf" -b 19200 -c arduino -p m328p -cstk500v1 -PCOM3 -v -U flash:w:C:\Users\TRANPH~1\Downloads\optiboot_atmega328.hex -U lock:w:0x0F:m

It was reported as ok

Arduino local station: I upload "optiboot-nrf24l01-flasher.ino" from https://github.com/nicolas-schurando/optiboot-nrf24l01-flasher after that I upload blink_led to Arduino remote station by command:

C:\Program Files (x86)\Arduino\hardware\tools\avr\bin>avrdude -C "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf" -b 19200 -c arduino -p m328p -cstk500v1 -PCOM4 -v -U flash:w:C:\Users\TRANPH~1\AppData\Local\Temp\arduino_build_920680/BlinkWithoutDelay.ino.hex

But I always get the message: avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x1e avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x66 avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x98 avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x66 avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x60 avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x7e avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x86 avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x7e avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00 avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x18

and nothing happened.

Please tell me where is my fault. Thank u so much

benchuk commented 6 years ago

you have to make sure that the other station is in range and is able to recive data - also make sure as a test that you only have rf24 on SPI and nothing else attached to the arduion station (just as test - as I had issues with interfecing with other components in parallel to the rf24) you ca try this command to upload the sketch remotly avrdude -C <you config file>-v -patmega328p -c arduino -PCOM5 -b115200 -D -U flash:w:firmware.hex works for me also I would recommand you to use https://platformio.org/ with vscode https://code.visualstudio.com/ I have a project setup with multiple arduion projects all in one worksapce and a lib of scripts uploading to remote sation - you can checkout the scripts folder for more info: https://github.com/benchuk/SmartHomeDIY

balrog-kun / optiboot

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