Minimum pin access to program via STLink

Hello,

I’m making my own mini-board and I was wondering what would be the minimum number of pins that have to be interfaced with in order to always be able to program the chip, no matter the current state of the chip. This assumes that the chip is connected to a crystal and power is supplied.

SWCLK / SWIO / GND would definitely be included in the required pins.
How about:
RESET: In which cases a reset of the chip would be necessary, also would power-cycle instead of reset work ?
BOOT0: I’m thinking of having BOOT0 always tied to ground, what scenario would make the chip unaccessible via STLink if BOOT0 was always connected to ground ?
BOOT1: Same as BOOT0.

I remember reading that the SWCLK & SWIO pins can or might sometimes be configured as GPIO so the chip can’t be accessed any more via these pins. I don’t remember where I read this, does anyone have a link with more info about this, and how to get SWCLK & SWIO back to being STLink-able ?

Thanks!

michaeliv wrote:Hello,

I’m making my own mini-board and I was wondering what would be the minimum number of pins that have to be interfaced with in order to always be able to program the chip, no matter the current state of the chip. This assumes that the chip is connected to a crystal and power is supplied.
<…>

@michaeliv

googling ‘connect under reset stlink’ gives the st manual pdf

http://www.google.co.uk/url?sa=t&rct=j& … ArLDuhWwLQ

i seem to have acquired a copy by following the above

it’ll explain the effect if any of boot0/boot1?

stephen

AFIK.

If you always intend to program via STLink,you can pull Boot0 and Boot1 low all the time.

At a pinch, you could also hard wire the reset line, and just power cycle the board instead.

You only need to connect the 2 SWD lines to program via STLink

and SWD needs a connection to card’s 3.3V Vcc as VTref, and GND of course.
Card’s nRESET is a practical must-have for the SWD interface.

SWD and CLK, optional is the trace pin… very handy for logging and and profiling in the debugger.

@stevech

Are you sure STLink needs to be connected to Vcc.

I sometimes power a board via USB, and its onboard 3.3V reg, and then only connect the STLink via SDIO SCLK and Gnd.

If the processor has the SWD pins enabled, there should be no need to connect under reset. But for safety I would have the reset pin available to the STLink

RogerClark wrote:Are you sure STLink needs to be connected to Vcc.

I sometimes power a board via USB, and its onboard 3.3V reg, and then only connect the STLink via SDIO SCLK and Gnd.

Thanks all for your answers, I’m getting a better idea about what is involved.
Can anyone tell me how the MCU can get it’s SWD pins disabled ( configured as GPIO ) ? Is there an stm32duino function to do this ?
If it reaches that state, what is the correct way to program it via STLink ? Hold down reset and access via STLink ?

Also if I intend to also program via USB, will this change anything for this particular case, will I need more pins exposed to program ?

Thanks!

SDW pins can be disabled if they are configured as GPIO in the firmware.

For boards like the Maple mini, the SWD pins are configured as GPIO, which means if you try to program over STLink after running a sketch, the STlink will not connect to the STM32 (this is part of the initialisation)

So you have to select “Connect under reset” in the STLink program, then hold the stm32 in reset, and then tell the STLink to connect, and then take the STM32 out of reset.

If you want USB you need 2 usb pins connected to the USB i.e USB D+ and USB D-.

To enumerate USB ideally you need an external PNP transistor or PChannel FET, but it is also possible just via a 1.5k pullup on one of the USB lines as we have a hacky way to switch one USB pin to GPIO and then back to USB which causes the USB re-enumeration – but we only to this to support boards without the proper usb reset electronics

But like Ray has said, Look at the Maple mini schematic, it has a complex USB reset system of 2 x NPN transistors (which I think can be replaced by one PNP), it also has the nesessary USB series resistors (22 ohm I think), and some boards also have USB protection devices as well.

BTW. I’m not sure what you are building, but I have been tempted for some time to design a DIgiStump style USB board based on the STM32, using the PCB as the USB edge connector.

