serial.printf get stucks in WWDG_IRQHandler when using compiled mbed instead of sources (but stdio printf works)

02 Jun 2018

Hi, I have ported mbed to custom targets (STM32F3 and STM32L4), the project has been created via CLI and then exported to SW4STM32 (vi aCLI exporter). Some serial.print statements are used, they are working fine.

I made a second project including compiled mbed instead of sources, the compiled mbed folder has been created with CLI tool (from the working mbed-os folder of the first project). This project compiles and works fine, except the serial.printf statements are ending in WWDG_IRQHandler which basically is a crash improperly handled (it stucks here).

I noticed something interresting ; stdio printf statementsare working fine. so I believe somehow the mecanism redirecting stdio printf to the uart port is not the same as the one used for serial.printf (maybe it doesnt use stream?).

Anyway, that's how it is, on the project with mbed source both serial.printf and printf are working fine, none stucks in WWDG_IRQHandler. On the project with compiled mbed (totally identical otherwise), serial.printf always stucks in WWDG_IRQHandler and stdio printf works fine. The problem is not related to the main code which only setup serial ports and oes printf/serial.printf statements. I did the same for the second target, the exact same problem is occuring.

If anyone has a clue please advise (mbed support if you hear me... Thank you.

02 Jun 2018

ok i found some clues about the problem after more step debugging in instruction mode, in one of the projects, there was a preprocessor define:

DEVICE_SERIAL_ASYNCH

I removed it and suddently the serial.printf statements worked and are not stuck in WWDG_IRQHandler anymore. However, the problem is not fully solved since the same project for the second target doesnt have this preprocessor define, so i couldnt remove it, and so the problem is stil there.

EDIT: i removed DEVICE_SERIAL_FC=1 in the second project and now serial.printf is working too. So these two defines were apparently the cause of the problem.