Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

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: 4063
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