I have created a new STM32 project using cube. I have changed main.c to main.cpp and enabled --cpp in the compiler. If something complains I add extern c so c++ can see it.

I have c++ code running "fine". However now that I started using interrupts I'm experiencing some problems.

I am using UART and HAL. I have defined HAL_UART_RxCpltCallback as extern "C" void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart). When there is a new character in UART the interrupt is executed and the function called correctly. As far as I understand my code is running in c++ in the callback and should be able to access my objects methods.

I want to execute m.onReceiveCharacter() from the callback where m for now is a global variable in the main.cpp file. The object has the method I try to call. I add that line to the interrupt and I can see with the debugger that the function is called and I can go trough it correctly.

However what happens is that sometimes (I still haven't found the logic) some of the members of m change for no apparent reason. For example I have a private member UART_HandleTypeDef* huart that is pointed to the right huart at the beggining when I initialize and after an interrupt (before even the m.onReceiveCharacter() is executed) changes "randomly" to another address.

Usually, if I have a function in the main loop doing some operations on m and the interrupt comes then suddenly the value of huart is changed. The value of huart is never changed in any way in the code and this happens before the interrupt code inside the function is called (but the callback function already entered to). I have seen similar issues with other variables that are also not to be changed.

Any ideas?

Summary: Some of the members of my object change "randomly" to new values when an interrupt comes. What are the possible causes? I am using STM32F030R8, with a project generated by Cube, in Keil compiler version 5.


closed as off-topic by Lundin, Elliot Alderson, Dwayne Reid, RoyC, Warren Hill Dec 17 '18 at 12:22


  • 1
    \$\begingroup\$ Impossible to debug without the code. Though if you have trace possibilities in your debugger, simply set a write breakpoint on the data and see who's the culprit. \$\endgroup\$ – Lundin Dec 11 '18 at 11:47
  • 3
    \$\begingroup\$ I'm voting to close this question as off-topic because the problem cannot be reproduced. How to create a Minimal, Complete, and Verifiable example. \$\endgroup\$ – Lundin Dec 11 '18 at 11:48
  • \$\begingroup\$ Can other functions of m be interrupted by m.onReceiveCharacter()? \$\endgroup\$ – Jeroen3 Dec 11 '18 at 12:27
  • \$\begingroup\$ Generally you should try to do as little in an ISR as possible. Could you perhaps set a flag or buffer the character and then deal with it in something called from the main loop? \$\endgroup\$ – Chris Stratton Dec 11 '18 at 13:52

After creating a very simple project and seeing it work I went back to the code. Going slowly with the debugger I found some functions after each the values went random. The functions were doing nothing to those values! And it happened right after entering in them, without executing any code. Then it came to me, stack overflow! I doubled the stack and now all the problems are gone.

