STM32F103 - CubeMX DFU
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-10-06 2:53 PM
Hi,
I couldn't find online a working bootloader implementation of STM32f103C8 based on generated files from CubeMX, i've started porting the F4 DFU to F1, there are two applications:
0x08000000 - DFU Bootloader
0x08008000 - Application
Jump between the address works perfectly, CRC works well, at the init of DFU bootloader i check the CRC at certain address if it matches the application that starts from 0x08008000.
Correctly the main issue is with the implementation of "MEM_If_Write_FS", this is the code:
uint16_t MEM_If_Write_FS(uint8_t *src, uint8_t *dest, uint32_t Len)
{
/* USER CODE BEGIN 3 */
uint32_t i = 0;
for(i = 0; i < Len; i+=4)
{
/* Device voltage range supposed to be [2.7V to 3.6V], the operation will
be done by byte */
if(HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, (uint32_t)(dest+i), *(uint32_t*)(src+i)) == HAL_OK)
{
/* Check the written value */
if(*(uint32_t *)(src + i) != *(uint32_t*)(dest+i))
{
/* Flash content doesn't match SRAM content */
return 2;
}
}
else
{
/* Error occurred while writing data in Flash memory */
return 1;
}
}
return (USBD_OK);
/* USER CODE END 3 */
}
When i try to load the app through dfu-util on linux the app freezes on:
Download from image offset 00000000 to memory 08008000-080083ff, size 1024
Poll timeout 50 ms
Poll timeout 0 ms
And on the debugger i get "Flash content doesn't match SRAM content" on the "MEM_If_Write_FS".
Is there any way to solve this issue?
Best,
Itamar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-10-07 7:27 AM
If you want to program by BYTE : in line 11 increment the counter by 1 and use appropriate parameter: FLASH_TYPEPROGRAM_BYTE. You increment by 4, and program by 32-bit (aka WORD).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-10-08 12:13 AM
Not sure i understand you, why should i change it to BYTE instead of WORD? shouldn't it work the same?
is the the reason the the dfu-util doesn't work?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-10-09 7:07 AM
UP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-10-09 7:48 AM
What is it you want everyone to do? Not sure there's a lot of pro interest in chasing down CubeMX issues.
Perhaps start by instrumenting the code so you don't stop real-time USB functionality.
Output things like the addresses involved, current content, addresses and mismatched data.
Make sure the memory is erased. Test flash code outside of DFU context.
Try using ST DFU tools
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-10-09 8:48 AM
You wrote that the error is in comparing the written value with original.
This indeed could be because writing flash is done in wrong granularity.
There's a comment in your source snippet that says that programming should be done by byte.
Same API, but stepping in the for loop then should be by one byte.
-- pa
