Discussion :

[transgohan]

Bonjour,

je travaille sur le driver d'un processeur Motorola 68302 pour faire une liaison HDLC et je rencontre des problèmes.

Le manuel utilisateur du 68302 décrit parfaitement le protocole HDLC et la façon dont il est géré au niveau des SCCs.
Cependant cela n'a rien à voir avec ce que j'observe après configuration et cela m'inquiète.

Contexte :
8 buffers de 1 024 octets fournis au 68302 pour la réception de trame.
Le paramètre MFLR (Max Frame Lenght Receive / Taille de trame max) est fixé à 10 240 octets.
Le paramètre MRBLR (Max Receive Buffer Lenght Receive / Taille de buffer) est fixé à 1 024 octets.

J'envoie un message de 2012 octets au 68302 (en externe via un autre processeur branché sur le même SCC).
Le gestionnaire d'IT ne me remonte qu'une seule IT de réception.
Un seul buffer semble rempli... Mais... Il déborde sur le buffer suivant !
La taille du buffer est de 2014 octets (2 octets de CRC ajouté par le protocole) et il est indiqué en tant que premier et dernière sous-trame.

Or d'après la documentation je devrais obtenir deux buffers...
L'un de 1 024 octets avec le flag sous-trame de début, un second de 990 (contenant les deux octets de CRC) et avec le flag sous-trame de fin.

Je n'ai pas la main sur le code du second processeur et donc mes tests ne sont pas vraiment aux cas limites.
Mais j'ai essayé le cas de figure suivant :

Envoi du message de 2012 octets, suivi quelques secondes plus tard d'un message de 16 octets.
Et là stupeur... Le premier message => même comportement il a débordé dans le second buffer.
Le second message a été placé dans le second buffer !!!

Du coup je me dis... Que se passe-t-il si je reçois deux messages très proches avec le premier de grande taille... Je vais avoir un message corrompu par le second ???
Et puis pourquoi mon processeur ne découpe-t-il pas les trames en sous-trame comme indiqué dans la documentation ?

Quelqu'un a-t-il déjà rencontré le problème ?


===================================
Edit
===================================
J'ai effectué un test très simple qui me fait maintenant couler de sacrées sueurs froides...
J'ai invalidé le code de remise à disposition des buffers pour qu'il reste avec le statut occupé en sortie d'ISR.

J'envoie un message de 3kio, il occupe donc trois buffers.
Seul le premier buffer est indiqué comme occupé, mais les deux autres sont allégrement écrasés, donc utilisés.
J'envoie ensuite un autre message, il vient se ranger dans le second buffer...
Je provoque donc un écrasement mémoire...

Je me dis donc... C'est une situation qui peut se produire si on a une grosse charge sur le lien.
J'ai mal configuré un truc c'est pas possible qu'un processeur de communication possède un problème pareil ???

[transgohan]

J'ai pu obtenir un logiciel sur le processeur émetteur qui envoie deux trames HTLC très proches et ainsi compléter mes tests.
Eh bah c'est pas la joie...

En déclarant des buffers de 200 octets et en envoyer une trame de 300 et une de 12 octets :
- un buffer de 200 occupé (début première trame)
- un buffer de 102 occupé (fin première trame)
- un buffer de 14 occupé (début et fin seconde trame)
Bref tout va pour le mieux ! C'est ce qu'est censé faire le protocole HDLC !

Maintenant, déclarons des buffers de 1200 octets et envoyons une trame de 1400 et une de 12 :
- un buffer occupé indiquant une taille de 1402 (donc il déborde sur le second buffer)
- un buffer de 14 occupé (qui donc a écrasé la fin de la trame précédente...)

Je n'explique pas cela autrement que par un bug dans l'implémentation du protocole des SCC sur ce processeur...

Je ne passe pas le sujet à résolu car la seule solution que je vois serait de passer mes buffers à une taille dépassant la taille max d'une trame...
Et quand on trimbale des trames de plusieurs kilo c'est pas du tout optimal...