Crc_Ip_SetChannelCalculate Timeout Issue on S32K3 RTD

[ZHANMENG]

Environment:

- MCU: S32K344 (Cortex-M7)
- SDK/RTD Version: RTD 5.0 (Real-Time Drivers)
- Toolchain: NXP GCC 10.2 for Arm 32-bit Bare-Metal
- IDE: S32 Design Studio
- Development Board: Custom board based on S32K344

Description:

I am implementing a CRC driver wrapper around the NXP RTD CRC IP driver for hardware CRC calculation. During development, I noticed that the Crc_Ip_SetChannelCalculate() function appears to be blocking without any timeout protection mechanism in the RTD library.

I have implemented a timeout protection wrapper to prevent potential hardware fault-induced deadlocks:

---------------------------------------
static uint64_t Crc_Ip_SetChannelCalculateWithTimeout(
uint32_t logicChannel,
const uint8_t *data,
uint32_t length,
uint64_t startValue,
bool isFirstCall,
uint32_t timeoutTicks,
uint32_t *elapsedTicks,
uint32_t *currentTicks)
{
uint64_t crcResult;

crcResult = Crc_Ip_SetChannelCalculate(logicChannel, data, length,
startValue, (boolean)isFirstCall);

*elapsedTicks += OsIf_GetElapsed(currentTicks, (OsIf_CounterType)CRC_TIMEOUT_TYPE);

return crcResult;
}
---------------------------------------

My implementation uses RTD standard OsIf timeout mechanism with a 1ms timeout (CRC_TIMEOUT_US = 1000U), returning CRC_STATUS_TIMEOUT if the operation exceeds this threshold.

Questions:

1. Has anyone encountered similar timeout or hang issues with the hardware CRC peripheral on S32K3 family devices when using Crc_Ip_SetChannelCalculate()?

2. Does NXP officially recommend implementing timeout protection for hardware CRC calculations, or is the hardware guaranteed to complete within a deterministic time frame?

3. Are there any known errata related to the CRC peripheral that could cause calculation delays or hangs (similar to the "Delay after an RCC peripheral clock enabling" issue documented for STM32 devices)?

4. What is the expected calculation time for hardware CRC operations? My current 1ms timeout is based on empirical testing, but I would like to know if there is an official specification.

Additional Context:

I have reviewed the NXP community forum and found related discussions about:
- S32K344 hardware CRC calculation returning no results
- CRC calculation over Flash areas with DMA

However, I could not find specific documentation about timeout handling for the CRC IP layer.

Comparison with STM32: STMicroelectronics has documented similar timing issues with their CRC peripheral, requiring:
- 4 clock cycles wait after CRC reset
- DSB (Data Synchronization Barrier) or NOP instructions between reset and data write
- Readback of control registers to ensure hardware completion

My implementation details:
- Using Hardware Channel 0 for 16-bit CCITT-FALSE and 32-bit Ethernet CRC
- Processing data blocks up to 2KB (CRC_MAX_DATA_LENGTH = 2048U)
- System clock: Cortex-M7 running at typical S32K344 speeds

Request:

Could NXP engineering team or community members provide guidance on:
1. Whether timeout protection is necessary for production code
2. Recommended timeout values for different data sizes
3. Any timing considerations or synchronization requirements for the CRC peripheral
4. Whether this is a gap in the RTD documentation that should be addressed

Any insights would be greatly appreciated!

Code Repository Reference:

My implementation can be found in my project at: drivers/crc/crc.c:67-81 and drivers/crc/crc.h:28-31

Thank you in advance for any guidance!

[Julián_AragónM]

Hi @ZHANMENG,

1. This depends on your application's needs. If you or your team find it necessary, then I see no issue implementing OsIf module for timeout.

2. & 3. The RTD drivers include a Quality package (ProfileReport.xlsx), which contains execution time of the APIs:

"...C:\SW32K3_S32M27x_RTD_R21-11_5.0.0_D2410_QualityPackage.zip\CRC\RTD_CRC_ProfileReport.xlsx"

Please check the Crc_SetChannelCalculate() function.

4. I don't believe this to be the case. If your application is affected by this blocking function, you can configure DMA, as it is fast execution and less CPU time. Chapters 6.2.3.2 & 3.6.6.4 from RTD_CRC_UM.pdf describes this configuration. 

Hope this helps.

Best regards,
Julián