Cannot access global memory with stm32H743 target

[bobbatcomcastdotnet]

I am having a problem with my BMP accessing global variables. My hardware is based on the STM32H743 chip. The application I am debugging is rather large (~300K code). I am using a native BMP with upgraded firmware:

Black Magic Probe (Firmware 54ee00b) (Hardware Version 3) Copyright (C) 2015 Black Sphere Technologies Ltd. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html

The same problem occurs with a Bluepill version of the BMP.

The error GDB returns is "access to memory location 0xxxxx is denied". However, if I do a memory dump I can access that memory address without problems.

This problem does not always occur and it only seems to happen when accessing global variables, particularly structures. I am using the GDB 'print /x variable` command to access the variables. In addition I have only seen this problem occur when debugging the STM32H743 code. I have never seen this problem when debugging my STM32F407 based code which is functionally the same as the STM32H743 version.

One final note the jlink probe does not have this problem. It always displays the variables correctly in the same environment.

[UweBonnes]

Please run bmp-hosted with debugging enabled and try to find the offending section. Perhaps this can give us some hints.

[bobbatcomcastdotnet]

Please run bmp-hosted with debugging enabled and try to find the offending section. Perhaps this can give us some hints.

Is there a Windows version of the bmp-hosted version? If so are there instructions as to how to build/run it? I am currently quite busy attempting to build a HID composite host driver for the STM32H7 so I don't know when I'll be able to get this task done. As you may know, there is very little libopencm3 support for the STM32H7. I can continue to debug my code with the jlink probe.

[UweBonnes]

When you have that problem via 'print /x variable` , resolve the address via "p &variable" and try to dump them memory via "x \<address>"

Do me another favour: Compile bmp-hosted and run bmp-hosted with the jlink. Flashing will be slow but normal debugging should work. Is the behaviour reproduced?

[bobbatcomcastdotnet]

When you have that problem via 'print /x variable` , resolve the address via "p &variable" and try to dump them memory via "x

"

Do me another favour: Compile bmp-hosted and run bmp-hosted with the jlink. Flashing will be slow but normal debugging should work. Is the behaviour reproduced?

Once again I must ask, Is there a Windows version of the bmp-hosted version? If so are there instructions as to how to build/run it? My environment is all Windows based.

[UweBonnes]

Please give https://github.com/UweBonnes/blackmagic/tree/artefacts/src blackmagic.exe a try. Libuse and libftdi and zadig for the devices are needed.

[sidprice]

@bobbatcomcastdotnet I have hosted running on Windows. To build from the current master:

cd src make clean make CC=gcc PROBE_HOST=hosted

That works for me.

Then start it "blackmagic -d YourComPort

Then you can connect with GDB ARM "target extended-remote :2000

[bobbatcomcastdotnet]

I downloaded https://github.com/UweBonnes/blackmagic/tree/artefacts/src blackmagic.exe and associated dlls. When I ran the app I get the following:

Microsoft Windows [Version 10.0.18363.959] (c) 2019 Microsoft Corporation. All rights reserved.

C:\Users\Bob>cd\apps\bmp_hosted

C:\Apps\BMP_Hosted>blackmagic.exe -d COM1 Using 0000:0000 Could not open \.\COM: 2

C:\Apps\BMP_Hosted>

I have my BMP connected and it is on COM1. Any suggestions?

[UweBonnes]

I cut off the 1 from COM1 by error. Try again.

[bobbatcomcastdotnet]

Do you mean download the exe again and then retry?

[bobbatcomcastdotnet]

I downloaded the new exe and retried it. I get the following results:

C:\Apps\BMP_Hosted>blackmagic -d COM1 Using 0000:0000 Serial write failed 121, written 0 Timeout on read RESP

C:\Apps\BMP_Hosted>

[UweBonnes]

Rub with -v 31 added to get a hint what is going wrong. And be sure that your BMP firmware is recent, so that remote is available.

[bobbatcomcastdotnet]

If I use the following command line I get:

C:\Apps\BMP_Hosted>blackmagic.exe -d -v31 com1 Using 0000:0000 Could not open \.-v31: 2

My BMP firmware version is:

Black Magic Probe (Firmware 54ee00b) (Hardware Version 3)

[sidprice]

It should be -> blackmagic.exe -d com1 -v31

[bobbatcomcastdotnet]

