System Workbench with STM32CubeMX troubles
that looks fine to me - are you sure the code is actually _not_ working?
eg: here’s the output of a successful launch of something I’m working on, generated using CubeMX and running on SW4STM32 on Kubuntu 18.04 :
Open On-Chip Debugger 0.10.0-dev-00011-g46c94c8 (2018-09-06-08:38)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Warn : Could not determine executable path, using configured BINDIR.
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter_nsrst_delay: 100
adapter speed: 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2.1 JTAG v29 API v2 M18 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.267509
Info : Stlink adapter speed set to 950 kHz
Info : STM32F107VCTx.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Stlink adapter speed set to 950 kHz
adapter speed: 950 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08008984 msp: 0x20010000
Info : Stlink adapter speed set to 4000 kHz
adapter speed: 4000 kHz
- Programming Started **
auto erase enabled
Info : device id = 0x10016418
Info : flash size = 256kbytes
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20010000
wrote 81920 bytes from file Debug/EthernetUDPTest.elf in 3.469247s (23.060 KiB/s)
- Programming Finished **
- Verify Started **
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000
verified 81148 bytes in 1.176350s (67.366 KiB/s)
- Verified OK **
- Resetting Target **
Info : Stlink adapter speed set to 950 kHz
adapter speed: 950 kHz
shutdown command invoked