I’ve heard there’s a list of commands the Arduboy’s booloader (Cathy) is capable of responding to.
How do I have a ‘conversation’ with the bootloader in order to use these commands?
The commands as mentioned in this thread.
‘A’ set current address
‘a’ get auto address increment support
‘B’ 0x00 0x80 ‘F’ write block to flash page (auto erases page)
‘E’ Exit bootloader (after 500msec)
‘g’ MSB LSB ‘F’ read block of flash
‘L’ leave programming mode
‘P’ enter programming mode
‘p’ get programmer type
‘S’ get software ID string
‘s’ read avr signature
‘T’ byte select device
‘t’ get supported device types list
‘V’ get software version
‘B’ MSB LSB ‘E’ write block to EEPROM
‘C’ byte Write high byte to page buffer
‘c’ byte Write low byte to page buffer
‘D’ byte write EEPROM byte
‘d’ Read EEPROM byte
‘e’ erase chip (erases application flash area only)
‘F’ Get low fuse bits
‘g’ MSB LSB ‘E’ read EEPROM
‘m’ Flash pagebuffer
‘N’ Get high fuse bits
‘R’ Read flash word
‘r’ Get lock bits
‘Q’ Get extended fuse bits
After rebooting the board, connect to the serial port @ 57600bps. IIRC, that’s all you need to be able to write commands to it. It’ll timeout and boot after a while if you don’t give it any commands.
The tricky bit is rebooting and connecting at the right time.
The original document describing the protocol may prove useful:
You start with opening the com port to which Arduboy is connected at 1200 baud and then close it immediately. This will tell Arduboy to go into bootloader mode.
In bootloader mode Arduboy acts as serial programmer listening for specific commands. The bootloader mode will remain active for 8 seconds unless specific commands are send.
The commands are a single character and may be followed by one or more parameters or data.
When a command is send, it is acknowledged by a cariage return (0x0D) or if the command is not understood, a question mark ‘?’ is returned. However commands requesting data are not acknowledged with a cariage return. The requested data is returned.
The capital S (request for Software ID command) is send to Arduboy in bootloader mode.
the response will be CATERIN (for standard Caterina bootloader)
The capital V (software version command) is send to Arduboy in bootloader mode.
The response will be 10 for software version 1.0 (for standard Caterina bootloader)
Send lower case v (hardware version command) is send to Arduboy in bootloader mode.
The respnse will be ? as the hardware version command is not implemented in standard Caterina bootloader.
You can play around with with the above commands in the Arduino monitor (you’ve have to be fast on windows though for changing the com port)
To keep the bootloader mode active indefinetly you can erase the sketch by sending a lowercase e (erase command) in bootloader mode.
Reading though the document @MLXXXp linked to will help understanding the other commands.
You can also have a peek at my Python scripts Here’s a snipped of backing up EEPROM of one of them.
bootloader.write("A\x00\x00") #select address 0 command
bootloader.read(1) #drop acknowledge
bootloader.write("g\x04\x00E") #read 1K EEPROM data command
eepromdata = bytearray(bootloader.read(1024)) #read 1K EEPROM data
Thanks, that was very descriptive and the python scripts are an excellent reference.
I’ve managed to get it to go into bootloader mode,
but I keep getting exceptions when trying to reconnect at 57600 baud.
I’ve got a feeling it’s my choice of language/API.
I’m using C#'s
SerialPort class, which is a wrapper around some Win32 stuff as far as I can tell.
I might have to resort to going down to the Win32 level to get it working if I can’t find a fix.
Either that or use something else.
Just in case it’s to do with my settings,
I’ve got baudrate=57600, parity=none, databits=8, stopbit=one and rtsenable=true.
(I got the parity, databits and stopbit from https://www.arduino.cc/en/Serial/Begin, but I can’t remember where rtsenable came from.)
Are you trying to reconnect on the same com port? On Windows two com ports are used. One for normal mode and one for bootloader mode. The baudrate and bit settings isn’t of any importance in bootloader mode.
Nope, I knew about the Arduboy’s port hopping.
I checked, it’s normally on COM4 but goes into COM5 when booting.
The error originates from a
set_DtrEnable function (which is actually the function generated for handling the setter of the
DtrEnable property), which in turn is accessed from a constructor.
I think I’ll give up for now and try again another day,
maybe with a different API.