Support for STM32WB55xx #458

newbrain · 2019-03-08T00:13:33Z

Here is the STM32WB support promised long ago...
What is done:

Flashing, erasing, debugging work as expected.
Option command improved error checks: number format, right number of parameter.
Slightly changed behaviour (saner, IMO):
With no parameters, print the options words. With erase resets them to defaults. With write only the provided words are written in the options, the remaining ones are left untouched instead of being read and rewritten.
New CPU2option command: changes the boot address and memory start for CPU2. Probably working only on preproduction HW: @zyp to be checked on final HW!
A new erase_page command has been added:
monitor erase_page <address> [number of pages]
it is written to be independent of the MCU, it relies only on info from the flash data structure, see discussion at STM32WB support #457

What is not there - and probably cannot be easily implemented (some docs are still not available):

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).

This is a largish commit: though the structure was prepared in #456, still the changes are spread all over, mostly due to the need of parametrize the flash controller base register.

UweBonnes · 2019-03-08T09:54:11Z

Probably you have a CPU marked "ES". I will try out the PR beginning next week and report back,

UweBonnes

Unrelated change.

newbrain · 2019-03-08T10:30:57Z

Thanks. The MCU is under a metal shield, I don't intend to desolder it...

…

On Fri, Mar 8, 2019, 10:54 UweBonnes ***@***.***> wrote: Probably you have a CPU marked "ES". I will try out the PR beginning next week and report back, — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#458 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQ_SzlHLVnJay8wn1W68te5Mrqy_Cjliks5vUjNHgaJpZM4bkYT8> .

UweBonnes · 2019-03-08T11:26:00Z

The metal shield, is plugged, at least on my parts. Look again.

zyp · 2019-03-09T02:16:39Z

My Nucleo kit arrived today, so I've had the opportunity to test this now.

As evidenced by the blinky currently running on my device, erasing, flashing and debugging works fine.
Like expected, CPU2opt command can only read; write and erase appears to just be ignored. At this point it's pretty much just an alias for «x/2wx 0x58004080» which doesn't seem to justify its existence.
The page erase command works fine, but I propose changing the interface. The mix of start address and number of pages feels inconsistent. Replacing the number of pages with an optional end address would be more consistent and convenient, especially later if it gets ported to devices with several page sizes (e.g. f4).
Like the RM says, CPU1 is not allowed to mass erase the chip. The command silently fails.

Other observations:

The metal shields are just clipped in place, and even has a label stating «REMOVABLE SHIELD».
Loading and decrypting the radio firmware is managed by FUS/RSS, a CPU2 firmware located in the upper 40k of the flash. STM32CubeProgrammer can talk to it through the DFU bootloader. I expect the yet unreleased AN5185 will document how to talk to it, so we can revisit the question of whether it makes sense to add support for loading the radio firmware when it's released.
I suspect the procedure to unlock the chip security still might work, but since it involves a full chip erase, it'll also remove the FUS/RSS firmware, which kinda bricks the radio functionality since you won't be able to load the encrypted radio firmware anymore. I'll probably try this at some later point when I have any disposable devices.

newbrain · 2019-03-10T18:05:57Z

Thanks @UweBonnes and @zyp for your comments and info!

Code comments:

Like expected, CPU2opt command can only read; write and erase appears to just be ignored. At this point it's pretty much just an alias for «x/2wx 0x58004080» which doesn't seem to justify its existence.

Ok, this is also as expected, in this light I'll remove all the strictly sample dependent stuff (I'll just keep it for my use), including the CPU2options command.

The page erase command works fine, but I propose changing the interface. The mix of start address and number of pages feels inconsistent. Replacing the number of pages with an optional end address would be more consistent and convenient, especially later if it gets ported to devices with several page sizes (e.g. f4).

