Is there any agreed-upon ways to enter bootloader mode from USB-Serial?

[technix]

I have completed 90% of my Arduino-compatible LPC2103 experimenting board. However I am looking at an agreed-upon method to reset the board from the host PC, and to put the LPC2103 chip into bootloader mode.

I wonder if the Arduino-style DCD flash and 1200 baud ping, as used by at least Arduino Due, would make an agreed upon method. The USB to Serial interface is provided using a STM32F042F4 chip, so as long as the protocol is kept simple anything should be doable.

[westfw]

I wonder if the Arduino-style DCD flash and 1200 baud ping ... would make an agreed upon method.

(Should say "DTR", BTW, which is only occasionally the same as DCD)
Well, it's agreed on by the Arduino folk (the 1200bps thing continues through most SAMD boards as well.)Most of the 'real' bootloader world seems to be generally appalled by the idea of initiating boot loading without having to flip a switch or change a jumper on the the hardware somewhere.  (and equally aghast at bootloaders that would give up and exit in a matter of seconds!) After all, uploading new code is mostly a "development" activity, which is a small minority of deployed chips.  Real developers don't use bootloaders - they connect up their expensive debug probes and such ("would you like to buy a debug probe?")  You can see the latter philosophy reflected in the STM ROM bootloader, the Atmel SAMBA stuff (in ROM on SAM3x, at least), and the TI "Tivaware" bootloader.

[technix]

I wonder if the Arduino-style DCD flash and 1200 baud ping ... would make an agreed upon method.

(Should say "DTR", BTW, which is only occasionally the same as DCD)
Well, it's agreed on by the Arduino folk (the 1200bps thing continues through most SAMD boards as well.)Most of the 'real' bootloader world seems to be generally appalled by the idea of initiating boot loading without having to flip a switch or change a jumper on the the hardware somewhere.  (and equally aghast at bootloaders that would give up and exit in a matter of seconds!) After all, uploading new code is mostly a "development" activity, which is a small minority of deployed chips.  Real developers don't use bootloaders - they connect up their expensive debug probes and such ("would you like to buy a debug probe?")  You can see the latter philosophy reflected in the STM ROM bootloader, the Atmel SAMBA stuff (in ROM on SAM3x, at least), and the TI "Tivaware" bootloader.

My board is a development kit and its use case is similar to that of Arduino's.

The LPC2103 itself has an internal bootloader, and the chip boots to it when a pin is held low when reset is released. On my board the 1200 baud ping would cause the STM32 chip to pull that pin low and reset LPC2103, bringing the chip into the bootloader. The DTR Flash just resets the LPC2103 with the bootloader pin pulled HIGH by a resistor.

For the STM32 I am thinking about creating the USB firmware as a CDC + HID composite, sending specific commands to the HID endpoint would cause the STM32 to re-enumerate into the in-firmware DFU interface.

[cv007]

Use an escape sequence with time guards (just like modems, remember those things?), which puts the stm32 in command mode. Then send a command to enter bootloader, or send a command to reset the lpc, or send a command to light an led, etc. Don't know how hard that would be but I imagine its not too difficult as you really only need to keep track of idle time then watch for the escape sequence when idle. Add in some code to do the command processing, and you are on your way.

[technix]

Use an escape sequence with time guards (just like modems, remember those things?), which puts the stm32 in command mode. Then send a command to enter bootloader, or send a command to reset the lpc, or send a command to light an led, etc. Don't know how hard that would be but I imagine its not too difficult as you really only need to keep track of idle time then watch for the escape sequence when idle. Add in some code to do the command processing, and you are on your way.

I cannot really use escape sequences since whatever comes in the CDC must be passed on to the LPC2103 faithfully. The STM32 can implement a HID interface alongside the CDC though, for its own control purposes.

[dgtl]

I would implement USB DFU protocol in the ST and wrap the updating inside the DFU protocol. At least somewhat standardized protocol, although a bit complicated in windows due to inf file signing needs. When the DFU mode in entered, the STM can take over the UART and do the programming; otherwise it can present a CDC bypass for USB-serial.

[cv007]

whatever comes in the CDC must be passed on to the LPC2103 faithfully

up until you want to get into bootloader mode, then it doesn't really matter anymore.

<escape_guard_time><escape_sequence><escape_guard_time>
guard time =  whatever you want
escape sequence = whatever you want

so it could be like a modem-
| 1s idle time | +++ | 1s idle time |
stm32 is now in 'command mode' where you can communicate with it

1. put stm32 in command mode
2. tell stm32 to get lpc2103 reset into bootloader
3. exit command mode (back to 'data' mode)
4. use whatever you have to program lpc2103
5. if lpc bootloader does not have built-in reset command
   put stm32 back in 'command' mode and tell it to reset the lpc
   stm32 back to 'data' mode

modems have been moving big amounts of data for a long time, and I don't recall inadvertant command mode being a problem

of course, this only works if the communicating micro is separate from the target micro, which it is in this case

just a thought

[technix]

whatever comes in the CDC must be passed on to the LPC2103 faithfully

