Semihosted serial from DISCO_F407VG to Eclipse

Mbed OS Hello world!
,
1

Hi,

I have a STM32F407G-DISC1 board, with which I can print messages to OpenOCD & gdb terminals in Eclipse CDT using the GNU MCU template for this target.

However I’ve not managed to get the same thing going in an Eclipse project generated via the MBed CLI.

I know the hardware support is there because it works with the GNU MCU template.
I have looked at every MBed guide I could find on the subject, official and not, but I’ve not had any luck so far. This is my source:

#include "mbed.h"
#include "mbed_trace.h"

void my_log(uint8_t dlevel, const char *group, const char *format, ...)
{
    va_list ap;
    va_start(ap, format);
    mbed_vtracef(dlevel, group, format, ap);
    va_end(ap);
}

Serial pc(USBTX, USBRX); // tx=2, rx=3

int main() {

    while(1) {
      	pc.printf("Hello 1\n");
    	printf("Hello 2\n");
    	my_log("Hello 3\n");
    }
}

This is how I generate my Eclipse project:

cd my-app/

mbed config root .
mbed deploy
mbed target DISCO_F407VG
#mbed target NUCLEO-F401RE

mbed config GCC_ARM_PATH "/home/user/opt/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.2.1-1.1.1/.content/bin"
mbed toolchain GCC_ARM

mbed config -L

mbed compile
mbed export --ide gnuarmeclipse

Finally, this is the OpenOCD trace I get when I launch a debug session for this project; note taht it says “semihosting is enabled”:

xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-11:25)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Started by GNU MCU Eclipse
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 2000 kHz
Info : STLINK V2J25M14 (API v2) VID:PID 0483:374B
Info : Target voltage: 2.880282
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x10076413
Info : flash size = 1024 kbytes
Info : flash size = 512 bytes
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x080002b8 msp: 0x20020000
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
semihosting is enabled

Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x080002b8 msp: 0x20020000, semihosting
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08001078 msp: 0x20020000, semihosting
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08001078 msp: 0x20020000, semihosting
===== arm v7m registers
(0) r0 (/32): 0x00000000
(1) r1 (/32): 0x00000000
(2) r2 (/32): 0x00000000
(3) r3 (/32): 0x00000000
(4) r4 (/32): 0x00000000
(5) r5 (/32): 0x00000000
(6) r6 (/32): 0x00000000
(7) r7 (/32): 0x00000000
(8) r8 (/32): 0x00000000
(9) r9 (/32): 0x00000000
(10) r10 (/32): 0x00000000
(11) r11 (/32): 0x00000000
(12) r12 (/32): 0x00000000
(13) sp (/32): 0x20020000
(14) lr (/32): 0xFFFFFFFF
(15) pc (/32): 0x08001078
(16) xPSR (/32): 0x01000000
(17) msp (/32): 0x20020000
(18) psp (/32): 0x00000000
(19) primask (/1): 0x00
(20) basepri (/8): 0x00
(21) faultmask (/1): 0x00
(22) control (/2): 0x00
(23) d0 (/64): 0x0000000000000000
(24) d1 (/64): 0x0000000000000000
(25) d2 (/64): 0x0000000000000000
(26) d3 (/64): 0x0000000000000000
(27) d4 (/64): 0x0000000000000000
(28) d5 (/64): 0x0000000000000000
(29) d6 (/64): 0x0000000000000000
(30) d7 (/64): 0x0000000000000000
(31) d8 (/64): 0x0000000000000000
(32) d9 (/64): 0x0000000000000000
(33) d10 (/64): 0x0000000000000000
(34) d11 (/64): 0x0000000000000000
(35) d12 (/64): 0x0000000000000000
(36) d13 (/64): 0x0000000000000000
(37) d14 (/64): 0x0000000000000000
(38) d15 (/64): 0x0000000000000000
(39) fpscr (/32): 0x00000000
===== Cortex-M DWT registers

I’m getting stuck here, could somebody help me setting this up ?

2

Hi
Do you know HW UART issue: DISCO_F407VG | Mbed ?
Regards,

3

No I did not, thanks for flagging that! (I was working with rev. 4 of the same user guide, UM1472, provided in the latest CMSIS pack available in Eclipse, STM32F4xx_DFP v2.14.0; it makes no mention of this.) I may try using a USART to USB dongle.

However, the GNU MCU template project for this platform does redirect console logs over the STLINK USB alright, so there has to be a pass-through… maybe using different tx/rx pins for the Serial?

4

Hello Pierre,

According to the “Select the MCU and various project settings” page it seems that the GNU MCU template is using an SWO (Serial Wire Output) for tracing rather than Semihosting. Wim Huiskamp published a good SWO library and also an example how to use it with NUCLEO boards. He also maintains a nice SWO viewer page.
Here you can find info on how to display the SWO output on screen when you cross-compile on Linux or Mac.

5

Ok that’s good to know. I posted the wrong link initially though, I was referring to this “hello World” example: Tutorial: Create a Hello ARM test project