Burn Bootloader

[billlask]

Firstly Thank you for your project

I want to ask you in we can make something similar for burn boostloader from arduino ide.

Thank you

[tchilton]

Hi billask,

The project is really aimed at providing an integrated way of coding from somewhere comfortable and programming a remote Arduino that is in a far less accessible location.

Bootloader programming is generally only done once at the start to convert a microcontroller into an Arduino compatible device, so this is not really within the scope of the project. I'd expect that when you build the hardware, you either get a pre-programmed Arduino, or you use the standard method to get the bootloader installed into a new unconfigured device.

However, if you are stuck with a device somewhere inaccessible and have the standard farduino install, then there is nothing stopping you from using the Raspberry Pi and AVRDUDE to re-program the boot loader. Obviously you would need the appropriate interface / cabling in place to allow that to happen, typically this is an SPI interface. You would also need to ssh into the Pi and have a copy of the bootloader image file that is appropriate for your platform and manually issue the correct command to avrdude to actually program the chip.

Within the project that I built, I had this capability in place, since it would give far faster programming capabilities, but due to some noise problems on the initial prototype board, I've not actually used it other than for testing, where it resulted in an un-bootable Arduino and I had to remove it and re-program it manually to get the device working again. I really must press the start button on getting the final boards manufactured to resolve that issue :-)

Out of interest, what is the problem that you are trying to solve ?

Regards

Tim

[billlask]

Hi Tim,

