2019-03-08 07:42 AM
Hello,
I'm currently struggling to setup flash reading launched from a PC.
I've used the example code for simple write and read with HAL from STM32 Cube SW.
The example show a reading of an uint32_t after writing a uint64_t.
Here is my code:
Writing flash (byte array to uint64_t) . I use a uint8_t array [88] as a buffer for the datas I generate. So I slice this buffer 8 bytes everytime to create an uint64_t for the HAL_FLASH_WRITE function.
uint64_t mydata = 0;
uint8_t buffer_flash_ht[88] ;
uint8_t reglet = 0;
uint8_t tampon8[8];
for (uint8_t i = 0; i < 8; i++){
tampon8[i] = buffer_flash_ht[i + reglet];
}
reglet = reglet + 8;
for (int i=0; i<8; ++i){
mydata = (mydata << 8) | tampon8[i];
}
if (HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, Address, mydata) == HAL_OK)
{
Address = Address + 8;
}
Reading flash
while (Address < FLASH_USER_END_ADDR){
data64 = *(__IO uint64_t *)Address;
uint8_t *message_data = (uint8_t *)&data64;
uint8_t result[8];
for(int i = 0; i < 8; i++) {
result[i] = message_data[i];
}
HAL_UART_Transmit(huart,message_data,sizeof(message_data),200);
Address = Address + 8;
}
The datas I obtain from this algorithm don't make sense.
I should get (for example) a 'h' (0x68) char in first position. But I receive a 0x19. And none of the others bytes I get correspond to what I wrote first.
Did I made a mistake in my pointer/value operations? I'm still not very confortable with this kind of instruction.
Thank you.
2019-03-08 07:47 AM
sizeof() would be that of the pointer
HAL_UART_Transmit(huart, (void *)&data64, sizeof(data64), 200); // Send 8 bytes
2019-03-08 08:35 AM
Hi,
Actually it sends 4 bytes, the uint8_t* pointer size.
The FLASH memory is accessible as a RAM ( for read ).
Try this:
HAL_UART_Transmit(huart, (uint8_t *)Address, block_size ,0xFFFF);
For the programming:
uint32_t mydata;
memcpy( &mydata , &(buffer_flash_ht[reglet]) , sizeof(uint32_t ));
HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, Address, mydata) ;
reglet += 4;
The MCU works quicker with uint32_t access.
Best Regards,
Alexey
2019-03-10 04:25 PM
Thank you both.
It solved the problem and now, everything work like a charm.
2020-07-08 08:00 AM
I was finally able to isolate the problem.
It was about the LSM6DSM and his interrupt.
For an unknown reason everytime I rebooted whe STM32, the LSM6 caused several repeated interruptions on the interrupt pin and it seem that it caused the program to enter in a unknown mode.
So I managed to counter this problem by firstly sending a reboot memory + software reset in the LSM6 CONTROL3_C register.
So now, the IRQHandler is normally called like it's supposed to be.
Thank you for your help.