Skip to content

Instantly share code, notes, and snippets.

@skeptomai

skeptomai/stm32-rust.md

Created January 3, 2023 00:48
Show Gist options
  • Save skeptomai/1aa429479ce413085a30cdce69cc757f to your computer and use it in GitHub Desktop.
Save skeptomai/1aa429479ce413085a30cdce69cc757f to your computer and use it in GitHub Desktop.
Download ZIP
bunch of rust stm32 info
Raw
stm32-rust.md

STM F1 Datasheets

Open Bootloader

STM32 Projects

Blue Pill, Green Pill, Black Pill

Songhe Boards

Blue Pill Boards

Green Pill Boards

ST Link Clone repurposing

IDE and Code Generation (includes VSCode)

Debugging, problems, and solutions

Blinky programs

What did we learn?

  1. The boot pins can both remain at (0,0) not (1,0). I'm not sure how this didn't work before, when the st-link wouldn't attach. From one of the 'getting started' links above:
   When both BOOT0 and BOOT1 pins are LOW, then the internal Flash Memory acts as the main boot space and when BOOT0 is HIGH and BOOT1 is LOW, the System Memory acts as the main boot space. These two options are important for us.

The rest of that document seems to be misleading, because it says to use the (1,0) configuration:

   To upload the code to the Flash Memory of the MCU, you have to select System Memory as the main boot space. The reason for this is that the System Memory contains the embedded bootloader, which is programmed during the production itself by STMicroelectronics.

It appears this is for programming over the USB port rather than with the ST_Link module, and refers to having a bootloader. So (1,0) to load a bootloader and (0,0) over USB to use the bootloader to load user code. With the ST_Link, and with the generated code in CubeIDE, leave everything at (0,0) and user code + ivt are in flash

This seems to verify that thinking. There's a minimal SWD bootloader on the chip, and that's what the ST-Link uses. That goes directly to flash and is thus persistent. That's typically used to flash a bootloader that then uses USART both to upload user code and to output status.

From that link:

   Next, ALL STM32 chips have at minimum, an embedded serial boot loader. It is factory ROM and can not be erased. This means that an external interface(JTAG/SWD) is not required to program a STM32at in most instances.  Watch out for possible mismatches in voltage.
  1. At (1,0) it appears to put the user code in main memory but the ivt in flash, such that trying to run an isr causes a systrap
  2. Need the IOC code generator to create both an ISR and HAL handler for systick. That generates code in the /stm32f1xx_it.c/:
     void SysTick_Handler(void)
     {
       /* USER CODE BEGIN SysTick_IRQn 0 */

       /* USER CODE END SysTick_IRQn 0 */
       HAL_IncTick();
       /* USER CODE BEGIN SysTick_IRQn 1 */

       /* USER CODE END SysTick_IRQn 1 */
     }

and when the code and ivt are written to flash, and this becomes the handler in the ivt, and this code calls HAL_IncTick, everything works.

  1. Memory layouts

    This is from the linker file. Notice the isr vector (interrupt table) is the first section in "FLASH" Rom type memory

/* Memories definition */
MEMORY
{
  RAM    (xrw)    : ORIGIN = 0x20000000,   LENGTH = 20K
  FLASH    (rx)    : ORIGIN = 0x8000000,   LENGTH = 64K
}

/* Sections */
SECTIONS
{
  /* The startup code into "FLASH" Rom type memory */
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector)) /* Startup code */
    . = ALIGN(4);
  } >FLASH

And, this from /system_stm32f1xx.c/

/* Note: Following vector table addresses must be defined in line with linker
         configuration. */
/*!< Uncomment the following line if you need to relocate the vector table
     anywhere in Flash or Sram, else the vector table is kept at the automatic
     remap of boot address selected */
/* #define USER_VECT_TAB_ADDRESS */

#if defined(USER_VECT_TAB_ADDRESS)
/*!< Uncomment the following line if you need to relocate your vector Table
     in Sram else user remap will be done in Flash. */
/* #define VECT_TAB_SRAM */
#if defined(VECT_TAB_SRAM)
#define VECT_TAB_BASE_ADDRESS   SRAM_BASE       /*!< Vector Table base address field.
                                                     This value must be a multiple of 0x200. */
#define VECT_TAB_OFFSET         0x00000000U     /*!< Vector Table base offset field.
                                                     This value must be a multiple of 0x200. */
#else
#define VECT_TAB_BASE_ADDRESS   FLASH_BASE      /*!< Vector Table base address field.
                                                     This value must be a multiple of 0x200. */
#define VECT_TAB_OFFSET         0x00000000U     /*!< Vector Table base offset field.
                                                     This value must be a multiple of 0x200. */
#endif /* VECT_TAB_SRAM */
#endif /* USER_VECT_TAB_ADDRESS */

/******************************************************************************/

Semihosting and OpenOCD

Embedded Rust

These require an /Embed.toml/ file that describes /rtt/ and /gdb/ target behaviour

[default.probe]
# USB vendor ID
# usb_vid = "1337"
# USB product ID
# usb_pid = "1337"
# Serial number
# serial = "12345678"
# The protocol to be used for communicating with the target.
protocol = "Swd"
# The speed in kHz of the data link to the target.
# speed = 1337

[default.flashing]
# Whether or not the target should be flashed.
enabled = true
# Whether or not bytes erased but not rewritten with data from the ELF
# should be restored with their contents before erasing.
restore_unwritten_bytes = false
# The path where an SVG of the assembled flash layout should be written to.
# flash_layout_output_path = "out.svg"

[default.reset]
# Whether or not the target should be reset.
enabled = true
# Whether or not the target should be halted after flashing.
halt_afterwards = false

