Cortex M3 mit JLink loeschen

[Olaf (Gast)]

In einem Anfall voruebergegangender Inkompetenz hab ich bei einem 
EFM32GG230 leider internen Oszillator abgeschaltet ohne den externen 
einzuschalten.
Jetzt laeuft der Controller nicht mehr und laesst sich auch mit dem 
JLink nicht mehr flashen.

****** Error: Could not find core in Coresight setup
Found SW-DP with ID 0x2BA01477
Found SW-DP with ID 0x2BA01477
Could not power-up system power domain.
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map seems to be reached
Iterating through AP map to find AHB-AP to use
Found SW-DP with ID 0x2BA01477
Secured EFM32 device detected. This could cause problems during flash 
download.
Note: Unsecuring will trigger a mass erase of the internal flash.
Device will be unsecured now.
Found SW-DP with ID 0x2BA01477
Could not power-up system power domain.
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map seems to be reached
Iterating through AP map to find AHB-AP to use
Cannot connect to target.

Dabei ist sichergestellt das der Controller nicht gelockt ist!

Es ist erstaunlich das der JLink nicht in der Lage ist da rueber zu 
flashen weil er sich laut Doku bemueht den Core sofort nach einem Reset 
anzuhalten um gerade Stoerungen eines Cores zu verhindern. Aber 
vielleicht nicht schnell genug.

Ich hab dann mal ein bisschen Doku gelesen (interessant was man so alles 
lernt) und mir ein eigenes kleines Script geschrieben. Das laeuft ohne 
Fehlermeldung durch.

Damit bin ich in der Lage das Flash in einer anderen MCU zu loeschen. 
Mit meiner gefraggten klappt das leider nicht.

Hat jemand eine Idee woran das liegen könnte? Habe ich noch etwas 
wesentliches nicht verstanden?

Insbesondere hier:

//There debug and system registers and one Silabs extent
//AP register CHIPAP_CTRL1 are used for this purpose.
//CHIPAP_CTRL1 address = 0x1, APSEL = 0x0A. bit 3 core_reset_ap,

SWDWriteDP 1 0x08

Bin mir unsicher ob das die korrekte Implementation ist!

Olaf

[Marco H. (damarco)]

Mich staunt das so etwas geht. Das dieser nicht selber den Clock Fault 
bemerkt und default auf den internen umschaltet.

[Stefan F. (Gast)]

Bei STM32 gibt es die Option "Connect under Reset". Da kannst du den 
Reset-Konopf drücken und halten, dann die Verbindung starten und dann 
den Knopf loslassen. Das ist vom Timing her ein bisschen Tricky, aber es 
verhindert wirksam, dass das fehlerhafte Programm startet.

Bei AVR wird der ISP Programmer auch immer während des Reset verbunden.

Vielleicht gibt es bei deinem J-Link auch so eine Option.

[Jens D. (jens)]

Bei den J-Link Tools gibt es ein St unlock
Das löscht den Flash und ggf die lock bits so fern sie gesetzt sind.

[Jim M. (turboj)]

Olaf schrieb:
> FM32GG230 leider internen Oszillator abgeschaltet ohne den externen
> einzuschalten.

Mach das Flash "unlock" im Simplicity Commander oder Simplicity Studio. 
Das jlink Skript könnte zu langsam sein, man hat nach dem Reset nur ein 
paar µs Zeit dafür.

[Olaf (Gast)]

Es handelt sich bei dem Controllern nicht um einen ST sondern einen 
EFM32. Ausserdem steht mir nicht die plappernde Unvernunft eines WinXY 
zur Verfuegung. :) Irgendwo zu klicken ist also keine Option.

Das sollte aber eigentlich kein Problem sein weil letztlich alles was 
kreucht, fleucht und klickt am ende mit JLinkExe (oder JLink.exe) 
spricht. Ich hab auch schon mit den diversen Resetoptionen rumgespielt. 
(vgl:exec SetResetType = 1 bis n)

Natuerlich koennte ich dieses boese kleine Miststueck einfach abloeten, 
mit einem Hammer drauf hauen und einen neuen aufloeten, allein 
intellektuell eine unbefriedigende Loesung.

Ich ueberlege gerade ob es was bringt wenn ich mit JlinkExe probiere 
ueber die MCU Register den Takt wieder einzuschalten.

> Mich staunt das so etwas geht. Das dieser nicht selber den Clock Fault
> bemerkt und default auf den internen umschaltet.

Wenn ich so darueber nachdenke, das ist in der Tat erstaunlich.

So sahen die letzten Mikrosekunden des Prozessors aus:

CMU_OscillatorEnable(cmuOsc_HFXO, true, true);
CMU_PCNTClockExternalSet(1, true);
//CMU_ClockSelectSet(cmuClock_HF, cmuSelect_HFXO);
CMU_OscillatorEnable(cmuOsc_HFRCO, false, false);  //interner Oszi aus

Wie man sieht habe ich eine Zeile auskommentiert weil ich von externen 
Quarz auf externen Oszillator umgebaut habe und mich fragte ob eine 
Konfiguration als externer Oszillator sinnvoll ist wenn man nur einen 
externen Takteingang braucht. Aber das zeigt mal wieder man sollte keine 
externen Libaries nutzen und lieber alles selber coden.

Olaf

[Olaf (Gast)]

Argh! Das Dingen laeuft wieder!

Ich hab den externen Oszillator kurz abgeloetet. Dadurch hatte der 
Controller wohl keine Zeit in den Abgrund des Todes zu laufen und ich 
konnte den ganz normal flashen. Problem geloest :-)

Olaf

[Jens D. (jens)]

Hat der EFM32 irgendwelche Boot Pins um zum Beispiel aus dem SRAM zu 
booten?
Dann würde dein Programm aus dem Flash nicht geladen.

Hatte mich damals mal wegen einem deaktivierten J-Link Port ausgesperrt 
und iar Studio kahm über ein Flash erase wieder drauf.
So lange der Controller nicht gelockt ist solltest du wie auch immer 
wieder dran kommen.

Versuche mal im J-Link command von Hand reset zu setzen ich meine mit 
dem Befehl r0 und schau ob du die register zum Beispiel gelesen 
bekommst.

[Jim M. (turboj)]

Jens D. schrieb:
> Hat der EFM32 irgendwelche Boot Pins um zum Beispiel aus dem SRAM zu
> booten?

Nein. EFM32 haben aber die Möglichkeit direkt nach Reset für ein paar µs 
via SWD den Flash zu löschen. Da gibts bei Silabs 'ne Appnote für, und 
es ist in die Tools (Silabs Commander, Simplicity Studio) integriert.

[Marco H. (damarco)]

Das meinte ich. Der hat den clock fault erkannt und wieder auf den 
internen umgeschaltet. Deine Anweisung wurde wieder rückgängig gemacht. 
Ich vermute mal das dieser dann im default Handler landet.

[Jim M. (turboj)]

Marco H. schrieb:
> Der hat den clock fault erkannt und wieder auf den
> internen umgeschaltet.

Das ist kein STM32, sondern ein EFM32 von Energy Micro, die von Silabs 
geschluckt wurden. Ich sehe da kein Clock Fault im Reference Manual. 
Wenn man da einen Fehler macht dann steht die Kiste, Debugger inklusive. 
Im Manual steht für dieses Szenario explizit eine Warnung drin.

Das mit dem Abklemmen vom Oszillator funktioniert hauptsächlich weil der 
normalerweise dafür benutzte Code wartet bis jener stabil läuft.