Accessing the bootloader

I am not quite sure where to ask this - so excuse me if I got it wrong. Can anybody help with the technique to enter the bootloader from the main program on an Arduino board?. I have an UNO R3 (genuine) and would like to do the programming via a different application. When programming from the Arduino IDE, I see 3 pulses of 62mS on the MOSI pin to the CPU - I can't seem to find a reference for entering the bootloader on the chip document.

https://github.com/Optiboot/optiboot/blob/master/optiboot/examples/test_dospm/test_dospm.ino

Thank you for the quick reply. Is Optiboot then the bootloader that comes standard with the UNO? - I was unable to actually confirm that.

daveve: Thank you for the quick reply. Is Optiboot then the bootloader that comes standard with the UNO? - I was unable to actually confirm that.

yes. version 4 https://github.com/arduino/ArduinoCore-avr/blob/0f3d4da614d5a195e03d70741031092a002e2d33/boards.txt#L72 https://github.com/arduino/ArduinoCore-avr/tree/master/bootloaders/optiboot

current version is 7

Thank you very much

is it all you want to know? there is more to know.

the 3 pulses are built-in LED on pin 13 blinking. It has nothing to do with the MISO function of the pin.

what do you mean by "enter the bootloader from the main program"? The link shows how to call a function in bootloader. is it what you want?

what do you mean by "would like to do the programming via a different application"? PC application or ATmega application?

Hi - I thought perhaps that the link you gave me would have a clue on entering the bootloader. What I mean by entering the bootloader is: Lets say I have a main program in flash which is running some application - say an application running a stepper motor. I make changes to the program and compile and want to reload the altered code. Using the Arduino IDE I can upload the program to the UNO. There should be a mechanism that causes the bootloader to run instead of my application in flash. The bootloader then receives the STK500 commands to re-program the flash. I was asking about the mechanism to cause the UNO to run the bootloader instead of the program running in flash.

