Hallo liebe Community nach vielen Projekten mit den AVR32 möchte ich mich mit der bare-metal Entwicklung auf den ARM9 Prozessoren beschäftigen. Aus Sicht der Softwareentwicklung existiert im Netz unzählig viel Lektüre über die first-level hardwareinitializierung, exception-vector etc. Ich habe jedoch noch das Problem, überhaupt erst eine Verbindung zu meiner CPU herzustellen. Für den Einstieg habe ich mir - das SAM9G45 OEM von in-circuit.de mit dem ADB 1003 - und ein SAM-ICE Debugger zugelegt. Das erste Problem ist, dass der SAM-ICE einen 20Pol JTAG-Header besitzt während das ADB1003 nur ein 10Pol-Header besitzt. Ich habe beide wie folgt mit einer Einzelverkabelung miteinander verbunden: SAM-ICE | Pin | Pin | ADB1003 -------------------------------- VTref 1 4,7 VCC Vsupply 2 - nc nTRST 3 8 JTAG_TRST GND 4,6,... 10,2 GND TDI 5 9 TDI TMS 7 5 TMS TCK 9 1 TCK RTCK 11 - nc RESET 15 6 JTAG_RESET Leitfaden hierfür war der AT91SAM-ICE User-Guide. Meine Erwartungshaltung war nun, dass ich loslegen kann mit dem Debugging. Ein erster Versuch, mit dem Programm SAM-BA V2.12 von Atmel, eine Verbindung zum CPU herzustellen scheiterte jedoch mit der Meldung "Write memory error @ address 0xFFFFFD00, multi word access (strm {r1..r0}): Adaptive clocking timeout". Der für das Adaptive clocking zuständige Pin RTCK liegt an GND da ich das Signal nicht an den 10Pin-Header geführt ist. Dem User-Guide des SAM-ICEs zufolge soll es optional sein... Das Fenster der Fehlermeldung trägt die Überschrift "J-Link V4.46f Error" so dass ich einen weiteren Versuch mit der JLink.exe aus dem Installationsverzeichnis von SEGGER gestartet habe. Überraschenderweise ist diese in der Lage die CPU vollständig zu erkennen und ermöglicht mir sogar einige Zugriffe. Ein weitergehender Versuch die CPU mit Befehl "r" zu resetten resultierte in folgender Ausgabe: Reset delay: 0 ms Reset type NORMAL: Using RESET pin, halting CPU after Reset Info: Failed to read ICE breaker after Reset, using default reset strategy. Info: Resetting target using RESET pin Info: CP15.0.0: 0x41069265: ARM, Architecture 5TEJ Info: CP15.0.1: 0x1D192192: ICache: 35kB (4*256*32), DCache: 32kB (4*256*32) Info: Resetting TRST Infor: J-Link: ARM9 CP15 Setting changed: 51078 from 78, MMU Off, ICache On, DCache Off" Insbesondere die dritte und letzte Zeile verstehe ich nicht. Kann mir jemand erklären was genau da abläuft? Vielen Dank im Voraus Gruß Tobias
Ein Versuch mit Keil µVision das Blinky projekt in den internen RAM der CPU zu laden resultiert in folgender Ausgabe. Load "C:\\Program Files (x86)\\Keil\\ARM\\Boards\\Atmel\\AT91SAM9G45-EK\\Blinky\\Int_RAM\\Blinky .axf" ProjectFile = C:\Program Files (x86)\Keil\ARM\Boards\Atmel\AT91SAM9G45-EK\Blinky\JLinkArm_SAM9G45 Int RAM.ini Info: Device "UNSPECIFIED" selected (0 KB flash, 0 KB RAM). Device = SAM9G45 Info: Device "UNSPECIFIED" selected (0 KB flash, 0 KB RAM). VTarget = 2.847V Info: TotalIRLen = 4, IRPrint = 0x01 Info: CP15.0.0: 0x41069265: ARM, Architecure 5TEJ Info: CP15.0.1: 0x1D192192: ICache: 32kB (4*256*32), DCache: 32kB (4*256*32) Info: Cache type: Separate, Write-back, Format C (WT supported) Info: RTCK is not connected Info: Auto JTAG speed: 8000 kHz Info: Using DBGRQ to halt CPU Info: J-Link: ARM9 CP15 Settings changed: 5217F from 78, MMU On, ICache Off, DCache On Info: TotalIRLen = 4, IRPrint = 0x01 Info: CP15.0.0: 0x41069265: ARM, Architecure 5TEJ Info: CP15.0.1: 0x1D192192: ICache: 32kB (4*256*32), DCache: 32kB (4*256*32) Info: Cache type: Separate, Write-back, Format C (WT supported) DLL version V4.46f, compiled May 10 2012 08:30:05 Firmware: J-Link compiled Jul 30 2008 11:24:37 ARM Rev.5 Hardware: V5.40 Hardware-Breakpoints: 2 Software-Breakpoints: 8192 Watchpoints: 0 Found 1 JTAG device, Total IRLen = 4: Id of device #0: 0x0792603F ARM9 identified. JTAG speed: 4 kHz Info: TotalIRLen = 4, IRPrint = 0x01 JTAG speed: 5 kHz Info: TotalIRLen = 4, IRPrint = 0x01 Include "C:\\Program Files (x86)\\Keil\\ARM\\Boards\\Atmel\\AT91SAM9G45-EK\\Blinky\\Clock.ini" /*********************************************************************** *******/ /* Clock.ini: Initialize clock to Main Oscillator clock */ /*********************************************************************** *******/ // <<< Use Configuration Wizard in Context Menu >>> // /*********************************************************************** *******/ /* This file is part of the uVision/ARM development tools. */ /* Copyright (c) 2005-2012 Keil Software. All rights reserved. */ /* This software may only be used under the terms of a valid, current, */ /* end user licence from KEIL for a compatible version of KEIL software */ /* development tools. Nothing else gives you the right to use this software. */ /*********************************************************************** *******/ DEFINE LONG PMC; PMC = 0xFFFFFC00; _WDWORD(PMC+0x20, 0x00004001); // CKGR_MOR: Enable main oscillator Info: ***** Warning: CP15 access for this CPU (0 bit scan chain) not yet supported Info: CP15.0.0: 0x00000000: Unknown implementer code, Architecure Unknown architecture Info: J-Link: ARM9, 0 core Info: ***** Warning: CP15 write access for this CPU (0 bit scan chain) not yet supported ***JLink Error: Bad JTAG communication: Write to IR: Expected 0x1, got 0x3 (TAP Command : 12) @ Off 0x14. SAM-ICE can only be used with ATMEL devices _sleep_(10); // Wait for stable Main Oscillator // PMC_MCKR: Select Main Oscillator clock // keep MDIV field _WDWORD(PMC+0x30, _RDWORD(PMC+0x30) | 0x00000001); Cannot read memory __________________________^ *** error 122, line 21: AGDI: memory read failed (0xFFFFFC30) _sleep_(10); // Wait for Master Clock ready _WDWORD(PMC+0x30, 0x00000001); // PMC_MCKR: Select Main Oscillator clock _sleep_(10); // Wait for Master Clock ready No Algorithm found for: 00000000H - 00000367H Programming skipped!
Da das board bereits mit einem Linux daher kommt vermute ich, dass eine art Code Read Protection dafür sorgt dass mein JTAG nicht funktioniert.
Hallo, also ein Writeprotect für das JTAG Interface kann nur mit der Laufenden Software bei Laufender Sitzung gemacht werden, nach einem Reset ist es wieder aufgehoben. Jedenfalls so bei meinem 9G10. Aber dann ist der ganze JTAG unereichbar. Der JTAG scheint soweit auch zu gehen, das RTCK ist bei einem JLINK nicht zwingend nötig, wird sogar langsamer. Aber wenn der SAM-ICE das Device nicht erkennt, würde ich mal ein Softwareupdate an dieser stelle machen. Die Meldungen mit dem CP15 Register kannst du erst einmal ignorieren, dazu must du sowieso den ganzen Coprozessor MMU und Caches studieren. Unter Umständen muss der Systemreset mit dem JTAG-Reset verbunden werden. Dein Vtarget mit 2,8xx Volt scheint auch nicht in ordnung zu sein, sollte doch 3.3Volt sein??? Gruß Sascha
Hallo Sascha vorab vielen Dank für deine Antwort. - Bei der Betriebsspannung muss es sich um ein unglücklichen Fehler handeln. Das Board wird über USB mit Spannung versorgt und eine Messung mit dem Multimeter ergab konstante 3.339V. - Ich habe das aktuelle Softwarepaket von Segger installiert. Jedoch kam es nicht zu einem Firmwareupdate. Allerdings verwendet µVision eine ältere DLL verion "DLL version V4.46f, compiled May 10 2012" während die JLink.exe die Verion: "DLL version V4.78c, compiled Oct 14 2013" verwendet. µVision verwendet jedoch die JLTAgdi.dll(Jlink / JTrace) welche nicht von Segger stammt statt der JLinkARM.dll. Während der Recherche zur Softwareversion ist mir folgendes klar geworden: Der SAM9G45 verwendet nach einem Reset den internen Slow Clock RC welcher eine undefinierte Frequenz von 20kHz bis 40Khz besitzt(Datenblatt Seite 59). Somit ist ein JTAG-Speed von 4Khz/5khz bereits zu hoch. Bestätigen lies sich diese Annahme mit der JLink.exe. In dieser habe ich versuchsweise einen JTAG-Speed von 2kHz definiert und einen Reset+Halt durchführen lassen. Während dieser Fall bisher immer die Meldung: "Info: Failed to read ICE breaker after Reset, using default reset strategy." lieferte, kam es diesmal nur zu folgenden fünf Zeilen: Reset delay: 0ms Reset type NORMAL: Using RESET pin, halting CPU after Reset Info: CP15.0.0: 0x41069265: ARM, Architecture 5TEJ Info: CP15.0.1: 0x1D192192: ICache: 32kB (4*256*32), DCache: 32kB (4*256*32) Info: Cache type: Separate, Write-back, Format C (WT supported) Ich vermute daher dass dies ebenfalls der Fehler beim Flashen/Debuggen mit µVision ist. Da ich mich allerdings noch sehr wenig mit ARM Mikroprozessoren auskenne, möchte ich hier nochmal eine Meinung Einholen. µVision lässt sich auf einen minimalen JTAG-Speed von 5khz einstellen was leider zu hoch ist. Gibt es eine Möglichkeit dies herab zu setzen? Gruß Tobias
Hallo, der JTAG Speed hat nichts mit dem CPU-Speed zu tun. Die Einheiten sind getrennt. Da du den Takt durch den JTAG-Port von extern bringst. Ich arbeite schon etwas länger mit einem AT91SAM9G10 und dort ist mir das Problem noch nicht aufgefallen. Aber nur mal so ein Tipp am Rande, lade dir doch mal die IAR Version und teste die!!! Keil hat doch seine eigenen Tools und vermutlich wird das Jlink a-la SAM-ICE nicht mehr richtig unterstützt. Wenn du dir die Segger Software herunterlädst, ist ein firmwareupdate Tool dabei und du kannst wenigstens damit mal versuchen den SAM-ICE auf den neusten stand zu bringen. Aber ARM9 müsste auch schon lange unterstützt werden? Stopp: habe gerade nochmal auf meiner Leiterplatte nachgesehen. Ich habe NRST mit NTRST verbunden, da gibts ein Errata. Und ich habe den RTCK auch verbunden. Es kann sein, dass der JLINK bei Kontaktaufnahme mit dem RTCK adaptiv clocking nutzt, was ich aber nacher in der Software umgehe. Gruß Sascha
Dass der JTAG Speed nichts mit der CPU-Speed zu tun hat, ist so nicht ganz richtig. "In general ARM cores without JTAG synchronization logic (such as ARM7-TDMI) can handle JTAG speeds up to the CPU speed, ARM cores with JTAG synchronization logic (such as ARM7-TDMI-S, ARM946E-S, ARM966EJ-S) can handle JTAG speeds up to 1/6 of the CPU speed. JTAG speeds of more than 10 MHz are not recommended." Quelle: http://www.segger.com/flasher-arm.html Da du das Glück hast an das RTCK Signal zu kommen wirst du wahrscheinlich nichts davon mitbekommen. Und nach der Initialisierung ist mit 266Mhz der SAM9G10 CPU ein bis zu 12Mhz JTAG-Speed kein Problem. Aus dem Datenblatt des SAM9G10 habe ich entnommen, dass dieser keinen internen RC OSC besitzt und in deinem Falle wahrscheinlich mit einem externen 12Mhz OSC startet wodurch das Problem gar nicht erst entsteht. Im worst-case hat der interne slow-clock RC des SAM9G45 20khz. 1/6 davon sind 3,3khz maximalen JTAG speed. Dies passt zum oben beschriebenen fehlerfreien Verhalten bei <3kHz JTAG. Eine Weitere Quelle welche diesen Sachverhalt bestätigt ist folgender Forumeintrag eines Mitarbeiters von Segger: "The SAM9G45 is based on a ARM926EJ-S core. On S-Cores, the maximum JTAG speed that can be used is 1/8 - 1/6 of the core speed. I do not know the state of your target system at the time of testing but after power-up the SAM9G45 starts with the slow clock (32 KHz) selected as the core clock." http://forum.segger.com/index.php?page=Thread&threadID=863 Ich werde versuchen eine andere IDE zu testen. Allerdings verspreche ich mir davon nicht viel. Lieber wäre es mir, die Keil µVision auf 2kHz einstellen zu können. Gruß Tobias
Hallo, Danke Tobias, da hast du sicherlich recht, das ich in der glücklichen Situation mit meinem 9G10 da bin. Sorry die Kopplung an die CPU habe ich noch so nicht gelesen. Habe gerade aber bei einem Projekt das ich vor 3 Jahren gemacht habe (ARM7TDMI) der mit 32KHz beim start getaktet wird gesehn, dass im Macro-File zur Initialisierung des Debuggers nach jedem Registerzugriff delay(10) steht, um vermutlich den Flaschenhals JTAG-CPU nicht zu überlasten. Dort habe ich auch keinen RTCK und es ging. Gruß Sascha
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.