STM32 Smart Connector

Introduction

Every hardware designer will tell you, there is never enough I/O on an MCU! Well, it does, but much less when it comes to choosing an ultra-low-power MCU dedicated to stand-alone IoT.

When we design autonomous communicating tags packed with sensors, the goal is both to consume as little as possible by having just the right number of input/output pins and optimize their use.

The problem we are going to answer is as follows: How to get serial communication to a PC on an MCU where all the pins are already in use and the hardware is frozen ? We agree, that seems like a bad start ! 😱

Some additional information before getting to the heart of the matter :

• The MCU in question is an STM32L0. An excellent product which in addition to consuming the equivalent of “nothing at all” (in advanced standby), is very flexible on the configuration of GPIOs.
• Why a serial connection ? Because the firmware that will be flashed in this MCU has a command line interface that allows you to dialogue and verify the execution of tasks live. The concern is that the hardware was not designed specifically for this firmware , so there is no UART wired to the outside.
• The STM32L0 being a Cortex M0 and not an M3 or M4, it does not include the Instrumentation Trace Macrocell (ITM) allowing the data output on the SWO pin.

The STM32L071

The STM32L071 is an “ultra low power” microcontroller from STMicroelectronics. Perfectly adapted to the IoT, it leaves a lot of leeway in the affection of its pinout. Moreover, a dedicated configuration tool is provided by ST: STM32 CubeMX

Here is the MCU pinout of the product. (For obvious reasons of confidentiality we’ve hidden some parts).

It can be seen that almost all the pins are used and the only solution to physically interface to the MCU are pins labeled he SYS_SWCLKand SYS_SWDIO because these are the programming (flashing) pins. The hardware manufacturer has logically wired theses pins on a physical connector in order to be able to flash the MCU of its product !

Here, the physical link with the manufacturer’s board, wired to the official ST-Link V2 “flasher”. In addition to the SWCLK and SWDIO signals the connector must provide the RESET, the GNDand finally the VDDin order to check that voltage is sufficient for a reflash.

The Trick

The beginning of the trick is precisely where you connect. Given that this is our only physical interface why not use it as UART ? Let’s see what CubeMX has to purpose !

If we look at the possibilities for assigning the PA13 pin we see that we can reconfigure it as LPUART1_RX(low power uart). The flexibility of the STM32 is such that it can redefine its programming port to a UART on the fly. Ditto with the PA14 pin that we will be able to assign to LPUART1_RX.

The strength of CubeMX is also being able to generate all the “C” source code associated with the pinout configuration. So with this configuration of PA13 and PA14 in UART, as soon as the flashed firmware will be executed by the MCU, the pin configuration will toggle from “SWD” to “LPUART1”. After toggling pins to UART, you can directly connect a “USB to Serial TTL” type FTDI cable in 3.3Volts for example. Thus by using the following HAL function, we will be able to view the characters sent by the MCU in a “serial” terminal :

HAL_UART_Transmit(&MY_UART_HANDLE, (uint8_t *)&character, 1, 2);

What about Reflash ?

Once the programming pins have been reconfigured to UART, one might imagine that the MCU is “bricked” in this mode forever. Obviously that is fortunately not the case, it suffices to apply the RESET signal on its dedicated pin for its internal bootloader to detect a flashing request.

To flash the MCU we use a STLink V2 and the STM32CubeProgrammer software which has the merit of being both multi-platform (windows, linux, macos) and usable from the command line !
So, we are not wasting time clicking buttons on the graphical interface, we execute the following command line which allows to force a hardware reset, launch the flash at the correct address and finally a reset to reboot !
./STM32_Programmer.sh -c port=SWD reset=HWrst -d firmware.bin 0x801FF00 -rst
If all goes well, the flash lasts about ten seconds for a “big” firmware.

Multiplexing UART/SWD

