ATxmega32A4U Internal 32.768kHz Oscillator und USB

[Simon K. (simon)]

Hallo Leute,
Ich habe gerade ein Projekt mit einem ATmega32A4U, der das interne USB 
benutzt (Mittels 32MHz internal oscillator und USBSOF-DFLL).
Der Systemtakt läuft im Moment mit einem Quarz+PLL auf 27.12MHz.

Versuche ich den 32.768kHz internal oscillator anzuschalten mittels
OSC.CTRL |= OSC_RC32KEN_bm;
und zwar egal an welcher Stelle im Code, erkennt der USB Host den 
Mikrocontroller nicht mehr. Windows sagt dann sowas wie "Gerät konnte 
nicht erkannt werden".

Auf den DM/DP Leitungen scheint noch was zu passieren, wenn ich dem 
Oszilloskop glauben schenken darf. Einen Hardware USB Analyzer habe ich 
leider nicht zur Hand.

Ich halte das für höchst merkwürdig! Hat jemand anders sowas schon mal 
erlebt oder kann das ausprobieren? Im Errata vom ATxmega32A4U steht 
davon jedenfalls nichts drin.

Gruß und Danke schon mal!

[Basti M. (counterfeiter)]

Der DFLL hängt doch irgendwie an dem 32.768 Hz internem Clock?!

Ansonsten wirklich komisch... und was passiert, wenn der Clock schon vor 
USB aktiviert wird?

[holger (Gast)]

>Versuche ich den 32.768kHz internal oscillator anzuschalten mittels
>OSC.CTRL |= OSC_RC32KEN_bm;
>und zwar egal an welcher Stelle im Code, erkennt der USB Host den
>Mikrocontroller nicht mehr. Windows sagt dann sowas wie "Gerät konnte
>nicht erkannt werden".

USB läuft halt nicht mit 32.768kHz.

[Simon K. (simon)]

Basti M. schrieb:
> Der DFLL hängt doch irgendwie an dem 32.768 Hz internem Clock?!
>
> Ansonsten wirklich komisch... und was passiert, wenn der Clock schon vor
> USB aktiviert wird?

Nein, die USB DFLL läuft mit dem USB SOF (Start of Frame) als 
Taktquelle.

holger schrieb:
>>Versuche ich den 32.768kHz internal oscillator anzuschalten mittels
>>OSC.CTRL |= OSC_RC32KEN_bm;
>>und zwar egal an welcher Stelle im Code, erkennt der USB Host den
>>Mikrocontroller nicht mehr. Windows sagt dann sowas wie "Gerät konnte
>>nicht erkannt werden".
>
> USB läuft halt nicht mit 32.768kHz.

Ich hab ja auch bloß den internen Oszillator aktiviert . Der Prozessor 
läuft natürlich weiterhin auf 27.12MHz.

[Simon K. (simon)]

Habe das Problem auch noch mal bei avrfreaks geschildert.
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1049473#1049473

[Simon K. (simon)]

Gibts denn hier Leute, die etwas mehr über USB Internas wissen als ich?
Ich habe weiter rumexperimentiert und kann einfach nicht herausfinden, 
wo das Problem sein soll.

Ich habe mal USBTrace zum Loggen benutzt. Im Anhang zwei Screenshots, 
die ein Log von USBTrace von beiden Fällen zeigt.

Auf meinem RIGOL DSO lässt sich leider nichts wesentliches erkennen, 
sonst hätte ich davon auch noch einen Screenshot angehängt.

Um die beiden Logs zu capturen, habe ich in folgendem Initcode die 
markierte Stelle auskommentiert (funktioniert), bzw. einkommentiert 
(funktioniert nicht).

