Grzegorz Szymaszek

I’m sorry, I don’t have any L0s to test.

I haven’t tried remote disassembly yet, the basic functionality—breakpoints, stepping through the code—seemed to just work last time I used it. I second @xor-gate: > Maybe there is something wrong...

Well, it seems that when the filename is not provided, the program prints the result of `stlink_read_option_bytes32()`: https://github.com/stlink-org/stlink/blob/db8f789400d0ac19536228b0bd774ac8f1d60ed6/src/st-flash/flash.c#L210-L215 It results in the following calls: - `stlink_read_option_bytes32()` - `stlink_read_option_bytes_f4()` - `stlink_read_option_control_register_f4()`...

We currently seem to read four bytes starting from 0x1fffc000, because that’s the way STM32F446’s option bytes are defined in the lib: https://github.com/stlink-org/stlink/blob/db8f789400d0ac19536228b0bd774ac8f1d60ed6/src/stlink-lib/chipid.c#L295-L305 I don’t really think the address is...

> 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...

> -- Looking for sys/mman.h - not found That was your original problem.

I’m sorry, I wasn’t able to find the correlation between the `mman.h` error and the `_FORTIFY_SOURCES` issue, so I suspected missing development packages. An explicit optimization flag had been set...

> And where I can find the missing packages, or who will put it back ? I don’t have a Fedora at hand, but I guess the package in question...

Hi! In [L496x_L4A6x.chip](https://github.com/stlink-org/stlink/blob/951859c119c570f3bdf8b42da0fbbaffec0848ab/config/chips/L496x_L4A6x.chip#L12), `option_base` is `0x1fff7800`, while here you set it to `0x1ff00000`. Should the values be the same?

Almost all other chip files have a comment referencing a C constant next to the `option_base`, like this one: https://github.com/stlink-org/stlink/blob/951859c119c570f3bdf8b42da0fbbaffec0848ab/config/chips/L496x_L4A6x.chip#L12 I don’t know if/when it is necessary, hopefully someone else...