STM32F446: st-flash --area=option read out.bin

[ApiumJacob]

• I made serious effort to avoid creating duplicate or nearly similar issue, related to issue Writing option bytes on STM32 G070/G071/G081 #1155 and Added option byte info for STM32F411XX #1141
• Programmer/board type: [STLINK/V2]
• Operating system an version: [Linux 5.4.0-74-generic 83~18.04.1-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux]
• stlink tools version and/or git commit hash: [v1.7.0 g179650d] built from source
• stlink commandline tool name: [st-flash --area=option read]
• Target chip (and board, if applicable): [STM32F446RE custom hardware]

The command line output differs from values written to a file that is passed on the command line. The following three examples are output of three different runs. I may be interpreting the generated output file incorrectly and this may not be an issue at all. Writing option bytes from the command line seems to work fine, didn't test writing from a file (didn't wan't to brick my chip).

Command line output:

st-flash --area=option read
st-flash 1.7.0
2021-06-22T21:49:10 INFO common.c: F446: 128 KiB SRAM, 4096 KiB flash in at least 128 KiB pages.
8f00bbed

$ st-flash --area=option read out.bin
st-flash 1.7.0
2021-06-22T21:50:20 INFO common.c: F446: 128 KiB SRAM, 4096 KiB flash in at least 128 KiB pages.
2021-06-22T21:50:20 INFO common.c: read from address 0x1fffc000 size 4
$ hexdump out.bin 
0000000 0080 1610                              
0000004

st-flash --area=option read out.bin 4
st-flash 1.7.0
2021-06-22T21:51:52 INFO common.c: F446: 128 KiB SRAM, 4096 KiB flash in at least 128 KiB pages.
2021-06-22T21:51:52 INFO common.c: read from address 0x1fffc000 size 4
$ hexdump out.bin 
0000000 0080 1610                              
0000004

[Nightwalker-87]

@Ant-ON @gszy Can one of you explain this behaviour based on a short review? This might not be a bug, but a improper implementation related to a missing parameter instead...

[gszy]

Well, it seems that when the filename is not provided, the program prints the result of stlink_read_option_bytes32():

stlink/src/st-flash/flash.c

Lines 210 to 215 in db8f789

	err = stlink_read_option_bytes32(sl, &option_byte);
	if (err == -1) {
	printf("could not read option bytes (%d)\n", err);
	goto on_error;
	} else {
	printf("%08x\n", option_byte);

It results in the following calls:

• stlink_read_option_bytes32()
  • stlink_read_option_bytes_f4()
    • stlink_read_option_control_register_f4()
      • stlink_read_debug32(sl, FLASH_F4_OPTCR, …) (where FLASH_F4_OPTCR = 0x40023c14, which is the actual memory address of the register)
        • sl->backend->read_debug32(sl, FLASH_F4_OPTCR, …)

Based on the STM32F446xx RM, I think 0x8f00bbed looks like a reasonable value.

---

On the other hand, when the filename is provided, the program calls stlink_fread() instead:

stlink/src/st-flash/flash.c

Line 207 in db8f789

err = stlink_fread(sl, o.filename, o.format == FLASH_FORMAT_IHEX, sl->option_base, o.size);

It results in the following calls:

• stlink_fread()
  • stlink_read(sl, 0x1fffc000, 4, …, …) (where 0x1fffc000 is the memory address of the option bytes)
    • stlink_read_mem32(sl, …, …)
      • sl->backend->read_mem32(sl, …, …)

Not digging too deep into these functions, I wonder if we actually want to read four bytes from 0x1fffc000. If I understand the RM correctly (Table 8 and Table 9), there are actually 16 option bytes:

Byte	Description
0x1fffc000	reserved
0x1fffc001	reserved
0x1fffc002	reserved
0x1fffc003	reserved
0x1fffc004	reserved
0x1fffc005	reserved
0x1fffc006	RDP
0x1fffc007	USER
0x1fffc008	reserved
0x1fffc009	reserved
0x1fffc00a	reserved
0x1fffc00b	reserved
0x1fffc00c	reserved
0x1fffc00d	reserved
0x1fffc00e	SPRMOD; reserved
0x1fffc00f	nWRP

[Nightwalker-87]

Looks to me as if at least the wrong address is read. Why should we read address fields that are reserved?
I've read before in another context that this can result in strange behaviour.
To me it would be reasonable to read the allocated and defined fields...

[gszy]

We currently seem to read four bytes starting from 0x1fffc000, because that’s the way STM32F446’s option bytes are defined in the lib:

stlink/src/stlink-lib/chipid.c

Lines 295 to 305 in db8f789

	.chip_id = STLINK_CHIPID_STM32_F446,
	.description = "F446",
	.flash_type = STLINK_FLASH_TYPE_F4,
	.flash_size_reg = 0x1fff7a22,
	.flash_pagesize = 0x20000,
	.sram_size = 0x20000,
	.bootrom_base = 0x1fff0000,
	.bootrom_size = 0x7800,
	.option_base = 0x1FFFC000,
	.option_size = 4,
	.flags = CHIP_F_HAS_SWO_TRACING,

I don’t really think the address is wrong, technically we are in the option bytes memory area; but the bytes we are interested in (RDP, USER, SPRMOD, nWRP) are obviously not included in these first four bytes. The easiest solution seems to set option_size to 16.

[Nightwalker-87]

Yes, and even more favourable could be to include an address mask for the valid option byte addresses to every chip-id config file.
This may help to find the correct fields with valid data for each individual MCU type.

[Nightwalker-87]

@gszy Please also take note of the latest discussion in #1180 in this context.

[Nightwalker-87]

This currently waits for #1181 to merge.

[Nightwalker-87]

We may continue with this now.

[Nightwalker-87]

@gszy BTW: Where did the .flash_size_reg parameter go?
Can we move the comments into the chip-id files as well? (I think so.)

[gszy]

Where did the .flash_size_reg parameter go?

I didn’t copy the flash_size_reg parameter, as I didn’t see it in the existing chip files (before my changes). Here is the relevant part of my script:

fprintf(f, "# Chip-ID file for %s\n#\n", device->description);
fprintf(f, "chip_id 0x%x\n", device->chip_id);
fprintf(f, "description %s\n", device->description);
fprintf(f, "flash_type %d\n", device->flash_type);
fprintf(f, "flash_pagesize 0x%x\n", device->flash_pagesize);
fprintf(f, "sram_size 0x%x\n", device->sram_size);
fprintf(f, "bootrom_base 0x%x\n", device->bootrom_base);
fprintf(f, "bootrom_size 0x%x\n", device->bootrom_size);
fprintf(f, "option_base 0x%x\n", device->option_base);
fprintf(f, "option_size 0x%x\n", device->option_size);

if (device->flags & CHIP_F_HAS_DUAL_BANK)
	strcpy(flags, "dualbank");
if (device->flags & CHIP_F_HAS_SWO_TRACING) {
	if (flags[0] == '\0')
		strcpy(flags, "swo");
	else
		strcat(flags, " swo");
}
if (flags[0] == '\0')
	strcpy(flags, "none");
fprintf(f, "flags %s\n\n", flags);

(/me wonders why GitHub highlights the second strcpy and the strcat in a different colour…)

Can we move the comments into the chip-id files as well? (I think so.)

We can move the comments there, though I’m afraid doing so manually would take less time than writing a script to do so (using some C parser or playing with grep and sed).