Le STM32, quelle belle machine... - Page 1

Bon alors le problème, là, il est simple, à la base...

J'ai un SPI MASTER (qui contrôle la CLK) et un GPS en face. Je communique avec des trames binaires au format UBX (6 octets d'entête, payload -if any-, 2 octets de CRC).

Donc j'envoie ma trame de requête au GPS qui doit va répondre un peu plus tard, une fois qu'il a lui même interprété la question et élaboré une réponse qu'il mettra à disposition sur le SPI.

1- Le STM32 envoie bien les 6 octets
2- Petite pause avec musique d’ascenseur
3- J'essaye de réceptionner les 6 octets d'entête de la réponse du GPS car il contient la taille de la payload -if any- (qui peut varier) pour savoir combien d'octets + 2 octets de CRC je dois lire ensuite

Et là, c'est le drame :/

Premier essai, je demande à lire que 6 octets

Sur l'analyseur logique, ligne du haut, on reçoit bien 6 octets, le premier à... FF (WTF!) Du coup mon entête est tronquée, je n'ai pas la taille.



Mais le mieux est encore ce que le STM32 reçoit : je lui demande de foutre tout ça à 'bufUbx=0x20017f18' (en haut à droite) et il me fout tout ça à... 0x20017f1c (en bas au centre, après le bleu)

Et ce n'est pas fini, la séquence 0Ah 04h 64h se transforme en... 0E34 (WTF!)



Deuxième essai, je demande à lire 6 octets + 1 pour espérer avoir la taille au complet

Réponse de l'analyseur logique, j'ai bien reçu 7 octets, avec la taille en little endian 64h 00h qui est là. Youpi !



Le STM32 transforme à présent la séquence 0Ah 04h 64h 00h en... 0A34 (WTF!)



Troisième essai, je demande à lire 6 octets + 1 + 4 pour espérer avoir quelque chose de correct en mémoire

L'analyseur logique voit bien la séquence de 11 octets demandée.



Qu'est ce que fout le STM32 ? Pour une fois il ne corrompt pas la mémoire, il oublie juste quelques octets en cours de route.

De la fin de séquence 31h 2Eh 30h 30 il ne reste que... 31, le reste est resté non initialisé.



C'est moi qui ne sais pas y faire ou c'est de la merde en LQFP64 ?

Pourtant j'ai bien configuré le DMA avec des mots d'un BYTE, donc il devrait purger un peu sa FIFO sans faire n'importe quoi.

je pense pas que le package change quoi que ce soit, c'est le même die partout.

regarde comment est branlé le driver spi de nuttx (bô RTOS posix BSD de la morkitu) sur le stm32 ca pourra t'aider.

https://bitbucket.org/nuttx/arch/src/874d126b08fbd9007ff65f7e24361c05181a800d/arm/src/stm32/stm32_spi.c?at=master&fileviewer=file-view-default

et son copain le DMA (quelle série de stm32?)

https://bitbucket.org/nuttx/arch/src/874d126b08fbd9007ff65f7e24361c05181a800d/arm/src/stm32/stm32f10xxx_dma.c?at=master&fileviewer=file-view-default

https://bitbucket.org/nuttx/arch/src/874d126b08fbd9007ff65f7e24361c05181a800d/arm/src/stm32/stm32f20xxx_dma.c?at=master&fileviewer=file-view-default

https://bitbucket.org/nuttx/arch/src/874d126b08fbd9007ff65f7e24361c05181a800d/arm/src/stm32/stm32f40xxx_dma.c?at=master&fileviewer=file-view-default

sinon j'ai chopé un bug spi sur le stm32f411, il FAUT que les GPIO SPI soient au moins en SPEED_50MHz sinon le bit de poids faible saute systématiquement. C'est pas ton souci présent'ment mais ca peut quand même être lié.

(bon, tu es qui ? On est plusieurs à se demander si tu es un ancien yAronaute revenu avec un nouveau pseudo )

Allez en vrac, quelques idées :
- regarde la liste des erratas pour ton µC
- relis bien les docs du µC et du GPS. Y'a pas une histoire d'alignement, de timing, etc. que tu n'aurais pas vue ?
- teste sans le DMA, en faisant du bête polling avec le contrôleur SPI
- si tu peux, déconnecte le GPS et connecte directement SI à SO, pour vérifier que tu reçois bien la même chose que ce que tu envoies

Par ailleurs, si la réponse du GPS n'est pas celle que tu attends même sur l'analyseur logique, je ne vois pas comment ça pourrait être le µC le coupable.

t'as vu squalyl, j'ai rien dit sur ST

j'ai vu ^^

si, ca peut. le bus spi peut être perturbé par le stm32 lui même.

j'ai du code spi sans DMA pour stm32 si tu veux.

Folco > c'est l'une de mes pistes aussi, mais je trouve que le style n'est pas tout-à-fait le même

squalyl (./5) :
si, ca peut. le bus spi peut être perturbé par le stm32 lui même.

J'y ai pensé, mais je trouvais ça vraiment tiré par les cheveux même pour ST .

(et c'est qui ce personnage que vous semblez vénérer comme un Dieu ancien et avec qui vous me confondez ? Ça en devient agaçant que vous parliez tout le temps de votre ex, je suis là, hôôô, hééé, mais allo quoi)



Ca y est, je pense avoir trouvé une piste sérieuse mais pas complètement farvelue : en fait le code d'initialisation généré automatiquement par STMCubeMX s'occupe bien de mettre en route la librairie HAL et les différents IP, mais les laissent cependant dans un état indéterminé, en tout cas en ce qui concerne le registre d'émission/réception du SPI.

Pour résoudre le problème et initialiser les FIFO, juste après l'initialisation du SPI, avant de descendre le niveau de CS, je fais un HAL_SPI_TransmitReceive "dans le vide" de 16 octets à FF histoire de forcer MOSI et MISO à l'état haut. Les transmissions suivantes s'effectuent ensuite comme attendu, la trame vue par l'analyseur logique est bien inscrite en entier dans la mémoire, à l'endroit indiqué.

Par contre elle commence toujours par FF, mais si l'analyseur logique l'a vue ainsi, il faut que je regarde du coté du GPS pour voir si ce n'est pas un octet de synchronisation. Ça va impliquer de faire plusieurs lectures combinées et de les aligner correctement. Bon, j'ai ma botte secrète : le buffer circulaire.

wohlala... bien content de pas utiliser ce stm32cube...

(en tout cas c'est quelqu'un qui a un analyseur logique de chez Intronix, ca ne laisse pas beaucoup de choix

Je ne connais que deux personnes qui on un tel matos

(Déterrage)

Je viens de remarquer la différence dans les pseudos

Nan... mais... putain...

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy.st.com%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fSTM32L476xx%20disambiguation&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=135#{C8E2F61A-1E19-4889-A0AA-5832C09B3EE9}

nan mais tout va bien, c'est que du refactor de code, y'a pas à se prendre la tête, c'est plus clair écrit comme ça ^^

Attention à la faute de frappe, hein, ce n'est pas un refactor correct, sinon il ne se serait pas plaint.

Ne jamais se fier au code fourni par les fabricants de µC/µP surtout si c'est ST ou Microchip. Ils gèrent ça par-dessus la jambe.

(d'un autre côté, tout refaire from scratch demande du temps qu'on a souvent pas )

On peut aussi utiliser NuttX.

Bah, les ingé de chez ST vont sur instructable pour savoir comment utiliser des composants électroniques, et mettent plus d'une semaine (et ralent comme pas possible) pour arriver a faire marcher un ESP8266 donc...

Ingés ou stagiaires ?

C'est la même chose?

Malheureusement ce sont des ingés, je les ai vus, ils ressemblaient pas a des stagiaires.

Je retrouve pas le topic, mais ingé apriori