void SystemInit(void)
{
  /* Disable JTAG */
  CCP = CCP_IOREG_gc;
  MCU.MCUCR = MCU_JTAGD_bm;
  MCU.MCUCR = MCU_JTAGD_bm;

  /* TODO: Why does USB fail when enabling RC32K? */
  /* Enable all used clocks */
#if 1
  OSC.XOSCCTRL = OSC_FRQRANGE_12TO16_gc | OSC_XOSCSEL_XTAL_16KCLK_gc;
  OSC.CTRL |= OSC_XOSCEN_bm;
  while(!(OSC.STATUS & OSC_XOSCRDY_bm))
    ;
#endif

#if 0 // <- HERE
  /* Activate 2MHz and 32.768kHz oscillators */
  OSC.CTRL |= OSC_RC2MEN_bm | OSC_RC32KEN_bm;
  while(!(OSC.STATUS & OSC_RC2MRDY_bm))
    ;
  while(!(OSC.STATUS & OSC_RC32KRDY_bm))
    ;

  /* Tune 2MHz Oscillator to 27.12MHz/14 */
  OSC.DFLLCTRL |= OSC_RC2MCREF_RC32K_gc;
  DFLLRC2M.COMP2 = 0x07;
  DFLLRC2M.COMP1 = 0x64;
  DFLLRC2M.CTRL = DFLL_ENABLE_bm;
#endif // <- HERE

#if 0
  OSC.PLLCTRL = OSC_PLLSRC_RC2M_gc | (14 << OSC_PLLFAC_gp);
#else
  OSC.PLLCTRL = OSC_PLLSRC_XOSC_gc | (2 << OSC_PLLFAC_gp);
#endif
  OSC.CTRL |= OSC_PLLEN_bm;
  while(!(OSC.STATUS & OSC_PLLRDY_bm))
    ;

  /* Set PLL as main clock */
  CCP = CCP_IOREG_gc;
  CLK.CTRL = CLK_SCLKSEL_PLL_gc;

  /* Use TCE0 as system tick */
  TCE0.PER = F_CPU / 256 / 10 - 1;
  TCE0.CTRLA = TC_CLKSEL_DIV256_gc;

#if 1
  /* Enable RTC with roughly 1kHz clock */
  CLK.RTCCTRL = CLK_RTCSRC_ULP_gc | CLK_RTCEN_bm;
  RTC.CTRL = RTC_PRESCALER_DIV1_gc;
#endif

}

Vielleicht kann da ja jemand weitere Vermutungen anstellen, was los ist?
:-)

[Simon K. (simon)]

Kleiner Nachtrag. Den Unterschied zwischen Funktion und Nichtfunktion 
macht sogar das Hinzufügen/Wegnehmen dieser einzigen Zeile Programmcode 
aus:

OSC.CTRL |= OSC_RC32KEN_bm;

Das gibts doch nicht!

[Basti M. (counterfeiter)]

Mal nachgeschaut ob beim OSC_RC32KEN_bm auch das richtige Bit gesetzt 
wird?

[Simon K. (simon)]

Basti M. schrieb:
> Mal nachgeschaut ob beim OSC_RC32KEN_bm auch das richtige Bit gesetzt
> wird?

Aus Verzweiflung habe ich alle defines mal mit dem Datenblatt überprüft 
und das passt soweit. Das wäre zu schon gewesen.

Ein Abgleich mit dem Atmel Software Framework ergibt auch keine 
Abweichungen.. Die haben da aber auch in keinem Beispiel den 32.768kHz 
Oszillator und USB gleichzeitig laufen. Sonst hätte man auf jeden Fall 
einen Beweis gehabt, dass das funktionieren MUSS.

[Fabian O. (xfr)]

Kann es sein, dass Du vergisst, den Schreibschutz für das 
OSC.CTRL-Register aufzuheben bzw. es danach zu viele Takte dauert? Schon 
das Vodern mit dem alten Wert könnte zu lang sein.

[Simon K. (simon)]

Du meinst die CCP? Das Register fällt nicht unter die durch die CCP 
geschützten Register. Auch mal testweise ein hinzufügen von CCP = 
CCP_IOREG_gc; direkt vor dem Zugriff bringt keinen Unterschied.

[Fabian O. (xfr)]

Ja, meinte ich. Habs mit dem CLK.CTRL-Register verwechselt, Sorry.

[Fabian O. (xfr)]

Falls es Dir moralisch hilft: Ich kann das Problem mit einem 
ATxmega128A4U reproduzieren. Wenn ich

OSC.CTRL |= OSC_RC32KEN_bm;

in das Programm einfüge, funktioniert die USB-Verbindung nicht mehr. 
Sehe im Datenblatt aber keine Erklärung, warum man das nicht machen 
dürfen sollte.

[Simon K. (simon)]

Fabian O. schrieb:
> Falls es Dir moralisch hilft: Ich kann das Problem mit einem
> ATxmega128A4U reproduzieren. Wenn ichOSC.CTRL |= OSC_RC32KEN_bm;in das Programm 
einfüge, funktioniert die USB-Verbindung nicht mehr.
> Sehe im Datenblatt aber keine Erklärung, warum man das nicht machen
> dürfen sollte.

Ja, das hilft mir :-) Vor allem jetzt vor dem Schlafengehen.

Riecht wohl ziemlich stark nach Silicon Bug, meiner Meinung nach.

[Master (Gast)]

Oh man...

das hat mich auch ein paar Nächte schlaf gekostet... Sehr gut 
Erkenntnis, kein Plan wie du da vor 10 Jahren drauf gekommen bist, aber 
Danke! Ich habe das Problem nicht ohne eure Hilfe finden können!

Wenn das mal jemand liest der sich auskennt, das ist ein Bug der 
wirklich schwer zu finden ist und unglaublich relevant wenn man mit USB 
arbeitet. Vielleicht könnte der mal ins Wiki...

[Simon K. (simon)]

Lang ist es her! Interessant, dass der Bug auch immer noch nicht in 
einem Erratasheet zu finden ist :-)