The Ware House

Flash – Boot – Debug

Now that I have an executable bootstrap, I need to flash an actual board with it to check if it works as expected. On a member of the STM32F030 family, there are two options for flashing:

  • Use the Software Debug (SWD) interface with a ST-Link adapter and an utility software to flash.
  • Use the serial interface to communicate with the boot loader in System Memory via an USB to serial adapter.

As the bootstrap code I want to test does nothing except giving control to an idle loop, I will need extra debugging on top of the flashing functionality, so the SWD interface is a must for what I want to achieve here.

ST-Link

SWD interface

Arm Serial Wire Debug Port (SW-DP) is provided as a two wire interface. On the STM32F030, the functionality is activated at reset on two pins (PA13=SWCLK, PA14=SWDIO). Most boards available online have pre-soldered pins for Vcc=3.3V, Gnd, SWCLK and SWDIO.

ST-Link v2

ST-Link is an in-circuit debugger/programmer for the STM8 and STM32 chipsets. There are three versions of the product as well as mini versions. I am using ST-Link v2 mini clones. For simple use cases, the ST-Link can provide power to the board to flash or test.

ST-Link v2 mini clone connected to STM32F030F4P6 based board

STM32 ST-Link Utility

Referenced as STSW-LINK004 on STMicroelectronics website, the STM32 ST-Link Utility comes with USB drivers and a firmware upgrade utility for the ST-Link. It’s a win32 application and there are regular updates to support the latest chipsets. I am currently using version 4.6.

Roadtesting the Bootstrap

First we activate the connection in the utility.

15:38:14 : ST-LINK SN : 57FF70064986515251411687
15:38:14 : ST-LINK Firmware version : V2J37S7
15:38:14 : Connected via SWD.
15:38:14 : SWD Frequency = 4,0 MHz.
15:38:14 : Connection mode : Connect Under Reset.
15:38:14 : Debug in Low Power mode enabled.
15:38:14 : Device ID:0x444 
15:38:14 : Device flash Size : 16KBytes
15:38:14 : Device family :STM32F030x4/F030x6

Then load the bootstrap code. Either binary, Intel hex or Motorola S rec format are supported. Our Makefile as rules for binary and Intel hex, objcopy also support Motorola S record as an output format. Last build produced boot.hex.

15:47:32 : [boot.hex] opened successfully.
15:47:32 : [boot.hex] checksum : 0x00000226 

Program and verify.

15:48:19 : Memory programmed in 2s and 250ms.
15:48:19 : Verification...OK
15:48:19 : Programmed memory Checksum: 0x00000226

Finally check the registers in the MCU Core Panel:

MSP: 0x20001000
PC:  0x8000008

After reset, the stack pointer has been initialized and the program counter is on the idle loop under execution.

If we check the Programming Manual PM0215 STM32F0xxx Cortex-M0 programming manual, we can read the following about the registers MSP and PC:

Stack pointer (SP) register R13
In Thread mode, bit[1] of the CONTROL register indicates the stack
pointer to use:
● 0: Main Stack Pointer (MSP)(reset value). On reset, the processor
loads the MSP with the value from address 0x00000000.
● 1: Process Stack Pointer (PSP).

Program counter (PC) register R15
Contains the current program address. On reset, the processor loads the
PC with the value of the reset vector, which is at address 0x00000004.
Bit[0] of the value is loaded into the EPSR T-bit at reset and must be
1.
  • According to this, initial values for MSP and PC registers are fetched from address 0x00000000 and 0x00000004 respectively, but we have located our isr table at the beginning of the Flash memory at address 0x08000000! This works because the memory space at address 0 is a mirror of another memory area. Which area is mirrored depends of the state of the BOOT0 pin. On the board I am testing, there is a jumper to select either Flash or System memory by setting the state of the BOOT0 pin to high or low.
  • The ESPR T-bit, mentioned in the description of the PC register is the Thumb bit. As I highlighted before when we checked the output of our first build, bit 0 of the second entry in our isr table is set to 1 as requested by this specification.

Checkpoint

We have used the Serial Wire Debug (SWD) interface to flash and debug our bootstrap in an actual board using a ST-Link hardware adapter and STM32 ST-Link Windows utility.

Next I will provide feedback of execution directly through the board.

Back to top