Using printf() with snapped NUCLEO board

I want to work towards making my own boards so as a first step I broke the programmer off of my NUCLEO-F401RE board and verified I could reconnect the two halves. I have a simple program in Mbed Studio where I blink the onboard led and do a printf() statement. With the detached programmer I can change the blink rate but I cannot see the printf() statement in the serial monitor as I normally do. My wiring is

SWCLK → PA_14
SWIO → PA_13
NRST → RST
SWO → PB_3
TX → PA_2
RX → PA_3
The jumper is removed from power(JP5)
JP6 is bridged
CN2 has the jumpers removed
JP4 is bridged
I have not changed any of the solder bridges on the bottom of the board.

When the program is uploaded the serial monitor prints nonsense so I assume PA_2 and PA_3 are connected to the st-link usb port.

I have tried removing the JP4 jumper as well as switching TX and RX but with no luck.

Hello,

  • Via JP6 you can measure the current what your MCU draws. So you not need to change it.
  • JP5 should be in position for E5V - position for E5V pin or VIN pin, if are as power supply
  • JP4 can be bridged when you want to use TX/RX from CN3
  • TX/RX must be crossed
  • Onboard Debug pins

BR, Jan

Thank you! I am now printing to the monitor. I must have tried switching the wires but not with JP4 jumped.

I am currently powering the board by connecting 3.3v from the stlink to 3.3v on the controller but I will add the power jumper and remove the wire when I switch to external power.

One more thing I found about the wiring.

I was a little confused when moving to using an external power source was that I had disconnected the 3.3v power between the stlink and microcontroller. When I unplugged the usb to the stlink the microcontroller stopped blinking. I then unhooked the SWD wires and it went back to blinking. So I guess you either have to keep the stlink powered at all times or disconnect it completely.

When I unplugged the usb to the stlink the microcontroller stopped blinking.

On STM boards the system clock for the main MCU is coming, by defalt, from the ST-Link’s crystal oscillator. If you unplug the USB cable after a successful startup the ST-Link loses power and the main MCU stops because there is no system clock coming from the ST-Link anymore.

I then unhooked the SWD wires and it went back to blinking.

This triggers a reset and when the MCU fails to startup with the ST-Link clock signal it falls back to generate the system clock with its internal RC oscillator.

So I guess you either have to keep the stlink powered at all times or disconnect it completely.

You are right. But there are two more options:

  • Configure the MCU to startup with its internal RC oscillator. Then you are free to disconnect the USB cable without stopping the MCU.

mbed_app.json :

{
    "*": {
        "overrides": {
            "clock_source": "USE_PLL_HSI"
        }
}
  • Install an 8MHz crystal along with decoupling capacitors for the oscillator on the main board and configure the MCU to startup with external crystal oscillator. In this case you are free again to disconnect the USB cable without stopping the MCU.

mbed_app.json :

{
    "*": {
        "overrides": {
            "clock_source": "USE_PLL_HSE_XTAL"
        }
}
1 Like

That is good to know. Is that just an output from the STM_JTCK pin on the st_link microcontroller because I do not see a connection between the oscillator on the st_link and the SWD header?

I have not changed any clock configurations before in mbed studio but I have cubeMX and can see the diagram. Will I lose some of my peripherals’ functions by not having that external clock and is there other performance disadvantages to using the internal one?

Unfortunately, the MCO signal is not available at any header/connector on the ST-Link board. However, you can reach it on the back side at solder bridge SB16.
On the main MCU board the external system clock (MCO) input is available at pin 29 of the Morpho Connector CN7 (Header 19X2).
For more info have a look at the user manual UM1724.

Will I lose some of my peripherals’ functions by not having that external clock and is there other performance disadvantages to using the internal one?

Generally, a crystal oscillator is more accurate than an RC one. However, the MCO signal is multiplied and divided inside the MCU with PLLs (Phase Locked Loops) and becomes quite accurate. As far as I can remember, the only peripheral you can loose when using the internal RC oscillator is the USB.

Thank you for helping me understand what is going on on the board. My plan was for my first custom board to just copy the components of my development board and then just add the sensors and extra voltage regulators I use on most of my projects. I assume in doing this there is no point in setting it up as a custom board in mbed studio.

In doing this does form factor matter? It looks like as long as its f401xE the memory size and pin assignment is the same.

For testing new ideas the NUCLEO/Arduino form factor fits very well. But if your plan is to build-in the custom board into your own equipment then a smaller form factor suits better. My favorite for such “projects” is this small form factor custom board equipped with an STM32F411CEU6. Because it has a 25MHz on-board crystal (opposed to the 8MHz NUCLEO boards) I decided to make a custom target for it.

FYI: here is another source for custom board examples:

NB: I will be happy to merge Blackpill support :slight_smile:

Thank you for the help! The main reason I was curious about alternate F4 chips is that I was having a really hard time finding any in stock is the US. I ended up finding some on RS though.

Hello Jerome,

Your offer is welcome! I have already made an attempt to merge it. However, I was not able to figure out how :frowning:

Classic way:

  • fork stm32customtargets repo
  • push into your fork
  • then open a pull request

Some build check will be automatically started,
and I merge! :slight_smile: