nicoboy
b1bb0fa21a
Le verrouillage total decide precedemment (aucun effacement, cycle
d'alimentation obligatoire) rendait le developpement intenable : chaque
breakpoint tuait le PWM jusqu'a debranchement. EMUSTOP n'est pourtant pas
un defaut de puissance mais un artefact du debogueur.
La distinction est maintenant explicite dans la boucle principale :
overcurrent / overtemp -> enter_safe_state(), VERROUILLE jusqu'au cycle
d'alimentation (PROMPT §8), aucun acquittement
emustop seul -> reprise controlee
La reprise ne redemarre PAS la conversion la ou elle s'etait arretee :
elle repasse par start_conversion(), le meme chemin qu'au boot, duty remis
a zero d'abord. Quand la rampe de soft-start existera, la reprise apres
breakpoint en beneficiera automatiquement.
uart_link_restart()
Reset logiciel du SCI, vidage des FIFO, abandon de la ligne en cours et
de la trame en attente. Pendant la halte l'ESP32 a continue d'emettre :
l'anneau de reception a deborde et la ligne assemblee est tronquee.
Le vidage avance seulement la QUEUE de l'anneau ; s_rx_head appartient a
l'ISR et n'est pas touche, ce qui exclut toute course.
TZCLR au demarrage dans safety_init()
TZFLG.OST est latche dans le materiel : il survit a un reset logiciel
comme a un rechargement de programme, et sans ce clear le PWM restait
coupe sans raison visible.
Sans danger, pour une raison precise : a ce stade pwm_init() a deja
force les deux sorties a l'etat bas (AQCSFRC), donc rien ne demarre ; et
si la condition de defaut est toujours presente le trip se re-verrouille
immediatement. On n'efface qu'un etat perime, jamais un defaut reel.
start_conversion()
Sequence de demarrage factorisee, appelee au boot et a la reprise.
Inhibe la decharge AVANT d'autoriser les etages -- jamais l'inverse,
sinon la conversion travaillerait contre le circuit de decharge.
Valide sur cible apres cycle pause/reprise/pause :
TZEINT.OST rearme a 1 (l'ISR l'avait mis a 0), AQCSFRC.CSFA a 0,
GPIO5 a 1 (decharge inhibee), GPIO16 a 1.
LIMITE CONNUE, non resolue ici : a la reprise l'effacement est immediat
alors que la telemetrie ne part que toutes les 300 ms. FAULT=1 ne sera
donc quasiment jamais emis, et l'ESP32 ignorera qu'un EMUSTOP a eu lieu
(sans meme voir de timeout si la halte a dure moins de 2 s). Transmettre
FAULT=1 AVANT la halte est structurellement impossible : la halte est
asynchrone, imposee par la logique de debug, sans point d'accroche
prealable -- c'est justement pourquoi TZ6 est un chemin materiel. La
solution sera un drapeau collant maintenu quelques secondes apres la
reprise.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>