STM32WB programming time during production

[pzt]

Hello,

I developed an application to automate the programming of the STM32B55xx, since I have a batch of more than 10000 parts. I used the documents AN5185 and UM2237 as a basis. For this product, I am using FUS version v1.2.0 and the "stm32wb5x_BLE_Stack_full_fw.bin" stack version v1.14.0.

However, the programming time takes more than 60 seconds when it is necessary to update the FUS, program the stack and the application firmware. I implemented a verification to detect the FUS version so that there is no need to update if the version is already the desired one, but it still takes more than 45 seconds to program the stack and the application firmware. The application uses less than 100kB of flash, and I noticed that what takes the most time are the various core resets that FUS performs during its update and stack programming. Therefore, I believe that migrating from a ST-LINK V2 to a ST-LINK V3 would not help in this case.

In production, I perform two steps. The first is to program the FUS, stack and production test firmware. After the test in production, I perform a new check if the FUS and the stack are correct and then I program the firmware of the final application to perform burn-in. Given the need for both steps, you can see that it will take me a long time to program all the parts. Therefore, I have two questions:

1. How to check if the stack that is programmed is the correct one, since other BLE stacks have the same version (v1.14.0.5)? Is there a way to identify which stack is programmed (besides checking the version)? That way I could shorten the second production stage.

2. How to update FUS and program the stack faster?

Thanks in advance!

[Piranha]

WOW! How many resets the FUS does? The flash itself should be capable of erasing and programming 100 KB in less than 2 seconds. Of course, calculating a hash and verifying a signature can take some time, but with a dedicated hardware it should be pretty fast.

[pzt]

I share a log for the following sequence, using STM32CubeProgramer v2.11.0, a ST-LINK V2 and a STM32WB55CE:

1. Delete stack;

2. Update FUS;

3. Read FUS;

4. Program stack;

5. Start stack.

For this sequence, we can see 12 reconnections (looking for the string "Reconnecting..."), 9 resets (looking for the string "Application is running, Please Hold on...") and, as can be seen, the download/program times are not a problem (looking for the string "Time elapsed"). From a reset to a reconnection, we can see that sometimes it takes more than 12 seconds (from 16:22:48 to 16:23:00), but usually it takes at least 4 seconds.

[Remy ISSALYS]

Hello,

In order to identify which stack is programmed, you can recover the stack type using the SHCI_GetWirelessFwInfo command. You can look the STM32WB-FUS-CLI project which allow to interact with FUS in order to perform an upgrade of the WS or FUS, delete the WS and switch between FUS and WS. In this example, the stack type is displayed in debug trace.

For your second question, can you share your script in order to understand why the programmation is too long.

Best Regards

[pzt · Accepted solution]

Sorry for the late answer.

Actually, the verification I do during production is via SWD. I don't see it as feasible or safe to interact with FUS via application firmware (as you stated, using SHCI commands). Reviewing the AN5185 document I noticed that the "Wireless stack memory size" can be verified by accessing the device information table (Table 7, page 20), which is located in SRAM2a public area. Thus, the version and size of stack (and other information in the device information table) can be used to verify that the stack is correct.

And no, I can't share proprietary code because the application has a lot of software dependencies (given its modularity) that the company doesn't allow me to share, sorry. I've already shared a log in the last message using STM32CubeProgrammer v2.11.0 which I described the sequence I made showing that it takes too long.