I’m trying to design an arduino pro micro -style board (http://artofcircuits.com/wp-content/upl … icro-1.jpg) based on STM32F103T8U6(qfn/36). It’s just a standard board, but with a more compact format for easier breadboarding.
That’s why I was wondering what I need to expose for programing. I’m thinking that I won’t be exposing the reset pin for programing.

So, which firmware / what should i avoid flashing in order to not configure the SWD pins as GPIO and therefore “Brick” my mini-board.
Also, I’m guessing that by default, chips that ship from the factory / DigiKey can be programmed without reset access, right ?
I’m planning on using a 1.5k resistor for reset. If I want to use the transistor reset mechanism then I would need a custom bootloader and would also have 1 less GPIO to use for general purpose, right ?

Funny enough, for my blue pill-board reset/re-enumerating via usb works on the ports on the left side of my laptop, but doesn’t work with the ports on the right side of my laptop. However it works with right side ports + USB hub. I’m under Windows 8.

I am not sure why you think a custome booloader would be a problem.
Its easy to add a new target to the existing bootloader and change the USB reset pin.

If you dont use a transistor to reset the USB, its not guranteed to work on all computers.
As what we do with boards like the BluePill etc is basically a hack. But we had no choice but to use a hack / workaround, as we cant change how those boards are made.

Its up to you, but if you are designing a board which you intend to make available for other people to use, I think you should seriously consider adding a reset transistor, even though that means loosing a GPIO line.

You should take a look at this thread

http://www.stm32duino.com/viewtopic.php?t=642&start=30

Also. I’m pretty sure there is a commercial board, which already uses the STM32F103T but I’m having trouble tracking it down.

I’m pretty sure someone has posted a link to it on the forum somewhere.

RogerClark wrote:You should take a look at this thread

http://www.stm32duino.com/viewtopic.php?t=642&start=30

Also. I’m pretty sure there is a commercial board, which already uses the STM32F103T but I’m having trouble tracking it down.

I’m pretty sure someone has posted a link to it on the forum somewhere.

@michaeliv

I think there is another STM32F103T board available, its not as long.

I will try to find it

Edit. Found it

http://www.hotmcu.com/stm32f103tb-arm-c … cPath=1_20

Note. It looks like this company has some dodgy / illegal software hosted on their site.

RogerClark wrote:@stevech

Are you sure STLink needs to be connected to Vcc.

OK, I’ve decided to add a USB disconnect circuit. I’m still deciding on which one would work best.
What would be the minimum component one that would work reliably ?
I found this one with 2 resistor + PNP that is claimed to be reliable: http://www.stm32duino.com/viewtopic.php?t=780
Also, there is the Maple Mini one but that uses 2 transistors.
Suggestions for best to use ?

Also on a side note — does anyone know why my blue pill won’t enumerate if I remove R10(10K resistor from PB12 to 3V3).

Thanks!

10k is very high for USB enumeration, 1.5k is more common.

I think the pullup is part of the USB spec and indicates to the host that a slave is attached.

Without it, the USB won’t re-enumerate.

Also.

Re: Circuits of USB reset transistors

See also http://store.iteadstudio.com/images/pro … e-v1_0.pdf

They use a P Channel FET and 2 resistors.

I have been meaning to test this way of resetting the USB, and I bought some P Channel FETS a while ago, but never got around to trying it.

As far as I can tell, either a single PNP (or P Channel) device is needed, or 2 NPN devices, as the purpose of the transistor is to pull USB D+ (PA12) high via 1.5k when signaled to reset the USB

Our hack method (with the 1.5k resistor permanent pulling up USB D+), relies on the GPIO being able to drive PA12 low. But this isnt really how you are supposed to reset the USB, it just happens to work most of the time

Thanks for the info, now I’m a bit confused however.
I did not know that a pull-up is required for enumeration.
BTW when you say re-enumerate do you mean:
– Initial device identification, when the device is connected for the 1st time
– Device re-identification after messing with the D+ line

So in order to adequately force device re-identification, you would have to have both the D+ and D- pins floating, without any pull-up, correct ?
If that’s the case then why use a transistor for disconnect ? Why not have D+ connected to another GPIO through a 1.5k resistor and configure the GPIO to output 3.3v, then when you want to re-identify the device, set the GPIO to floating. How is this different than using a GPIO-controlled transistor ?

Does anyone have a link where more details about this are given ? Preferably a straightforward explication, not a 500 page USB spec

Here is one link : http://www.beyondlogic.org/usbnutshell/usb2.shtml

martinayotte wrote:Here is one link : http://www.beyondlogic.org/usbnutshell/usb2.shtml

michaeliv wrote:I see no reason to use a GPIO-controlled transistor. I guess there must be something I’m missing.

or use a FET

For anyone curious, I’ve tested the resistance of the D12 GPIO to ground while the micro is unpowered and it measured at 33 MOhms. which IMO would not pose an issue.
Having said this, it seems there is no reason not to use the 1.5k resistor from D+ to another GPIO.
The only reason that I can see now is that the 33MOhms resistance isn’t guaranteed by spec so theoretically in the future it might change — however I view this as extremely unlikely.

Perhaps the HIGH voltage on the GPIO is not guaranteed to be 3.3V, there is bound to be some volt drop though the internal circuit for the GPIO inside the STM32

RogerClark wrote:Perhaps the HIGH voltage on the GPIO is not guaranteed to be 3.3V, there is bound to be some volt drop though the internal circuit for the GPIO inside the STM32

To build the bootlooader you need make.exe (I think I use WinAVR’s copy), and just put the path to the arm gcc compiler in your PATH var

Arduino hides GCC in the %appdata%/Arduino15 folder somewhere

Hi all,
if it can help, here is the schematics of my “multistandard” board (see my post on the “Welcome” section: http://www.stm32duino.com/viewtopic.php?f=2&t=841) that uses one PNP for the USB disconnect signal.

PS: These days I’m making a new board that will “join” the STM32 “world” with the CPLD/FPGA “universe”… I’ll post here the result (if any… ). Currently I’m starting the PCB design using a single layer homemade board…. not so easy…. some transmission line problems to manage….

Cheers.

UPDATE (schematic errata):

L2 is upside down;
USB (J3) shield is unconnected. Better connect it to GND.

michaeliv wrote:For anyone curious, I’ve tested the resistance of the D12 GPIO to ground while the micro is unpowered and it measured at 33 MOhms. which IMO would not pose an issue.
Having said this, it seems there is no reason not to use the 1.5k resistor from D+ to another GPIO.
The only reason that I can see now is that the 33MOhms resistance isn’t guaranteed by spec so theoretically in the future it might change — however I view this as extremely unlikely.

I asked a ST-Guy at Maker Fair SF Bay 2016 about the pull-up-to GPIO mystery. Though he was a software guy and didn’t know the specifics behind the choice he pointed out that with pull-up-to GPIO you’re pulling up to the micro’s internal voltage which is subject to noise. Though that wouldn’t seem that much of a big deal since ST says in their datasheet that the pull-up should be done to 3.0v-3.3v.