Console via USART
Open, HighPublic

Description

Console on secure side is retargeted to CMSIS USART driver (./platform/ext/common/uart_stdout.c).

USART driver Send function is called also from SVC with highest interrupt priority which blocks the USART interrupt and leads to deadlock. This is not manifested with Musca USART drivers which implement blocking send - not compliant with CMSIS USART Driver. It does occur instantly with any other CMSIS compliant USART driver.

As far as I understand the console on secure side will be redesigned to cope with that.

There are also other issues with using the USART driver:

  • missing wait while busy after send
  • missing power on/off

This is being address with:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/1409/7/platform/ext/common/uart_stdout.c

It also tries to address printf retargeting issues however this needs another iteration.

Console on non-secure side is also retargeted to CMSIS USART driver (./app/main_ns.c) however has less constrains.

It has the same issues with using the USART driver:

  • missing wait while busy after send
  • missing power on/off

This is being address with:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/1409/7/app/main_ns.c

It also tries to address printf retargeting issues however this needs another iteration.

RobertRostohar triaged this task as High priority.

Hi Robert,

Is there any light weighted driver for console usage in CMSIS?

Due to the isolation is there, the SPM is the core part and it needs to output characters only; it does not need rich functions which never been used.

Hi Ken,

Unfortunately there is no lightweight CMSIS UART driver for console only.

However there are alternative options for I/O retargeting.

Event Recorder [1] could be used for retargeting STDOUT [2].

Event Recorder is a software component for event annotations that can be also used to collect console output. It is device agnostic and only requires an event buffer (no drivers). Event data is written into a buffer and read out by the debug unit and displayed.

[1] http://www.keil.com/pack/doc/compiler/EventRecorder/html/er_theory.html
[2] http://www.keil.com/pack/doc/compiler/RetargetIO/html/_retarget__examples_er.html

Thanks. The even recorder looks quite keil specific. Hmmm, let's try to find some other way.

TFM is involving a self-implemented printf, which means the existing solution is not applicable for re-targeting toolchain provided printf into putc/write.
So this can be a solution:

  • Reduce the log api into limited numbers, such as one api such as tfm_core_log_put_buf.
  • Adapt this tfm_core_log_put_buf API with USART driver.
  • During adapting we add power control and wait for busy.
  • Remove the busy wait in USART driver.

The only problem is this STDIO may be called inside SVC; but since we are not using interrupt mode usart at current so it should be applicable.
Please provide feedback.

Any CMSIS compliant USART driver will use interrupts in order to implement non-blocking functions. These drivers are typically provided by silicon vendors and they will not work when used with current TF-M approach.

Well. So the first step we are creating patches to add power/wait; after this we plan to purge the SVC calling to uart driver.

This comment was removed by mingyangSun.
davidwang reassigned this task from davidwang to KenLSoft.Wed, Nov 27, 3:06 AM

@KenLSoft will look at the UART interrupt support in SVC issue.