Prozessor läuft im Debug-Modus schneller als im Normalem Modus

[Basti B. (basti195)]

Hallo,

ich habe ein etwas komisches Problem.
derzeit arbeite ich auf einem Cortex-m4 Prozessor(Atmel SAM4SD32C). 
Dieser kann über eine PLL mit bis zu 120Mhz getacked werden.
Der Fehler ist mir über die USART Schnittstelle aufgefallen.

Wenn der Prozessor im Debugmodus läuft(Atmelstudio F5) läuft der 
Prozessor Takt so wie er soll. bzw. die Baudrate der gesendeten Pakete 
entspricht der erwarteten Baudrate.
Bricht man nun aber den Debugvorgang ab, sodass der Controller geresetet 
wird und der Prozessor unabhängig vom PC startet stellt sich die 
Baudrate so ein, dass sie einer 12Mhz clock entsprechen würde.

Die Baudrate überprüfe ich mit einem Logic Analyser mit Auto-Baudraten 
Erkennung.

Hat einer vielleicht eine Idee wie es zu diesem verhalten kommt?

Danke
Grüße

[(prx) A. K. (prx)]

Sebastian B. schrieb:
> Hat einer vielleicht eine Idee wie es zu diesem verhalten kommt?

Takteinstellung funktioniert nur im Debug-Modus. Der Chip kommt mit 
interner 12MHz Rate hoch und die PLL Programmierung scheitert, wenn die 
Verzögerungen des Debug-Modus nicht greifen.

[Basti B. (basti195)]

das würde zumindest die 12Mhz erklären.
während der Initialisierung warte ich solange, bis das PLL-lockbit 
gesetzt ist, bevor ich die Master-Clock auf die PLL umbiege.


PMC->PMC_MCKR = PMC_MCKR_CSS_SLOW_CLK; // select 32k hz als Takt quelle
// enable 12mhz oszilator
PMC->CKGR_MOR =  CKGR_MOR_KEY_PASSWD  | CKGR_MOR_MOSCXTEN 
|CKGR_MOR_MOSCSEL ;
// enable PLLA teiler(1-255)  muliplizierer 7(-62) + 1
//Takt = 12mhz / 6 * "x"
 PMC->CKGR_PLLAR = CKGR_PLLAR_DIVA(6)| CKGR_PLLAR_MULA("X")
                  |CKGR_PLLAR_PLLACOUNT(62) | CKGR_PLLAR_ONE ;

//warte auf lockbit
   while ((PMC->PMC_SR&(PMC_SR_LOCKA))) {}

 //  Aktivire PLLA als Master Clock
 PMC->PMC_MCKR = PMC_MCKR_CSS_PLLA_CLK  ;

[Basti B. (basti195)]

gibt es ansonsten noch ideen?

[Basti B. (basti195)]

Ich habe das Problem über einen Counter gelöst, der zusätzlich zum 
Lockbit der PLL etwas zeit gibt

danke an A. K für die anregung

[(prx) A. K. (prx)]

Ich kenne diesen ARM bisher nicht, aber normalerweise muss man bei einem 
Quarzozillator warten bis er hochgefahren ist, bevor man ihm verwendet. 
Das kann ich hier nicht erkennen.

Das läuft also normalerweise so:
- Oszillator einschalten
- Warten bis er hochgefahren ist
- Oszillator verwenden

Mit PLL schliesst sich dann dessen Sequenz an.

[(prx) A. K. (prx)]

Kurzer Blick ins Datasheet offenbart eine detaillierte Beschreibung der 
Programmiersequenz für die Taktversorgung: 29.14 auf S.522, die das von 
mir eben beschriebene bestätigt.

[Basti B. (basti195)]

A. K. schrieb:
> Ich kenne diesen ARM bisher nicht, aber normalerweise muss man bei einem
> Quarzozillator warten bis er hochgefahren ist, bevor man ihm verwendet.
> Das kann ich hier nicht erkennen.
>
> Das läuft also normalerweise so:
> - Oszillator einschalten
> - Warten bis er hochgefahren ist
> - Oszillator verwenden
>
> Mit PLL schliesst sich dann dessen Sequenz an.

Mit de Erklärung klingt es logisch :)
Danke