We have seen that we were able to communicate in UART and then reflash via ST-Link, but the problem is that we must systematically disconnect the USB/Serial cable to reflash. Indeed, programming signals (Serial Wire Debug or SWD) cannot be “mixed” with the USB/Serial cable. Our idea was therefore to create a connector capable of handling both modes at the same time (UART and SWD), thus the development phases are much more comfortable, there is nothing to physically touch between each reflash!
This famous connector will interface exactly between the ST-Link (which gives the programming orders) and the cable that connects it to the sensor board (the MCU).

Below, theorical multiplexing schematic UART/SWD :

(As is, it can’t work, either one has to be physically disconnected).

The Smart Connector

The purpose of this connector is to manage the two IO/CLK (SWD) lines and the UART in order to connect one or the other at the right time. By default, the UART is connected.

How to detect a flashing hand-shake :

• NRSTtoggle from high to low. This “reset” the STM32L0 and his bootloader look for what happen on the CLKpin.
• Just before NRST toggle to low the CLK pin already provide a synchro signal.
• The STM32L0 bootloader detects a signal on CLK pin and it initiates a hand-shake process.

The Smart Connector uses an ATtiny85 microcontroller and “in-house” firmware to monitor the RST transition, switch the lines and subsequently confirm this hand-shake phase.

Hand-shake

In order to visualize the hand-shake, here is a capture via a logic analyzer of the RESET and CLOCK lines during a flash of a small memory area. At first RESET goes low for ~ 38ms before going back up and the CLOCK is already running. This is the phase that the Smart-Connector must detect in order to switch to SWD mode very quickly for the flash to take place correctly. The end RESET is used to reboot the target.
It comes from parameter -rstwhen calling /STM32_Programmer.sh

Toggling the lines

To physically “toggling the lines” we use a dedicated component : the TMUX154E from Texas Instruments. Driven directly by a pin of the ATtiny, this component will act as a double “relay”, without the constraints of size and slowness of these. It’s super fast (in the order of a nanosecond), and uses 3.6 volts.

Smart Connector TMUX schematic :

ATtiny85 microcontroller

The ATtiny85 microcontroller is an 8-bit (10/20Mhz) AVR with 8 pins. Just enough for our application ! There is a compatible version of the Arduino framework and it can be flashed directly from the USB port of a PC as long as a Micronucleus bootloader has been injected beforehand. It is therefore sufficient to design a “USB form factor” PCB and voila ! We can flash it on the fly via a simple command :

./micronucleuse -run myWonderfulFirmware.ino.hex

Smart Connector ATtiny schematic :

PCB Design

In order to ensure all the functions for which the Smart Connector is designed, it must be inserted directly into the STLinkV2, offer a connector for the Tag Connect cable which connects to the STM32L0, a connector for the FTDI UART, and various selectors/switches used to select the general behavior. Without forgetting the USB connector to flash the firmware.

Smart Connector inserted in STLink V2 :

Firmware

Available here as open source !

The firmware is written in C language over the Arduino framework, and compiled via Arduino IDE. It consists, essentially, of a reset and clock detection functions and a state machine called in a loop. By default in “UART” mode, the firmware spends its time waiting for a reset and detecting a flashing hand-shake between the STLink and the STM32L0.

Smart Connector firmware pseudo-code :

while(1)
{
  if(RESET_DETECTED) // reset send by STLink to initiate hand-shake (physical reset pin to low)
  {
    toggleLines(); // toggle line from UART to SWD
    
    if(CLOCK_DETECTED) // clock send by STLink on SWCLK (STM32L0)
    {
      while(FLASHING_TIMEOUT)
      {
        if(!CLOCK_DETECTED) // clock stopped abruptly
          ERROR;
        if(RESET_DETECTED) // reset to indiquate successful end
          SUCCESS;
      }
    }
  }
}

Conclusion

And voilà !
It’s much more comfortable to only have to connect the board to the Smart-Connector once and have UART and reflash working together !
During long days of hardware development, it is worth its weight in time past !