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.

The plan is:

• Will use customized implementation of 'printf' to avoid reference low-level APIs and __stdout.
• This 'printf' will call USART directly.
• SVC printf will be removed. No log output under SVC mode.

https://review.trustedfirmware.org/c/trusted-firmware-m/+/2933
https://review.trustedfirmware.org/c/trusted-firmware-m/+/2934
https://review.trustedfirmware.org/c/trusted-firmware-m/+/2935
https://review.trustedfirmware.org/c/trusted-firmware-m/+/2936

https://review.trustedfirmware.org/c/trusted-firmware-m/+/2489
https://review.trustedfirmware.org/c/trusted-firmware-m/+/2955

With all these patches merged, the status is:

• SVC print is removed
• Others are using the customized print function: tfm_log_printf to output message.
• toolchain __stdout is removed.

To provide non-blocking operations, interrupts are used by any CMSIS-compliant USART driver. Typically supplied by silicon makers, these drivers are incompatible with the current TF-M implementation. x trench run

I saw this suggestion marked as solved. I don't know how it was resolved?
baldi's basics

USART rules that are compliant with CMSIS can cause them to trip, thus it is important to make sure there is enough unblocked access geometry dash unblocked

To provide non-blocking operations, interrupts are used by any CMSIS-compliant USART driver. The current TF-M method is incompatible with the drivers normally given by silicon makers. coreball

Thank you. The even recorder looks quite keil specific. trabajo de masajista

Making sure there is enough unblocked access is crucial since USART rules that are in compliance with CMSIS could trip them. Bitlife

This allows a developer to bring up a terminal emulator on the host PC and communicate with the DB410c using a command line interface tunnel rush. This can be very valuable when performing in depth debugging as well as using fastboot.