Software Reset Cortex M3

[Siro]

Hallo,
gibt es beim ARM Cortex M3 eine Möglichkeit bzw. einen Mnemonic der einen kompletten Neustart auslöst. Bei den PICs gibt es den Mnemonic "RESET".
Danke für eventuelle Info:
mfg. Siro

[Siro]

Ich kann nun selbst meine Frage beantworten.
Der eigentliche Kern Cortex M3 selbst, hat die Möglichkeit für einen RESET.
Dafür ist das SYSRESETREQ Bit im AIRCR-Register zuständig.
Hier wird ein Bit gesetzt, welches nach außen hin einen Reset auslösen könnte. Wenn die Hersteller diese Leitung jedoch nicht an ihre Peripherie Bausteine anbinden geht es natürlich auch nicht. Beispiel LPC17xx von NXP
Hier geht es nicht

Es gibt auch einen Funktion, welche in der CMSIS Implementation vorhanden ist. NVIC_SystemReset()

Aber wie schon gesagt, in meinem Falle LPC17xx völlig nutzlos. Schade...

Nun werde ich einen Portpin mit der Resetleitung verbinden, das
sollte eigentlich funktionieren. Versuche stehen aber noch aus.
Siro

[Arkaiden]

Hi,

Spring doch einfach mit einem void Pointer an die Start Adresse deines Programms.

[josefkoller]

Na das mit dem Jump auf Zero würde ich lassen.
Kann dir nur meine Erfahrungen mit dem AVR's beschreiben.

Ein Jump auf Zero macht nicht wirklich das, was ein HW-Reset tut.
Eine SW-Alternative ist ein Watchdog.
Bei mir läuft dies so:
- erstelle eine Sub-Routibe "SysReset"
- starte dort einen Watchdog mit möglichst kurzer Zeit
- gehe in eine Edlos-Loop

Der Watchdog besorgt den Rest.

[beppo]

Hallo Siro,

ich weiss, der Thread ist alt...


Es gibt auch einen Funktion, welche in der CMSIS Implementation vorhanden ist. NVIC_SystemReset()

Aber wie schon gesagt, in meinem Falle LPC17xx völlig nutzlos. Schade...


Ich arbeite schon seit längerem mit dem LPC1752. Die NVIC_SystemReset() scheint bei mir zu funktionieren. Ich dachte immer das sei zuverlässig, aber anscheinend gibt es Umstände in denen die Funktion versagt. Kannst du nähere Angaben machen, unter welchen Umständen der Reset nicht funktioniert?

Schöne Grüße
Beppo

[Siro]

Hallo Beppo,
ich freue mich über deine Rückmeldung und werde versuchen Dir das Problem zu erklären.

Vorab aber ersteinmal wie ich darauf gekommen bin:
Ich arbeite mit der IAR Entwicklungsumgebung (Embedded Workbench) Ich habe für mein Projekt "JTAG Debugging" eingestellt. Lief auch alles soweit, dachte ich zumindest....
Dann habe ich mich mit dem PWM1 Module beschäftigt. Mit dem Ossi meine PWM angesehen. Als ich einen Reset auslöste (von der Entwicklungsumgebung aus) lief meine PWM trotzdem weiter. Da wurde ich das erste mal stutzig. Das bedeutete , daß die Register der CPU nicht ordnungsgemäß initialisert wurden. Als ich dann die Ossistrippe an den JTAG Reset anschloss, um mir das Signal anzusehen, stellte ich fest, daß hier garnichts geschah. Die Resetleitung wird garnicht bedient.Nun dachte ich zuerst es ist ein Fehler in der Entwicklungsumgebung oder des JTAG Treibers und kontaktierte die Firma IAR. Dort sagte man mir, ich könnte über eine spezielle Scriptdatei dem JTAG Interface eine zusätzlichen Hardware RRESET auslösen lassen. Hab ich dann getan. Hat mich aber auch nicht weitergebracht. Nach etlichem hin und her und neuen zusätzlichen Problemen sollte ich mir eine Demosoftware von IAR runterladen, dort sollte alles einwandfrei laufen. Das tat ich dann auch. Ich fügte in dieses Projekt meine PWM Routinen ein und war verblüfft, daß es nun funktionierte. Nach einem Reset wurden anscheinend auch die Register richtig initialisiert. Als ich mir den Reset Pin des JTAG Interfaces ansah, musste ich feststellen, der wird immer noch nicht bedient. Beim durchforsten aller Einstellparameter stellte ich dann aber fest, daß in dem Demoprojekt nicht JTAG sondern SWD (Serial Wire Debug) angekreuzt war. Das kannte ich noch garnicht. Also mal wieder gegoogelt... Da braucht man ja nur 2 Leitungen und Masse, also kann ein externer Hardware Reset auch nicht ausgelöst werden, weil die Hardwarestrippe wird ja garnicht bedient. Es scheint aber irgendwie möglich zu sein, einen ordnungsgemäßen Reset mittels SWD auszulösen. Wie das genau funktioniert weis ich aber auch nicht.