The reason for wanting the information is that I am programming using the following: 1. Notepad++ instead of the editor in the IDE (I am used to Notepad++ and it has more facilities than the built-in editor (I set the IDE to use an external editor) 2. I have a PC "Monitor" application which connects to serial ports and has many other facilities compared to the one provided in the Arduino IDE.

As the programming section of the Arduino uploader uses the same serial port as the external application I am using, I need to close the serial port on the PC application before doing an upload via the IDE and then re-enable it afterwards. So to simplify, I want to embed the uploader within the serial port application.

then my link is irrelevant. you want to replace avrdude.

Here a look at this webpage that I came across while researching another problem, you will have to replicate the stk500 protocol to interact with the bootloader. Everything You Always Wanted to know about Arduino Bootloading but Were Afraid to Ask

Thank you both for the assist.

I did not want to write a book in the post as I assumed there was a spec somewhere that I could not find. Before asking for help, I did a fair amount of searching and found a C# app that said it replaced the AVRDUDE. The exit from main flash to bootloader was indicated as being a drop of DTR/RTS for a period of 250mS. I tried this and found that the pulse length was not critical, but I gained access to the bootloader and could issue the getsync and get the correct responses as well as get the version (major,minor) which in my case was 4.4. There is no indication of which bootloader it is - therefore my question to Juraj. However, after doing this, the access timed out and the main program in flash started up again. I could replicate this as many times as I wanted - but it always timed out. If I kept sending the getsync cmd, I could get it to NOT timeout. Presuming that there was more to it, I used a scope and checked all the pins of the ATMega 328P for a signal of some sort to instruct the ATMega to go to bootloader code. All I found (on all pins) were the 3 pulses of 62mS on the MISO pins as mentioned above and a reset pulse with a length according to the capacitor of 100nF which is in series between the pin of the USB mega8u2 and the reset pin of the 328p cpu.

I looked at the post indicated by david_2018 and found that the information was similar to what I saw i.e. "DTR and RTS are both toggled from High to low several times" but without a definition of the number of pulses or the length thereof. The doc on the STK500 protocol is quite clear and seems to function, but .. it does not mention the method of accessing the bootloader code. I could of course just make sure that commands are sent fast enough to prevent the timeout - but this seems really iffy. If for some reason windows (on which the uploader runs) decides to go off and do something else (like an endless timeout waiting for a bad ip address) then it is quite possible that programming would be corrupted. Optiboot seems to just accept a block of data with no checksum or CRC. So I was hoping someone had the actual information on what was required. The ATMega 328P datasheet by the way, indicates that programming via the bootloader takes place while the reset is held low - but I presume that is for ICP programming and NOT IAP programming.

Have you seen the Optiboot Source Repositor Wiki and associated source code and such?

In general, you can't "access the bootloader" from the application. Normal operation is that the bootloader is only enter after a hardware reset. The most recent Optiboot (from the github site, or from MCUDude's "Minicore" site), it's been hacked slightly so that if you jump to the start of the bootloader, it will also attempt an upload. You have to make sure that the MCUSR is cleared, and all active interrupts are turned off, and maybe turn off some peripherals, so it's not very clean. (Some of the newer chips have the ability to generate a reset internally, which works much better. But the ATmega328p can't, except for the WDT (which is already used by the bootloader to start the App.) Note that the bootloader only runs for one second after starting, so you also have to ensure pretty tight timing between "starting the bootloader" and starting the application that uploads code.

The doc on the STK500 protocol is quite clear and seems to function, but .. it does not mention the method of accessing the bootloader code.

The STK500 protocol describes the communications protocol between the PC and the programmer (STK500 is originally a programmer communications protocol, rather than a bootloader protocol.) It doesn't cover details like how the programmer or chip enters the communications mode.

Optiboot seems to just accept a block of data with no checksum or CRC.

Well, individual "pages" of data that have to be delimited by appropriate commands, so there's quite a bit of "defacto" error checking.

The ATMega 328P datasheet by the way, indicates that programming via the bootloader takes place while the reset is held low - but I presume that is for ICP programming and NOT IAP programming.

That IS for ISP programming, which is NOT the same as bootloader-based programming. When RESET is held low, no user code runs at all (including the bootloader as user code.)

The webpage I linked shows the sequence of commands that are sent by avrdude to load the contents of a hex file onto an arduino using the optiboot bootloader, although it may have changed in the years since that was written. If you want to program an arduino through your serial monitor program, then you will need code within that program to read the hex file generated by the compiler and issue the correct sequence of commands over the serial line, as well as respond appropriately to the command responses sent back from the arduino.

Would be a lot easier if your serial monitor program was capable of releasing the serial port, calling an external program (avrdude to upload the code, or a batch file to compile and upload), then reconnect to the serial port when the external program exits.

the bootloader runs after reset and waits a little for serial upload. on Uno the DTR signal is wired to reset circuit to do the reset by uploader.

Hi All - thank you for all the replies.

The suggestion of spawning a child process may well be the easiest way. (david_2018) There is normally a little trick to allow you to force the bootloader to run after you reset or it is by timing i.e. respond within x period with a command. Juraj & westfw have indicated that it is a wait i.e. every time the chip reboots - it waits for a command to be sent to indicate that it must stay in the bootloader.

When attempting to check this manually - i.e. I dropped the DTR/RTS, sent a getsync, checked the version and then issued the enter programming mode cmd - it timed out - so I presumed I had the wrong info.

Perhaps I was taking to long to get to the enter program mode command and this caused the issue. I looked at the code for optiboot and could not see a timer - so presumed it was a trick rather than timing

I now presume that I took to long to get to the actual "enter programming mode" command and so will try this again with shorter timing.

westfw - I presumed there would be simple error checking in the form of something similar to the Intel Hex format where simply adding the data together (including the checksum) results in a zero answer - making it simple to check the basic integrity of the data block and doesn't use many bytes.

daveve: Perhaps I was taking to long to get to the enter program mode command and this caused the issue. I looked at the code for optiboot and could not see a timer - so presumed it was a trick rather than timing

From the Optiboot wiki:

The (configurable) UART is configured and the WDT is enabled with a 1s timeout. Optiboot attempts to read commands from the (configurable) serial port. Valid characters will cause the WDT to be reset, and the application flash area to be programmed (hopefully.) With no valid UART traffic, or after programming, the WDT is allowed to expire, causing the chip to reset.

If you allow more than 1 second between characters on the serial line, then the watch dog timer expires and resets the chip, exiting the bootloader. If you look at the getch() function in optiboot, the instruction watchdogReset() is what resets the timer.

Checksumming was added for stk500 v2. It’s a nicer “protocol”, but I think implementing it in 256 instructions would not be possible. V1 relies on the read-back and compare after programming is done.

You might be able to process the hex file to generate a file with all the bootloader commands and program data, then send the file as raw data within your terminal program. Have not looked to see if there is any specific responses that need to be sent to the bootloader, or whether blindly sending data is acceptable.

david_2018 - Thanks - I missed that in the wiki and as mentioned I should have seen that the WDT would expire. I will check the conditions for the WDT reset to make sure I conform. westfw - thanks for the info david_2018 - The PC application I mentioned has already got support for similar purposes - programming an Atmel chip, a PIC chip and 8032 based chip. So we can communicate interactively to check the responses and report when the sync fails the basic connection, check that the device is an Uno etc.