Wrong flash size reported for various chips

[10110111]

I'm debugging firmware on STM32H725VGT that has some code above 0x8020000. When I try to access this memory e.g. via disas command in GDB, I get "Cannot access memory at address 0x802xxxx". I've tracked it down to info mem reporting flash region from 0x08000000 to 0x08011c00. The 0x11c00 size is also what I get from st-info --flash. This size is wrong: the chip has 1MiB of flash.

I've also tried this on another chip, the one on STM32F407G-DISC1, and st-info --flash reports flash size of 0x3fffc00, which would be almost 64MiB! The actual size is still 1MiB.

I'm running stlink from develop branch, at e97f438. OS is Ubuntu 20.04 (Linux 5.4.0-65-generic).

[Ant-ON]

@10110111 Can you post output of st-info --flash?
Can you post value of 0x1FF1E880 register (read in GDB: x/1uw 0x1FF1E880)?

[10110111]

The register read returns 1024. The output is below.

$ st-info --flash
---------- old ------------
# Chip-ID file for H72x/H73x
#
chip_id 0x483
description H72x/H73x
flash_type  10
flash_size_reg 0x1ff1e880
flash_pagesize 0x20000
sram_size 0x20000
bootrom_base 0x1ff00000
bootrom_size 0x20000
option_base 0x5200201c
option_size 0x2c
flags 2

---------- new ------------
# Chip-ID file for H72x/H73x
#
chip_id 0x483
description H72x/H73x
flash_type  10
flash_size_reg 0x0
flash_pagesize 0x20000
sram_size 0x20000
bootrom_base 0x1ff00000
bootrom_size 0x20000
option_base 0x5200201c
option_size 0x2c
flags 2

0x11c00

[Ant-ON]

@10110111 Have you edited the configuration files? flash_size_reg should be 0x1ff1e880...

[10110111]

No, I don't even know where they are :) . I just did make install and went on to run st-util.

[Ant-ON]

I don't know where they too... Apparently someone broke they :(
Unfortunately, I can only advise you to comment their reading function in the chipid.c. Using an array with chip descriptions works stably.

[10110111]

I guess it's /usr/stlink/chips/H72x_H73x.chip. And flash_size_reg is absent there, as in any other file in this directory.

[Ant-ON]

It turns out that they need to be recreated and updated in the source code.
They generated in current directory if uncomment the line:

stlink/src/stlink-lib/chipid.c

Line 1105 in e97f438

// dump_chips ();

[Nightwalker-87]

The flash_size_reg issue is currently being fixed for all .chip files in /config/chips.

[Nightwalker-87]

As mentioned in a previous comment common.c does not use the data from the .chip device files and holds hardcoded device-specific values for various operations e.g. for use with st-flash. Therefore common.c needs to be rewritten to make use of the revised chip-parametre files.
@10110111 you can test the chipid_cleanup branch to test st-info in the meanwhile. This should now provide the correct values which are passed to the stlink-lib library in the background.

[antoinefaure]

Hi,

I've tried to generate the files as per @Ant-ON instructions, but it seems it doesn't solve the issue while waiting for the rework.

The file H74x_H75x.chip ends up looking like this :

# Chip-ID file for H74x/H75x
#
chip_id 450
description H74x/H75x
flash_type  a
flash_pagesize 20000
sram_size 20000
bootrom_base 1ff00000
bootrom_size 20000
option_base 5200201c
option_size 2c
flags 3

Which is pretty similar to what is in config/chips, except the 0x have been removed, and the flags have been replaced to what I assume is their total value.

After running make install st-util is now complaining because it doesn't know how to interpret the flags:

Unknown flags word in /usr/local/stlink/chips/H74x_H75x.chip: '3'

As a workaround, I have removed all the chip files in /usr/local/stlink/chips/. I doubt this is ideal, but so far it is working with my H7 :)

[10110111]

you can test the chipid_cleanup branch to test st-info in the meanwhile. This should now provide the correct values which are passed to the stlink-lib library in the background.

Seems to work OK now. I get 0x40000 as the flash size of an STM32F401VCT6U from st-info, and GDB shows a sensible memory map and is able to read data from high regions. Can't check on H7 right now, because I don't have access to it.

[Nightwalker-87]

@antoinefaure The files should not be generated automatically for any longer. I have disabled this approach recently and manually revised all new chip files one by one to hold the correct information. Afterwards the old device database from chipid.c (later outsourced to chipid_db_old.h) was removed. Please solely test this on the chipid_cleanup branch (see comment from @10110111) and don't use develop for this specific issue. We will have a look at the leftovers as soon as the branch chipid_cleanup has merged, the source file common.c references these new device files and thus at that time only one source of device-specific information remains. This is why I am looking forward to reviews and testing in #1212.