Using Sid's command line I get:

C:\Apps\BMP_Hosted>blackmagic.exe -d com1 -v31 Using 0000:0000 +#!GA# Timeout on read RESP

Does this help?

[UweBonnes]

This looks like either no BMP is connected to COM1 or the firmware on the BMP is not recent and does not support the remote protocol.

[bobbatcomcastdotnet]

I downloaded the latest nightly build for the BMP and reloaded it onto the BMP using dfu-util. I confirmed it is connected to COM1 (i.e. I can debug using com1). The results I get when I run the blackmagic.exe app is the same as before:

C:\Apps\BMP_Hosted>blackmagic.exe -d com1 -v31 Using 0000:0000 +#!GA# Timeout on read RESP

Any ideas...?

[sidprice]

@UweBonnes Is there a reason you have Bob using the branch in your repo and not the master? I am running the master here on Windows 10.

[UweBonnes]

The original request was to run with jlink and bmp-hosted to see if the access problem is also with BMP-Jlink-hosted. Bob also is on windows and did not offer to compile himself.

Please offer him your binary.

[sidprice]

Well it seems that the master branch is now broken because I see the same issue as Bob. Let me regress and get a build that works. I don't have time to debug it right now.

[sidprice]

@UweBonnes OK, here is the issue, I now remember mentioning this a while ago. In order to use blackmagic.exe you need to FIRST connect to the BMP using GDB, then exit GDB, and blackmagic.exe will connect.

@bobbatcomcastdotnet Launch arm-none-eabi-gdb.exe and connect to the BMP with "target extended-remote //./COM1". Exit GDB and try "blackmagic -d COM1"

[bobbatcomcastdotnet]

@sidprice That certainly fixed the problem :) When I run the blackmagic app I now get the following response:

C:\Apps\BMP_Hosted>blackmagic -d COM1 Using 0000:0000 Remote is Black Magic Probe 71e5b4d Listening on TCP: 2000

Now all I have to do is figure out how to use the new TCP access. As you may remember Sid I use my own IDE to do all of my STM32 development work. The BMP support my debugger currently has was not designed to use a TCP port so the IDE debug code does not currently have the means to handle this scenario. But it will as soon as I can get to it.

Thanks for your help Sid :)

[sidprice]

@bobbatcomcastdotnet Happy you are connected, sorry my brain fade lost the vital data 😞

[UweBonnes]

instead of tar ext com1 use tar ext :2000

[bobbatcomcastdotnet]

OK, I've got everything setup to run BMP-Hosted. Everything is apparently correct until I try to execute the GDB command 'monitor swdp_scan' at which point I get the following from blackmagic.exe:

C:\Apps\BMP_Hosted>blackmagic -d com1 Using 0000:0000 Remote is Black Magic Probe 71e5b4d Listening on TCP: 2000 0xe0041000: Debug component - Unknown (PIDR = 0x04001bb975 DEVTYPE = 0x13 ARCHID = 0x4a13) Timeout on read RESP

C:\Apps\BMP_Hosted>

At which point blackmagic terminates. Any ideas...?

[UweBonnes]

The abort is strange. Is that reproducable? Add debugging to see where it happens. Otherwise I will add the unknow component soon.

[UweBonnes]

Unknown PIDR is fixed by #706

[bobbatcomcastdotnet]

@UweBonnes Okay, what is the next step for me?

[UweBonnes]

As I told before: The abort is strange. Is that reproducable? Add debugging to see where it happens.

[UweBonnes]

B.t.w; Are you sure you don not overclock the device, e.g. run an old version with 480 MHz or all those overdrive related bit are set the right way and wait states are enough?

[bobbatcomcastdotnet]

@UweBonnes The abort happens every time I attempt to debug my application so yes it is reproduceable. I am running the app at 480mHz. Now that you mention it I don't know is the STM32H743 chip is the correct version to support 480mHz. I am using clock code developed by Brian Viele for the libopencm3 project. Perhaps this is an area to investigate before we go any further with this process. However, this doesn't explain why the jlink probe appears to work? This is the exact reason I decided to try the jlink, to see if I had some kind of hardware issue.

Forgive me for my ignorance but you stated "Add debugging to see where it happens" in your comment. How do I do that? Is there a command line option that needs to be added?

[UweBonnes]

Add "-v 31", and log the output to a file.

