Open FerdinandEn opened 3 months ago
In a few more experiments, I found that the problem occurs when debugging a program that was converted from a uVision project. I created a project for the STM32H753ZGT directly and as a converted project. The debugging in the directly created program works, the converted one does not.
Maybe a stupid question: Do you load the ELF file build by uVision or the one built by CMSIS-Toolbox? The difference is that uVision requires DWARF4 debug information whereas the Arm Debugger in VSCode requires DWARF5.
@jkrech I translated it in Keil Studio and deleted the objects directory from uVision to be on the safe side. I used the converted program code. Where do I have to enter that I want DWARF5 debug information?
Sorry, the default in AC6 when using -g is still DWARF4, therefore it should not make a difference even though in uVision we explicitly force -gdwarf-4. Therefore this cannot be the root cause.
@FerdinandEn , could you please confirm which target board you are using?
STM32F756ZGT (Nucleo Board)
I created a project for the STM32H753ZGT directly
STM32F746ZGTx
I am using a STM32F756ZGT
(Nucleo Board). Originally the project was created for STM32F746ZGT
. The difference is only the Crypto/Hash-Unit. I tried both boards no difference.
I also have the same problem with the STM32H753ZI. However, only when I use a converted project. As soon as I create a project directly with Keil Studio, the variable view of the debugger works.
I use a different project for the STM32H753ZI.
Thanks for confirming, I've tried this project with a NUCLEO-F746ZG and can reproduce the problem.
Comparing the generated map-files of a uVision build with a CMSIS solution build, the code size differs by ~2.5kBytes (same AC6 version). (See Blinky.map.uvision.txt and Blinky.axf.map.csolution.txt ).
The different code location of mainThread
seems to disagree with the MPU configuration. If I comment out the call to MPU_Config
in main
, then the count
variables update correctly in memory and the debugger views. I need to consult an expert on our end to fully understand the MPU configuration in this example. And how the code size difference causes trouble. The location of the variables themselves in memory doesn't change between the two builds.
I'll keep this ticket open until I have more info on MPU config. But I currently don't think this is a debugger problem.
Forgot to mention: when I say a uVision build
, I mean opening the uvprojx
in uVision.
I just exported the uVision example to csolution with the latest MDK 5.40 version. The problem is still present. But the code sized difference improved. Now ~0.2KBytes.
@FerdinandEn , this makes me wonder how you did convert the uVision project to a csolution? Was it the export from uVision? Which MDK 5 version, if so? Or did you use the conversion in the CMSIS Solution extension?
@jreineckearm In most cases, I carry out the conversions from within Keil Studio. I select the uvprojx
file with the right mouse button and choose Convert uvproj to csolution
. Due to the regular updates, I assume that I am using the most up-to-date conversion program.
MPU -> I have tested whether the variables are updated when I deactivate the MPU. The view then also works for me.
The MPU setting shown is suggested by ST. It has the effect that access is prohibited in the external memory area for memory and peripherals. This prevents incorrect cache accesses. However, activating the MPU also means that all memory areas, including the internal ones, can only be accessed in privileged mode.
However, I also have programs where the display of variables works even if the MPU is active.
Thanks, @FerdinandEn , for the additional information! This is very useful. The required privileged access is actually a good hint to follow up on the debugger side. We'll further investigate and get back to you.
Type: Bug Report
Describe the bug
It is a simple project - blinking a led
I can compile, flash and start the debugger.
I can modify the code and the behavior change (blink frequency)
The global variables are modified in super loop.
I can see the content of the variables in Globals and I can add as watch.
If the programm is running the shown content of the variables does not change in both views (debug stopped) - blinking occurs.
Same behavior in Memory inspector.
If I change the initial value, I can see the change.
If I control the program in Dissambly and register view. I can see, that variable is modified as expected.
To Reproduce
see example code