The L4 itself has different page sizes, and I agree with the proposal (I'm changing the code now). Thanks.

Unrelated change.

I think I have many, some is formatting (I don't like to see hex numbers with a mix of upper and lower case), and some is more substantial (option handling).
I will revert the option handling if you thinks it's "too much"; it's much less warranted now, as I'm removing the CPU2options command, though I maintain that better error checking is an added value.

The page erase function is just missing a "static", so as to be accessible from other targets
Please let me know whether that's ok, or it's better to move it in, say, command.c: it's needed here to manually erase the chip leaving the radio FW alone, as @zyp confirms.

Other:

The metal shield, is plugged, at least on my parts. Look again.

The metal shield is, in fact, removable. No label on mine, though.
I did not examine it very closely, and mistook the clips for solder (we were told at the WS that the shield was permanently fixed).
The chip is marked ES32WB55, as expected.

Loading and decrypting the radio firmware is managed by FUS/RSS, a CPU2 firmware located in the upper 40k of the flash. STM32CubeProgrammer can talk to it through the DFU bootloader. I expect the yet unreleased AN5185 will document how to talk to it, so we can revisit the question of whether it makes sense to add support for loading the radio firmware when it's released.

Yes, I'll check my boards, but I suspect I haven't got it. But I can freely load everywhere in flash (ESE == 0).

UweBonnes · 2019-03-10T19:42:26Z

Perhaps one "no-code change only cleanup commit" and one commit introducing the new feature. I think that works out clearest what changed. But no hard rules on that, only a proposal. What about putting and exporting the page erase function in command.c?

zyp · 2019-03-11T16:43:17Z

I second putting cosmetic changes in a separate commit, makes the revision history easier to browse later. A PR can contain more than one commit, so even if you split up unrelated changes, you can still submit them all at once.

Today I tried the command for editing option bytes and couldn't get it to write anything, so either I'm not understanding how to use it correctly or it doesn't work properly. Poking at the flash registers directly to make the same changes worked, so it's not that I'm not permitted to make them.

I also just had to try turning off the security to see if it was possible, and have apparently bricked the device harder than I expected to. The aforementioned full chip erase apparently went through and the ESE bit at 0x1fff8000 reads 0, but the ESE bit in FLASH_OPTR remains at 1 and everything else still appears locked. Since I still can't read the top area of the flash, I can't say for sure whether I erased it, but STM32CubeProgrammer doesn't manage to connect to FUS anymore.

In other words, I've now got a device where I apparently lost the ability to load the encrypted firmware binaries, and I still didn't gain the ability to load my own code for CPU2. I don't recommend attempting the same. :)

UweBonnes · 2019-03-11T16:58:38Z

Option bits and register only get into sync after a RESET. Did you issue a reset?

B.t.w. what are FUS/RSS you talk about ? Fuses? Relative Signal strength?

zyp · 2019-03-11T17:31:44Z

Yes, I've tried both the traditional power on reset and the OBL_LAUNCH bit in FLASH_CR. I can change other stuff in the same register like RDP just fine and have it take effect, but FLASH_OPTR.ESE reads as 1 no matter what.

RSS and FUS are respectively Root Security Services and Firmware Update Service. Like I wrote in my first comment it's a preinstalled firmware stored at the top 40k of the flash, responsible for loading and decrypting the encrypted CPU2 firmware binaries.

UweBonnes · 2019-03-11T17:42:29Z

Sorry for tedious question: Di you change FSD? And perhaps: Do you have a Stlink with original firmware? Can STM32CubeProgrammer perhaps help you?

zyp · 2019-03-11T17:49:20Z

I tried setting FSD but FLASH_SFR still appears to be locked.

Anyway, I'm not worried about recovering the device. I went into this fully expecting to lose the ability to load encrypted firmwares, I was just hoping to get the ability to run my own code on CPU2 in return. :)

newbrain · 2019-03-11T18:05:08Z

So it seems that what was described as a silicon bug in ES, is still there but as some kind of protection?

I'll split the commit as suggested. What's the preference for the erase page command?
I'd put it in the clean up one, while introducing it for regular L4.

I'll check the options code.

newbrain · 2019-03-15T22:22:15Z

I did not have much time to work on this as I am abroad (but I brought the Nucleo).
So, here is a short update:

I have found the cause of the option command failing: bad initialization of FPEC_BASE in attach function, so the SR is not in a clean state, and option writing will fail.
A workaround is issuing a load command before using option, this will leave SR in good state.
I hope I'll be able to update the PR tomorrow.

newbrain · 2019-03-16T17:23:57Z

Split in 3 commits:

Adding the erase page command to command.c and .h.
Note, the command is still per target (as are e.g. the mass erase ones).
Improve option command handling, some cleanup. Prepare data structures (changed flags).
Add the actual STM32WB55 support.

This has been tested only with a WB55 Nucleo:

The option command problem is resolved. Still it's strange that SR signals an error right after POR (same as L4, as it would seem)
Flashing and debugging work.
The erase page command works.

UweBonnes · 2019-03-16T18:35:12Z

src/target/stm32l4.c

 #include "target_internal.h"
 #include "cortexm.h"

-static bool stm32l4_cmd_erase_mass(target *t);


Unneeded shuffling around unchanged code.
\

Yes, I had moved that without noticing and forgot to reset the position, no reason to do that.

UweBonnes · 2019-03-16T18:35:56Z

src/target/stm32l4.c

@@ -109,19 +114,20 @@ static int stm32l4_flash_write(struct target_flash *f,
 #define OR_DBANK 		(1 << 22)

 #define DBGMCU_CR(dbgmcureg)	(dbgmcureg + 0x04)
-#define DBGMCU_CR_DBG_SLEEP		(0x1U << 0U)


Whitespace changes

But...they are misaligned, why keep them that way?

Style versus functional change

src/target/stm32l4.c

UweBonnes · 2019-03-16T18:40:51Z

Ferderico, sorry if I am picky. You still have unrelated and whitespace changes. git log --check also shows whitespace errors. Otherwise thanks for your persistance so long.

newbrain · 2019-03-16T18:55:58Z

It's your duty and privilege to be picky, and for me an opportunity to learn (first time I contribute to a real project).
Thanks for pointing me to git log --check.
I got better in handling branches, commits, rebasing and even cherry picking but git is complex.
The whitespace errors are my fault: as said, I'm abroad and missed one editor setting.
For some of the unrelated changes, see the comments.

UweBonnes · 2019-03-16T19:15:04Z

I only commented some places, so look around for more issues.

A command to erase one or more pages in flash in command.c. To use it, include command.h and add monitor_cmd_erase_page to the target command list.

Better error handling in option command. Erase page cmd integrated. Changes in the info structure for coming WB55 support.

The support is implemented completely in stm32l4.c. Major changes are related to the different flash controller address, and some special handling for options.

newbrain · 2019-03-16T21:50:23Z

Style versus functional change

I see and know the difference, of course.
If a source file is not touched no reason to do that.
Given the heavy edits here, why not have a easier on the eyes (== easier to maintain) code?
One might object that the added value is low, still, I find it non-negative.
(BTW: this has always been the official policy at work, so it's a bit of an automatism for me)

Anyhow, if the policy is not to have this kind of edits, I'm reverting them.
Thanks for your patience.

newbrain · 2019-03-16T22:03:24Z

Otherwise thanks for your persistance so long.

Hah! You won't get rid of me so easily.

zyp · 2019-03-17T00:14:10Z

IMO any improvements should be acceptable. The only argument against style changes is that it increases the number of edited lines that has to be reviewed. I'd say just put them in their own commit bundled in the same PR so the style and the functional changes can be reviewed separately. A style only commit is easy to review to check that it's actually only style changes.

If you use a Git GUI with line by line staging (e.g. sourcetree/gitx/gitg/etc…) it's a fairly easy process to turn a bunch of changes into a neatly grouped set of commits. At work I often create like five-six commits at a time because I've been making edits all over the place and while it made sense to work on them at the same time, they are independent enough they should be reviewed separately.

UweBonnes · 2019-07-19T12:27:44Z

Newbrain, can you resolve the conflicts?

newbrain · 2019-07-19T17:12:59Z

Possibly in about 15 days, currently out in the mountains with no computer...and no real internet.

…

On Fri, Jul 19, 2019, 14:27 UweBonnes ***@***.***> wrote: Newbrain, can you resolve the conflicts? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#458>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEH5FTSV4TOVXYJ74HFSFXDQAGXMZANCNFSM4G4RQT6A> .

UweBonnes · 2019-09-01T18:43:02Z

Please try with #507. Please also look at the comments around the flash region command.

akamensky · 2020-03-07T09:24:20Z

Is this still planned to go ahead at any time? I may need to work with WB55 soon-ish. Would love to use BMP for that if possible.

UweBonnes · 2020-03-07T11:16:52Z

As you hopefully know, BMP is a community effort. What about following the steps from https://tighten.co/blog/adding-commits-to-a-pull-request and cloning newbrain:STM32WBsupport and test and report back? And best rebase to master to update the PR.

akamensky · 2020-03-07T15:15:47Z

@UweBonnes, sure, I will see if I can repeat the same. I think I was just mostly checking with PR author here to see if he is still interested in completing his contribution here.

zyp · 2020-03-07T15:33:24Z

@akamensky If you're just looking for something to use, the PR as it is is working. Just check it out and build it.

UweBonnes · 2020-03-09T11:22:50Z

I would appreciated a rebase PR.

akamensky · 2020-03-09T15:04:22Z

I am trying to rebase the PR on my fork, however I don't think I understand code well enough to resolve a conflict in src/target/stm32l4.c:stm32l4_cmd_option. If I were to provide a completely valid changeset in rebased code, I'd need to either dig deeper into the code (to understand the context of the changes) or (I think simpler here) do my best effort and provide a PR for review, which will need to be done with extra scrutiny to said function.

UPD:

There are conflicts all over in stm32l4.c in final commit. Considering I am not familiar with this code at all I would rather not submit anything that would mess up existing cpu functionalities.

Moreover I am not sure why this even had to be added in stm32l4.c as this is entirely different series probably deserving its own target perhaps?

- Stripped down from erase_page - G4 option handling probably missing.

UweBonnes · 2020-03-09T18:44:17Z

You can try
https://github.com/UweBonnes/blackmagic/tree/stm32wb55
with Newbrains effort merged into git head. Tests, feedback and additions welcome!

newbrain · 2020-03-09T22:20:50Z

I must apologize for not taking care of this myself (after more or less promising I'd do).
What I thought was a momentary spike in my workload transformed in the daily routine, and I have much less spare time (and energy) to dedicate to this.

Thanks once again for your excellent work.

- Stripped down from erase_page - G4 option handling probably missing.

esden · 2021-12-15T22:05:03Z

What is the status on this PR? I see it is currently conflicting HEAD so it would need to be at least rebased? What needs to be still done on this?

zyp · 2021-12-15T22:14:42Z

As far as I can see, this was rebased and merged in #942, so both this and #457 can be closed.

esden · 2021-12-15T22:19:11Z

Thank you very much @zyp! :)

UweBonnes reviewed Mar 8, 2019

View reviewed changes

newbrain force-pushed the STM32WBsupport branch from 4f63303 to c6e15d6 Compare March 16, 2019 17:08

UweBonnes reviewed Mar 16, 2019

View reviewed changes

src/target/stm32l4.c Show resolved Hide resolved

newbrain added 3 commits March 16, 2019 20:57

Generic erase page command

316da66

A command to erase one or more pages in flash in command.c. To use it, include command.h and add monitor_cmd_erase_page to the target command list.

option improved, erase page commad, ready for WB55

cf46467

Better error handling in option command. Erase page cmd integrated. Changes in the info structure for coming WB55 support.

Support for STM32WB55

6f86839

The support is implemented completely in stm32l4.c. Major changes are related to the different flash controller address, and some special handling for options.

newbrain force-pushed the STM32WBsupport branch from c6e15d6 to 6f86839 Compare March 16, 2019 21:49

rubdos mentioned this pull request Oct 2, 2019

Initial STM32WBx5 support. drone-os/drone#1

Open

2 tasks

UweBonnes mentioned this pull request Mar 9, 2020

Erase range #606

Closed

UweBonnes added a commit to UweBonnes/blackmagic that referenced this pull request Mar 9, 2020

stm32l4: Use blackmagic-debug#458 merged with master

e9bfbc8

- Stripped down from erase_page - G4 option handling probably missing.

UweBonnes added a commit to UweBonnes/blackmagic that referenced this pull request Mar 10, 2020

stm32l4: Use blackmagic-debug#458 merged with master

145cca9

- Stripped down from erase_page - G4 option handling probably missing.

UweBonnes added a commit to UweBonnes/blackmagic that referenced this pull request Jun 16, 2020

stm32l4: Use blackmagic-debug#458 merged with master

8665b90

- Stripped down from erase_page - G4 option handling probably missing.

UweBonnes mentioned this pull request Dec 22, 2020

STM32G070 option bytes support #819

Closed

fabalthazar mentioned this pull request Mar 10, 2021

Comprehensive STM32G0 driver #841

Merged

UweBonnes mentioned this pull request Apr 18, 2021

Add support for STM32WLxx #856

Merged

DrZlo13 mentioned this pull request Oct 28, 2021

Support for STM32WB55 #942

Merged

esden closed this Dec 15, 2021

Support for STM32WB55xx #458

Support for STM32WB55xx #458

Conversation

newbrain commented Mar 8, 2019 • edited Loading

UweBonnes commented Mar 8, 2019

UweBonnes left a comment

Choose a reason for hiding this comment

newbrain commented Mar 8, 2019 via email

UweBonnes commented Mar 8, 2019

zyp commented Mar 9, 2019

newbrain commented Mar 10, 2019

UweBonnes commented Mar 10, 2019

zyp commented Mar 11, 2019

UweBonnes commented Mar 11, 2019

zyp commented Mar 11, 2019

UweBonnes commented Mar 11, 2019

zyp commented Mar 11, 2019

newbrain commented Mar 11, 2019

newbrain commented Mar 15, 2019

newbrain commented Mar 16, 2019 • edited Loading

UweBonnes Mar 16, 2019

Choose a reason for hiding this comment

newbrain Mar 16, 2019

Choose a reason for hiding this comment

UweBonnes Mar 16, 2019

Choose a reason for hiding this comment

newbrain Mar 16, 2019

Choose a reason for hiding this comment

UweBonnes Mar 16, 2019

Choose a reason for hiding this comment

UweBonnes commented Mar 16, 2019

newbrain commented Mar 16, 2019

UweBonnes commented Mar 16, 2019

newbrain commented Mar 16, 2019

newbrain commented Mar 16, 2019

zyp commented Mar 17, 2019

UweBonnes commented Jul 19, 2019

newbrain commented Jul 19, 2019 via email

UweBonnes commented Sep 1, 2019

akamensky commented Mar 7, 2020

UweBonnes commented Mar 7, 2020

akamensky commented Mar 7, 2020

zyp commented Mar 7, 2020

UweBonnes commented Mar 9, 2020

akamensky commented Mar 9, 2020 • edited Loading

UweBonnes commented Mar 9, 2020

newbrain commented Mar 9, 2020

esden commented Dec 15, 2021

zyp commented Dec 15, 2021

esden commented Dec 15, 2021

newbrain commented Mar 8, 2019 •

edited

Loading

newbrain commented Mar 16, 2019 •

edited

Loading

akamensky commented Mar 9, 2020 •

edited

Loading