STM32F107 Software Reset breaks Interrupt functionality

[David Wallén]

I have FreeRTOS set up on an STM32F107 performing several tasks of different priority in "parallell".

There is one task of IDLE priority that blinks an LED and one task of Normal priority that receives communication over CAN (triggered by external interrupts). There are also some tasks that reads values off the ADC and uses DMA.

There is also a bootloader in place that can receive new firmware via CAN.

When the MCU is powered it starts in the bootloader, and a custom CAN message kicks it to the application, and everything works fine. The application can receive messages from CAN, blink the LED and execute calculations just fine.

Another custom message can bring it from the application back to the bootloader (via a call to NVIC_SystemReset()), which works. But it is when attempting to bring the MCU back to the application (after NVIC reset) that things start to behave weirdly:

Sometimes, roughly ~60% of the time, the MCU seems to not enable interrupts. The LED blinks just fine (indicating the RTOS is still running its most low-priority task) but the application is not responding to CAN messages. Which to me indicates that interrupts have not been set up correctly.

I have tried putting LED indications on hardware fault handlers and failure to initialize CAN without any success, so I am not sure what the MCU is doing.

I also tried disabling IRQ and all system clocks before calling the NVIC reset without any luck.

Do you have any ideas on how to troubleshoot this further?

Is there any recommended procedure to perform before calling NVIC_SystemReset?

Thanks in advance!

BR,

David

[Bob S]

And I think "uninitialized memory" is a red herring (not the real issue). As I said, the "C" startup code initializes all of RAM that it THINKS your program is using. If some RAM is really not getting initialized (like any dynamically allocated memory) then clearing memory at the start of the program (or before rebooting) only masks the actual problem.

[Alexey Trifonov]

Hi Bob,

In case of not initialized variables in code, we can know that, by using this approach.

Best Regards,

Alexey

[Bob S]

You need to look at the TX line to know what baud rate (and UART clock/prescaler) is actually being used by your CPU. The RX line tells you what OTHER devices on the CAN bus are using. I'm not that familiar with CAN, but you may have to modify things to get your board to send something.

Do you have a serial port that you can output debug info to? Or can you run the STLINK debugger while running this code? You need to find out what how the system clock is configured and all the relevant CAN config registers. Presuming of course that this is the actual problem.

[Bob S]

Maybe, maybe not. If it is an uninitialized variable, clearing RAM may ALTER the behavior, it may fix it, or it may have no (visible) effect. It all depends on what the uninitialized variable is intended to hold and where in memory the variable is located.. For example, if the variable is a local variable that has some path through the code that doesn't initialize it (though the compiler *ought* to complain about that *if* he has that warning enabled), then clearing RAM at the start of the program could have no effect on this because the variable will depend on what was pushed on the stack in that location before that function was called, IF anything was indeed pushed onto the stack at that location previously.

And if clearing RAM makes the program APPEAR to work correctly, that still doesn't mean it truly is working. It may have just changed how the error manifests itself.

The REAL answer is still to find out what was uninitialized.

[Tesla DeLorean]

The common trap is that local/auto variable aren't initialized by default, and will contain random stack junk.

Thus a compelling case for

void SystemClock_Config(void)
{
  RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};
  RCC_OscInitTypeDef RCC_OscInitStruct = {0};
 
...
}