cancel
Showing results for 
Search instead for 
Did you mean: 

During startup I occasionally get stuck in the function UTIL_SEQ_WaitEvt located in STM32_seq.c.

Louis Loving
Senior

Here is the function running in my STM32WB55CG:

/**
 *  this function can be nested
 */
void UTIL_SEQ_WaitEvt( UTIL_SEQ_bm_t evt_id_bm )
{
  UTIL_SEQ_bm_t event_waited_id_backup;
  UTIL_SEQ_bm_t current_task_id_bm;
 
  /** store in local the current_task_id_bm as the global variable CurrentTaskIdx
   *  may be overwritten in case there are nested call of UTIL_SEQ_Run()
   */
  current_task_id_bm = (1 << CurrentTaskIdx);
 
  /** backup the event id that was currently waited */
  event_waited_id_backup = EvtWaited;
  EvtWaited = evt_id_bm;
  /**
   *  wait for the new event
   *  note: that means that if the previous waited event occurs, it will not exit
   *  the while loop below.
   *  The system is waiting only for the last waited event.
   *  When it will go out, it will wait again fro the previous one.
   *  It case it occurs while waiting for the second one, the while loop will exit immediately
   */
  while((EvtSet & EvtWaited) == 0)
  {
    UTIL_SEQ_EvtIdle(current_task_id_bm, EvtWaited);
  }
  EvtSet &= (~EvtWaited);
  EvtWaited = event_waited_id_backup;
 
  return;
}

The code repeatedly calls UTIL_SEQ_EvtIdle(current_task_id_bm, EvtWaited).

current_task_id_bm is set to: CFG_TASK_SYSTEM_HCI_ASYNCH_EVT_ID

EvtWaited is set to: CFG_IDLEEVT_HCI_CMD_EVT_RSP_ID

Since I am not getting stuck there every time, it feels like some kind of race condition.

The comment seems to mention never leaving the while loop but I am not understanding it if it is telling me how to fix or prevent it.

Thanks for any help.

13 REPLIES 13

@Christophe Arnal​, if I make change these values from what is generated by CubeMX, I don't see anything on UART1 TX.

Do I also need to make the following changes (particularly setting CFG_DEBUG_BLE_TRACE 1):

/******************************************************************************
 * Debug
 ******************************************************************************/
/**
 * When set, this resets some hw resources to set the device in the same state than the power up
 * The FW resets only register that may prevent the FW to run properly
 *
 * This shall be set to 0 in a final product
 *
 */
#define CFG_HW_RESET_BY_FW         0
 
/**
 * keep debugger enabled while in any low power mode when set to 1
 * should be set to 0 in production
 */
#define CFG_DEBUGGER_SUPPORTED    0
 
/**
 * When set to 1, the traces are enabled in the BLE services
 */
#define CFG_DEBUG_BLE_TRACE     1
 
/**
 * Enable or Disable traces in application
 */
#define CFG_DEBUG_APP_TRACE     0
 
#if (CFG_DEBUG_APP_TRACE != 0)
#define APP_DBG_MSG                 PRINT_MESG_DBG
#else
#define APP_DBG_MSG                 PRINT_NO_MESG
#endif
 
#if ( (CFG_DEBUG_BLE_TRACE != 0) || (CFG_DEBUG_APP_TRACE != 0) )
#define CFG_DEBUG_TRACE             1
#endif
 
#if (CFG_DEBUG_TRACE != 0)
#undef CFG_LPM_SUPPORTED
#undef CFG_DEBUGGER_SUPPORTED
#define CFG_LPM_SUPPORTED         0
#define CFG_DEBUGGER_SUPPORTED      1
#endif
 
/**
 * When CFG_DEBUG_TRACE_FULL is set to 1, the trace are output with the API name, the file name and the line number
 * When CFG_DEBUG_TRACE_LIGHT is set to 1, only the debug message is output
 *
 * When both are set to 0, no trace are output
 * When both are set to 1,  CFG_DEBUG_TRACE_FULL is selected
 */
#define CFG_DEBUG_TRACE_LIGHT     0
#define CFG_DEBUG_TRACE_FULL      0
 
#if (( CFG_DEBUG_TRACE != 0 ) && ( CFG_DEBUG_TRACE_LIGHT == 0 ) && (CFG_DEBUG_TRACE_FULL == 0))
#undef CFG_DEBUG_TRACE_FULL
#undef CFG_DEBUG_TRACE_LIGHT
#define CFG_DEBUG_TRACE_FULL      0
#define CFG_DEBUG_TRACE_LIGHT     1
#endif
 
#if ( CFG_DEBUG_TRACE == 0 )
#undef CFG_DEBUG_TRACE_FULL
#undef CFG_DEBUG_TRACE_LIGHT
#define CFG_DEBUG_TRACE_FULL      0
#define CFG_DEBUG_TRACE_LIGHT     0
#endif

If I do, at this point, I start getting the linker error that HW_UART_Transmit_DMA is not defined.

HW_Uart.c was not generated for our project by CubeMX and that appears to be where that function is defined in other projects.

Am I missing a step in CubeMX?

Hi Christophe,

When you say " unless you added your own events in addition to the existing one" and "confirm if you added or not your own events" are you saying that if you add your own events to the sequencer used in all BLE example projects for the STM32WB you are susceptible to the aforementioned race condition?

If yes, how do you suggest integrating your own functionality into say, the p2p_server_app structure that's loaded when you select the STM32WPAN peripheral in CUBEMX. Presently, I manifest much of the functionality for my custom application by registering and setting events with the sequencer's optimised super-loop and do occasionally experience the race condition described in the original question.

See related question

Kind regards,

Tom

ItachiThuan
Associate II

I was also trapped in the while loop in line 25 too. I tried to reproduce with the wrong wireless stack and it always happens (with EvtSet =0 and EvtWaited=1). Is there any way to break the loop so I can add further action (warning) instead of hanging in that while loop when the wireless stack is not appropriate?

Thanks in advance!

Christophe Arnal
ST Employee

Hello Tom,

Yes, the only case to match the race spotted condition would be to add your own events to be waited for.

Note that the Sequencer has been fixed in V1.12.0. So, I would recommend to switch to it and check if the problem is still there.

Regards.