[Bug Report] X-Cube AI stucks on initialization when CRC peripheral is off.

[TAdam.1]

X-Cube AI initialization stucks on ai_network_create() when CRC peripheral is off. I noticed this problem when i tried to use X-Cube AI library inside a C++ class and called ai_network_create() inside a constructor. Class constructor was called before main(), so CRC peripheral was not initialized at that time.

I propose to change ai_network_create() to return an error when CRC fails or is off, instead of stucking in an infinite loop.

[SofLit]

Dear @TAdam.1​ ,

This is normal CRC is required to support the NN library run-time protected mechanism and CRC activation was mentioned in UM2526 (Getting started with X-CUBE-AI Expansion Package for Artificial Intelligence (AI)) / section 3.2.3 CRC .

STM32

[TAdam.1]

Dear sir, I understand that CRC is required for this library to work. I am just suggesting that initialization function should return an error when CRC fails, instead of stucking in an infinite loop. This way I can detect this error and react appropriately. śr., 14 lip 2021, 13:48 użytkownik ST Community napisał:

[SofLit]

Dear @TAdam.1​ ,

So this is not a bug (as per the title) since the CRC activation is mandatory and the information was provided in the Cube AI document ;).

But you are talking about a "change request" of the implementation of ai_network_create() to return an error when CRC.

I will ask internally to study this change, if it will be taken I will inform you.

Thank you.

STM32

[Tesla DeLorean]

Enable the peripheral clock in SystemInit() which should execute prior to constructors. ​

[TAdam.1]

It is aslo an option, but I've already moved initialization to separate function ran after main(), and it solved the problem. I write this post to warn users and to encourage ST developers to improve the library, so it would return an error instead of freezing the whole system.

[TAdam.1]

Dear sir,

When a function encounters an incorrect hardware configuration and it freezes the application instead of returning an error, I consider this a bug. Whether you consider it a bug or not is none of my concern. I am glad that this problem has been noticed and I am happy for your quick response.

Thank you for your help.

Tomasz Admaczyk-Koreywo

[Tesla DeLorean]

Just saying it's the CMSIS architected way to get pre-init stuff in order, like enabling the FPU, external memories, etc that need to be viable to unpack and initialize the statics, and call the constructors.

The initialization of things in main() which the HAL and CubeMX promote is the "worst practices" methodology.

Having stuff locked to STM32 hardware via the CRC Peripheral is also a bit pointless/petty in my opinion,

[jean-michel.d]

Dear,

With the latest release v7, now if the CRC is not clocked before to call the ai_network_create function, the following ai_error is returned:

.type =AI_ERROR_CREATE_FAILED, .code=AI_ERROR_CODE_NETWORK

Not that for the other functions (ai_networl_***), previous behavior is conserved, the application hangs.

br,

Jean-Michel