STM32WB support

[zyp]

Hi, I saw @newbrain mention in #456 that he's already working on STM32WB support, but I don't want to clutter up that PR with unrelated discussion, so I'm opening a new ticket.

I've got a STM32WB Nucleo on the way, and I figure the first thing I wanna do with it is get blackmagic support for it in place, but I also don't wanna do double work if somebody else is already making progress on it.

@newbrain: How far along are you?

[newbrain]

Hi, I'm almost there, I had to rework the coming PR a couple of times (due to #445 e subsequent #455), but I'm testing it right now so it will soon be up. I have got a Nucleo and a Dongle, but they sport sample HW, so some details are different: when you have final HW please give it a run, when my PR is up (there's some chance tonight CEST).

What is there so far:

• The PR is an addition to the stm32l4.c code: #456 was written with that in mind, same probe and attach functions (before #445 it was a separate source file, with another one containing common parts extracted from l4 support)
• Flashing/erasing works, but every now and then I get a error (also with a plain STM32L476, I think it's completely unrelated).
• Better error handling for the options command, as they are quite delicate and might lock you out.
• Specific default values for final and pre-prod HW
• Added a command for page erase, just handy to avoid erasing the radio FW with a mass erase: monitor erase_page <address> [number of pages]
• A command to set the CPU2 options (this might not work on final HW, it does on mine)

What is not there - and is not going to be, from me:

• The possibility to lock/unlock the chip security (ESE/FSD bits); the final RM does not make any mention of the procedure, and according to it the chips come pre-secured from factory (it was different in an early version I have): the code just leave those alone.
• A way to flash the radio FW: while the pre-prod HW is "open", for the final one it seems you need to use the bootloader or OTA update (my HW does not have any bootloader, so I can't even try that).

[UweBonnes]

"monitor erase_page

[number of pages]" We should do something similar for NRF5. Otherwise: What is wrong with "release often, release early?

And consider developping together with https://github.com/UweBonnes/blackmagic/tree/blackstlink. So more need to reflash the on-board stlink or use an external BMP.

[newbrain]

"release often, release early": If the preference is, in general, to have a minimal viable commit (e.g. initially only flash/debug, commands then might follow in another PR) I can adapt. I thought that would have mean more work for the official maintainers. At this point I will still make a single PR for STM32WB, but will keep this in mind for the future.

NRF5: I have 0 experience with NRF5, but from a cursory look at the code, I see that the same command code I use could be easily adapted: I, in fact, invoke the basic flash erase function, which is itself base paged. The code could be generic for any target, taking the erase function pointer and page/flash size from the flash structure. I will adapt the function, name it more generally, and remove the static, so that just an extern declaration in nrf51.c will be enough. Is that an acceptable way forward?

blackstlink: If I understand correctly the content of the blackstlink branch, it is a gdb server implementation to use an unmodified STlink as BMP? (I think you dropped a "no" in the last paragraph)

That's quite interesting, even though I wonder what the difference would be for an average end user WRT OpenOCD or similar (I did not check any detail). I'll check it more thoroughly (as usual, time allowing...), thanks for the "invitation".

[UweBonnes]

Release often. release early: If your development branch is on Github, annouce it here, maybe with some hints fot expected errors. So others can test early and avoid duplicate work

Sector erase: Reuse is good!

Blackstlink branch offers "stlinkv2" as PROBE_HOST. The platform compiles a PC "blackmagic_stlinkv2" executable like for the libftdi platform "blackmagic" is compiled. Running "blackmagic_stlinkv2" seaches for connected STLINK boards, like the stlink on a P-NUCLEO-WB55. So:

• Normal users can use BMP for a Nucleo/Disco board without additional hardware or reflashing the stlink.
• Compile/debug cycles are faster as firmware upload to the BMP and USB reenumeration is not needed
• Debug messages go to PC console.
• You can use other tools (e.g. Stm32CubeProgrammer, openocd, pyocd and pystlink) alternativly.

Stlinkv2 compiles with mingw(xx)-make on my Linux machine. I did not test yet on a real or virtual windows machine.

Regarding openocd: blackmagic_stlinkv2 does not force you to scan and remember millions of configuration options. Attach problems like seen and partial corrected here are much worse on openocd. Getting patches accepted with zylin feels like a PITA.

[newbrain]

I see, thanks for the clarification. 1st and 4th points are very good for an end user, and 2nd and 3rd for contributors: I compile BM in less than 3 sec on WSL, but the DFU update really takes its time, including HW fiddling.

Regarding openocd: blackmagic_stlinkv2 does not force you to scan and remember millions of configuration options.

One thousand times this! I do not use it directly, I mostly develop in Visual Studio Community, with VisualGDB, a commercial product that shields you exactly from this kind of problems.

[esden]

Any updates on this issue? Maybe it would be good to have a checklist of what still needs to be done here?

[esden]

As far as I understand the support for STM32WB is now added with #942 if any additional parts need to be added please send in pull requests. :)