-
Notifications
You must be signed in to change notification settings - Fork 67
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
stm32g491 support? #52
Comments
Confirmed, code is not appropriate for a Category 4 stm32g4 device :-(, the code in mcu is only for Category 2 and Category 3 devices. Attempts to flash fail during the erase phase as it tries to use the Category 3 option. Is there anything I can do to help? |
I was expecting the following to fix the 'problem' with stm32g491, but I still get an error: Erase [ ] 0% 0 bytesDFU state(10) = dfuERROR, status(3) = Device is unable to write memory Here is the code adjustment:
|
Found out why we got the error, dfu-util insists on sending ERASE_PAGE and SET_ADDRESS DFU commands, which are not supported by src/bootblock.c, here is my hacky code adjustment following. I probably need to investigate what sboot_stm32 is doing that results in dfu-util wanting to use these two commands.
Edit: my DFU_STR_FLASH had keys that optionally enabled ERASE cycle, before FLASH cycle, so I can turn that off. However the latest dfu-util will insist on using the SET_ADDRESS command blowing sboot_stm32's compatibility unless we add support for it first. |
My WAG and heads up, stuff like (untested, I am a few weeks away from this being a priority) is missing:
But I am sure that is flawed since usb driver, albeit similar to stm32f4 from the HAL perspective, might not be from the lower level driver perspective. IDK. I have a NUCLEO-G491RE in my hands where I am working on porting an application from stm32f429 and noticed that to use sboot_stm32, it was borken. Once application port and bringup is done, then I can test sboot_stm32.
The text was updated successfully, but these errors were encountered: