Arduino Due: Programmierung ohne 16U2

[Geri (Gast)]

Hallo,

kann mir jemand bitte beim Verständnis der beiden USB-Ports des Arduino 
Due helfen? V.a geht es mir um die unterschiedlichen Methoden, wie der 
SAM-Chip in den Programmierbaren modus versetzt wird. Er muss ja 
gelöscht werden, bevor er programmiert werden kann. Dies geht entweder 
über die Pushbuttons, oder der 16U2 übernimmt das, oder, wenn der Native 
USB - Port verwendet wird - irgendwie softwareseitig - und genau da 
stehe ich an: Wie funktioniert das genau? Der Trick ist ja, dass der 
Programming port des SAM mit Baudrate 1200 geöffnet wird, um in den 
Programmiermodus zu gelangen. Aber wie funktioniert das genau? Wo finden 
diese Software-Tricks statt? Am Sam-Chip oder in der Arduino-IDE? Und 
weshalb ist diese Methode unsicherer als über die Serielle 16U2 - 
Methode? Kann der SAMBA-Bootloader im Flash des Sam-Chips dabei 
beschädigt werden? Ich glaube, ich hab da irgendetwas grundsätzliches 
nicht verstanden...

Danke für die Aufklärung!

[Silvio L. (otti20vt)]

Alles micht so schlim wie du meinst :)

Kabel an den Programming Port und gut ist :)

Hast du das Due in der IDE Installiert?

[EGS (Gast)]

Moinsen,

Also unter folgendem Link, bis zum Punkt "Communication runterscrollen 
und dort lesen was dort mit dem 16u gemacht wird (Seriell zu UART) und 
dass der andere Port für Funktionen wie z.B. HID Gerät genutzt werden 
kann und direkt auf den SAM32 geht.

https://www.arduino.cc/en/Main/ArduinoBoardDue

Seitdem die Seite von den Machern des Arduino zwischen USA und Rest der 
Welt unterscheidet gibt es anscheinend Probleme für manche die 
Informationen zu beschaffen...

Achso ist natürlich wie die meisten Elektronik-Seiten oder HAndbücher 
auf Englisch ;)

Gruß EGS

[STK500/Besityer (Gast)]

Geri schrieb:
> Der Trick ist ja, dass der
> Programming port des SAM mit Baudrate 1200 geöffnet wird, um in den
> Programmiermodus zu gelangen. Aber wie funktioniert das genau? Wo finden
> diese Software-Tricks statt?
PC-seitig.
Wobei der 16U2 sich beim Programmingport darum kümmert.

> Am Sam-Chip oder in der Arduino-IDE? Und
> weshalb ist diese Methode unsicherer als über die Serielle 16U2 -
> Methode?
Ist sie nicht, nur etwas komplizierter.

> Kann der SAMBA-Bootloader im Flash des Sam-Chips dabei
> beschädigt werden? Ich glaube, ich hab da irgendetwas grundsätzliches
> nicht verstanden...
eigentlich nicht. Die User-Firmware kann vielleicht schaden nehmen, aber 
der Bootloader ist eh fest eingebrannt.

[Heinrich (Gast)]

Hallo,

ich habe mich damit auch mal befasst wie das funktioniert. Das was ich 
da bisher rausgefunden habe ist folgendes:
Vorweg, ich benutz Mac OS. Wo die Pfade bei Windows oder Linux liegen, 
weiß ich leider nicht. Daher gebe ich hier nur die Pfade von der Mac IDE 
an.
Es gibt den Ordner 
Arduino.app/Contents/Resources/Java/hardware/arduino/sam/system/CMSIS/De 
vice/ATMEL/sam3xa/source/gcc
Dort findest du die Datei startup_sam3xa.c und folgenden Codeausschnitt:

void Reset_Handler(void)
{
  uint32_t *pSrc, *pDest;

  /* Initialize the relocate segment */
  pSrc = &_etext;
  pDest = &_srelocate;

  if (pSrc != pDest) {
    for (; pDest < &_erelocate;) {
      *pDest++ = *pSrc++;
    }
  }

...
}

Dieser wird aufgerufen, wenn du den Controller startest. Dieser 
Codeausschnitt macht nichts anderes als Code von dem Flash in den RAM zu 
kopieren. Die Definitionen von _etext, _srelocate befinden sich im 
Linkerscript in sam3x_sram.ld und sam3x_flash.ld, welche sich ebenfalls 
in dem oben genannten Ordner befinden.

Nun ist er Arduino gestartet. Jetzt kann man sich mal das USB Subsystem 
anschauen. Dort gibt es folgendes. In der Datei
Arduino.app/Contents/Resources/Java/hardware/arduino/sam/cores/arduino/U 
SB/CDC.cpp
Befindet sich die Funktion

bool WEAK CDC_Setup(Setup& setup)
{
  uint8_t r = setup.bRequest;
  uint8_t requestType = setup.bmRequestType;
...

  if (REQUEST_HOSTTODEVICE_CLASS_INTERFACE == requestType)
  {
...
    if (CDC_SET_CONTROL_LINE_STATE == r)
    {
      _usbLineInfo.lineState = setup.wValueL;
      // auto-reset into the bootloader is triggered when the port, already
      // open at 1200 bps, is closed.
      if (1200 == _usbLineInfo.dwDTERate)
      {
        // We check DTR state to determine if host port is open (bit 0 of lineState).
        if ((_usbLineInfo.lineState & 0x01) == 0)
          initiateReset(250);
        else
          cancelReset();
      }
      return true;
    }
  }
  return false;
}

Wenn diese aufgerufen wird, kann ein Reset getriggert werden. Schau dir 
den Code einfach mal an. Der Reset wird nach 250 Ticks ausgeführt wobei 
1 Tick = 1ms sind. Folgende Datei führt den Reset aus:
Arduino.app/Contents/Resources/Java/hardware/arduino/sam/cores/arduino/R 
eset.cpp
Dort findest du auch die erste Funktion die Mittels eines Pargmas in den 
RAM während des Startups geschoben wurde.
Die Funktion tickReset() in der Datei
Arduino.app/Contents/Resources/Java/hardware/arduino/sam/cores/arduino/c 
ortex_handlers.c
zyklisch aufgerufen.

Ich hoffe, ich konnte damit ein wenig helfen.

MfG
Heinrich

[Geri (Gast)]

Hallo Heinrich,

Vielen Dank, das klingt genau nach dem, was ich gesucht habe. Jetzt muss 
ich mich nur mal durch den Code arbeiten und melde mich dann wieder mit 
Fragen, die sicherlich auftauchen werden;-)


Heinrich schrieb:
> Ich hoffe, ich konnte damit ein wenig helfen.
>
> MfG
> Heinrich

[Kaj (Gast)]

STK500/Besityer schrieb:
> Wobei der 16U2 sich beim Programmingport darum kümmert.
Nein, tut er nicht. Wenn man den Due manuel (also ohne die Arduino IDE) 
mit hilfe von Bossac flashen will, muss man vorher händisch den port 
einmal mit 1200 baud öffnen. Mag sein, dass man den 16u2 mit einem 
Befehl dazu bringen kann, aber von alleine macht der da erstmal gar 
nichts.

Geri schrieb:
> Kann der SAMBA-Bootloader im Flash des Sam-Chips dabei
> beschädigt werden?
Nein. Der Bootloader ist in einem ROM-Bereich eingebrannt.

Weiteres findest du im Datenblatt, Seite 327, Kapitel 22:
SAM3X/A Boot Program