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.