Debugger does not update content of variables

[FerdinandEn]

Type: Bug Report

Describe the bug

• OS and Version: Windows & Ubuntu
• VS Code Version: 1.89.1
• Extension Version: 1.1.2
• Target Device: STM32F756ZGT (Nucleo Board)
• I have deleted all extensions and Keil Studio pack new installed

It is a simple project - blinking a led

#include "main.h"

volatile uint32_t count = 1;
volatile uint32_t count2 = 5;

/**
  * @brief Entry point of user program
  */
void mainThread(void)
{
  for(;;)
  {
    HAL_GPIO_TogglePin(redLed_GPIO_Port, redLed_Pin);
    count++;
    count2 = count2 + count;
    HAL_Delay(1000);
  }
}

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

[FerdinandEn]

001-Blinky.zip

[FerdinandEn]

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.

[jkrech]

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.

[FerdinandEn]

@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?

[jkrech]

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.

[jreineckearm]

@FerdinandEn , could you please confirm which target board you are using?

• In the above description, you say STM32F756ZGT (Nucleo Board)
• A little later you say I created a project for the STM32H753ZGT directly
• The attached workspace suggests you use an STM32F746ZGTx

[FerdinandEn]

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.

[jreineckearm]

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.

[jreineckearm]

Forgot to mention: when I say a uVision build, I mean opening the uvprojx in uVision.

[jreineckearm]

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?

[FerdinandEn]

@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.

[jreineckearm]

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.