Setup

• Board: NUCLEO-L412KB
• BSP: S2868A2 (Reproduces more often on custom S2-LP boards)
• IDE: STM32CubeIDE 1.7

The board is connected to the S2-LP devkit through jumper cables, as described:

Digital Interface:

• A1 (PA1) -> SPI_CLK (CN9-4)
• A5 (PA6) -> SPI_MISO (CN5-5)
• A6 (PA7) -> SPI_MOSI (CN5-4)
• D3 (PB0) -> S2LP_SPI_CSN (CN8-2)
• A3 (PA4) -> SDN (CN9-8)
• D6 (PB1) -> GPIO3 (CN8-6)

Additional connections

• VCC (3v3) -> S2LP_VIN (CN6-4)
• GND -> S2LP_GND (CN6-7, CN5-7)
• [S2868A2 only] VCC (3v3) -> EEPROM_CSN (CN9-6).
  I do not use the EEPROM functionality, so EEPROM_CSN has to be pulled up.

The bug

S2LP Driver code enters infinite loop when RcoCalibration fails.
The reason is the S2LP_RcoCalibration function, located in s2lp.c.
The function does not check the case of RCO calibration error.

According to the datasheet, when RcoCalibration fails, the ERROR_LOCK bit in MC_STATE1 register is set.
Currently, the S2LP_RcoCalibration function waits until the RC_CAL_OK bit is set, without checking the ERROR_LOCK bit.
Therefore, when the RCO calibration fails, the function does not exit the loop.

How To Reproduce the bug
The bug occurs in software, following a hardware error, so it is slightly tricky to reproduce.
From my experience, the hardware error occurs once in a while, so to reproduce it I reset the Nucleo devkit using reset button, until the hardware error occured - which was followed by the software getting stuck.

Additional context

• Global behavior of my application project: simple P2P sender and receiver, used to develop high level driver for S2LP.
• Modules that cause the problem: S2LP driver, in the S2LP_RcoCalibration function.
• Use case that generates the problem: S2LP initialization using driver code.

In my implementation - I created a function in the high-level driver that replaces the S2LP_RcoCalibration function, which checks the case of RCO calibration failure, and returns an error code accordingly.

To make my high level driver stable - in case of failure, I started again the whole process of initialization (incluiding resetting S2LP using the SDN pin), for about 10 times.

From experimenting, I noticed the maximal amount of times the error has repeated itself was 4.
Therefore, my code tries to initialize S2LP in a for loop for 10 times until it has success, otherwise it returns failure - which should be dealt with by the driver user.

I will soon create a pull request with a patch.

Hi there!

See here:
https://github.com/STMicroelectronics/x-cube-subg2/blob/main/Drivers/BSP/Components/S2LP/S2LP_Library/inc/S2LP_Regs.h#L364

The comment states that the RSSI_TH signal detect threshold is in 0.5 dB steps but in the S2-LP datasheet (page 68) it is stated that it is in 1 dB steps.

Best regards,
Pieter

Driver code does not compile due to incorrect code.

Setup

• Board: NUCLEO-L412KB
• BSP: S2868A2 (Reproduces anywhere, software related)
• IDE: STM32CubeIDE 1.8

Context

I am comparing the code of this repository - to the S2LP driver code I acquired using
STM32CubeIDE software package manager (following STMicroelectronics YouTube tutorial)

I will refer to the code acquired following this tutorial as the original code,
since it is a release version, therefore it is safe to assume more people have the same driver code.

Bug details

Code that causes the problem:

• Calls S2LPSpiReadRegisters instead of S2LP_ReadRegister (The first one is not defined therefore incorrect)
  • Source files: s2lp_general.c ,s2lp_types.c
• Multiple definition of ModeExtRef enum:
  • Original definition in s2lp.h (exists in current release of x-cube-subg2)
  • Duplicate occurrence in s2lp_general.h
• Calls to undefined function/macro s_assert_param (not defined at all in the repository).
  • Source files: s2lp_general.c

