STM32WB55 support

[e11i0t23]

Hi,

Great work so far, working well over usb for my test project, How is the bluetooth support coming along, I saw Ilya was working on the radio stack, and helper drivers, Is this functional and if not, what still needs implementing/testing?

Cheers
Elliot

[Giovanni]

Hi,

I applied the latest patches.

Giovanni

[FXCoder]

Hi,
The basics are there for normal STM32 type use.
There is still more to be done on the basic CPU1 use such as bringing the HAL over to use the common RCC LLD.

Then for CPU2 support (where the radio stacks run) the IPCP driver has to be implemented and perhaps a HSEM driver.
The Secure Flash region has to be observed and should be excluded in the .ld from CPU1 code space.
If EFL is to be implemented then it should take the Secure Flash boundary into consideration.

The IPCP needs to conform to channels assignments and requirements of the ST radio stacks running in CPU2.
There are controls for CPU2 enable/run etc. that also need to be taken care of (maybe a pseudo driver like RCC?).

Once all that is done then it should be possible to write some initial test applications to access an ST stack loaded into CPU2.
You'll need the latest STM32CubeProgrammer to establish/update FUS and load various radio stacks for BLE, 802.15.4 and Thread into CPU2.
Research the STM32CubeWB repo for more details of the stacks and simple ST applications using those stacks.
--
Bob

[akscram]

Hi Giovanni,

Thank you for accepting the last patches! It seems that some of new files were not included, namely files under testhal/STM32/multi/USB_CDC. Can you please check?

Hi Elliot,

Bob provided a very comprehensive explanation about what should be done! I've already researched a couple of examples in the mentioned repository and in the attachments you can find my personal notes about initialization sequence in one of them, namely BLE_p2pServer which I use as a reference. (I apologize for my illegible handwriting.) The sequence is not complete, i.e. it includes only a part of initialization and what's is not covered yet is initialization of appropriate structure for different radio stacks including BLE (called transport layer initialization). Once my changes with the clock configuration for CPU2 and the radio stack were merged, I decided to spent some time for reducing code duplication, as Giovanni suggested, by moving to RCCv1 including Bob's patch for PLLSAI1. I hope that I will publish these changes soon and switch back to my sketches for HSEM and IPCC.

Best regards,
Ilya.

[Giovanni]

I added the missing files.

Giovanni

[FXCoder]

Hi Ilya,
With respect to the WB55 support...
I've been working on a project which has WL55 but may migrate in its next revision to use a WB55 + Semtech external chip for LoRa.
So I've been digging into the WL55 and WB55 Cube "examples" on github.

On the WB55 CPU2 stacks are "black box" ST binaries.
The CPU1 side application code will need to adhere to the channel assignment and utilisation defined by the message box definitions that CPU2 stacks have fixed into them.

I've created a draft IPCCv1 driver which is relatively straight forward at the LLD and basic HLD.
The next question becomes how to best describe the message passing/channel mapping so that CPU1 application code can discover/use the correct mapping/message passing that will match the ST stacks running in CPU2.

I guess that mapping/assignment could be part of the "config" data passed to IPCC when it is started.
This needs some more thought though since both the use and structure of the data has to be accommodated.
Not quite a simple task!

Note that the WL55 can also use IPCC.
However, it can run in single CPU mode and talk to the radio on SPI as well as in dual core mode.
In this case the CPU2 code is not "black box" ST stacks but just Semtech driver with a few ST optimisations so life is a little less complicated in WL55.

Thoughts?
--
Bob

[akscram]

Hi Bob,

Thank you for the update on this. Right, WB55 doesn't allow to run any user code on CPU2 except binaries signed by STM which support different or different combinations of radio stacks. I like the idea about mapping RX/TX channels to callbacks through config for IPCC as we consider IPCCv1 as a low level driver and let other high level drivers, e.g. BLE, Zigbee, etc, handle events depending on what stack is used.

Best regards,
Ilya.

[Giovanni]

Found a problem, STM32_HAS_SPIR is not defined in all registries, this mean the SPI driver is doing checks on an undefined symbol on all platforms.

Giovanni

[FXCoder]

Hi,
This is a WL55 change (vs WB55) so we better let Vitaly know.
Solution is to edit all registries?
--
Bob

[Giovanni]

Hi,
This is a WL55 change (vs WB55) so we better let Vitaly know.
Solution is to edit all registries?
--
Bob

Yes, all registries of devices using SPIv2. The SPI driver has no checks on symbols exported by the registry so this kind of things can go unnoticed, note how newer driver do this kind of checks in those .inc files.

Giovanni