• State
  • Replies 6 replies
  • Subscribers 32 subscribers
  • Views 120 views
  • Users 0 members are here
Support feedback
Options
Options
Related

MSPM0-SDK: MCAL FEE—Unbounded polling loop

Francois Charlot
Mastermind 30212 points

Part Number: MSPM0-SDK

Hi all,

The Fls_Ctrl.c file in the MCAL 1.0.0 FEE driver contains an unbounded polling loop:

bool Fls_waitForCmdDone(void)
    {
        /* Wait for command to complete */
        while ((FLASHCTL->GEN.STATCMD & FLASHCTL_STATCMD_CMDDONE_MASK) !=
               FLASHCTL_STATCMD_CMDDONE_STATDONE) {
            ;
        }
    
        return ((FLASHCTL->GEN.STATCMD & FLASHCTL_STATCMD_CMDPASS_MASK) ==
                FLASHCTL_STATCMD_CMDPASS_STATPASS);
    }

The M0G TRM does not state that CMDDONE in FLASHCTL->GEN.STATCMD will always be raised at some time. Does the flash controller ensure that CMDDONE is always raised at some time, even if the flash command does not complete normally for any reason?

In case this is not guaranteed by design, should a timeout be added to this polling loop? Which duration? Or should the driver allow other tasks to interrupt it during the polling loop?


Best regards,
François.

  • 0
    TI__Mastermind 28312 points

    Hi Francois,

    This could related to an Autosar level requirement. However, I'll ask internally about this question.

    Best Regards,

    Diego Abad

  • 0
    TI__Mastermind 28312 points

    Hi Francois,

    As per the TRM,

    STATCMD will be set whether the flash operation passes or fails, I don’t think it will be stuck forever without setting the bit DONE in the design.

    And for the matter of a timeout, we do have a timeout mechanism provided called TIMEOUT_SUPERVISION for program and erase flash operations which can be enabled and timeout value can be configured from Tresos as well. 

    Best Regards,

    Diego Abad

  • 0 in reply to Diego Abad Sajamin
    TI__Mastermind 30212 points

    Hi Diego,

    The TRM has quoted above says "completion", which implies a successful completion of the command, otherwise the command has not completed. For the flash controller to be able to tell that a command has timed out because it has failed for some reason, it would need to integrate a counter detecting such a failure after a certain number of clock ticks. This number could use the flash characterization data (below table from the datasheet) and be programmed into the FACTORY registers. Such values could not be hard-coded into the flash controller because they depend on the characterization data, and you do not want to re-do a silicon because those values have changed for some reason. I do not see such timeout values in the FACTORY registers, but they could be part of the reserved registers, so I am asking you to check whether we have such a mechanism. Could you please check?

    Then you said "we do have a timeout mechanism provided called TIMEOUT_SUPERVISION for program and erase flash operations which can be enabled and timeout value can be configured from Tresos as well".

    That's good in case we do not have a timeout mechanism integrated into the flash controller. Where is this documented? I did not see anything in the FEE module documentation...

    Then, I see this in FeeApp_Startup.c:99:

    NVIC_EnableIRQ(SysTick_IRQn);

    Can't this conflict with other modules (or the application) using the SysTick? Maybe we have an example illustrating the use of TIMEOUT_SUPERVISION without interfering with the application?


    Best regards,
    François.

  • 0
    Prodigy 20 points

    We have considered enabling TIMEOUT_SUPERVISION configuration but it seems that it will only be checked after Fls_waitForCmdDone() is done, so if the function is stuck the counter for timeout will not be evaluated.


  • 0 in reply to Rana Abed
    TI__Mastermind 28312 points

    Hi Team,

    Understood. I'll get back to both feedback to my team and see what is their input.

    Best Regards,

    Diego Abad

  • 0 in reply to Diego Abad Sajamin
    TI__Mastermind 28312 points

    Hi Team,

    Here are the comments from the MCAL team expert:

    The FEE algorithm is built entirely upon the provided MCAL FLS module and invokes FLS APIs internally to perform flash operations. Consequently, any timeout mechanisms applicable to the FLS module are also applicable to the FEE. The timeout supervision implemented in the FLS module utilizes OS-layer API stubs, which in our demo application utilize the SysTick timer. Customers are free to use any other available on-board counters or timers if the SysTick is already occupied.

    That being said, these mechanisms are functionally effective provided that Fls_waitForCmdDone() does not become indefinitely 'stuck.' These timeout mechanisms are designed to ensure that flash operations complete within the maximum expected time specified in our datasheet; a failure to complete suggests that the flash may have reached its end-of-life (exhausted its erase cycles) and is no longer reliable.

    The datasheet value is inside the Program and Erase Timing:

    My internal team also confirmed that the STATCMD.CMDDONE will always achieved in all Flash operations, so as long as the device is working as intended, which is the assumption, then the Fls_waitForCmdDone should never be halted.

    Best Regards,

    Diego Abad