Thank you for so fast response. In my case i use only the usb Atmel AVR MKII programmer for both programming and burn bootloader.So i think its good idea to add to this project the burn bootloader feature.Since the connection with the raspberry and programmer is working i think i must only change some files on the arduino ide for when click burn bootloader do the same procedure like upload(transfer with winscp and burn it with ssh. But i dont know what files i must change.Can you help me on this?

I have and some quections if you can help me. Whats the difference between Upload via host : Chicken Coop pi - Prod and Dev? Whats the upload profile?I see that n 328 has rotator and on 2560 has main controller?

Thank you in advance for your help

[tchilton]

Hi billask,

Firstly the easy stuff, chicken coop prod and dev are my production coop (in the garden) and my development coop (on my shelf / desk). Rotator is a second microcontroller that handles moving a solar panel so that it tracks the sun, the name rotator comes because it is built from a TV aerial rotator assembly. This bit is no longer in use as the gearbox in the rotator rusted out after the main bearing let water in after a couple of years.

Now, to the main point, I still know very little about your setup. I know you have a Raspberry Pi and an AVR ASP MK II as the programmer (SPI interface), but nothing about the devices you are trying to configure / use and why you want to program the bootloader so much - its generally a one-time action during the initial build of the chip. It may infrequently need an upgrade (for some new feature), or replacement if it gets corrupted somehow. I need to know the board type you are using as the config in the Arduino framework is device specific and so is the correct bootloader file.

I took a look at my scripts and there is code in there for bootloader burning on Mega 2560 (main/burnbootloader), so this should give you the pointers you need for whatever chip you are using as you can use the same approach.

The problem I had at the time was that the version of avrdude on the Raspberry Pi didn't include native RPi hardware SPI support, it was bitbanging and therefore a lot slower than it needed to be, also one of the pins wouldn't correctly configure for negative logic (~ on the pin name in the config), so it needed a fix. I also had to add in a reset capability, this is what the GPIO commands in the burnbootloader file are doing. That pin has an open collector transistor and a pull-up on it.

Kevin Kuzner merged my edit for the negative logic into his avrdude for Raspberry Pi, its available here https://github.com/kcuzner/avrdude, but a lot has changed in 7 years so its probably worth checking if those issues remain or if the fixes have been merged into the main avrdude branch.

Note that you don't need to use an AVR ASP to program since the Raspberry Pi has an SPI interface on board that can be used, so that would be cheaper and need less clutter in the target box. Just keep the SPI interface cables short to reduce noise.

What I'd suggest you do next is :

1. Review why you want to program the boot loader so much - I'm not understanding why you need that. In my case, I was modifying the bootloader and considering replacing it to free up resources on the target, although all I ended up with was a modified bootloader because of the interface issue I mentioned previously.

2. Take a look at (but do not modify) the standard Arduino config files for the board you are using to see the command lines that are used (boards.txt, platform.txt and programmers.txt in C:\Program Files (x86)\Arduino\hardware\arduino\avr). Once you have seen how the commands are run, do the same thing from the command line with a manual invocation of avrdude. Once you have this, you will understand how to modify the burnbootloader script accordingly

3. The best option though is to consider upgrading to a newer Arduino board such as one of the ESP32 family from Espressif, they go for about £6-£10 and include WiFi in many module types (ESP32-S2 / ESP32-S3) and all have the ability for over the air (OTA) programming out of the box, so you can program them directly from Arduino code, removing the whole need for the farduino project. This is the route that I've gone with my project, although my replacement boards and code are still in build as other things always seem to be more important.

The only thing to watch out for with OTA is that if you are not careful with your code, you might not be able to initiate OTA routine when you want to, the rules for this are in the documentation. Its basically long delays or crashes in your code that result in the OTA check routine not being run frequently enough.

I went down the route of having two other pins that were remotely configurable, one for reset and one to indicate I wanted to do OTA, so just service that. This means having a second route into the unit (another ESP32), where both can support the programming of the other as that chance of two screwed up firmwares at the same time should be a lot lower.

Here's an article on how to do OTA on the ESP32 https://lastminuteengineers.com/esp32-ota-updates-arduino-ide/

Tim

[billlask]

Hi Tim,

In general my project is to make a remote portable flasher. I have a raspberry that connect to a hotspot of a mobile phone.The raspberry is running zerotier sto its in local network with other pc thought internet connectivity.So with your project a user can remotly upload a sketch.I have test and usb over network but your solution work much better.To complete my project i want to make all feature for example burn bootloader and serial monitoring(I am in searching for this maybe i will make a web server to monitor the data select serial baud rate etc.

For starting i want to make all features for the cpu that you have make (328,2560)

How can i trigger this main burnboostloader fron a arduino click?

In my case i use the usb programmer so i think its not problem the spi(for sure it will be better if you programm it direcly from the raspberry)

With the esp i have bought a ready solution http://wiloader.com/ but i havent receive yet to test it.

Thank you for your info its very interesting

[tchilton]

Hi Billask,

The code as provided will do Mega 2560, but it expects the configuration I had - a Raspberry Pi with the modified avrdude and used the SPI interface of the RPi, plus a couple of GPIO pins (24 etc) along with some level changers as the Pi is 3.3V and the Arduino's I was using were 5V. Something like this works well to do the level shifting https://www.pololu.com/product/2595, you can get this from many suppliers.

If you want to use your interface, just change the command line in main/burnbootloader and test as I explained before directly from the command line, this would help you understand what's happening under the hood.

Doing the same for other chips would simply use the same approach but with different command lines and different bootloader files (i.e. the ones provided by the Arduino framework), plus require some updates to the script to cope with the variety of chips. Mine were all AVR family, but Arduino now has many board families and this project is not applicable to all of them - such as the ESP32 like I described before.

I would not advise trying to clone for all devices that are supported by Arduino, that would be an unmanageable overhead, mess up the menus in the IDE etc, this is why I limited the project to one or two devices as that should meet most needs. I've had to make changes as the Arduino framework made changes, often things would not work properly after updates and I'd have to check the scripts and edit accordingly. A proper programmer option would be the better route here. Wiloader looks like a neat project, although it looks like you will need an access point for it to connect to - the Pi can be configured for this, but secure it properly as devices that connect would be on your LAN with the configuration you detailed.

Serial debugging is fairly easy to do, just connect the Raspberry Pi serial port to the Arduino serial port and make sure that the voltage levels are compatible, use a level shifter if required to convert 3.3V to 5V and vice-versa. If you use the standard config, the downloads are over serial anyhow, so its the same wiring and pins. You might want to watch out for the DTR pin, this causes the Arduino to reset when you connect to the device and its used to force the device back into the bootloader for programming. You can always use stty to disable that on the Pi. (stty -F /dev/ttyACM0 -hup), but don't forget to turn it back on before programming again (stty -F /dev/ttyACM0 hup). I use this to see what state my app is in after weeks of uptime when I'm debugging. I don't want it in a just-booted state when hunting a stability bug.

On the Raspberry Pi, install minicom and configure that to use the on-board serial port (/dev/ttyACM0), the only thing you have to do is to close minicom before you program the device and re-open it afterwards since two things cant share one physical serial port. I ssh into the Pi, then use this method to debug my chicken-coop project. My code has retries in it if the port is in use, this is on the Raspberry Pi code in the upload script as I always forget as I'm focused on the code. Some newer Pi's need some config in /boot to enable the serial port as its shared with Bluetooth iirc. Obviously I don't need to close the SSH connection, only the minicom session (Ctrl-A, X) is the hotkey

You mentioned serial over IP - have you tried VirtualHere - https://www.virtualhere.com/. I used this between my PC and the Raspberry Pi to control some equipment from my PC and it worked very well. There is no reason this shouldn't work between the Pi and AVR ASP, and its free for one USB device, its also quite cheap to buy.

I won't be extending this project for the functions you are looking for, since its effectively obsolete with newer microcontrollers, but I'd be happy if you dug in and tried some of the suggestions above to learn how the Arduino framework works and perhaps learn a bit of Linux too. You are also free to fork the project if you wish.

Tim

[tchilton]

Closing issue since this is not a direction I want to take this project in, there has been no update from @billlask for 2 months and several far better alternatives solutions have been provided.