up until you want to get into bootloader mode, then it doesn't really matter anymore.

<escape_guard_time><escape_sequence><escape_guard_time>
guard time =  whatever you want
escape sequence = whatever you want

so it could be like a modem-
| 1s idle time | +++ | 1s idle time |
stm32 is now in 'command mode' where you can communicate with it

1. put stm32 in command mode
2. tell stm32 to get lpc2103 reset into bootloader
3. exit command mode (back to 'data' mode)
4. use whatever you have to program lpc2103
5. if lpc bootloader does not have built-in reset command
   put stm32 back in 'command' mode and tell it to reset the lpc
   stm32 back to 'data' mode

modems have been moving big amounts of data for a long time, and I don't recall inadvertant command mode being a problem

of course, this only works if the communicating micro is separate from the target micro, which it is in this case

just a thought

This would mean that whatever the LPC2103 code might be, this sequence is no longer available as an alert sequence. Not ideal as a general purpose dev board.

Since the STM32 is providing the USB to Serial conversion - that is tunneling UART inside USB - I might as well use the lower level protocol - USB here - to provide a side channel. That is what the HID interface is all about, a simple side channel.

I would implement USB DFU protocol in the ST and wrap the updating inside the DFU protocol. At least somewhat standardized protocol, although a bit complicated in windows due to inf file signing needs. When the DFU mode in entered, the STM can take over the UART and do the programming; otherwise it can present a CDC bypass for USB-serial.

For the LPC2103 I just need to trigger the bootloader mode, the actual uploading is better be done using just the CDC bypass, this is why I don't feel like using USB DFU protocol. Either a HID interface or specific trigger operations on the CDC, this is intended to put LPC2103 into bootloader mode and hand it back to regular CDC.

[cv007]

This would mean that whatever the LPC2103 code might be, this sequence is no longer available as an alert sequence. Not ideal as a general purpose dev board.

You are correct- only if you think your programming software will decide to wait 1 second, send the escape sequence (inadvertently), then wait another second- that is the sequence that has to be avoided in the data flow.  Your programming software is not going to do that inadvertently, and your normal 'data' mode is going to have a hard time triggering the command mode unintentionally. If your lpc programming software already uses cdc (serial), it may be simple to add a 'preamble' which first puts the lpc into bootloader mode, similar to a pc initializing a modem. Like I said, modems have used this system since, well.. since we stopped placing the telephone handset on a modem cradle.

[westfw]

Well, the advantage of using the DTR hack to reset and enter the bootloader is/was that it happens automatically with existing software - open the serial port, and DTR changes - presto!
The disadvantage of using the DTR hack is that ... anything that opens the serial port might cause a reset/bootloader entry.
The advantage of the 1200bps hack is that any host-side software can cause the bootloader to be entered, using only standard and common COM port APIs.
The disadvantage of an extra HID endpoint is that now you need "advanced" USB programming on the host side to access the bootloader.

[technix]

Well, the advantage of using the DTR hack to reset and enter the bootloader is/was that it happens automatically with existing software - open the serial port, and DTR changes - presto!
The disadvantage of using the DTR hack is that ... anything that opens the serial port might cause a reset/bootloader entry.

On my board the DTR causes only a reset, bot a bootloader entry.

The advantage of the 1200bps hack is that any host-side software can cause the bootloader to be entered, using only standard and common COM port APIs.

That is the point.

The disadvantage of an extra HID endpoint is that now you need "advanced" USB programming on the host side to access the bootloader.

There is libhidapi for this.

[westfw]

The disadvantage of an extra HID endpoint is that now you need "advanced" USB programming on the host side to access the bootloader.

There is libhidapi for this.

It's not that the APIs don't exist; it's that you're committing to writing a utility that invokes them, for 4-ish operating systems, when you could have gotten by with "mode com1:1200,n,8,1" or "stty -f /dev/tty.usbserial1234 1200" in a shell script, if your product catches on.  (Hmm.  Is there already a cross-platform cli utility that implements most of the libhidapi?  I guess there could be...)

Hmm.  There's the "protocol" implemented by the "halfkay" bootloader on PJRC's Teensy boards.  It includes a "reboot" command...https://www.pjrc.com/teensy/halfkay_protocol.html

[technix]

The disadvantage of an extra HID endpoint is that now you need "advanced" USB programming on the host side to access the bootloader.

There is libhidapi for this.

It's not that the APIs don't exist; it's that you're committing to writing a utility that invokes them, for 4-ish operating systems, when you could have gotten by with "mode com1:1200,n,8,1" or "stty -f /dev/tty.usbserial1234 1200" in a shell script, if your product catches on.  (Hmm.  Is there already a cross-platform cli utility that implements most of the libhidapi?  I guess there could be...)

libhidapi itself masks the difference of all platforms. I just need to tell it to look for a specific VID/PID (which can be extracted from walking the device tree in an OS-specific way from the CDC port) and send bytes like a regular pipe.

I am thinking about creating a cross platform tool for uploading code to the board (kind of like avrdude.)