Porting SBSFU to the same family

[MHoss.1]

I'm trying port the SBSFU example STM32L476 board to our MCU which is STM32L475. Fortunately they are very similar. I'm going through the code and it makes sense but I could not find a single reference about porting it. ST has documents that explain what is going on but not how to port it. Which files should I be modified? I am going over all the source codes (.c, .h). Not sure what parts of the linker file (or any other files I'm not aware of) should be modified. A practical guide would have been useful.

A little rant: I wish this feature was implemented in the CubeMX, that would have made life a lot easier for people who don't have a long background in fw development.

[waclawek.jan]

Are you talking about https://www.st.com/en/embedded-software/x-cube-sbsfu.html or something else?

Have you gotten it working on any reference platform (Nucleo, Disco, Eval) that material is mentioning? (I'm not not using it and not going to investigate it)

Is there any material difference between the 'L475 and 'L476 at all, as far as bootloading is concerned? Review any possible differences in the memories and any related peripheral, and proceed according to those differences. I don't think you'll find many.

JW

[MHoss.1]

Yes, I mean the expansion package.

I'm still trying to get it to work (don't have an eval, so should make the example work on my own device which is not disco or eval).

You probably pointed to my main problem here, the datasheets for them are not a few pages, so comparing them doesn't seem like a logical task. I didn't find any tool or reference that points to their differences. If I can figure that out then it's just digging into the datasheet and fixing differences.

[Jocelyn RICARD]

Hello,

the SBSFU package contains an example for the L475 already.

What you need to adapt to your board is located in Target directory.

The integration of SSBSFU to CubeMX is under study but it a huge work for quite little added value.

The User application can be developed with CubeMX. You just need to adapt the mapping to fit to SBSFU.

Best regards

Jocelyn

[MHoss.1]

Yes, I saw that but all the examples are for evaluation boards and BSP should be taken out. For example I wanted to test the SBSFU with debugger to make sure it goes to the state machine properly, but TRACE is using UART. I went through the code to make sure everything related to COM and BSP are removed.

Thanks for the guide, I found my way through the SECore and SBSFU, now working on the UserApp.

I understand with all the options and possibilities that SBSFU has it can be very hard to implement it into CubeMX but here are some points:

1. For most users who are not experienced (like me), the default settings work very well. I would have been very happy to have the base settings without any UART or loader in the SBSFU so I can just compile them with a few flag changes then add my own UserApp. That way I could focus my effort.
2. Some of the hardcoded values make the transition harder, for example addressing different parts of the package is hardcoded as "../../../../2_Images_SECoreBin/Inc". So if I want to move them around (for example to have one SECore and two SBSFU), or rename directories have to change many addresses while in eclipse one could define a user variable and use that for the roots. That way such addresses need to be changed only in one place.
3. Maybe if there was a way for users to contribute by pull request on github or add to a wiki for user manual they could help each other more efficiently. For example the porting guide is not for all IDEs, I use eclipse so I could add to the wiki how one can add the symbols to debug the SECore. This might seems trivia to you because of your extended background but could save confusion or a few hours of another user that has to look through the options.

[Jocelyn RICARD]

Well, I don't really catch what is the issue with tracing with UART. Why do you need to remove it ?

Anyway, you should be able to achieve this just removing the SFU_DEBUG_MODE flag in app_sfu.h.

Or is this a matter of removing BSP dependency ?

About point 1, you can remove loader from SBSFU using flag

#[define SECBOOT_LOADER SECBOOT_USE_NO_LOADER]​ 

But here again I don't catch the problem you have with that.

About adding your own application instead of the demo application, this can be done by replacing the demo application.

This brings the constraint of having the application at same location to be able to use the scripts.

Having application in another directory requires adapting the directories in the postbuild script. I agree this require some work and could be improved

About point 2, I agree SBSFU contains too much hardcoded paths. Now this is usually one time modification to adapt to your project.

About point 3, this is a good idea. I will suggest this to development team. All your points are valid !

Best regards

Jocelyn

[MHoss.1]

The MCU I'm using is in a designed board, so all the BSP dependencies should be removed and the UART is connected to a sensor. I went through the code and made it barebone. I agree that this is a one time thing.

The flags are very helpful, I used them.

My biggest trouble with replacing the UserApp is that I use CubeMX for my code which has a different directory structure than the sample code. So have to adapt it. It is feasible, my complain is that it is just time consuming. Maybe if only the UserApp was like a CubeMX build, other parts could be adapted once and the User App could be replaced easily. We use the same micro for different projects so I have different UserApp which can use the same SBSFU. Maybe this is a more of a rant as a novice user.