[STM32H735]: Can't access all device memory

[c-grant]

• Programmer/board type: [STLINK V3 on STM32H735-DK]
• Operating system an version: [Windows 10 19042.1083]
• stlink tools version and/or git commit hash: [1.7.0]
• stlink commandline tool name: [st-util]
• Target chip (and board, if applicable): [STM32H735 on STM32H735-DK]

When attaching to this board I can not read all the memory regions,
Specifically AXIRAM, SRAM1, SRAM2, SRAM4 (possibly others)

running in verbose mode I noticed the regions missing from the XML output

2021-07-10T23:55:34 DEBUG gdb-server.c: send: m<?xml version="1.0"?><!DOCTYPE memory-map PUBLIC "+//IDN gnu.org//DTD GDB Memory Map V1.0//EN" "http://sourceware.org/gdb/gdb-memory-map.dtd"><memory-map> <memory type="rom" start="0x00000000" length="0x100000"/> <memory type="ram" start="0x20000000" length="0x20000"/> <memory type="flash" start="0x08000000" length="0x100000"> <property name="blocksize">0x20000</property> </memory> <memory type="ram" start="0x40000000" length="0x1fffffff"/> <memory type="ram" start="0xe0000000" length="0x1fffffff"/> <memory type="rom" start="0x1ff00000" length="0x20000"/> <memory type="rom" start="0x1ffff800" length="0x10"/></memory-map>

RM RM0468 page 133 has the following

0x38800000 -
0x38800FFF Backup SRAM

0x38000000 -
0x38003FFF SRAM4

0x30004000 -
0x30007FFF SRAM2

0x30000000 -
0x30003FFF SRAM1

0x24020000 -
0x2404FFFF RAM shared between ITCM and AXI

0x24000000 -
0x2401FFFF AXI SRAM

Doing an examine of SRAM4 produces the following output

2021-07-11T00:08:25 ERROR gdb-server.c: cannot recv: -2 2021-07-11T00:08:25 DEBUG common.c: *** stlink_run *** 2021-07-11T00:08:25 DEBUG common.c: *** stlink_read_reg 2021-07-11T00:08:25 DEBUG common.c: (16) *** 2021-07-11T00:08:25 DEBUG usb.c: r_idx (16) = 0x61000000

I have another board (STM32H743 NUCLEO-144) that has these same regions + more and these reads work. I noticed in the XML output it included these other regions. Looking in gdb-server.c, I do not see a mapping for this chipid and it seems to be using the default.

[c-grant]

Attached are mods that I did locally to access the memory areas
gdb-server.zip

[Nightwalker-87]

@c-grant Can you please submit the code changes in form of a Pull Request to allow for comparison and describe what you did and how you proceeded on testing? I assume it is rather unlikely that someone else is going to dig through or manually compare single source code files to identify changes. Thx.

[c-grant]

I can try. I have not ever used git or submitted pull requests before and I didn't want to accidently violate any contribution guidelines. Not sure how to comply with the travis CI compliance on Windows with visual studio. Being it was a single source module change of about 10 lines I thought it might be an easy diff.

[c-grant]

Attempt made

[Nightwalker-87]

@c-grant: Thanks for doing so. As GitHub holds many features and workflows for automated maintenance which we partially use, this procedure allows to deal with issues efficiently and in an equal way and procedure. Though contributors are encouraged to check their code prior to submitting, a failing CI is not the end of the world - it does happen every once in a while. The checks are mainly there to ensure that no bugs are introduced accidentally and not to access the quality of the whole contribution itself.