STM32H7: Width of FLASH_ACR_LATENCY in rm0433 versus stm32h743xx.h

[Uwe Bonnes]

Hello and all good wishes for the new year!

While RM0433 has 4 bits reserved for FLASH_ACR_LATENCY, stm32h743xx.h only defined

#define FLASH_ACR_LATENCY_Msk               (0x7U << FLASH_ACR_LATENCY_Pos)

What counts? Is bit3 in FLASH_ACR evaluated by the STM32H743 or not?

[Tesla DeLorean]

Will need to check my notes, but you should be able to do a write-readback check to see what gates were fabbed. ​I have parts that ran up to 533 MHz.

[Khouloud GARSI]

Hi @Uwe Bonnes​ ,

All the best for 2019 :smiling_face_with_smiling_eyes:

The header file is correct: The "FLASH_ACR -> LATENCY" bit-field is mapped on 3 bits. 

-> The reference manual will be updated accordingly.

Many thanks for your continuous valuable feedback!

Khouloud.

[alister]

RM0433 Rev 7 still says FLASH_ACR LATENCY is 4 bits and every version of stm32h743xx.h on github says FLASH_ACR_LATENCY_Msk 4 bits too.

@Khouloud GARSI​ or @Imen DAHMEN​, could you confirm please?

[Imen.D · Accepted solution]

Hi @alister​ 

You are right, I raised the request internally to align the github and the RM with the Cube firmware.

So, the defined of the FLASH_ACR LATENCY will be updated to 3 bits (instead of 4 bits).

Thanks for your contribution.

Imen

[alister]

Hi @Imen DAHMEN​ 

I have a problem in production that may depend on this.

Is this the exact correction to the STM32H7 FLASH_ACR documentation please?

Bits 31:6 reserved

Bits 5:4 WRHIGHFREQ

Bit 3 reserved

Bits 2:0 LATENCY

Thanks

Alister

[Imen.D]

Hi @alister​ ,

In the "FLASH access control register (FLASH_ACR)" section, the table's Bit 3 should be marked as "reserved" + replace the description of this bit-field:

1111: 15 wait states used to read from non-volatile memory

by

0111: seven wait states used to read from non-volatile memory

Imen