[default.general]
# The chip name of the chip to be debugged.
chip = "stm32f103C8"
# A list of chip descriptions to be loaded during runtime.
chip_descriptions = []
# The default log level to be used.
log_level = "WARN"

[default.rtt]
# Whether or not an RTTUI should be opened after flashing.
# This is exclusive and cannot be used with GDB at the moment.
enabled = true
# A list of channel associations to be displayed. If left empty, all channels are displayed.
channels = [
    # { up = 0, down = 0, name = "name" }
]
# The duration in ms for which the logger should retry to attach to RTT.
timeout = 3000
# Whether timestamps in the RTTUI are enabled
show_timestamps = true

[default.gdb]
# Whether or not a GDB server should be opened after flashing.
# This is exclusive and cannot be used with RTT at the moment.
enabled = false
# The connection string in host:port format wher the GDB server will open a socket.
# gdb_connection_string

** Cargo installed stuff

cargo-binutils v0.3.4:
    cargo-cov
    cargo-nm
    cargo-objcopy
    cargo-objdump
    cargo-profdata
    cargo-readobj
    cargo-size
    cargo-strip
    rust-ar
    rust-cov
    rust-ld
    rust-lld
    rust-nm
    rust-objcopy
    rust-objdump
    rust-profdata
    rust-readobj
    rust-size
    rust-strip
cargo-clone v1.0.0:
    cargo-clone
cargo-embed v0.12.0:
    cargo-embed
cargo-flash v0.12.1:
    cargo-flash
cargo-generate v0.11.1:
    cargo-generate
cargo-xbuild v0.6.5:
    cargo-xb
    cargo-xbuild
    cargo-xc
    cargo-xcheck
    cargo-xclippy
    cargo-xdoc
    cargo-xfix
    cargo-xinstall
    cargo-xpublish
    cargo-xr
    cargo-xrun
    cargo-xrustc
    cargo-xt
    cargo-xtest
itm v0.3.1:
    itmdump
rust-analyzer v0.0.0 (/Users/christopherbrown/Projects/rust-analyzer/crates/rust-analyzer):
    rust-analyzer

** Rustup installed targets

aarch64-apple-darwin
thumbv7em-none-eabihf
thumbv7m-none-eabi
wasm32-unknown-unknown
wasm32-wasi

GDB enhancements

NOTE: this doesn't work on brew-install eabi-gdb

pip3 install pygments

gdb dashboard

Oh, wait, there's an /arm-eabi-gdb-py/ binary.. NOTE Try this!

General embedded stuff

SVD is kinda like device tree. It takes the Arm Cortex-M peripheral info and schematizes it. Tools can read the SVD and generate code.

Hardware on order

Amazon.com order number: 114-3226663-6252266
Order Total: $8.91

Shipping now
 
Items Ordered	Price
1 of: UGREEN Mini USB Cable, 2 Pack USB 2.0 Cable Nylon Braided USB Mini B Charging Cord Compatible with GoPro Hero 3+, PS3 Controller, Digital Camer, Dash
Sold by: UGREEN GROUP LIMITED (seller profile) | Product question? Ask Seller 

Condition: New
$8.99

Amazon.com order number: 114-2864060-6056232
Order Total: $50.24

Preparing for Shipment
 
Items Ordered	Price
1 of: STMICROELECTRONICS STM32F3DISCOVERY EVAL KIT, STM32 F3 Series Discovery
Sold by: Aleksandra & Co. (seller profile) 

Condition: New
$45.63

Amazon.com order number: 
Order Total: $51.74

Shipping now
 
Items Ordered	Price
1 of: BOJACK 14 Vaules 840 pcs 2-125mm Solderless Flexible Breadboard Connecting Line Cables Breadboard Jumper Wires kit
Sold by: BOJACK ELECTRON (seller profile) 

Condition: New
$13.99
1 of: 4PCS Breadboards Kit Include 2PCS 830 Point 2PCS 400 Point Solderless Breadboards for Proto Shield Distribution Connecting Blocks
Sold by: REXQualis Official US (seller profile) 

Condition: New
$11.98
1 of: BOJACK 20 Values 200 Pcs Inductor 1 uH to 4.7 mH 0.5 W Color Ring Inductor 1/2 Watt Assortment Kit
Sold by: BOJACK ELECTRON (seller profile) 

Condition: New
$13.99
1 of: BOJACK 1000 Pcs 25 Values Resistor Kit 1 Ohm-1M Ohm with 5% 1/4W Carbon Film Resistors Assortment
Sold by: BOJACK ELECTRON (seller profile) 

Condition: New
$10.99
1 of: Swpeet 240Pcs 24 Kinds Different Electrolytic Capacitors Range 0.1uF－1000uF Assortment Kit, 10V/16V/25V/50V Aluminum Radial Electrolytic Capacitors for TV, LCD Monitor, Radio, Stereo, Game
Sold by: Swpeet (seller profile) 

Condition: New

Upload utilities including dfu-util

From [[https://arduino.stackexchange.com/questions/67733/how-do-i-upload-an-arduino-stm32-binary-from-the-mac-command-line][stm binary upload from the command line on a mac]]

There are several different tools for uploading binaries to a Cortex M3. Depending on the board (not chip) configuration, they include (ht: Majenko):

dfu-util through an FT232 adapter
stm32flash through serial
micronucleus through the Micronucleus bootloader
stlink through an STLink programmer
Many Arduino flavors use a board with some kind of USB or FT232 adapter. In this case:

the STM32 line of processors include a DFU (device firmware update) bootloader in ROM.

The dfu-util project supports a Mac version of dfu-util, their command line DFU tool.

Note that this answer is identical for any binaries which run on the processor, be they Arduino sketches or programs developed with other frameworks.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment