STM 32 qui reset les paramètres

[Gabin]

Bonjour,

J'ai un problème sur ma RS CNC 32 avec lequel j'arrivais a vivre avec mais qui m'embête pas mal aujourd'hui. Mes paramètres GRBL se réinitialisent quand je me connecte au PC.
Je pense qu'il y a un problème avec la carte, qui se reset à chaque fois que je m'y connecte.

A chaque fois que j'essaye de me connecter à ma carte GRBL, il faut que je fasse une certaine manip :

1) J'allume la CNC
2) Je branche le cable USB vers l'ESP 32 situé sous mon écran.
3) Je me connecte via arduino ou universal gcode sender, peu importe, ça fait pareil.
4) Au moment de la connexion, l'écran TFT s'éteint puis se rallume et je reçois ce message :

**** Connected to COM5 @ 115200 baud ****
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1216
ho 0 tail 12 room 4
load:0x40078000,len:9720
ho 0 tail 12 room 4
load:0x40080400,len:6352
entry 0x400806b8
setup: rxfifo size before interrupt=1

5) Je me déconnecte du port COM sur mon PC.
6) Je vais dans le menu Fraisage --> USB
7) Je me reconnecte
8) si je fais $$, je perds tous mes réglages GRBL, ils reviennent à ceux d'origine

Si aujourd'hui ça me pose problème, c'est que j'aimerais connecter un convertisseur PWM --> 0-10V pour commander ma broche chinoise, mais si les paramètres se réinitialisent, c'est vraiment pas pratique pour régler.

Peu importe si avant l'étape 3 je vais d'abord dans le menu Fraisage -->USB, dès que je me connecte la première fois en USB, j'ai un reset.

J'ai déjà changé le STM32, car j'ai jamais vu ce problème sur le forum. J'ai repris le même modèle, est ce que ça pourrait être la cause?

[mstrens]

Normalement les paramètres consultables par $$ restent mémorisés dans le STM32 et ne sont donc pas perdus après un reset ou même un power down.
S'ils sont perdus, il est probable que le STM32 utilisé n'est pas équipé d'une puce du fabriquant officiel mais d'une copie chinoise.

La solution est soit:
- d'acheter un autre module stm32 es espérant que ce soit un "original"
- reflasher en mettant directement les paramètres désirés dans le fichier defaults.h (et aussi config.h)

[Gabin]

Bonjour mstrens et merci pour ta réponse rapide ! Aurais tu un lien d'un STM32 "original" ? Les deux que j'ai seraient des copies?
J'ai prévu d'utiliser ma RS CNC à la fois en mode laser et en mode usinage, donc à chaque en-tête de Gcode, je pensais mettre $32=0 ou $32=1, et aussi changer les vitesses min et max à chaque en tête.

Je demandais ça car je veux utiliser un convertisseur pwm vers 0-10 V. Et je n'arrive pas à aller jusqu'à 10V à l'aide du convertisseur. Je bute à 8V :/

[Gabin]

Petite mis à jour, après trois jours de doute et remise en questions, je viens de déconnecter les fils qui étaient cablés, et j'obtiens bien une sortie 0-10V continue ! Reste à travailler pour que le reste marche

[mstrens]

Pour le STM32, je n'ai pas de lien. Il y a déjà longtemps que je n'en ai plus acheté et il n'y a aucune garantie que mon dernier vendeur n'ait pas changé de fournisseur depuis lors.
Demandes à HTheatre s'il en aurait encore un dans son stock de pièce.

Pour le signal PWM, comment as tu fait le branchement du signal PWM.
A mon avis, il faut brancher le PWM+ sur une pin 5V vcc de la carte stm32 et brancher le PWM- sur la pin PWM de la carte stm32.

Tu peux aussi faire le test suivant:
le voltage max (10V) devrait être obtenu (avec réglage sur le potar de ton module) si tu branches PWM+ sur une source 5V et PWM- sur le Gnd de la même source. Pour ce test, il ne faut donc pas raccorder la pin PWM de la carte STM32. Si ce n'est pas possible dans cette configuration, le problème se situe au niveau de ton module.
Si tu peux obtenir le 10V ainsi et pas en utilisant la carte STM32, il y a peut être un problème de fréquence du signal PWM. Je ne sais pas quelle est la plage de fréquence autorisée pour ton module et si celle paramétrée dans le firmware est adaptée. Au besoin, il faut changer le paramétrage.

[HTheatre]

Bonsoir,

Je confirme qu'il me reste 2 STM-32 de chez RobotDyn. Il sont équipés de la puce STM-32 originale. Clique sur "Service de dépannage" dans ma signature, si tu es intéressé, pour connaître les modalité du service que je propose.
Je peux te donner le lien où je me fournis, mais en ce moment RobotDyn est en rupture partout dans la monde, suite à une pénurie de la puce STM-32 originale (dixit RobotDyn, que j'ai contacté). Inutile de commander un module avec puce APM-32, j'en avais commandé un pour tester avec notre RS-CNC32 et cela ne fonctionne pas pour une question de fréquence d'horloge (mstrens est le plus calé pour expliquer cela)

Par contre, je ne suis pas certain que le simple fait de mettre $32=0 ou $32=1 en début de Gcode sera suffisant pour basculer de la fraiseuse au laser. Cela va dépendre du signal PWM qu'accepte ton laser pour fonctionner. Le convertisseur PWM -> 0-10V que tu montres fonctionne avec un signal PWM inversé, c'est à dire par défaut le signal PWM émis par les pins PWM de la carte GRBL 32 bits. Or la plupart des lasers fonctionnent avec un signal PWM "à l'endroit". Cela nécessite donc de modifier un paramètre dans le firmware pour inverser le signal PWM (déjà matériellement inversé par défaut de la carte GRBL): l'inverse d'un signal PWM inversé étant un signal PWM "à l'endroit". Les commandes $32=0 ou $32=1 ne font que respectivement désactiver et activer le mode laser. Ces commandes sont sans effet sur le sens du signal PWM de la carte GRBL.

Or avec le firmware "classique" du STM-32 cette manipulation ne peut être réalisée qu'une reflashant le firmware pour passer le signal soit en inversé soit "à l'endroit". Cela impliquerait donc de reflasher le STM-32 selon si tu souhaites utiliser le laser ou la fraiseuse commandée par le signal PWM de la carte GRBL.

Une bonne solution reviendrait à utiliser un firmware spécifique à ta configuration. Jette un œil au post de pju dans ce topic. Il donne les fichiers à remplacer dans le firmware original pour contourner ton problème et propose de créer 2 boutons sur l'écran pour activer soit le laser soit la fraiseuse. Sinon, tu as également mes explications à manutere ici, peut-être un peu plus détaillées.

@+

[Juroui]

Bonjour,

J'avais également eu ce pb l'an dernier : https://www.makerfr.com/forum/viewtopic ... 683#p29683

Effectivement les qualités des bluepill sont très aléatoires.
Durant le confinement en attendant d'autres achats de STM32 chez Ali, j'ai eu le temps d'approfondir les pb des fakes et autres joyeusetés (beaucoup de choses intéressantes sur les forums m'ont fait découvrir que c'était courant).
Au final, j'ai encore reçu les mêmes, j'ai testé le remplacement que des puces par des vrais 128kB, pas une partie de plaisir à souder mais cela fonctionne.

Concernant les fakes (ou pseudo fake car vendu pour 64kB), seul 64kB sont exploitables et la solution que j'ai trouvée c'est alors de décaler l’EEPROM simulée de grbl avant les 64kB dans un emplacement flash libre.
Je l'ai placée en 0x0800fc00.
Evidemment il faut vérifier que cette plage d’adresse est vide, ce qui est le cas car le prg s’arrête en 0x0800BEC0 (version du FirmGRBL32-150120.zip) , peu de chance d‘adresser ailleurs.

screen04.jpg

Cela m'a permis de résoudre ce pb le temps de recevoir les autres STM32. A défaut cela restait fonctionnel (le temps de faire joujou avec) à condition de lancer à chaque reset le fichier de config mis sur la SD.

Voila si cela peut aider d'autres à dépanner ce pb.

[mstrens]

Merci pour l'info.
Il est cependant étonnant que dans atollic, l'adresse EEPROM soit dans une adresse supérieure à 64K pour un STM32F103C8.
En effet, à ma connaissance, le STM32F103C8 officiel est donné pour une ROM de 64K et non de 128K même si en pratique ils ont tous une ROM de 128K. La raison en est, je pense, que son bon fonctionnement n'est pas garanti.

Sans doute que les copies chinoises sont elles "d'origine" limitées à 64K pour réduire les frais de production.

On pourrait mettre dans la documentation la modification que tu as faite car elle devrait pouvoir fonctionner aussi pour les STM32 "officiels".

[mstrens]

En fait l'adresse , n'est pas définie par Atollic mais directement dans le programme dans le fichier
6-AXIS-USBCNC-GRBL-master/util/stm32eeprom.h

Ce n'est donc pas une erreur d'Atollic mais de la part de celui qui a porté GRBL sur STM32.

Je pourrais donc faire la modif directement dans la version sur github.