Skip to main content
Associate
June 24, 2026
Question

Need help getting started with STSAFE-A110 (X-NUCLEO-SAFEA1B) on STM32H503 Custom Board

  • June 24, 2026
  • 3 replies
  • 101 views

Hello everyone,

I am looking for some help getting started with the STSAFE-A110 in a new project.

My Setup:

  • MCU: Custom board using STM32H503CBT6

  • Secure Element: X-NUCLEO-SAFEA1B expansion board

  • Software: STM32CubeIDE with the X-CUBE-SAFEA1 middleware added via CubeMX

  • Output: I am using the USB CDC Virtual COM port (Classic Middleware) for my output. I have not enabled and am not using UART.

The Problem:
I am completely stuck trying to get the initial communication working. I cannot seem to establish communication between the STM32H5 and the STSAFE-A110 through I2C, and I cannot get StSafeA_Init() to initialize the STSAFE properly.

I have tried reading the user manual (UM2646 - Getting started with the X-CUBE-SAFEA1), but I find it extremely confusing. It does not clearly outline the necessary steps that I need to take to start the project properly from code generated by CubeMX.

What I need help with:
Could someone provide a clear, step-by-step guide on how to actually bring up the STSAFE-A110 from a blank CubeMX project? Specifically:

  1. What exactly needs to be configured in CubeMX for the X-CUBE-SAFEA1 middleware to work?

  2. What is the exact sequence of initialization calls required in main.c to start talking to the chip?

Any guidance or a minimum working example would be greatly appreciated.

Thank you!

3 replies

Grom
ST Employee
July 1, 2026

Hello ​@Paul632 ,

X-CUBE-SAFEA1 is an older package that will soon be deprecated.

I would recommend using the new Cube package:  X-CUBE-STSE01 | Product - STMicroelectronics..

Please note that this package is based on the Secure Element Library (STSELib), which is maintained on GitHub and updated monthly. Its release cadence differs from that of the Cube package because of the additional framework integration testing required.

All the information needed to get started with the STSAFE-A product family and STSELib can be found in the following SDK wiki: stsafe-a-sdk Wiki . While this documentation is primarily intended for bare-metal implementations outside CubeMX, it is still relevant for the Cube package, even if the embedded library version may be slightly older.

Please do not hesitate to reply on this thread if you need any further support.

Best regards.

Paul632Author
Associate
July 2, 2026

Dear Grom,

Thank you for your reply. We were able to make use of X-CUBE-SAFEA1 for our project.

We currently have a prototype based on a custom STM32H5 MCU, and for testing purposes we have used an X-NUCLEO-SAFEA1B board. The testing was successful, and we are now moving forward with the design of the actual product, which will be a custom PCB containing both the STM32H5 MCU and the STSAFE-A110 chip.

I have two questions:

  1. Can we reuse the current code generated using CubeMX and the X-CUBE-SAFEA middleware on our custom PCB?

  2. Are the connections for the STSAFE-A110 correct?

     

Any help would be much appreciated. Thank you.

Best regards,
Paul

Grom
ST Employee
July 2, 2026

Hello Paul,

1. Current CubeMX / X-CUBE-SAFEA firmware

 

If the code currently generated with CubeMX and the X-CUBE-SAFEA middleware has already been successfully tested on your prototype, I do not see any objection to using this firmware for production.

 

The X-CUBE-SAFEA package fully supports the STSAFE-A110. By comparison, the newer STSELib supports the full brand protection secure element portfolio, including STSAFE-A120 and STSAFE-L010, and provides greater integration flexibility.

 

The purpose of STSELib is to simplify adoption and improve time-to-market for end-product developers.

 

In your case, the key point in deciding whether to stay on the current package or migrate to the new one is whether your end product must comply with the Cyber Resilience Act (CRA).

 

The CRA requires software deliverables and vendors to support, among other things:

  • vulnerability management
  • third-party dependency tracking
  • security defect assessment and impact analysis
  • patch, mitigation, or advisory publication
  • supported-version and maintenance-window definition
  • traceability between issues, fixes, releases, and impacted versions

These aspects are covered by the STSELib / X-CUBE-STSE01 roadmap and maintenance model.

 

Therefore:

  • if your product falls under the CRA, I would recommend moving to the new package
  • otherwise, you can continue with X-CUBE-SAFEA

 

2. STSAFE-A110 Connection diagram

 

The connection diagram looks correct, and the STSAFE-A110 should function properly. A few comments below:

 

  • /RESET line

If the /RESET pin is not driven by the host, which appears to be the case in your design, we usually recommend tying it directly to VCC.

In the current implementation, the LED would never switch on, which may introduce unnecessary BOM cost.

  • Decoupling capacitor

As recommended in the datasheet, standard decoupling capacitors should be placed very close to the VCC and GND pins.

This helps stabilize the supply rail, especially when the power source is not local or when multiple transient events occur.

Please see the datasheet extract below.