If you’ve successfully integrated STM Shell, meaning you’ve got a prompt on your terminal, then this page isn’t for you. But you may still want to read it as a prophylactic measure. To put it bluntly, maybe you were successful only because your STM32 is too small. There, I said it, I’ve shamed the size of your microchip. Deal with it.

All joking aside, here are some of the problems I’ve come across using different targets.

1.   Check your NUCLEO

If you’re using a NUCLEO, keep in mind that those tend to have a lot of solder bridges. There are two reasons why :

• Offering you flexibility in configuring the board for your application.
• Allowing ST to reuse the same circuit board for STM32 devices with different pinouts.

I’ll never say it again : RTFM. Each NUCLEO’s manual contains a complete list of all its solder bridges, what they do, and their factory setting. But also, do not trust the manual blindly. Perform a visual inspection of your NUCLEO to ensure it is setup the way you think it is.

A common issue with the default configuration is that it may or may not route the ST-LINK’s clock output to the STM32’s clock input. You can then end-up with a board that can be programmed but does nothing. It’s usually just a matter of closing the right solder bridge. Another issue is the UART connection between the ST-LINK and STM32. It could be open, or it could be routed to the wrong pair of pins. Again, this can be sorted-out by opening or closing the right solder bridges.

Funny how each NUCLEO comes with an on-board ST-LINK, when they really ought to ship them with a free soldering iron…

2.   VCP Driver

Again a NUCLEO issue. The ST-LINK probe on your NUCLEO is a composite USB device that combines in one package a JTAG probe and a USB-to-Serial bridge (VCP).

Funny thing is, when you install STM32CubeIDE and it offers to install the relevant drivers, those drivers only cover the probe functionality. Depending on your computer’s OS you may need to install a driver so the NUCLEO also appears as a COM port on your computer.

You can find this driver on the ST website, here.

3.   Linker Voodoo

Some microcontrollers introduce additional complications to the use of DMA. That could be why you’re missing a prompt on your terminal. You won’t face this on a puny STM32F103. This issue is typically reserved to the largest and fastest STM32, including (but not limited to) the STM32H7 family.

The root of the problem isn’t the chip itself (it’s great) but some of the assumptions made by STM32CubeIDE when you create a project. And as we all know…

In other words, you should really pay close attention to the memory organization of the specific STM32 device you’re targeting.

Should you find that your DMA controller can only really read from a specific SRAM block, you will need to make sure that STM Shell internal variables end-up in that SRAM block.

You can do so through your project’s linker script. If you’ve never had a reason to open one or have no idea what they are, you can find yours in the root of your project. Those are files with the “ld” extension. Depending on the microcontroller you may get one or two, with names ending in _FLASH.ld and _RAM.ld.

You may only get a “FLASH” linker script, but if your chip is capable of running code from RAM you will also get a “RAM” linker script. If you’re unsure which script you’re currently using, by default you’re linking to Flash your code, so that should be your clue. To make extra-sure and/or change your script, you need to open your project’s properties :

I’ve taken the step to attribute STM Shell variables to a “.shell” linker section, therefore all you need to do is declare that section in your linker file and point it to the RAM area you require. Here’s an example of what it could look like :

  .shell :
  {
	. = ALIGN(4);
	*(.shell)
	*(.shell*)
	. = ALIGN(4);
  } >RAM_D1

If you’re unfamiliar, I strongly suggest reading the official GNU ld documentation at https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_chapter/ld_3.html as linker script language is really unintuitive.