Add simple read/write support for STM32WB55 chips. #786
Conversation
|
Looks good, we should prevent long functions with conditional checks switching on chip type. Better create functions per chip type eg STM32W and call that function. |
|
Makes sense; I might have time this weekend if you don't mind leaving this open. |
|
No problem, take your time!
… On 27 Mar 2019, at 02:45, WRansohoff ***@***.***> wrote:
Makes sense; I might have time this weekend if you don't mind leaving this open.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Okay, hopefully this is a little bit cleaner. The G0 and WB series seem to have similar register offsets (like, FLASH_CR is offset by 0x14 instead of the usual 0x10), so I used the same logic for both and updated it to use the existing Flash register methods. |
|
Great, thanks for the effort! |
|
This PR breaks flashing programs on STM32G071 (which I described in #759). When I revert stlink to c6836b4, the flashing works again. I am not well familiar with the flashing procedures nor the stlink codebase. Could you, @WRansohoff, look at it, please? |
|
Well, it's certainly possible - I did try to unify the G0 and WB code since they looked mostly identical and it made the code easier to read. I have a ~126KB binary to test with, and it shows the same thing, failing to verify after 4096 bytes. I guess that's what happens when you assume, huh? Sorry, but thanks for bringing this up. I'll take a look, it's probably something dumb. |
|
I think that #797 should fix this issue, assuming I didn't mess up the Github pull request interface. |
This adds support for STM32WB55 chips - I've only tried a simple 'blink' program on the 'Nucleo-68' board, but it seems to work.
The logic and register offsets look about the same as the STM32G0 series, though - I might check if it would be easy to merge that logic, or maybe adapt it to the other chips' abstractions like
set_flash_cr_pg(...). Would that be better?