How to Debug STM32N657? - pyOCD and uVision

[FerdinandEn]

Experience report with questions

I want to get to familiarize myself with the STM32N657 (Nucleo). To do this, I am creating a few test programs. The first step is to create an FSBL (First Boot Loader) that controls the LEDs. Creating and compiling is no problem. The STM32N657 does not have internal flash memory. When the system is reset, the program is loaded from the external flash into the RAM by the system ROM. For the first test of the program, this loading process into the RAM can also be handled by the debugger.

pyOCD

When I start pyOCD, I get the following error message:

pyOCD reports that it cannot write to RAM. I have adapted the following entry in CubeMX+STM32N6.cbuild-run.yml:

 name: Flash
        access: rx
        start: 0x34180400
        size: 0x0003FC00
        from-pack: Keil::STM32N6xx_DFP@1.0.0
        
 name: Flash
        access: rwx

After starting the debugger, no CM55 registers can be seen and the dissambler cannot be started. After the Memory Inspector, however, the content of the memory from address 0x34180400 was still 0.

In the debug console,

Program received signal SIGINT, Interrupt.
0x18003514 in ?? ()

is displayed as the last line. Address 0x18003514. See also uVision.

How do I configure pyOCD to start the debugger correctly?

uVision

I then tried to debug using the uVsion.

After starting the debugger you will see the following disassmbly

Here too, the processor is in the address range 0x18003A1A. By entering the following commands, I can load the program correctly and run it with up to the main() function.

LOAD $L@L.axf incremental // Load project binary
PC = _RDWORD(0x34180404); // Set Program Counter to Reset_Handler() address
g,main

I have saved these instructions in the debugLoad.ini file.

I then tried to load the debugLoad.ini file as an initialization file in the debug dialog. However, this does not result in the program being loaded correctly. The commands must be executed after the loading process. I have created the file myInclude.ini for this purpose.

define button "Setup", "include ..\\..\\..\\..\\debugLoad.ini"

I start this via the initialization file. The file is used to create a button in the debug toolbox. By pressing the button, the program can be started after loading. It is also possible to press the Reset button in the uVision interface and then restart the program. The program can then be tested in all points.

I have tested the GPIO_IOToggle example from the ST-N6 repository. This works completely with uVision. The described procedure is not necessary here. The program can be started there directly.

I can't explain the difference. I have used the same settings as in the ST-uVision project.

I would be very grateful if someone could explain the reason for this behavior.

Note: I have upgraded Keil Studio to CSolution 2.11.0. To test the new version, I copied the new CSolution files from .vcpk to the uVision directory cmsis-toolbox.

Note: With CSolution 2.10.0 I noticed that a clear of the Csolution project was performed when starting uVision. You had to recompile before the debugger could be started.

[RobertRostohar]

Let me try to help with the pyOCD setup.

The memory description in the STM32N6xx_DFP 1.0.0 pack has some issues.

The RAM memory (named Flash) at address 0x34180400 which is the startup memory for code has the access rx. This means that it cannot be written directly but requires a programming algorithm which is however not provided in the pack (actually not needed since it is RAM).

When gdb and pyOCD see the rx attribute they report that the memory is not writable (error that you have shown in the first picture).

A quick solution is to change the access attribute to rx in the generated .cbuild-run.yml file as you have done (note that the file gets regenerated by the tools).

Next step is to adjust the launch.json for execution from RAM.

The following should help:

• disable automatic updates: use "updateConfiguration": "manual"
• load the program from gdb rather than via pre-launch task (avoids reset between loading and running)
  • remove "preLaunchTask": "CMSIS Load"
  • add load to initCommands
• set PC/SP in initComamnds
• force HW breakpoints to be used with pyOCD: "serverParameters": ["-bh"]

The launch.json should have the launch entry similar to:

            "name": "STLink@pyOCD (launch)",
            "type": "gdbtarget",
            "request": "launch",
            "cwd": "${workspaceFolder}/",
            "program": "<name>.elf",
            "gdb": "arm-none-eabi-gdb",
            "initCommands": [
                "load",
                "set $pc=Reset_Handler",
                "set $msp=(unsigned int)&_estack",
                "tbreak main"
            ],
            "customResetCommands": [
                "monitor reset halt"
            ],
            "target": {
                "server": "pyocd",
                "serverParameters": [
                    "gdbserver",
                    "--port",
                    "3333",
                    "--probe",
                    "stlink:",
                    "--connect",
                    "attach",
                    "-bh",
                    "--cbuild-run",
                    "${command:cmsis-csolution.getCbuildRunFile}"
                ],
                "port": "3333"
            },
            "cmsis": {
                "cbuildRunFile": "${command:cmsis-csolution.getCbuildRunFile}",
                "updateConfiguration": "manual"
            }

After that you should be able to start the debug session and land in main.

[FerdinandEn]

@RobertRostohar
Thanks for the suggestions.

I could not set the stack. The _estack label is not known in my project. However, this is not a problem as the stack is set in the reset handler.

What is still missing is the setting of the VTOR. The vector table has not been updated. This means that no interrupts can be called.

Unfortunately, my experiments have led to the fact that I can no longer debug with pyOCD. For example, I get the error message

Failed to read peripheral SYSCFG_S: Error: readMemory failed @ 0x56008000 for 40 bytes: CodeExpectedError: Unable to read memory., session=c040df7d-9d70-496e-ac7a-88efecf60e08

It could be that the problem started after I added the -bh entry. However, the problem now occurs even without the entry.

After a power cycle, it works once with uVision. If you start the debugger again, you receive an error message that the start does not work. After a power cycle it works again.

With the CubeIDE, I can debug normally after a power cycle, several times in succession.

[RobertRostohar]

Try adding "monitor reset halt" before "load" to the "initCommands". This should hopefully properly reset the CPU (including VTOR).

[FerdinandEn]

@RobertRostohar
I have tested it. VTOR was not set. However, I have the problem that the debugger has no access to SYSCFG. VTOR is stored there. VTOR must be adjusted after the internal boot loader.

[RobertRostohar]

Could you share a test project including prebuilt image and the launch scripts?

[FerdinandEn]

@RobertRostohar
I like to do it

000-N6NucBlinky.zip

[RobertRostohar]

Thanks for the project. With a few tweaks, I was able to get the debugger to work with VS Code and CMSIS-Debugger using pyOCD.

The first issue that you have seen with the reported error Failed to read peripheral SYSCFG_S is reported by the Peripheral Inspector extension. For some reason debugger cannot read memory at SYSCFG_S. It seems that the debugger cannot recover from the memory faults and a target power-cycle is required.

In order to avoid all of this, don't use the Peripharal Inspector for the time being. Don't expand the Peripherals in the debug view.

It seems that once the Peripheral items are expanded, VS Code remembers this in the folder specific workspace storage. This explains why the debugger worked initially but would not anymore after the Peripherals were inspected. To bypass this, you can copy the project to a new folder or delete the workspace cache for the current folder. Then the errors should be gone as long as the Peripherals are not inspected again.

The workspace storage for folders is located in <user>\AppData\Roaming\Code\User\workspaceStorage (on Windows). It contains folders that have hashed names. Inside each folder is a workspace.json which includes the project folder name. So it is possible to search only for a specific folder and delete its workspace cache (not aware of a simpler method).

Alternative is also to temporarily disable the Peripheral Inspector extension.

The second issue is that the program image created by AC6 will not be loaded correctly by gdb.
See: CMSIS-Debugger Known Limitations and Workarrounds: AXF files built with Arm Compiler 6 toolchain

Loading an AC6 .axf image results in the project failing to run as expected. The variables are not correctly initialized. For example uwTickFreq = HAL_TICK_FREQ_DEFAULT should set the default Tick frequency but the actual variable stays at 0 and HAL_Delay() will hang.

To fix this the .hex file should be used explicitly for gdb load.
Update initCommands in the launch.json to use load <path>/FSBL.hex

After that the debugger should correctly load the image and when running the application, the LED should blink.

P.S.: VTOR does not need to be configured since it already points to the right address. This can be checked by executing the following command in the debug console:

>x/wx 0xE000ED08
0xe000ed08:	0x34180400

[jreineckearm]

There is also a setting to suppress saving the tree layout between sessions. This should equally suppress loading once changed in the VS Code settings but after a layout had been saved in a previous session.

[FerdinandEn]

I can start the debugger and run tests. I'm really glad that the SYSCFG_S issue isn't a hardware problem.

Is there a reason why the path under program is saved in Windows notation?

"program": "out\\FSBL\\STM32N6\\Debug\\FSBL.axf",

This write format also is possible

"program": "out/FSBL/STM32N6/Debug/FSBL.axf",

The \ path does not work for load. A / path must be specified here.

Many thanks for your support

[RobertRostohar]

I'm glad to hear that it works now with VS Code and CMSIS-Debugger using pyOCD.

Is there a reason why the path under program is saved in Windows notation?

This is generated by a script engine which seems to use platform specifics. But I don't believe this really matters as along as it works (on linux / would be generated).

The \ path does not work for load. A / path must be specified here.

Correct. The load is executed withing gdb and the path needs to be in line with gdb expectations.

[RobertRostohar]

Regarding the issue with uVision.

I believe that you are opening a Csolution .csolution.yml in uVision. This is not a native uVision project and the behavior is different.

When you start a debug session an auto created initialization is executed which contains a LOAD command.

/************************************/
/* auto-created from cbuild-set.yml */
/************************************/
LOAD "./FSBL.axf"

The LOAD command does not have the incremental option which will not work correctly when loading to RAM.

Adding user initialization file with LOAD incremental will however not work since it is merged automatically and LOAD is overwritten.

One way of overcoming this is to add a user initialization file which includes another file with the user commands.

Create myInclude.ini with the contents:
include ..\\..\\..\\..\\debugLoad.ini

Then enter this initialization file under the debug settings. After that starting the debug session should load correctly the image (second incremental LOAD), set the PC and run until main.

The Command window should show:

Include "D:\\Test\\000-N6NucBlinky\\out\\FSBL\\STM32N6\\Debug\\FSBL.Debug+STM32N6.ini" 
/***********************************/
/* auto merged from cbuild-set.yml */
/***********************************/
LOAD "./FSBL.axf"

include ..\\..\\..\\..\\debugLoad.ini
LOAD $L@L.axf incremental // Load project binary
PC = _RDWORD(0x34180404); // Set Program Counter to Reset_Handler() address
g,main

When using uVision native projects, it should be enough to just use the debugLoad.ini diectly.

[FerdinandEn]

Thanks for the information about uVision. I hadn't thought of that workaround. My solution with the button has the advantage that when debugging, I can press the uVision reset button and then restart the program without having to restart the debugger.

[jkrech]

@FerdinandEn can this issue be closed or are there any questions or open items left?