Doch egal wie , wo , was da passiert, brauchst Du Dir eigentlich keine Gedanken darüber machen. Weil im Normalfalle wird deine Schaltung ja mit einem Hardwarereset gestartet und damit gibt es auch kein Problem. Während der Debugging oder Entwicklungsphase wirst Du auch nichts davon merken, Weil: Die C-Software initialisiert ja selbst den RAM, vorinitialisierte Variablen usw. Dann werden deine eigenen Funktionen aufgerufen die den Reset initialisieren. Und so braucht Dich das nicht zu beunruhigen. Über "SWD" scheint das Problem garnicht zu existieren.

Mich hatte es nur "gestört" daß nach einem Reset die PWM weiter läuft, obwohl ich die Register noch garnicht initialisert habe.
okay: "Siro" ist da etwas pingelig :-) Aber zumindest habe ich ja eine Erklärung dafür gefunden. Wenn ich nicht mit JTAG sondern mit SWD arbeite, habe ich das Problem ja nun auch nicht mehr.

Doch nun zur eigentlichen Erklärung mittels CMSIS:
in der Datei "core_cm3.h" steht folgendes:

static __INLINE void NVIC_SystemReset(void)
{
SCB->AIRCR = ((0x5FA << SCB_AIRCR_VECTKEY_Pos) |
(SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk) |
SCB_AIRCR_SYSRESETREQ_Msk); /* Keep priority group unchanged */
__DSB(); /* Ensure completion of memory access */
while(1); /* wait until reset */
}

Das eigentliche Problem ist "SCB_AIRCR_SYSRESETREQ_Msk"
ergibt sich aus folgender Definition weiter oben in der Datei:

#define SCB_AIRCR_SYSRESETREQ_Pos 2 /*!< SCB AIRCR: SYSRESETREQ Position */
#define SCB_AIRCR_SYSRESETREQ_Msk (1ul << SCB_AIRCR_SYSRESETREQ_Pos) /*!< SCB AIRCR: SYSRESETREQ Mask */

Das ist also das Bit 2 im AIRCR Register, welches gesetzt werden muss, um einen Reset auszulösen. und im Datenblatt UM10360 steht auf Seite 772 genau für dieses Bit folgender Hinweis: Note: support for SYSRESETREQ is not included in LPC17xx devices. Also auf Deutsch: Das Bit gibt es nicht, auch in deinem LPC1752 nicht.
Das stimmt aber so nicht ganz, der Cortex Kern hat natürlich dieses Bit, die Firma NXP hat aber diese Resetleitung intern anscheinend nicht an die Resetleitungen ihrer Peripheriebausteine angschlossen. Ich hoffe, daß ich dies so richtig interpretiert habe.

Das mit dem Jump auf 0 ist wirklich keine gute Lösung zu diesem Problem, das ist dann ein Warmstart ohne Register Initialisierung... Ob es mit dem Watchdog geht, bin ich mir garnicht so sicher, meiner Meinung nach gibt es dabei auch keine Registerinitialisierung, wie bei einem richtigen Hardwarereset, aber ich habe es noch nicht ausprobiert, vielleicht komme ich noch dazu. Aber wie schon früher erwähnt, habe ich nun einen Portpin an den Hardware Reset Pin angeschlossen. Nun kann ich "echte" Hardware-Resets auslösen. Funktioniert einwandfrei.

Siro

[beppo]

Hallo Siro,
vielen Dank für die Antwort.

"Note: support for SYSRESETREQ is not included in LPC17xx devices." habe ich im Datenblatt auch gefunden. Allerdings funktioniert bei mir der Reset über NVIC_SystemReset() trotzdem. Sehr seltsam. Habe ich vielleicht eine neuere Silicon-Version? - Allerdings habe ich in den Errata Sheets auch nichts darüber gefunden.

Schöne Grüße
Beppo

[Siro]

der Reset NVIC_SystemReset() funktioniert ja auch. zumindest für den Prozessor.

Siro

[TobiKa]

Wie wärs wenn du nen Watchdog auslöst?
Oder bei "scharfem" Watchdog in eine Unendlichschleife gehst?