[pucpood]

Bonjour,

Je galère depuis plusieurs semaines avec le RN4678 implanté sur le proto à base de PIC24 dont j'ai la charge.

Aucun problème pour dialoguer avec ce RN4678 via son UART : je peux envoyer des commandes et recevoir les réponses.
Le simple couplage avec un appareil Android se passe bien également (en mode "PIN 4 digits").
En revanche impossible d'ouvrir un socket SPP. Lorsque je crée le socket avec mon appli Android, le RN4678 capte bien la demande et l'@mac de l'Android, mais c'est aussitôt suivi d'une déconnexion.
Voici les données brutes que je reçois via l'UART du RN4678, du reboot jusqu'à la fin de mes tentatives de connexion :
%REBOOT%%CONNECT,94FB29055756%%DISCONN%%CONNECT,94FB29055756%%DISCONN%%CONNECT,94FB29055756%%DISCONN%%CONNECT,94FB29055756%%DISCONN%
Je suppose que quand ça fonctionne, on a %RFCOMM_OPEN% après l'adresse mac.
Au fait, comment on indique au RN4678 qu'il est "maître" ? Il s'auto-déclare maître lorsque qu'un tiers se connecte ? Le RN4677 propose la commande SM,1 pour ça, mais elle ne fonctionne pas pour le RN4678 pour lequel elle semble avoir un tout autre sens.

J'ai aussi récupéré le status du RN4678 avec la commande GK. Elle répond "0,4,0". OK pour les 0, mais le 4 signifie "On power-up, the authentication co-processor test failed".
Cet intitulé me laisse perplexe.
La commande D n'apporte pas d'information intéressante. Elle permet toutefois de voir que l'adresse de l'Android tiers a été enregistrée.

Côté Android, je suis sûr de mon code à 99.9% vu qu'il fonctionne avec une autre plateforme équipée d'un RN42.

Après ces innombrables tests, je ne sais plus quoi faire...

[pucpood]

Bonjour !

J'ai résolu mon problème de connexion. C'était un problème "multicouche", avec principalement 2 éléments :
1 - le mode DEBUG de MPlabX n'est pas fiable. Peut-être une mauvaise cohabitation avec les INTs, ce qui peut se comprendre en fait. Ce n'est toutefois pas la première fois que le debugger me trompe, il m'avait déjà fait le coup avec le contenu d'un tableau où les valeurs affichées étaient erronées.
2 - un problème de câblage : la ligne PIC du CTS dédié au BT était aussi prise par le CS de la carte SD, sauf que cette carte SD a été ajoutée "à la volée" sans documentation, je n'ai donc pas détecté ce conflit. Coup de chance, cette patte de la carte SD s'est dessoudée, provoquant des faux-contacts. C'est en cherchant où elle était soudée que j'ai trouvé le conflit. Pour le coup j'en veux un peu à mon développeur hardware.

Les leçons à tirer pour le soft :
- ne pas faire une confiance aveugle au mode DEBUG
- regrouper au même endroit l'init de toutes les lignes d'un composant pour facilement visualiser les conflits
Et pour le hard : D O C U M E N T E R !