X-CUBE-SMBUS 2.1.0 - Optimized builds hang when waiting on STACK_SMBUS_IsReady()

[wrigbybf]

In the code examples provided with AN4502, this pattern is used often:

    while ( STACK_SMBUS_IsReady(pcontext) != SMBUS_SMS_READY) { }

But in our code, when built with the Release CMake preset, this hangs forever.

My understanding is that this is because the `StateMachine` member of the SMBus context struct (SMBUS_StackHandleTypeDef) is getting updated by the SMBUS interrupt handlers, but it isn't marked volatile:

   * @brief Stack state machine handling structure - the stack operation context
   */
  typedef struct
  {
    uint32_t      StateMachine;              /*!< Keeps track of current stack state      */
    SMBUS_HandleTypeDef  *Device;            /*!< HAL driver handle  */
    uint8_t       *ARP_UDID;                 /*!< A UDID used in ARP */
    st_command_t  *CurrentCommand;           /*!< NULL, unless a command is being processed       */
    st_command_t  *CMD_table;                /*!< Pointer to first record in the table of all supported commands      */
    uint32_t      CMD_tableSize;             /*!< The supported commands table size    */
#ifdef PMBUS13
    SMBUS_ZoneStateTypeDef TheZone;          /*!< The zone structure */
#endif      
    uint16_t      Byte_count;                /*!< Indicates current buffer position    */
    uint16_t      SlaveAddress;              /*!< Master remembers to which slave it is talking to */
    uint8_t       OwnAddress;                /*!< Device address, ARA response / Host: Address of the device that sent alert / */
    uint8_t       OpMode;                    /*!< Operation mode (read/write)      */
    uint8_t       SRByte;                    /*!< A preset byte for use in Send byte/ Receive byte transactions   */
    uint8_t       Buffer[STACK_NBYTE_SIZE+2U];  /*!< The I/O buffer on which the SMBUS stack operates
                                                    extra 2 bytes are command code and block length */
  }
  SMBUS_StackHandleTypeDef;

I worked around the issue by declaring our own pointer to the SMBus context, but this isn't optimal, as it marks the entire struct volatile, and causes a ton of compiler warnings to be thrown:

extern volatile SMBUS_StackHandleTypeDef *pcontext;

[Saket_Om]

Hello @wrigbybf 

Thank you for bringing this issue to our attention.

I reported it internally to be fixed by our development team.

Internal ticket number: 191968 (This is an internal tracking number and is not accessible or usable by customers).