Additional code problems

• Missing import of s2lp_general.h in s2lp.h.
  • This masks all the problems in s2lp_general files. but this does not prevent the compilation errors.
  • The s2lp_general files exist in the repo and their purpose seems correct.
  • In my opinion they should not be deleted, but rather fixed
• Duplicate definition of S2LPGeneralLibraryVersion()
  • Source files: s2lp.h, s2lp_general.h
  • In my opinion it should stay in s2lp.h
• Duplicate functions in s2lp_general files, which already defined in s2lp.h and implemented in s2lp.c:
  • S2LPGeneralGetDevicePN, already exists as S2LP_GetDevicePN
  • S2LPGeneralGetVersion, already exists as S2LP_GetVersion
  • S2LPGeneralSetExtRef, already exists as S2LP_SetExtRef
  • S2LPGeneralGetExtRef, already exists as S2LP_GetExtRef
  • S2LPRadioSetExternalSmpsMode, already exists as S2LP_SetExternalSmpsMode
  • S2LPRefreshStatus, already exists (and widely used) as S2LP_RefreshStatus
    Since the functions already exist, it would be incorrect to delete them
    (as this would break compatibility to the previous release version).
    Therefore - a good solution would be to keep the existing functions,
    move them into s2lp_general files, while removing the duplicate functions defined in the s2lp_general files.
    This way the functionality and compatibility will be preserved.
    In addition, this solution seems to align with the purpose of s2lp_general files.
• Duplicate definitions of the g_xStatus variable
  • Original one in s2lp.c
  • Duplicate one in s2lp_types.c
    This does not cause compilation error, but it is incorrect.
    A fix to this would be to choose one between the two.
  • In my opinion, s2lp_types should not contain the definition of g_xStatus since it is not a type.
    It is rather a global instance variable. Therefore I believe it should be declared in s2lp.h and defined in s2lp.c
    (similar to the IO_func variable in s2lp.c)

How to reproduce the bug

Copy the source files located in Drivers/BSP/Components/S2LP to your project, then compile.

Additional context

I am using the driver code to write S2-LP high-level interface, which is platform independent.
Therefore, the code is more sensitive to platform dependent definitions.
Example of such platform dependent code:

• The driver code contains the function s_assert_failed, and calls to undefined s_assert_param macro.
  The current behavior of a failed assert is a printf call, and infinite error loop.
  Driver code should not behave this way.
  Parameter validations are important and should be performed, but the result
  of bad parameter should be returning an error code.
  Therefore, in my patch I temporarily defined empty macro for s_assert_param,
  but I believe both s_assert_param and s_assert_failed should be removed from
  the driver code.

Solution

I have patched the mentioned problems, compiled and tested my patch by running simple P2P app.
Soon I will open a pull request containing my tested patch.

Caution

The Issues are strictly limited for the reporting of problem encountered with the software provided in this project.
For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post a topic in the ST Community/STM32 MCUs forum or in the ST Community/Q&A Topics.

Describe the set-up

• Nucleo-f401RE
• x-cube-subg1
• running Project S2868A2_CLI example on NUCLEO-f401RE from the project source as it is.
• CubeIDE 1.14.4

Describe the bug

• S2LP_ManagementIdentificationRFBoard function freezes and does not Return
  IN
  
  freeze_readregisters_on_s2lp.csv
• On the SPI Bus I see the data shown i the attached file

How To Reproduce the bug
Run the example

Additional context
I can not understand what I did wrong as obvious this Project is used (probably) by others.

If applicable, add screenshots to help explain your problem.

S2LPPktBasicWhitening(S_ENABLE);
S2LPPktStackWhitening(S_ENABLE);
S2LPPktBasicFec(S_ENABLE);
S2LPPktStackFec(S_ENABLE);

these code causes:

Error[Li005]: no definition for "S2LPWhitening"
Error[Li005]: no definition for "S2LPFec"