Skip to content

TARGET_STM: fix flash api 64bit address alignment on L4 and WB #12086

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

Merged
merged 1 commit into from
Dec 17, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion targets/TARGET_STM/TARGET_STM32L4/flash_api.c
Original file line number Diff line number Diff line change
Expand Up @@ -205,7 +205,7 @@ int32_t flash_program_page(flash_t *obj, uint32_t address,

/* HW needs an aligned address to program flash, which data
* parameters doesn't ensure */
if ((uint32_t) data % 4 != 0) {
if ((uint32_t) data % 8 != 0) {
volatile uint64_t data64;
while ((address < (StartAddress + size)) && (status == 0)) {
for (uint8_t i = 0; i < 8; i++) {
Expand Down
2 changes: 1 addition & 1 deletion targets/TARGET_STM/TARGET_STM32WB/flash_api.c
Original file line number Diff line number Diff line change
Expand Up @@ -154,7 +154,7 @@ int32_t flash_program_page(flash_t *obj, uint32_t address, const uint8_t *data,
StartAddress = address;

/* HW needs an aligned address to program flash, which data parameters doesn't ensure */
if ((uint32_t) data % 4 != 0) { // Data is not aligned, copy data in a temp buffer before programming it
if ((uint32_t) data % 8 != 0) { // Data is not aligned, copy data in a temp buffer before programming it
Copy link
Contributor

@kjbracey kjbracey Dec 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change isn't wrong, but it would be nice to tidy a bit - get rid of the pointer aliasing and volatile. I'd rather this was

if ((uintptr_t) data % 8 != 0) {
    while ((address < (StartAddress + size)) && (status == 0)) {
        uint64_t data64 = 0;
        for (int i = 0; i < 8; i++) {
            data64 |= (uint64_t) data[i] << (i * 8);
        }
     }

Although I would have thought it should be possible in principle to just case the uint8_t * to a __packed uint64_t * to get the compiler to figure out how to do a potentially-unaligned load. Catch is I don't think either CMSIS or Mbed has the necessary compiler macros to do that portably.

CMSIS has __UNALIGNED_UINT32_READ, but not __UNALIGNED_UINT64_READ. :(

I guess you could just do

while ((address < (StartAddress + size)) && (status == 0)) {
    uint32_t data_low = __UNALIGNED_UINT32_READ(data);
    uint32_t data_high = __UNALIGNED_UINT32_READ(data + 4);
    uint64_t data64 = ((uint64_t) data_high << 32) | data_low;
    if (HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, address, data64) == HAL_OK) {

which should be just the same or only a bit off having a direct 64-bit macro.

(And do that unconditionally - don't check for alignment - there's really no need to increase the code size to "speed-optimise" the aligned case).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi

So let's wait for ARM-software/CMSIS_5#768 merge in mbed ?

Then, to be honest, as this looks as optimization, this will not come in our todo list very soon...
So any help and pull requests are welcomed!

Jerome

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, okay, we can revisit this when that appears, rather than go for a half-nice version.

volatile uint64_t data64;
while ((address < (StartAddress + size)) && (status == 0)) {
for (uint8_t i = 0; i < 8; i++) {
Expand Down