Loading...
 

Zephyr project on STM32

   Zephyr Workbench, a VSCode extension to manage Zephyr on STM32.
It enables users to easily create, develop, and debug Zephyr applications.
Main features:
  • Install host dependencies.
  • Import toolchain and SDK.
  • Create, configure, build and manage apps.
  • Debug STM32.
You can directly download it from the VSCode marketplace
For more details, visit the Zephyr Workbench

System Workbench for STM32

Forum List Topic List

You are viewing a reply to SysTick_Handler doesn't trig under Debug mode  

SysTick_Handler doesn't trig under Debug mode

Posted by arulprabhu on 2017-01-20 11:22
I too face the same issue when i import the code from STM32-MAT/TARGET. Able to successfully import and build the code but i too not able to see SysTick_Handler triggered. Since execution of step function in matlab code depends on this. My Actual logic executes based on SysTick, it is stuck now. Can you please post how do you solved your problem?
Reads: 4653
Link
Posted by arulprabhu on 2017-01-21 10:01

I did solved it. STM32-MAT/TARGET creates a variable remainAutoReloadTimerLoopVal_S. This variable is declared as static uint32_t remainAutoReloadTimerLoopVal_S = 1; in main.c. If we change this to static volatile uint32_t remainAutoReloadTimerLoopVal_S = 1; it will work. SysTick_Handler is triggered.
Fix:
added “volatile”
Tools used.
1.STM32-MAT/TARGET
2.STM32CubeMX
3.System Workbench for STM32

Link
Posted by dautrevaux on 2017-01-21 14:28 France

Hi,

In this case it seems that this is a bug in STM32-MAT/TARGET code generator. I can’t really give more advise on this (not knowing the code where this variable is used) but if volatile is needed there, that probably means the variable is tested (in a loop?) while it is modified in another piece of code (probably some kind of interrupt).

I presume that when you said SysTick_Handler is not invoked you mean that your SysTick-dependent code is not executed but the handler is correctly invoked, writing this variable that is checked in the main loop.

I can’t check as I don’t own Matlab/Simulink Software, but you should probably notify the STM32-MAT/TARGET development team of this problem; I think the System Workbench for STM32 toolchain is more aggressively optimizing the code, so the need for the volatile declaration, but there may be other places where the code generated by STM32-MAT/TARGET may need to be corrected.

Bernard (Ac6)

Link