Document and Programming Tool Quality ?

[mkrug]

Dear ST and STEmployees,

I know, everything is hard and stressful and nobody has time to take care about daily quality topics. However, I need to let you know that I'm heavily disappointed about the documentation and programming too. quality around the STM32WB55RG.

My personal story: I'm teaching as a professor at a German university. About two years ago I asked a student to work with the STM32WB55RG in his final year project. It was about using the STM32WB55 for a custom sensor node that is transmitting data using BLE. All started with the respective Nucelo Board.

The student managed to get the non-BLE part running on the Nucleo board, but not the BLE part. The project finally failed and slept about 2 years. Now I have a different usecase. So I thought I will do it on my own.

Beside the really complicate structure and most of the ST teaching (webinar, documents) material outdated, I really ask myself if this product family is something worth to consider for teaching or product development?

I just come across the problem of updating RF-Stack and FUS. Having no success and a lot of frustration on my side.

Parts of the frustration is that the documents available seems to be outdated and/or partly wrong. Just to give you some example. The release notes for the BLE Stack say that the 'full' version has to be programmed at 0x080CA000 for the 1MByte version. The UM2237 tells on page 100 the same address for FUS and BLE-Stack (latter likely wrong) and a filename for the BLE Stackfile that is outdated since 2/2020 (18months!). Additonally I got from a post in the forum that (https://community.st.com/s/global-search/0x20030030 somewhere in the middle) that reading the FUS version will not work if the SWD is used for the connection. So if this is the case, why is this pushbutton available in the SWD version of the STM32Programmer (Beside that I don't understand the technical background)?

The entire programming sequence seems to be unstable. Sometimes a change in the RDP (0->1->0 read out protection) is recommended to delete the flash before programming. Sometimes it is recommended that should be followed by a -fwdelete command (firmware delete) before starting to program the new FUS/RF-Stack. Is this really necessary? If so - I strongly recommend to publish an errate or application note that is really working as a cookbook example how to deal with the FUS/RF-Stack update realiably.

Certainly, that might be all based on a wrong usage of the SW tools by myself (still remaining the documentation errors). However, if I fail - how good will it work for students and young engineers? Will this really lever their innovation potential - or will it be the other way round?

In the meantime I need to do a fix on my Nuceleo board (probably the fastest solution will be to buy a new one and not touching FUS/Stack) to fulfill my promise I made towards a colleague in helping him with the device. After that - I think fear I need to wait another 2 years before the product become usable in an appropriate way.

Any comment and discussion is appreciated.

Best Regars

Markus

[Tesla DeLorean]

The closed and secure nature of these, and IoT software stacks in general is likely to get more obfuscated and complicated, than less. There's generally a move to stop fiddlers and hackers from disrupting or exploiting systems.

I'd expect the partitioning of this software to be cumbersome, and evolving, and require the images for the two halves to be coherent in versioning/expectations. The protection methods need to be cleared and firmware flushed in many cases to allow the reapplication of new software. Bricking protected devices is a frequent outcome, they are designed to fail securely, and be resistant to modification and/or tampering.

ST's primary customers are large, and have deep teams, they aren't geared to supporting individuals. Technical Support is burdensome and expensive, expect to bear those costs to get the level of service/support desired.

You should perhaps look to technologies and stacks which are open and for which source is completely available. There's a lot of proprietary and regulatory pressures to limit this, especially in the radio domains.

[mkrug]

Hi DeLorean,

I fully understand that my very limited needs of components cannot be the driving force for the product development and maintencence. Actually I got from another major semiconductor manufacturer the statement that: Usually our customers also buy the service from our field application engineer and he/she is covering all the nasty aspects.

Well, that might be a common standpoint but for me this isn't a good explainations why things are not completely documented, misleading or simply wrong.

I also understand that IoT devices have to fulfill high demands concerning manipulation. But this is something different from what I experience that a device is not behaving like it should with the original documentation and original tools.

Best Regards

Markus