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 two short videos (registration required) highlighting:

System Workbench for STM32


Redirect printf for STM32L476 Discovery?

ST’s seminar for the STM32L476 Discovery used IAR tools and the labs included source to redirect printf and scanf to a USART in order to use the STLink debugger connection via a terminal emulator running on a PC.

I’d like to do the same thing with the System Workbench, but I find the gcc-arm toolchain doesn’t work the same as IAR. I found a template online to implement the redirect, but was wondering if anyone has actual working code to do this that they’d care to share.

The directions I found so far indicate the _read() and _write() methods can be rewritten to redirect to/from a USART.

Thanks, Max

I’ll pass on what I found so perhaps others will not have to waste as much time as I did on it.

Here’s a code snippet of what I found worked to redirect printf() and scanf() though USART2:

int _write (int fd, char *ptr, int len)
{
HAL_Status = HAL_UART_Transmit(&huart2, (uint8_t*) ptr, len, 0xFFFF);

return len;
}

int _read (int fd, char *ptr, int len)
{

*ptr = 0x00; // Flush the character buffer

HAL_Status = HAL_UART_Receive(&huart2, (uint8_t*) ptr, 1, 0xFFFF);

return 1;
}


I found by trial and error if I didn’t have the line to clear the buffer, the old data was retained ... causing an endless loop if you’re looking for a cetain character to generate a response.

The read is a simple single character. Those familiar with HAL should be aware that reading in a longer string will require a more complex solution where you to set a ring buffer ..... and is probably best done with DMA.

There were other things needed to get the terminal emulator on the PC working:
Install Windows lib_usb support with Zadig
Update the STLink firmware
Run the terminal emulator in administrator mode (perhaps a Windows 10 quirk?)
Modify printf statements to end with a return and line feed

For the record, this is my environment:
Windows 10 laptop, Intel i5
Eclipse Mars.1 Release 4.5.1
GNU Tools Arm Embedded 4.9 2015q3
OpenSTM32 1.5.2
WinUSB (v6.1.7600.16385)
STM32CubeMX V 4.10.0
STM32L476 Discovery
ST-Link V3.7.0


Just simply download the STM32cubeL4.zip archive. You’ll find it on the STM web page. Latest version I think is 1.2.0.
This includes bunch of examples for the L4. It comes with SW4STM project file. Look for UART/UART_Printf.

Just load it in ac6/system workbench. Build it and try it.

Mattes,

Thanks for the pointer! I downloaded this large file and it looks like it contains a wealth of useful examples.

The UART_printf you mentioned is for the STM32L4-EVAL board and according to the comments in the main.c file depends on a linked library Small printf?

I’m not sure what this is ..... but I was able to import and build the SW4STM32 project. :-) I didn’t try to modify it to run on the Discovery board yet.

Thanks again, Max


I stumbled across that myself. But the STM Cube/HAL libs brings everything you need. Just build and load it. it will work out-of-the box.
Mat


sprintf coem wsith defeual gcc lib it’s not very big and you shoudl have penty of flash with the l476

uart TX wit DMA is trivial just grab the code from the sample (if yu sue cueblx you ned to enabel uart interutp and TX dma channel)
reception untils some char is not suited for dma that just does fxie size xfer
but you can do this by using chatr by char interrupt base rx and checking for last one in the hal callback or reckign one lmore byte reception.

if you need print (not scan) for debug it coudl be more convenient and less intrusive (faster no uart needed) to use itm trace
trace view is not integrate in eclispe/opencod but you can use stlink utiity for that.
You lose ability to debug at same time but speed is quite good (2MHz spi like) thsi can be almost be Real time trrace if you send single char.

last you can use semihosting that provdie i/o (not only console but also file access) in host system via the debug link
but this is relatively slow , it require ssome extra coding lib (rdimon) etc ...
you may find all that in the gnu arm eclispe template or even maybe on sw4stm32 templates.


Excellent !

I have try rewrite fputc() so many times but failed.

_write just works !

But I want to know why fputc() doesn’t work.