Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32


nucleo f401re uart example

I tried the the nucleo f401re example UART_printf. Build fine with no error. When running the code I do not get any chars coming out of the TX (D1) pin.

Does anybody knows what’s wrong?
Did some googling and found this:

“By default, Arduino header pins D0 & D1 are disconnected on all Nucleos. Instead, Serial2 Tx/Rx are routed to the ST-Link board to give debug output over USB to host PC.
Refer to http://developer.mbed.org/platforms/ST-Nucleo-F401RE/Question and choose other pins for your motor connection.eg Serial1 Tx/Rx on D8/D2”

quote from here:
https://developer.mbed.org/questions/6017/Im-trying-to-make-a-uart-communication-w/Question

Can anybody confirm that?
Why would ST include a sample that does not work with the board?

Anyway attempted changing the code to Uart_1, but no luck so far.

Mat

Hi Mat,

Yep doesnt make so much sense to me either. You’ve figured it right anyway, I did the same last year with the 411RE also.
As you read, the UART is currently bridged over the ST-link’s virtual COM. First open the virtual COM and see the characters will be there hopefully.
After this you need to hackerise the board a little bit. I dont remember exactly but maybe couple zero ohms links need removing. In mine Id got the arduino uart enabled , then routed a spare UART over to the ST-link since its nice for printf debugging output.
something like attached.
hope it helps....
vik

vik,

thanks for yhe feedback. Now that you mention “virtual com’ it triggers some old memory.

I al;tready tried switching from Uart2 to Uart1 (pa9,pa10) but for some reason I don’t get any data ouyt of that either. migh be my mistake with the setup though. Still requires some more exploring.

mat


So I got things sorted. As Vik pointed out the serial interface 2 (pa2/pa3) is routed through the virtual com interface of th eprogrammmer’s USB interface. For those of you who are using Linux. it will be /dev/ttyACM0. So a simple cat /dev/ttyACM0 should echo all printf send from the foirmware side. in Fedora 24 or earlier there is something called ModemManager that gets in your way. Things run more smoothly if you disable it. the following worked for me:

systemctl status dbus-org.freedesktop.ModemManager1.service
systemctl disable dbus-org.freedesktop.ModemManager1.service
the easiet is now to reboot so Network manager stops using the ModemManager.

So I now finally get my data send out via serial from the F401 nucleo board. Cool. But there is still one caveat:
Mat



So now I can send data out via serial from the F401 nucleo board. Cool. But there is still one caveat:

The data I receive is distorted. Not all the char but roughly 3 out of 4.
For every char I send, I will receive one char.

I added delays sending between chars. same issue. So obviously no overfow issue.
I started switching baudrate. But no change.

I checked with my Saleae LA, hooking up to the TX/RX pins on the programmer board (right next to teh SWD header).
I see the same serial stream I see on the Host/PC side. So the corruption seems to already happen when the STM 32 F401 sends the data out.

I am using for testing the STM32 demo sample. So not sure what is wrong.

Anybody else encountered similar behaviour?
I never had such issue with my other ST board. So I am at loss right now.
Is there something wrong with the initialization of the chip?

Mat


Hi Mat,

What happens if you send the working character over and over again? Does it flake out sometimes? If so it could be a signal strength problem. I’d scope it and look at the data if you can.