Skip to main content
M
Marcin_Gasiorek
Explorer II
March 7, 2025
Solved

RFAL issue

  • March 7, 2025
  • 3 replies
  • 670 views

Hi,

In the RFAL implementation I found issue where the timer ID is compared with system time.

In the /source/rfal_nfc.c file the following snippet looks suspected (lines from 2288 to 2292):

 

if( ((platformGetSysTick() + RFAL_NFC_T_FIELD_OFF) > gNfcDev.discTmr) || (aux) ) /* In case Total Duration has expired or expring in less than tFIELD_OFF */
 {
 platformTimerDestroy( gNfcDev.discTmr );
 gNfcDev.discTmr = (uint32_t)platformTimerCreate( RFAL_NFC_T_FIELD_OFF ); /* Ensure that Operating Field is in Off condition at least tFIELD_OFF */
 }

 

 The `discTmr` can contains a timer ID returned by the `platformTimerCreate()` function. When the timer ID value is less than sum of the `platformGetSysTick() + RFAL_NFC_T_FIELD_OFF` it can cause false result on the first condition:

 

((platformGetSysTick() + RFAL_NFC_T_FIELD_OFF) > gNfcDev.discTmr)

 

 

    This topic has been closed for replies.
    Best answer by Grégoire Poulain

    Hi,

    Thank you for your analysis and reporting.
    Your analysis is correct, and indeed this usage is inconsistent with the timer interface.

    As Brian detailed before such usage is functional when using the ST provided timer     abstraction, where the timer ID/reference is the expiration time/tick itself.
    Such arithmetics shall not be performed directly on the timer ID/reference, and the appropriate solution is to make use of an additional API to provide the remaining time until timer expiration.

    An upcoming version of the RFAL will incorporate/make use of this new timer API.



    For the time being, one can proceed as follow :

    ((platformGetSysTick() + RFAL_NFC_T_FIELD_OFF) > gNfcDev.discTmr)

// Change to:
(platformTimerGetRemaining(gNfcDev.discTmr) < RFAL_NFC_T_FIELD_OFF)



    Where platformTimerGetRemaining() shall return the remaining time (ms) until expiration, for example on FreeRTOS, see the example within  TimerGetExpiryTime.

     

    Kind regards
    GP

    3 replies

    B
    Brian TIDAL
    Technical Moderator
    March 7, 2025

    Hi,

    do you use a bare metal implementation or a RTOS based implementation?

    Rgds

    BT

    M
    Marcin_GasiorekAuthor
    Explorer II
    March 7, 2025

    Hi,

    I'm using RTOS based implementation. However I posted here to just communicate the possible issue.

    Regards

    Marcin

    B
    Brian TIDAL
    Technical Moderator
    March 7, 2025

    Hi,

    a bare metal implementation will not be impacted by this issue but a RTOS implementation returning an index or a timeID is likely impacted. I'll report this internally and will keep you posted as soon as a fix or a workaround is available.

    Thanks for reporting

    Rgds

    BT

      G
      Grégoire PoulainAnswer
      ST Employee
      March 13, 2025

      Hi,

      Thank you for your analysis and reporting.
      Your analysis is correct, and indeed this usage is inconsistent with the timer interface.

      As Brian detailed before such usage is functional when using the ST provided timer       abstraction, where the timer ID/reference is the expiration time/tick itself.
      Such arithmetics shall not be performed directly on the timer ID/reference, and the appropriate solution is to make use of an additional API to provide the remaining time until timer expiration.

      An upcoming version of the RFAL will incorporate/make use of this new timer API.



      For the time being, one can proceed as follow :

      ((platformGetSysTick() + RFAL_NFC_T_FIELD_OFF) > gNfcDev.discTmr)

// Change to:
(platformTimerGetRemaining(gNfcDev.discTmr) < RFAL_NFC_T_FIELD_OFF)



      Where platformTimerGetRemaining() shall return the remaining time (ms) until expiration, for example on FreeRTOS, see the example within  TimerGetExpiryTime.

       

      Kind regards
      GP

        Terms & ConditionsAccessibility statement