search

bigdragon1977 / stm32flash

Automatically exported from code.google.com/p/stm32flash
0 stars 0 forks source link

use RTS and DTR connected to RESET and BOOT0 to enter bootloader mode #37

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
this is not really an issue but since i didnt find any place else to go with 
this i post it here...

if anyone interested i can provide a patch for stm32flash which uses the RTS 
and DTS lines (connected to RESET and BOOT0) to put the STM32 into bootloader 
mode before programming. it can be enabled by a new command line option.

Original issue reported on code.google.com by biertrin...@online.de on 27 Nov 2012 at 8:30

GoogleCodeExporter commented 9 years ago 
I`m is interested in this patch. Please post it here.

Original comment by alat...@list.ru on 28 Nov 2012 at 6:25

GoogleCodeExporter commented 9 years ago 
here the patch. so far only for linux (wont compile on windows...)
connect DTR to BOOT0 and RTS to RESET and use the -t option

Original comment by biertrin...@online.de on 27 Dec 2012 at 9:23

Attachments:

GoogleCodeExporter commented 9 years ago 
ST implemented a similar feature on their STM320518-EVAL evaluation board, 
described in UM1537, and referenced in AN2606 (p.72).  The RS232 control lines 
named in these documents are "backwards" (i.e. they use "CTS" for what is 
actually "RTS", which is accounted for by the note that you must use a 
null-modem cable when connecting to the board.  That confusion aside, they have 
used the exact opposite connectivity, i.e. RTS controls BOOT0, while DTR 
controls NRST.  To keep the hardware simple, they used a non-inverting level 
converter for DTR, which is not so common (and not available from, for example, 
FTDI USB converters).  In principle these control lines can default to either 
high or low when not actually connected to a modem, but when I checked four 
common terminal-emulator programs I found that, unless used for hand-shaking, 
all of them set both RTS and DTR off (i.e. to a "high" RS232 logic level).  
Thus to retain simple terminal connectivity, with bootloader operation being 
the unusual case, this seems to be the defacto standard.  By using the 
un-inverted (but level-shifted) version of DTR, the STM320518 eval board is 
able to use a simple diode-OR connection for both RS232 control lines to their 
respective inputs.  If you only have the inverted DTR signal available, then 
you must use a NMOS transistor to pull down NRST.  The convenience, if not 
often the true necessity, of having a "switchless" bootloader seems 
under-appreciated.  I build things that occasionally need field-upgrading, and 
the idea of providing a special switch for this purpose is highly unattractive. 
 Issue #40 points out that wireless (e.g. Bluetooth)-connected devices also 
need a "switchless" bootloader.  In this case, however, only RTS is commonly 
available.  Are there any thoughts from the community with respect to 
conforming to ST's implementation?

Original comment by jim.van....@gmail.com on 8 Jan 2013 at 3:36

GoogleCodeExporter commented 9 years ago 
Since this is board-specific and not part of the STM32 or the protocols, 
wouldn't it be better to do the RTS/DTR manipulation in a script or wrapper 
program that calls stm32flash to do the talking? Maybe some option would be 
needed for stm32flash to leave the pins as they are (I have not checked). Note 
that opening an unopened serial port automatically toggles DTR on some 
platforms, but one program can open it and set the pins, keeping the device 
open while another program also opens it.

Original comment by lists.to...@gmail.com on 9 Jan 2013 at 10:04

GoogleCodeExporter commented 9 years ago 
Antonio Borneo implemented this very nicely in his recent patches. His work is 
included in version 0.3beta2.

Original comment by lists.to...@gmail.com on 9 Dec 2013 at 11:20

GoogleCodeExporter commented 9 years ago 
Issue 40 has been merged into this issue.

Original comment by lists.to...@gmail.com on 9 Dec 2013 at 11:25