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


Debugger becomes unresponsive when enabling SysTick interrupt

I have a strange problem with the debugger that occurs when I enable the SysTick interrupt. The code works fine when not enabling it and can be debugged normally. Once I enable the SysTick interrupt by setting bit 0 of the SysTick.Control register, the debugger becomes unresponsive and does not stop at breakpoints any more. I left the interrupt priorities at their default values, all 0. I checked in the memory view that the interrupt vector is initialized and points to the correct code. However, the breakpoint at the interrupt handler code entry is never reached/triggered. I saw the other posts here regarding SysTick issues, but none of the suggestions there helped. The only hint I have is that when the debugger is stopped, I can see the PRIMASK register having a value of 1. Any ideas what could be wrong here?
- Klaus
(Windows 10, OpenOCD Version: 1.13.2.201703061529, BluePill board with STM32F103C8 @72MHz)

I think I know what is wrong, but I do not understand why. I had to change the BOOT0 jumper to 1 for the debugger to be able to flash the code and to reset the CPU. However when I want to debug the code with the SysTick interrupt enabled, I have to change the BOOT0 jumper back to 0 before I start the code execution. Debugging works fine now, but I have no clue why. Can somebody please help me to understand this?

Hi

If BOOT0 is pulled up the bootloader from ROM gets executed. The debugger then has no source code available. How can it follow the jump to the application?
The appclication can be downloaded to flash memory by st-link v2 hardware connected to SWD without using the build in bootloader. But if the application has not defined a debug interface (SWD or JTAG) you will not be able to do this a second time. Then you have to pull up BOOT0 while reset to reconfigure these pins. I can not imagine why a disabled SysTick allows debugging when starting from build in bootloader.

Dieter


Hi Dieter, thanks for your explanation. I cannot see the connection to the SysTick as well, but the issue is reproducable. I guess I should have mentioned that my code is in assembler. So the debugger never has some high-level language source code available - which is fine in my case. And application start is not an issue, because the application (a VM to support a high-level language other than C) starts in the reset handler and it seems that there is always a reset after programming. I guess I just have to get used to changing the jumper back to BOOT0=0 after flashing the code.

- Klaus