Code gets stuck when loggin error due to AWS MQTT failure

[VernonNaidoo169]

FSP Version: 4.3 Debugger: J-Link (SWD) Processor: RA6M2 OS: FreeRTOS

Note: The project was configured with e2studio, and migrated across to using vscode, but this issue presents on both.

Description: When debugging, if there is an error on connection for MQTT, the code gets stuck in vLoggingPrintf. There is no hard fault or error of any kind, see call stack in image. Stepping in code does not move from the vprintf line. Perhaps some initialisation was not done prior to the code reaching this point?

[renesas-brandon-hussey]

Hi @VernonNaidoo169 , this appears to be an application issue and would better submitted to the Renesas Engineering Community here.

There's not much information to go on here, but when printf() is involved, the issue is typically related to the stack or heap. I'm not sure which toolchain you're using but if you're using GCC then IIRC it uses malloc() and attempts to allocate around 1KB of data on the first call. Have you checked to see if any memory allocation is happening? Is your stack or heap big enough? Do you have dynamic memory allocation enabled?

[VernonNaidoo169]

Hi @renesas-brandon-hussey, Thank you for the reply. I did open an issue on the forum that got no traction so was advised to open an issue here. My main stack is set to 0x1000 and the heap is 0x8000, so that should be more than enough to handle this. The individual thread stack is also ~45k so it should not be running out of RAM. Dynamic memory allocation is enabled. My working theory was some kind of initialization issue, as if I delay all my threads enough, I mostly (not always) make it passed this point. I will look into the possibility of this being memory running out.

[renesas-austin-hansen]

The default vLoggingPrint* definitions were causing build issues depending on compilers and libraries used and were replaced with empty stubs as of FSP v5.0.0. Users may create their own versions of these functions as needed.