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