Pourquoi mon émetteur-récepteur CAN ne reçoit-il pas de messages à moins qu'un long délai de démarrage ou qu'un analyseur de bus ne soit connecté?


8

J'utilise un MCU 16 bits, PIC24HJ64GP504 , pour écrire une application CAN. Fondamentalement, c'est la communication entre ma carte et un autre nœud qui continue d'envoyer des données à ma carte en utilisant CAN à 1 Mbit / s. Je configure le module ECAN dans mon PIC24 pour fonctionner à 1 Mbit / s. J'ai écrit le code de telle manière que pendant les 10 premières ms, le module ECAN accepte tous les messages provenant de l'autre côté, puis j'ai reconfiguré le module ECAN pour accepter uniquement les messages avec l'ID de message 0x13.

Voici maintenant le problème .. L'autre nœud et ma carte sont mis sous tension au même instant. L'autre nœud commence à transmettre des messages après environ 40 ms après la mise sous tension. Mais je ne peux pas en obtenir de message sur ma carte. Maintenant, si j'allume d'abord ma carte, donnez-lui un peu de temps pour reconfigurer le module ECAN avec de nouveaux filtres et installez-vous puis allumez l'autre nœud, alors tout fonctionne parfaitement.

Maintenant, la partie la plus étrange .. Si j'ai un analyseur de bus CAN connecté entre ma carte et l'autre nœud et même si j'allume les deux nœuds en même temps, tout fonctionne bien ... pas besoin d'alimenter ma carte en premier. J'ai essayé cela avec trois analyseurs de bus différents de différents fabricants et j'ai obtenu les mêmes résultats.

Il me semble que lors de la reconfiguration du module ECAN, il faut un certain temps pour s'installer. Et avec l'introduction de l'analyseur de bus dans le bus, ce temps est en quelque sorte écourté pour que tout fonctionne parfaitement. Mais je ne sais pas exactement quel pourrait être le problème.

Je me bats avec ce problème depuis sept jours.

PS: Aujourd'hui, j'ai vérifié avec une portée et découvert que si l'autre nœud commence à transmettre après 170 ms après la mise sous tension, alors tout fonctionne bien. Avant cela, mon appareil ne recevra aucun message de lui à moins que l'analyseur de bus ne soit connecté. Le pire, c'est que je ne peux pas retarder la transmission de l'autre nœud, le firmware de ce nœud est propriétaire.

