Added option byte address for L4Rx devices

[bauen1]

The location of the option bytes is the same as for the STM32L496ZG.

It is different due to different flash sizes.

It was tested to work by disabling the ST Bootloader on various self build boards.

[gszy]

Hi! In L496x_L4A6x.chip, option_base is 0x1fff7800, while here you set it to 0x1ff00000. Should the values be the same?

[bauen1]

Oh, no, 0x1FF0 0000 is correct, taken from the RM0432 Rev 9 Reference Manual.
I mixed it up with Flash Size Register that I'm also debugging for this particular microcontroller.

[gszy]

Almost all other chip files have a comment referencing a C constant next to the option_base, like this one:

stlink/config/chips/L496x_L4A6x.chip

Line 12 in 951859c

option_base 0x1fff7800 // STM32_L4_OPTION_BYTES_BASE

I don’t know if/when it is necessary, hopefully someone else will explain it.

[Nightwalker-87]

@bauen1 @gszy It should always be present in the chip-id files and if option byte use is implemented in the code as well for the respective mcu type the related memory address from the reference manual needs to be present in the chip-id file. Otherwise 0x0 is set.

So please only update this setting if the interaction with option bytes is also implemented in the codebase. As far as I can see this is currently not the case here.

[bauen1]

@Nightwalker-87 What code would be missing ?

I don't have a STM32L496 / STM32L4R5 available to test right now, but looking at the code, there is already stlink_write_option_bytes_l4 which should be used by both, and uses the sequence described in RM0432 Rev 9 Reference Manual, Section 3.4.2 Option bytes programming, page 141.

[Nightwalker-87]

One would have to check especially option_bytes.c and common.c closely whether existing implementations do also apply and work for this specific variant. It can be assumed that this cannot simply be concluded from the existence of stlink_write_option_bytes_l4. This should be reviewed and tested in order to have that verified.

[bauen1]

@Nightwalker-87 The method stlink_write_option_bytes_l4 should probably be called stlink_write_option_bytes_l4_l4p.

The L4 / L4P have the same flash type and the same magic dance for updating the option bytes.
Because the flash id is the same, stlink_write_option_bytes_l4 is used, which matches the manual requirements, same for the generic option byte read.

I've also just tested it again by disabling / enabling the ST bootloader, and it works correctly.

[Nightwalker-87]

@bauen1 As there appears to be no difference between L4 and L4P in the behaviour on writing option bytes, it shall be fine to preserve the method stlink_write_option_bytes_l4 and use it for both.

What device was used for testing?

[bauen1]

@Nightwalker-87 It was tested on a nucleo development board (https://www.st.com/en/evaluation-tools/nucleo-l4r5zi.html) and an in-house developed board with a stm32l4r5zi .

[Nightwalker-87]

ok. It would be good though if we had at least one further L4/L4P-device of different type tested successfully.

[bauen1]

@Nightwalker-87 You mean another L4P device ? Because nothing changed for the L4 devices, though I could test that with an STM32L496ZI