STM32_WPAN not possible to build without adv_trace and UART peripheral enabled

[christianegerer]

I'm trying to configure and generate a project with STM32CubeMX for the STM32WBA5MMGHx BLE module.

When enabling the STM32_WPAN middleware, the ADV_TRACE module gets automatically enabled under Utilities. This in turn requires to enable at least one UART/LPUART peripheral, otherwise type UART_HandleTypeDef is undefined and compiler throws and error:

../../Core/Inc/app_conf.h:304:8: error: unknown type name 'UART_HandleTypeDef'; did you mean 'RTC_HandleTypeDef'?
[build] 304 | extern UART_HandleTypeDef huart1;
[build] | ^~~~~~~~~~~~~~~~~~
[build] | RTC_HandleTypeDef

The STM32_WPAN throws a warning about not configured/wrong Platform Settings.

Is there any possibility to configure STM32_WPAN without ADV_TRACE enabled?

Used STM32CubeMX version is 6.17.0 and WBA firmware v1.19.0 and cmake project is generated.

[Pierre_Agneray]

Hi,

I’m sorry to bother you, but I am currently facing a very similar issue.

I am working on a project based on the STM32WBA65, using the BLE stack along with the sequencer (UTIL_SEQ). I started from the BLE_DataThroughput example provided by ST and I am adapting it to my custom hardware.

However, my board does not include any UART peripheral, and I do not need any UART-based debug or trace functionality.

The problem is that CubeMX forces the ADV_TRACE middleware to remain enabled when BLE is activated. As a result, the project depends on UART (for example UART_HandleTypeDef huart1), which leads to compilation errors such as:

unknown type name 'UART_HandleTypeDef'

This seems very similar to the issue you described.

Have you made any progress on this topic or found a clean workaround to remove the UART dependency?

I would be very interested in any suggestions or best practices.

Thank you in advance!

Best regards,
Pierre

 

[Andrew Neil]

---

@christianegerer wrote:

otherwise type UART_HandleTypeDef is undefined and compiler throws an error:.

---

Have you checked to see if there's any #if which should be disabling that line?

If that's the only error, then a workaround would be to just delete or comment-out that line.

[christianegerer]

@Andrew Neil : the part of the code is auto-generated by CubeMX. Of course a workaround is to manually delete/comment this line after each code regeneration. It's just annoying. Additionally, at least for CMake based project, CubeMX adds the file adv_trace_usart_if.c  to the target sources in the auto-generated cmake/stm32cubemx/CMakeLists.txt file. So if you comment out the line

extern UART_HandleTypeDef huart1;

in app_conf.h, you also need to remove adv_trace_usart_if.c from the target sources by doing something like this in the root CMakeLists.txt:

get_target_property(COMMON_SRC Common SOURCES)
list(REMOVE_ITEM COMMON_SRC ${CMAKE_CURRENT_SOURCE_DIR}/cmake/stm32cubemx/../../Projects/Common/WPAN/Interfaces/adv_trace_usart_if.c)
set_target_properties(Common PROPERTIES SOURCES "${COMMON_SRC}")

Otherwise, you get more compile errors in adv_trace_usart_if.c. Don't know if a similar workaround is possible for the Eclipse-based CubeIDE.

Actually, it would be nice if CubeMX would allow a custom logging backend besides UART. I actually replaced now adv_trace_usart_if.c with a custom adv_trace_rtt_if.c to log via Segger RTT. But it still requires to define a UART peripheral in CubeMX because of this line above in app_conf.h. Fortunately, I have the spare pins available to define a LPUART peripheral on my custom board although I don't use it.

@Pierre_Agneray : If you can afford it, i.e., if you have spare pins on your custom board, you can just enable a UART/LPUART in CubeMX as the easiest workaround. If not, I think you need to manually modify the auto-generated sources. Maybe it can be even automated. Haven't tried that except for the CMake part in my setup.

Anyway, to me it looks like a logical error in the auto-generated sources by CubeMX and I hope ST fixes this in an upcoming release (and maybe even allows custom logging backends).

[Pierre_Agneray]

@christianegerer  Thank you very much for your detailed answer.

Enabling a UART/LPUART peripheral does indeed fix the issue on my side, so I will use this workaround for initial testing.

However, I will eventually need to remove the UART in the final version of my project, as I am working on a low-power system. Keeping an unused UART enabled could negatively impact power consumption, which I would like to avoid.

@Andrew Neil You are right, manually deleting or commenting out the generated code is a possible workaround. However, in practice it quickly becomes quite tedious, as the UART introduces multiple dependencies across many generated files

@christianegerer I also find your idea of automating the cleanup process very interesting. I may try to write a small Python script to remove the unwanted files and references after code generation, although this also adds some complexity to the workflow

In any case, this does seem like a limitation (or inconsistency) in the current CubeMX code generation, and I hope it will be improved in a future release.

Thank you all for your help and insights.

Best regards,
Pierre

[Imen.D]

Hello All,

I will inform our CubeMX team about this related request and your feedback.

@Ghofrane GSOURI Could you please review this post.

Thank you for your contribution.