Enable ''RS485 mode'' while in ''bootloader mode''?

[stmicro23]

Posted on February 06, 2015 at 18:23

Is it possible to enable ''RS485 mode'' while in ''bootloader mode'' to allow the possibility to perform a DFU (device firmware update) over RS485?

We use a STM32 F072 microcontroller on our custom PCB board and we have the USART port connected to a RS485 chip (ST1480).

I have not had success in trying this on our board, but I might be missing something.  My attempt involved configuring the USART port in RS485 mode using USART_DECmd() and then jumping to the bootloader via a function pointer (as discussed in other STM32 threads).

I was also wondering if it is possible to use different USART pins than the default when in bootloader mode.  If this were possible, I would think you would need to configure the pins as ''Alternate Function X'', configure the USART, then jump to the bootloader.

References:

- AN2606 ''System Memory Boot Mode'' Section 20 - STM32F07xxx (p. 87)

- AN3155 USART protocol for bootloader mode

- RM0091  STM32 Reference manual, Section 26.5.16 - RS232 Hardware flow control and RS485 Driver Enable (p. 699)

Thanks!

#bootloader #usart #rs485

[Tesla DeLorean]

Posted on February 06, 2015 at 18:29

No, this is where you'd write your own loader to uses the pins and protocols of your choosing.

[stmicro23]

Posted on February 13, 2015 at 00:06

Thanks Clive, I found App Note 4065 to create a custom bootloader for the F0x microcontrollers:

STM32F0xx in-application programming using the USART (AN4065) 

[Microstar]

I‘m looking for same solution for using system boot over RS485, ​not found yet.

[Tesla DeLorean]

The System Loader has some expectations I don't think you'll be able to meet.

For manufacturing programming one typically exposes USART1 RX/TX in a way that allows you to talk to the loader.

For field programming you really want to be controlling the user experience.

[Mon2]

The applied RS485 transceiver is half duplex and respectively requires a GPIO pin to drive the transmitter during a transmit. To debug, monitor the respective DE pin to see if it is toggling during these bootloader attempts. If not, a possible work around is to consider a RS485 transceiver that is auto-enabled internally for the direction control.

For example, see Maxim

https://www.maximintegrated.com/en/products/interface/transceivers/MAX13488E.html

NB: Before jumping in, please note that these are 5 volt operated transceivers. Respectively, the I/O will be @ 5 volt levels but fairly confident that the ST GPIO pins are 5 volt tolerant but please do confirm this detail in the respective datasheet before proceeding.

In theory the above idea should work. If you do proceed, please post your results.

Another approach is to use 3v3 transceivers from any vendor and use a bit rate timer to enable / disable the DE signal as noted here:

http://www.ti.com/lit/ug/tidubw6/tidubw6.pdf

Basically the one shot timer is timed to the baud rate your will be using and is triggered off the START bit of the frame. I think a simple SILEGO device would work well here to eliminate a lot of driver timed logic....just saying.

[Fahmi Maulana]

i have an idea for this, you can use module uart to ttl (max485 with inverter 74hc14), only need 2 pin (Rx Tx), so u can programming over there. entry into serial bootloader and flash it, hope it working properly