-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
STM32F446: st-flash --area=option read out.bin #1156
Comments
Well, it seems that when the filename is not provided, the program prints the result of Lines 210 to 215 in db8f789
It results in the following calls:
Based on the STM32F446xx RM, I think On the other hand, when the filename is provided, the program calls Line 207 in db8f789
It results in the following calls:
Not digging too deep into these functions, I wonder if we actually want to read four bytes from
|
Looks to me as if at least the wrong address is read. Why should we read address fields that are reserved? |
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
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 |
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 currently waits for #1181 to merge. |
We may continue with this now. |
@gszy BTW: Where did the |
I didn’t copy the 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
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 |
Yes, of course - that's out of question. I've already started to go through the comments chip by chip. We should also check the I'll start a new working branch for this. |
} else if (strcmp (word, "flash_size_reg") == 0) {
if (sscanf(value, "%i", &ts->flash_size_reg) < 1) {
fprintf(stderr, "Failed to parse flash size reg\n");
} if (params->flash_size_reg & 2) {
flash_size = flash_size >> 16;
} |
@Nightwalker-87 Line 1615 in ac63368
@ApiumJacob described the bug. It is necessary to rewrite this part: Lines 203 to 217 in db8f789
to something like uint32_t option_byte = 0;
err = stlink_read_option_bytes32(sl, &option_byte);
if (err == -1) {
printf("could not read option bytes (%d)\n", err);
goto on_error;
} else if (NULL != o.filename) {
int fd = open(o.filename, O_RDWR | O_TRUNC | O_CREAT | O_BINARY, 00700);
if (fd == -1) {
fprintf(stderr, "open(%s) == -1\n", o.filename);
goto on_error;
}
write(fd, option_byte, 4);
close(fd);
} else {
printf("%08x\n", option_byte);
} This fix does not support writing to ihex. But ihex is more complicated. Bytes can be read from one place (copies in RAM), and must be written to another address (in flash). |
@Ant-ON @gszy I am looking forward to point out the current state of option byte read/write support for the different MCus supported by this toolset. In this context I've pushed a Can you have a look at it and reconsider contributing to this issue based on your previous thoughts? |
@gszy I've set |
@Ant-ON I tried this out, but it seems incomplete and leads to errors during compilation as well. |
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:
The text was updated successfully, but these errors were encountered: