J'utilise divers microcontrôleurs et microprocesseurs depuis de très nombreuses années maintenant, mais il me semble que la série Kinetis KE (en particulier le S9KEAZN64AMLC) me contrarie.
17 janv.2015 TL; DR:
Freescale confirme que la version 2.0.0 de leur logiciel Kinetis Design Studio ne fonctionne pas avec cet appareil (y compris leur propre carte d'évaluation TRK-KEA64). Ils recommandent d'utiliser CodeWarrior MCU V10.6 pour le moment.
Segger a publié la v4.96a (le "a" est important, j'utilisais la v4.96), ce qui corrige le problème et vous permet d'utiliser une carte de débogage Segger J-Link Lite CortexM avec KDS et d'avoir une capacité complète de programme / débogage.
Avant que Segger ne publie la v4.96a, j'ai réussi à flasher la puce en reprogrammant le débogueur OpenSDA sur la carte d'évaluation FRDM-KL25Z bon marché de Freescale (15 $) en reflasher le firmware OpenSDA fourni avec USBDM (en utilisant la version 4.10.6.2.240). J'ai ensuite utilisé le logiciel autonome "ARM Programmer" d'USBDM. Je n'ai pas passé beaucoup de temps à essayer de faire fonctionner le débogage, car je suis assez compétent en débogage "oldschool" pour ne pas en avoir besoin. Veuillez vous assurer que vous flashez un programme "bénin" dans le KL25 cible intégré ou il peut interférer avec la programmation puisque la ligne de réinitialisation du KL25 cible intégrée est toujours connectée au débogueur OpenSDA même avec la coupe J11 (voir le billet de blog de Keith Wakeham , lié ci-dessous).
Un grand merci à Erich Styger de m'avoir aidé très gracieusement à déterminer le problème et à confirmer mes conclusions par e-mail.
Revenons maintenant à notre question régulière:
J'ai construit une carte de dérivation de 3,3 V. Il a des LED sur PTA, une connexion UART sur PTC et les lignes SWD sont sur leurs lignes dédiées. Il n'y a littéralement rien d'extraordinaire ou de drôle à propos de cette planche.
J'utilise un J-Link Lite pour Cortex-M (J-Link LITE CortexM-9, voir https://www.segger.com/jlink-lite-cortexm.html ) et sous OSX et Windows, j'obtiens le même résultat: l'utilitaire J-Link Commander peut identifier la puce, je peux lire et écrire sur SRAM et jouer avec les périphériques avec des lectures et des écritures manuelles à l'adresse d'E / S mappée en mémoire correcte. Cependant, lorsque j'essaie de flasher l'appareil, il échoue.
$ JLinkExe
SEGGER J-Link Commander V4.94c ('?' for help)
Compiled Oct 31 2014 20:08:55
DLL version V4.94c, compiled Oct 31 2014 20:08:48
Firmware: J-Link Lite-Cortex-M V8 compiled Jul 17 2014 11:40:12
Hardware: V8.00
S/N: 518107921
Feature(s): GDB
VTarget = 3.332V
Info: Could not measure total IR len. TDO is constant high.
Info: Could not measure total IR len. TDO is constant high.
No devices found on JTAG chain. Trying to find device on SWD.
Info: Found SWD-DP with ID 0x0BC11477
Info: Found Cortex-M0 r0p0, Little endian.
Info: FPUnit: 2 code (BP) slots and 0 literal slots
Cortex-M0 identified.
Target interface speed: 100 kHz
J-Link>device skeazn64xxx2
Info: Device "SKEAZN64XXX2" selected (64 KB flash, 4 KB RAM).
Reconnecting to target...
Info: Found SWD-DP with ID 0x0BC11477
Info: Found SWD-DP with ID 0x0BC11477
Info: Found Cortex-M0 r0p0, Little endian.
Info: FPUnit: 2 code (BP) slots and 0 literal slots
J-Link>r
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
J-Link>erase
Erasing device (SKEAZN64xxx2)...
(...several second pause while it communicates with the MCU...)
****** Error: PC of target system has unexpected value after erasing sector. (PC = 0xFFFFFFFE)!
---------------------------------------------------------------------- Registers -------------------------------------------------------------------------------------
PC = FFFFFFFE
Current: R0 = 00F3E3BE, R1 = 00000001, R2 = 4004801C, R3 = 00000001
R4 = 00000000, R5 = 00000000, R6 = 000000F4, R7 = 1FFFFD61
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Info: J-Link: Flash download: Total time needed: 2.174s (Prepare: 0.894s, Compare: 0.000s, Erase: 0.736s, Program: 0.000s, Verify: 0.000s, Restore: 0.542s)
ERROR: Erase returned with error code -5.
Le J-Link Lite est parfaitement bien (je peux lire et écrire sur le SoC nRF58122, un autre processeur Cortex-M0 avec lui) et l'appareil semble fonctionner autrement. Je sais que le Kinetis est déverrouillé car ils sont des stocks d'usine de DigiKey, mais même alors, la commande "kinetis unlock" dans JLinkExe expire sans aucune erreur ou information utile.
À ce stade, je suis sûr de faire quelque chose de stupide, mais je ne sais pas ce que cela pourrait être.
Quelqu'un a-t-il déjà travaillé avec ces appareils? Comment les programmez-vous?
modifier pour ajouter une procédure pas à pas:
Quelques informations supplémentaires:
J'ai lu que la broche NMI # est activée lors de la réinitialisation (et j'ai vérifié cela en lisant SIM_SOPT) mais aussi qu'elle a un pull-up interne lorsqu'elle est activée. Sur cette partie particulière, PTB4 est sur la broche 10 qui est un no-connect dans ma conception. La désactivation de la broche NMI ne fait aucune différence. RST # est similaire; Il est connecté à un bouton poussoir qui met la broche à la terre et va également au J-Link Lite, mais il n'y a pas de pullup externe. Cela ne devrait pas avoir d'importance car comme NMI #, la broche RST # a un pullup interne qui est activé lorsque PTA5 est configuré pour être une réinitialisation.
En regardant l'horloge maintenant ... Hors réinitialisation, ICS est la source d'horloge du FLL et BDIV dans ICS_C2 est réglé sur 001 (la réinitialisation par défaut). Si je comprends bien, cela signifie que l'oscillateur interne à 32 kHz est multiplié par 1024 par le FLL puis divisé par 2, ce qui rend ICSOUTCLK à 32 kHz * 1024/2 ou 16,8 MHz. Je peux vérifier via la CLI J-Link que le FLL est verrouillé en lisant ICS_S:
J-Link>mem8 40064004 1
40064004 = 50
(LOCK et IREFST sont définis, c'est correct.)
Je passe ensuite à vérifier que la carte SIM a l'horloge activée pour le contrôleur flash en lisant SIM_SCGC. Je peux également vérifier rapidement pour m'assurer que BUSDIV dans SIM_BUSDIV est réglé sur zéro, ce qui signifie que le BUSCLK a la même fréquence que ICSOUTCLK (c'est-à-dire qu'il n'est pas divisé):
J-Link>mem32 4004800c 1
4004800C = 00003000
J-Link>mem32 40048018 1
40048018 = 00000000
Jusqu'à présent, tout va bien. BUSCLK est de 16,8 MHz et l'horloge du contrôleur flash n'est pas fermée.
Passons maintenant au contrôleur flash. La réinitialisation du FCLKDIV est nulle et nous avons besoin d'une horloge de 1 MHz. Le tableau 18-2 dans KEA64RM montre que FDIV doit être défini sur 0x10.
Hors réinitialisation:
J-Link>mem8 40020000 1
40020000 = 00
La configuration du séparateur et la vérification des choses sont bonnes:
J-Link>w1 40020000 10
Writing 10 -> 40020000
J-Link>mem8 40020000 1
40020000 = 90
FDIVLD est défini et la valeur correcte dans FDIV est affichée.
Avant d'aller trop loin, assurons-nous que le flash n'est pas protégé:
J-Link>mem8 40020001 1
40020001 = FE
KEYEN = 11 (désactivé) et SEC = 10 (non sécurisé). D'accord. Essayons de vérifier que le périphérique est vide:
J-Link>mem8 40020006 1
40020006 = 80
J-Link>w1 40020002 0
Writing 00 -> 40020002
J-Link>w1 4002000a 1
Writing 01 -> 4002000A
J-Link>mem8 40020006
J-Link>w1 40020006 80
Writing 80 -> 40020006
J-Link>mem8 40020006 1
40020006 = 83
Ici, nous voyons que les bits MGSTAT dans FSTAT indiquent que la vérification en blanc a échoué et également que des erreurs non corrigibles ont été trouvées. Impair. Essayons de l'effacer nous-mêmes:
J-Link>w1 40020002 0
Writing 00 -> 40020002
J-Link>w1 4002000a 8
Writing 08 -> 4002000A
J-Link>w1 40020006 80
Writing 80 -> 40020006
J-Link>mem8 40020006 1
40020006 = 80
La commande effacer tout a réussi. Essayons maintenant un chèque en blanc:
J-Link>w1 40020002 0
Writing 00 -> 40020002
J-Link>w1 4002000a 1
Writing 01 -> 4002000A
J-Link>w1 40020006 80
Writing 80 -> 40020006
J-Link>mem8 40020006 1
40020006 = 80
Maintenant, le chèque en blanc va bien?
À ce stade, je suis prêt à abandonner, à manger la perte de ces prototypes et à utiliser un processeur de ST où je n'ai jamais eu ce genre de problèmes auparavant. La documentation de Kinetis est suffisamment complète mais elle est très dense et j'ai du mal à démarrer. Je peux faire bouger les E / S via des lectures de mémoire et accéder à d'autres périphériques, mais je ne peux pas pour la vie de moi comprendre ce qui ne va pas avec le contrôleur flash. Je travaille avec des micros depuis plus de 20 ans et ce genre de difficulté est quelque chose que je n'ai jamais rencontré auparavant.
20150102 modifier:
Donc toujours pas ici. J'ai en fait acheté une carte d'évaluation FRDM-KL25Z (15 $ chez DigiKey) et je l'ai modifiée en plaçant le logiciel générique CMSIS-DAP sur le débogueur OpenSDA et en coupant J11 selon le blog de Keith Wakeham . J'ai la cible intégrée (le KL25Z) qui exécute un programme simple afin qu'il n'interfère pas avec la ligne de réinitialisation et je peux voir mon SKEAZN64 avec OpenOCD et jouer avec, mais malheureusement il ne peut pas le programmer non plus. Le logiciel Kinetis Design Studio (KDS) ne flashe pas mon Kinetis car il dit qu'il est protégé et que je dois effacer en masse, mais OpenOCD (dans le cadre de KDS) ne semble pas savoir comment faire cela. La version git master d'OpenOCD que j'ai construite sur mon Mac comprend Kinetis, mais pas la série KEA spécifique, donc je suis de retour à la case départ.
Revenons au J-Link ...
@AdamHaun avait un très bon indice, et si je règle le type de réinitialisation de J-Link (commande rsettype) sur le type '6' (Kinetis), J-Link est censé désactiver le chien de garde après la réinitialisation du noyau. En regardant le registre WDOG_CS1 (0x40052000), il semble que c'est le cas, mais toujours pas de dés. Une opération d'effacement semble dérailler avec le PC à 0xfffffffe et le code d'erreur -5, et une commande "unlock kinetis" ne fonctionne que si je désactive la broche de réinitialisation à l'aide de SIM_SOPT (en écrivant la valeur 32 bits 0x00000008 à 0x40048004). Malheureusement, si je le fais, le processeur ne pourra plus jamais être arrêté, probablement parce que l'interface SWD ne peut pas utiliser la ligne de réinitialisation pour forcer le SWD DAP dans un état connu.
20150103 modifier:
J'AI UNE LED CLIGNOTANTE
RÉPÉTER
J'AI UNE LED CLIGNOTANTE
Version TL; DR: placez l'image USBDM sur la carte FRDM-KL25Z (une histoire à part entière), utilisez l'application autonome ARM Programmer pour envoyer le test .elf sur la carte. Cycle d'alimentation et voilà.
La version longue viendra plus tard. J'ai maintenant moins de 48h pour écrire et déboguer le logiciel de cette carte KEAZN64, terminer de modifier / tester les autres logiciels qui l'accompagnent et travailler sur une documentation pour un autre client. Je promets que je vais mettre à jour cette question avec une réponse détaillée. Je voulais juste partager mon succès. Merci à TOUS pour votre aide. Je devrais peut-être parler avec les mods parce que j'aimerais vraiment donner la prime à quelques-uns d'entre vous en particulier.
Réponses:
Je ne trouve en fait aucune erreur logique dans votre procédure, mais voici quelques suggestions:
il y a aussi un registre FTMRH_FERSTAT (à 4002_0007h). Il est censé vous dire ce qui n'a pas fonctionné ... mais uniquement en cas de parité (ou d'erreurs de double parité). Je ne suis pas convaincu que cela enregistrera quoi que ce soit en cas ou effacera des erreurs, mais cela vaut probablement la peine d'être vérifié.
la documentation de KEA mentionne également qu'une interruption peut être déclenchée par des erreurs flash (section "18.3.5 Interruptions flash et EEPROM"). Je ne sais pas si c'est ce qui se produit lorsque le SEGGER l'efface, mais c'est une explication plausible pour expliquer pourquoi le PC change aussi puisque vous avez vu des erreurs signalées dans le registre FSTAT. Malheureusement, la section de documentation de KEA pour le contrôleur d'interruption ("3.3.2 Configuration du contrôleur d'interruption vectorisé imbriqué (NVIC)") pointe assez vaguement vers le site Web d'ARM pour une documentation complète. Je n'ai pas pu déterminer s'il existe un gestionnaire d'interruption par défaut configuré (au démarrage) pour les erreurs flash.
Vous n'avez fait que des effacements au niveau du secteur manuellement, essayez donc manuellement (comme en écrivant vous-même le registre approprié) d'émettre une commande d'effacement flash complet; la seule façon de le faire dans une seule commande semble être la "commande flash non sécurisée" documentée dans la section 18.3.9.10 (p. 246) du manuel. Cela va à la fois «non sécuriser» l'appareil et effectuer un effacement complet du flash et de l'EEPROM. Vous pouvez interroger un bit FSTAT (CCIF) pour voir quand il est censé être terminé et vérifier à nouveau les indicateurs d'erreur par la suite. EDIT: il y a aussi une section "18.3.9.7 Effacer tous les blocs" dans le manuel, duh.
essayez une fréquence d'horloge de bus inférieure. Tout ce qui dépasse 0,8 Mhz fonctionne selon la documentation. Je suggère cela parce qu'il y avait un fil sur le forum Freescale où un flash externe fonctionnait bien, mais pas au-dessus d'une certaine fréquence qui était toujours dans la plage ok-documentée. Il est donc possible que le contrôleur flash de la puce soit floconneux et ne puisse pas fonctionner sur la gamme complète des fréquences indiquées.
de même, ta puce différente. Il n'est pas inconcevable qu'étant donné leur coût (environ 3 $), vous en avez un mauvais. Je me souviens avoir une puce x86 intégrée qui fonctionnait bien à bien des égards mais qui avait des erreurs étranges sur certaines instructions en mode protégé; mon problème est parti avec un appareil différent de la même marque. Il n'est pas clair pour moi si Freescale a (publiquement déclaré) des pas et des errata pour ces appareils ou non.
C'est tout ce à quoi je peux penser en termes de suggestions de débogage qui n'ont pas été dites par d'autres sur cette page.
20150103 modification (s):
(Matériel déplacé ici de mes commentaires et développé)
Il semble que toutes les séries Kinetis ne soient pas (officiellement, au moins) testées avec tous les clignotants. La toute nouvelle série EA que vous utilisez actuellement ne semble officiellement prise en charge que par le clignotant Cyclone MAX de Freescale; c'est le seul répertorié sur la page de Freescale pour les séries EA . Maintenant accordé, pour les Kinetis plus âgés comme KL0, la liste est beaucoup plus longue, y compris un SEGGER . Je ne sais pas si c'est simplement à cause d'un manque de tests d'autres flashs pour la série EA ou s'il y a en fait une bizarrerie de programmation impliquée que seul leur Cyclone MAX connaît actuellement. J'espérais que ce n'est peut-être que Freescale qui tarde à lister d'autres flashers, mais en vérifiant le manuel J-link (je l'espère, la bonne), il n'y a pas de série Kinetis E ou EA répertoriée (p. 249) testée non plus, mais uniquement des appareils Kinetis K10 à K60 (et certains MAC7 plus anciens).
Il convient de noter que le logiciel / micrologiciel PExDrv pour le Cyclone MAX dispose d'un service pack (v10.3) daté du 3/20/2014, qui «ajoute la prise en charge des dérivés MKE04Z64, MKE04Z128, MKE06Z64, MKE06Z128, SKEAZ64 et SKEAZ128». Un autre indice est que le propre logiciel de bootloader / flashloader open-source de Freescale pour le Kinetis, bien qu'il ait été mis à jour encore plus récemment en 12/2014, ne répertorie aucun appareil de la série E ou EA [sub] comme pris en charge. Je pense donc qu'il y a quelque chose de suffisamment différent en ce qui concerne le clignotement entre la série E / EA et d'autres Kinetis comme le K10, bien que je ne sache pas exactement quelle est cette différence. Par conséquent, je pense qu'attendre que le flash EA fonctionne automatiquement avec tout autre chose que le Cyclone MAX est probablement irréaliste à ce stade. Vous pourriez éventuellement comprendre comment le faire au niveau "bare metal" (commandes de registre direct) à partir de la documentation de la série EA, mais je conviens que la documentation est assez obtuse; il manque certainement toutes les instructions étape par étape qui ne sont qu'un manuel de référence. Si le chargeur de démarrage / flashloader open source de Freescale avait pris en charge la série E / EA, vous '
Votre expérience avec le FRDM-KL25Z (fourni avec une série Kinetis L) va dans le même sens, c'est-à-dire que vous ne pouvez pas échanger une série L avec une série EA et utiliser le même clignotant (OpenSDA dans ce cas).
Et si vous êtes comme Keith (le blogueur) qui "pense que 100 $ pour un programmeur est ridicule", vous ne serez probablement pas satisfait de la perspective de laisser 900 $ + sur ce Cyclone. Je ne sais pas si Freescale fait cela exprès pour contrecarrer leurs clients automobiles ou quoi ... Il semble sûrement étrange que l'outillage pour la plupart de la série Kinetis ne fonctionne pas avec l'E / EA.
Sachez également que la fonction de clignotement d'OpenSDA ne fonctionne que sous MS Windows , apparemment.
Si vous êtes prêt à essayer (pirater) plus de cartes, une avec un Kinetis de la série E pourrait être une meilleure idée, par exemple FRDM-KE02Z (13 $ chez Digi-Key); utilise également OpenSDA afin qu'il puisse être piraté. Pour autant que je sache, ils ne fabriquent / vendent pas de planches avec la série EA. Cependant, il semble que vous ne puissiez pas utiliser un processeur / carte OpenSDA pour programmer un type Kinetis différent de celui de sa propre carte , même si les deux processeurs sont dans la même série (par exemple L), mais avec des nombres différents.
Malheureusement, "Open" dans OpenSDA signifie seulement que la spécification SDA est ouverte, pas qu'ils donnent le code source en open-source; donc je ne trouve même pas de code source pour programmer un flash de la série E.Apparemment, je n'ai qu'à moitié raison à ce sujet. OpenSDA v1 n'est pas open-source, mais v2 l'est .Voici donc la liste des points bas sur OpenSDAv2 . Il s'agit essentiellement d'un chargeur de démarrage et d'un clignotant CMSIS-DAP / mbed. Il peut donc ne pas avoir les mêmes fonctionnalités ou ne pas prendre en charge les mêmes puces que la v1 ... et cela s'avère en fait être le cas parce que flash_features.h ne répertorie aucun MKE (Kinetis E-series) et encore moins SKE (EA-series) dispositifs. En résumé, la proposition de Freescale pour la série EA semble être: achetez notre clignotant Cyclone à 900 $ ou bonne chance en écrivant le vôtre à partir des bits incomplets de l'open source que nous avons publiés.
Il s'avère cependant qu'il existe un projet open source qui peut programmer au moins la série E Kinetis, à savoir USBDM . Le bit pertinent de son changelog est:
Et d'après cette entrée de journal, il semble que les séries E soient originales. Il n'y a pas de support direct pour la série EA (SKE), mais cette base de code est probablement votre meilleur pari si vous voulez pirater votre propre clignotant; ou peut-être pouvez-vous convaincre l'auteur d'USBDM d'ajouter le support de la série EA (SKE). En tant que matériel pour USBDM, il s'avère que vous pouvez utiliser le FRDM-KL25Z que vous avez déjà acquis; mais vous devez encore pirater le logiciel USBDM pour prendre en charge les puces SKE.
Le fichier de configuration principal pour USBDM semble plutôt intimidant. Dans USDBM, différents clignotants (bases de code) sont utilisés pour différents appareils de la série MKE: quelque chose appelé "FTMRE" est utilisé pour MKE04 et MKE06, mais "FTMRH" est utilisé pour MKE02. Après m'être brièvement penché sur les deux bases de code, vous voulez presque sûrement la base de code FTRMH et non celle de FTRME. Ce dernier a une structure FTMRH différente de celle de votre appareil SKEA64, par exemple, le diviseur d'horloge n'est pas le premier mais le 4ème champ. FTRME définit également le bus FIDV sur 0x17 = 24Mhz, ce qui semble hors de portée pour votre puce (p. 224 dans le manuel KEA64 suggère un maximum de 20Mhz). FTMRH le définit à 0x0F = 16Mhz (comme vous le faites), ce qui semble correct.
À ce stade, (à moins que vous ne vouliez acheter le Cyclone MAX), le mieux est de contacter Podonoghue pour que votre puce fonctionne avec sa base de code. Il semble actif et tout à fait disposé à aider avec de nouveaux appareils (sur le forum freescale) .
De plus, à partir de ce code source USDBM, je peux prophétiser qu'il n'y a aucun moyen que votre SEGGER puisse correctement flasher votre SKEA par lui-même à moins qu'il ne reçoive d'abord sa propre mise à jour du firmware. Pourquoi dis-je ça? Parce que la base de code FTMRH de l'USBBM est utilisée par exactement un appareil, le MKE02, dont votre SEGGER semble ne rien savoir non plus (sur la base de son manuel). D'autres appareils plus courants comme les séries Kinetis L et K utilisent un clignotant USDBM différent basé sur une base de code "FTFA". Si vous regardez le code FTFA , la structure du registre du contrôleur flash (commençant également à 0x40020000) est différente pour ceux-ci; le premier champ n'est même pas un diviseur d'horloge, mais le registre des statistiques, etc. "Excellent" moyen pour Freescale de fabriquer des appareils incompatibles ... mais une aubaine pour les fabricants de clignotants, sans aucun doute.
la source
Avez-vous essayé ceci: déverrouillage et effacement de FLASH avec Segger J-Link
Vous devez prétendument:
Ce que j'ai trouvé intéressant, c'est que vous devez le déverrouiller et l'effacer à l'étape suivante si vous voulez que le déverrouillage soit permanent:
EDIT1: ajout de données erronées.
EDIT2: pouvez-vous peut-être lire le registre Flash Security (FSEC)? As-tu essayé?
EDIT3: tiré de l' utilisation des fonctions de sécurité et de protection Flash de Kinetis, Rév.1, 6/2012
Je suis également tombé sur un article mentionnant que différentes familles de kinetis nécessitent différentes manipulations de signal RESET lors de la tentative de lecture / écriture du registre MDM-AP.
EDIT4: avez-vous essayé d'ajouter une forte traction sur SWD_DIO? C'est un coup dans l'obscurité, mais Freescale le recommande.
la source
Vous devez d'abord arrêter le processeur. Il est évident que vous obtenez un symptôme d'un processeur en cours d'exécution. J'utilise openocd; avant de flasher l'appareil, j'utilise la commande "reset halt". Cet "arrêt" est une sous-commande de "réinitialisation", pour l'arrêt immédiatement après la réinitialisation, alors qu'il existe également une commande d'arrêt autonome.
Alors cherchez une commande "reset halt", juste un arrêt ne suffira pas car vous devez vous rendre à l'état de pré-initialisation des vecteurs je suppose.
la source
Je ne l'ai pas encore mentionné, donc je vais continuer et spéculer que le problème est que cette partie a un cache qui est activé lors de la réinitialisation. Ceci est cohérent avec le comportement "bizarre" que vous avez observé avec le chèque en blanc. Le Flash sous-jacent a été mis à jour mais pas le cache. Pour résoudre ce problème, désactivez le cache de données et d'instructions en écrivant sur
MCM_PLACRatF000_300Chet videz également le cache au fur et à mesure. Ce même comportement étrange a probablement également confondu le Segger.la source
Étant donné que le message d'erreur concerne la valeur du PC, il semble que le processeur déraille quelque part. C'est un long plan, mais avez-vous essayé de désactiver la minuterie de surveillance?
la source