[UweBonnes]

And look if you have a Rev Y dev or a Rev V device.

[bobbatcomcastdotnet]

I will try the -v31 option a little later today.

Is there a way to programmatically determine the device rev? I can't read the version # from the actual chip itself.

[UweBonnes]

bit 8..15 in DBGMCU_IDCODE?

[bobbatcomcastdotnet]

@UweBonnes Yeah, I found that just after I wrote the last message :( I added code to read the rev and it is 0x2003 so the chip is a revision V which means it is 480 mHz compatible.

[bobbatcomcastdotnet]

@UweBonnes I ran the app again and produced the following output test.txt

[UweBonnes]

Another thing to check: Is the SWD connection between your BMP and the target board stable? Enough ground lines, sensible long and no shacky connections? Does the target power the level shifters on the BMP with the right VDDIO? What is VDDIO by the way? And can you test with SWD from another Nucleo/Disco board?

Otherwise, is your program open? I can test with a H743 disco and a H745 disco.

[bobbatcomcastdotnet]

@UweBonnes The SWD connection between the BMP and the target is stable (a 4" ribbon cable). It has three ground lines (in the ribbon cable). The target power for the level shifters on the BMP is supplied by the target (with the VREF signal) which is reported as 3.3V. I have used the same BMP (and ribbon cable) with several other boards (both F1 and F4). I have also used the BMP with a Nucleo-H743ZI2 board although on a different project. When I use the jlink probe I am using the same ribbon cable.

Unfortunately, the project is not open for distribution.

Did the test.txt file I sent have any useful information?

[UweBonnes]

Where and how did you send?

[bobbatcomcastdotnet]

I sent it here as an attachment to the message sent 2hr ago.

[UweBonnes]

Did not look carefully enough. The stall still happend during swd scan. I have no idea!

[bobbatcomcastdotnet]

@UweBonnes Something I neglected to mention which may or may not have meaning. My IDE executes GDB using the mi2 interpreter. This might cause the blackmagic app trouble??? In fact, it might also be the reason I am having trouble accessing global variables (if the actual commands sent to the BMP are not handled properly).

[UweBonnes]

BMP does not support MI2 to my knowledge

[sidprice]

@bobbatcomcastdotnet MI2 is the protocol between a client application and GDB, BMP uses the Remote Serial Protocol, which is for GDB to GDBServer communications.

Does your IDE launch GDB and communicate with that, or is it connecting directly to BMP?

[bobbatcomcastdotnet]

@UweBonnes Why not? The interpreter used by GDB should have no effect on the BMP since BMP uses the Remote Serial Protocol (RSP).

@sidprice I launch GDB and communicate with that. I do not talk directly to the BMP.

[bobbatcomcastdotnet]

That being said it is possible that GDB generates different RSP commands when MI2 is used, I don't know. However, whatever RSP commands are being generated the BMP should handle them correctly.

[sidprice]

@bobbatcomcastdotnet Using MI2 to communicate with GDB has no effect on the communication with the BMP. In fact in the ImageCraft debugger I wrote I also used GDB/MI, worked fine with BMP and ctxLink.

Unfortunately I don't have an STM32H743 to try it out :{

[bobbatcomcastdotnet]

@sidprice I have a couple more STM32H743 boards on order. Perhaps I could send you one to test on. The application I am working on is a HID composite host that will eventually connect to an Rii 2.4G Mini Wireless Keyboard with Touchpad Mouse. As you might expect there currently is no libopencm3 USB support for the H743 (actually there is almost no H743 support at all from libopencm3) so I am using code that came from ST Micro and uses the HAL library. The code utilizes a host structure to hold the host data and a pointer to that host is passed all over the place. It is that structure I need to examine using the print /x *phost GDB command and it is that command that the BMP fails on with an error message. JLink on the other hand does not fail. I have other code that uses the H743 which also fails to access global vars using the BMP.

[sidprice]

@bobbatcomcastdotnet I would be happy to try and take a look. @UweBonnes is the expert on the BMP interface to the target, however, maybe I can collect enough data to enable him to see the issue.

If you have a small project that demonstrates the issue you should send that along too.

[bobbatcomcastdotnet]

@sidprice When I receive the boards (they are from China) I will send one along to you. I will try to work on a small project that demonstrates the problem but that may be difficult since the problem only appears to happen on my larger code :(