-1
Initialiser Bonjour toutSTM32F746 time out
Je suis en train de migrer d'un STM32F407 à un STM32F746. Le problème que j'ai rencontré était en utilisant la bibliothèque ST HAL pour initialiser le CAN. Le code a été généré à partir de MX Cube (4.16). En utilisant un Nucleo-144 STM32F746, j'ai pu dépasser le code d'initialisation (MX_CAN1_Init()) pendant le débogage (ST-Link), mais pas sur le système de production en utilisant un uLink Pro en débogage. Le temps d'attente est dépassé en attendant que le périphérique CAN (bit MSR INAK ne soit pas effacé).
Les broches CAN n'étaient connectées à rien, c'est-à-dire flottantes.
Généralement, la broche CAN Rx est entraînée au niveau de ralenti droit par l'émetteur-récepteur CAN. Placer des résistances de traction avec une polarité incorrecte sur ces lignes fera tomber tout le bus (cela a été fait). Il est préférable de ne pas utiliser de résistance de tirage. – Lundin
@Lundin Avoir une résistance de tirage ne devrait pas affecter négativement le bus car les aigus sont "récessifs". Alors oui, l'émetteur-récepteur CAN devrait le tirer correctement, cependant pour tester le code, lorsque l'émetteur-récepteur CAN n'est pas nécessairement câblé, le fait de ne pas tirer sur la broche RXD empêchera le module CAN de s'initialiser. J'ai mentionné que je n'ai pas d'émetteur-récepteur connecté. – Flip
Si vous n'avez pas d'émetteur-récepteur CAN, vous êtes en général en mode "loopback", où le signal ne quitte même pas le MCU. J'ai vieilli depuis que je me suis rendu compte que jouer avec de telles choses pendant la phase de développement est tout simplement néfaste. Mieux vaut obtenir un émetteur-récepteur et un autre nœud, comme un adaptateur d'écoute CAN, le plus tôt possible. Il n'y a pas beaucoup d'efforts impliqués dans la réparation de cela, par rapport au débogage comportement particulier causé par ne pas tester avec des conditions réelles. Les simulateurs en général devraient être évités, si possible. – Lundin