J'ai également lu dans un forum aujourd'hui que CAN a besoin de la résistance de 120 Ω au nœud pour le faire fonctionner (même si mon nœud n'en a pas et qu'il fonctionne bien, à condition de disposer d'un certain temps pour régler après la reconfiguration). Je soupçonne que l'introduction de l'analyseur de bus modifie d'une manière ou d'une autre certains paramètres électriques du réseau de sorte que le temps mis par mon nœud pour s'installer après la reconfiguration est écourté. Mais je ne suis pas sûr.. :(


1
Pouvez-vous nous donner des liens vers tous les produits que vous utilisez. Cela permet de formuler plus facilement des réponses concrètes.
Kortuk

Êtes-vous en mesure d'apporter des modifications à votre carte ou attendez-vous / espérez-vous une solution purement logicielle?
vicatcu

Êtes-vous sûr que l'autre nœud continue de transmettre, même si votre propre nœud n'est pas opérationnel? Certaines implémentations CAN utilisent un compteur d'erreurs et si celui-ci déborde (par exemple en raison de l'absence de réception de nœuds), le nœud émetteur s'arrête.
Schedler

Réponses:


9

Vous "lisez sur un forum" quelque part que le bus CAN a besoin de résistances? Sérieusement!!?

Cela fait partie intégrante de votre conception. Si vous allez utiliser CAN, vous devez le comprendre, ce qui signifie lire la documentation correspondante.

Spearson a raison mais pour la mauvaise raison. Un bus CAN différentiel comme vous l'avez probablement (vous n'avez pas dit quelle puce d'interface vous utilisez, mais vous avez probablement un bus CAN différentiel standard piloté par quelque chose comme un MCP2551 à chaque nœud) nécessite une résistance entre les lignes. En effet, l'état récessif est signalé par les deux lignes passivement rapprochées et l'état dominant par elles activement écartées. Les résistances entre les lignes dans ce sens sont l'équivalent d'une résistance de rappel sur une ligne à collecteur ouvert. Sans quelque chose qui rassemble les lignes lorsque rien ne conduit le bus, le bus ne fonctionne pas.

Les résistances fonctionnent également comme des terminateurs comme l'a souligné Spearson. Vous utilisez généralement une paire torsadée pour les deux lignes de bus. Cela a une impédance d'environ 120 Ω. Ce type de bus CAN différentiel est défini comme ayant un couplage de 60 Ω entre les lignes afin de pouvoir être mis en œuvre avec 120 Ω à chaque extrémité pour terminer le bus et éviter les réflexions.

 


À quoi fait référence "spearson"? Un utilisateur nommé "spearson" qui a laissé un commentaire (depuis lors supprimé ou l'utilisateur a changé le nom d'écran?)? Un livre (nom de l'auteur)?
Peter Mortensen

@peter: Apparemment oui.
Olin Lathrop

4

En fonctionnement CAN normal, un nœud répétera sa transmission jusqu'à ce qu'il soit ACK'd ou que le nombre d'erreurs ait été dépassé. Lorsque l'analyseur CAN est connecté au réseau, il émet le bit ACK lorsqu'il détecte la trame de votre premier nœud, ce qui rend la transmission réussie. Si vous utilisez l'analyseur Microchip CAN BUS, vous pouvez le configurer en mode «écoute seule», ce qui signifie qu'il n'émettra aucun bit ACK, n'affectant donc pas le réseau. Vous devriez donc pouvoir voir la trame CAN répétée dans l'affichage de l'analyseur jusqu'à ce que le deuxième nœud émette un ACK ou que le premier nœud quitte la transmission en raison du nombre d'erreurs.

Le bit ACK sera défini par un nœud de réception (si la trame est complète et correcte) quel que soit le filtrage d'adresse.

Il est fort probable que votre premier nœud atteigne un état d'erreur car la trame n'est pas acquittée. Vous devez détecter cela dans le logiciel en utilisant le registre CiINTF. Vous pouvez également configurer le PIC pour émettre des interruptions pour les conditions d'erreur à l'aide du registre CiINTE.

Si votre oscilloscope ne décode pas les trames CAN, essayez l' analyseur Saleae Logic . Il décodera la trame CAN et affichera le bit ACK / Erreur. Il a été beaucoup plus fiable que l'analyseur Microchip CAN.


3

Il y a un slot ACK (deux bits) dans une trame CAN. Si un nœud A transmet les données et qu'il y a cinq autres nœuds sur le bus, après la transmission, quel que soit le nœud reçu, la trame mettra le bit dominant dans la fente ACK. Cela indique que le message a été transmis avec succès. Sinon, les contrôleurs CAN le considèrent comme une erreur sur le bus.

Lorsque vous ajoutez un analyseur CAN, il envoie un ACK à l'émetteur. L'émetteur pense que le bus est bon et continue de transmettre. En l'absence d'un analyseur CAN, lorsque vous reconfigurez votre contrôleur CAN, l'émetteur n'obtient pas d'ACK et pense qu'il y a une erreur sur le bus, il arrête donc de transmettre.

J'espère que vous avez compris.

Assurez-vous que ACK se déroule correctement. Essayez également de ne pas éteindre complètement votre récepteur CAN pendant la reconfiguration.

Une autre astuce (je ne suis pas sûr que cela fonctionnera toujours) consiste à envoyer un DLC zéro et une trame ID zéro après la reconfiguration. Cela indiquera au nœud émetteur que le bus est actif et il commencera à transmettre.

Remarque: une résistance de 120 Ω est un MUST !!! . Une résistance de terminaison est LA chose importante sur N'IMPORTE QUEL bus.


Votre astuce pour envoyer un DLC zéro et une trame ID zéro après l'initialisation, est en fait déjà dans les normes, connu comme un message de démarrage. Son ID est le même que le battement de cœur (0x700 + ID de nœud) et a un DLC unique de 1. Les outils de l'analyseur devraient le reconnaître.
BullBoyShoes
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.