Atmel SAM TWI Peripherie auf JTAG Pin nutzen

[Michael (Gast)]

Hallo, habe hier ein SAM4E-EK auf dem ich bereits den TWI0 ohne Probleme 
nutzen kann. Allerdings brauche ich für meine Hardware zwingend auch den 
zweiten I2C (TWI1) vom Controller. Dieser liegt wie der TWI0 auf 
Peripheral A.
PIN = Peripherie A = SYSIO
PB4 = TWD1 (TWI Daten) = TDI (JTAG) und
PB5 = TWCK1 (TWI CLK) = TDO/TRACESWO.

Da ich über den SAM ICE Debugge habe ich mich dann für Serial Debugwire 
entschieden, da hier die Pins TDI und TDO scheinbar unbenutzt sind. Um 
auf Nummer sicher zu gehen habe ich einen weiteren 20Pol 
Pfostenverbinder ohne Pin 5 und 13 (TDI und TDO) auf den SAM ICE 
gepresst, damich diese Leitungen wirklich getrennt sind zum Debugger.

Wenn ich die Portpins, wie auch schon bei TWI0, Peripheri A zuweise 
bleibt der PB5 Pin low. Beide Pins (PB5/PB4) haben einen Pullup nach 
VCC.

Einziges Problem in meinen Augen kann eigentlich nur noch der TRACESWO 
sein, der ja an der TPIU hängt. Da gucke ich aber nicht durch wie ich 
den konkret abschalten soll. Wenn ich einmal über den SAM ICE Debugge 
(20Pol verbindung gesteckt) ist der Pin low, dann zieh ich z.B. den 
Debugge, resette den MC und der Pin liegt hoch, aber der I2C macht 
nichts und Debuggen kann ich ja in dem Moment logischer Weise nicht.

Habt ihr noch irgendwelche Tips wie ich den TWI1 ebenfalls nutzen kann? 
Chip ist der SAM4E16E. Irgendwie sind die Pins nicht wirklich an 
Peripherie A.

[Thomas F. (tomasf)]

Die entsprechenden Debugfunktionen müssen in der Applikation erst 
abgeschaltet werden.

Auf einem SAM4S sieht das so aus:

MATRIX->CCFG_SYSIO |= (1 << 4) | (1 << 5);

Auf dem SAM4E müsste das auch so gehen.

Debuggen geht dann noch über SWD (nur die beiden SWD-Leitungen).

[Michael (Gast)]

Danke dir, das war zummindest ein Schritt in die richtige Richtung.
Habe auch den entsprechenden Absatz im Datenblatt gefunden.

26.9 System I/O Configuration
The System I/O Configuration register (CCFG_SYSIO) allows to configure some I/O lines in System I/O mode (such as
JTAG, ERASE, USB, etc...) or as general purpose I/O lines. Enabling or disabling the corresponding I/O lines in
peripheral mode or in PIO mode (PIO_PER or PIO_PDR registers) in the PIO controller as no effect. However, the
direction (input or output), pull-up, pull-down and other mode control is still managed by the PIO controller.

Trotzdem will der TWI1 immer noch nicht. Im Prinziep habe ich die 
gleiche Vorhergehensweise wie bei TWI0 durchlaufen (Ich nutze übrigens 
das ASF).

Pin Configuration ist

MATRIX->CCFG_SYSIO |= (1 << 4) | (1 << 5); //Disable SYSIO
ioport_set_pin_peripheral_mode(TWI1_DATA_GPIO, TWI1_DATA_FLAGS);
ioport_set_pin_peripheral_mode(TWI1_CLK_GPIO, TWI1_CLK_FLAGS);

TWI initialisiert

#define I2C_BUS1_ADDR_U5 0b0100000

twi_master_options_t opt_bus2 = {
    .speed = 300000,
    .chip  = I2C_BUS1_ADDR_U5
  };

  twi_master_setup(TWI1, &opt_bus2);

Datenpaket lesen

  uint8_t data_received[1];
  
    twi_package_t packet_read = {
      .addr         = {2},      // TWI Command
      .addr_length  = sizeof (uint8_t),    // TWI slave memory address data size
      .chip         = I2C_BUS1_ADDR_U5,      // TWI slave bus address
      .buffer       = data_received,        // transfer data destination buffer
      .length       = sizeof(data_received)                    // transfer data size (bytes)
    };
    
  while(twi_master_read(TWI1, &packet_read) != TWI_SUCCESS);

Nach der Initialisierung sind die Register gleich wie in TWI0.  Wenn ich 
die Datenleitungen PB4 und PB5 als output initialisieren und nicht dem 
TWI1 zuordne lassen diese sich auch High und Low schalten. Nur wenn der 
TWI1 den Pinnen zugeordnet ist, sind diese immer High. twi_master_read() 
hängt er sich in der Funktion auf und bekommt scheinbar kein 
TWI_SR_RXRDY.

Hier auch einmal die FUnktion (unverändert aus dem ASF):

uint32_t twi_master_read(Twi *p_twi, twi_packet_t *p_packet)
{
  uint32_t status, cnt = p_packet->length;
  uint8_t *buffer = p_packet->buffer;
  
  /* Check argument */
  if (cnt == 0) {
    return TWI_INVALID_ARGUMENT;
  }

  /* Set read mode, slave address and 3 internal address byte lengths */
  p_twi->TWI_MMR = 0;
  p_twi->TWI_MMR = TWI_MMR_MREAD | TWI_MMR_DADR(p_packet->chip) |
      ((p_packet->addr_length << TWI_MMR_IADRSZ_Pos) &
      TWI_MMR_IADRSZ_Msk);

  /* Set internal address for remote chip */
  p_twi->TWI_IADR = 0;
  p_twi->TWI_IADR = twi_mk_addr(p_packet->addr, p_packet->addr_length);

  /* Send a START Condition */
  p_twi->TWI_CR = TWI_CR_START;

  while (cnt > 0) {
    status = p_twi->TWI_SR;
    if (status & TWI_SR_NACK) {
      return TWI_RECEIVE_NACK;
    }

    /* Last byte ? */
    if (cnt == 1) {
      p_twi->TWI_CR = TWI_CR_STOP;
    }

    if (!(status & TWI_SR_RXRDY)) {
      continue;
    }
    *buffer++ = p_twi->TWI_RHR;

    cnt--;
  }

  while (!(p_twi->TWI_SR & TWI_SR_TXCOMP)) {
  }

  p_twi->TWI_SR;

  return TWI_SUCCESS;
}

Da das Ganze beim TWI0 super funktioniert schließe ich hier eigentlich 
den Fehler aus. Irgendwas muss noch mit meiner Peripheriezuweisung 
falsch sein. In der Funktion wird auch das TWI-MMR richtig beschrieben. 
Danach passiert nichts mehr in den Registern / in der Funktion.

Die PIO Statusregister PIO_PSR P4 und P5 sind auch auf 0 sodass sie der 
PIO_ABCDSR0 und 1 Peripherie zugeordnet werden. Hier sind alle Bits 0, 
also Peripherie A für den TWI.

[Thomas F. (tomasf)]

Schwer zu sagen, wo der Fehler ist, wenn du den Code nur in Ausschnitten 
postest.

Schaltest du die Clock des TWI1 irgendwo ein?

in der Art:

pmc_enable_periph_clk(ID_TWI1);

[Michael (Gast)]

Danke für deine Hilfe Thomas, die Clock sollte aktiviert sein, habe sie 
auch nochmal expliziert über den PMC eingeschaltet -> keine Veränderung.

Ich habe auch für meine Übersicht nochmal ein neues Projekt (mit Vorlage 
für das SAM4E-EK Board) angelegt, den TWI Service über den ASF 
hinzugefügt und in der init.c den TWI1 definiert:

#ifdef CONF_BOARD_TWI1
MATRIX->CCFG_SYSIO |= (1 << 4) | (1 << 5);
ioport_set_pin_peripheral_mode(TWI1_DATA_GPIO, TWI1_DATA_FLAGS);
ioport_set_pin_peripheral_mode(TWI1_CLK_GPIO, TWI1_CLK_FLAGS);
#endif

Ansonsten ist die Source unangetastet. Alles Andere ist in der Main 
passiert:

#include <asf.h>

#define I2C_BUS1_ADDR_U5 0b0100000

int main (void)
{
  board_init();
  
  sysclk_init();
  
  pmc_enable_periph_clk(ID_TWI1);
  
   twi_master_options_t opt = {
     .speed = 50000,
     .chip  = I2C_BUS1_ADDR_U5
   };

   twi_master_setup(TWI1, &opt);

   uint8_t data_received[1];

   twi_package_t packet_read = {
     .addr         = {2},      // TWI slave memory address data
     .addr_length  = sizeof (uint8_t),    // TWI slave memory address data size
     .chip         = I2C_BUS1_ADDR_U5,      // TWI slave bus address
     .buffer       = data_received,        // transfer data destination buffer
     .length       = sizeof(data_received)                    // transfer data size (bytes)
   };
   // Perform a multi-byte read access then check the result.
   while(twi_master_read(TWI1, &packet_read) != TWI_SUCCESS);
   
   while(1);

  // Insert application code here, after the board has been initialized.
}

Das ganze Projekt ist auch als .zip angehängt.

Auch hier sind beide TWI Leitungen permanent high und er hängt in der 
twi_master_read().

[Thomas F. (tomasf)]

>

> 
>    twi_master_options_t opt = {
>      .speed = 50000,
>      .chip  = I2C_BUS1_ADDR_U5
>    };
>

Das ist auf jeden Fall problematisch. twi_master_options_t liegt bei dir 
auf dem Stack und du initialisierst nicht alle Felder. Da steht dann 
also Müll drin. Da fehlt so was in der Art:

.smbus = 0;
.master_clk = sysclk_get_peripheral_bus_hz(TWI1);

[Michael (Gast)]

Nein, ich fasse es nicht. Es passiert etwas an den Pinnen was im ersten 
Augenblick nach I2C ausschaut. Super.. Den Rest kann ich leider erst 
morgen genauer betrachten. Der Wahnsinn. Es scheint wirklich an 
irgendeinem Müll im Speicher gelegen zu haben.

Wirklich super vielen lieben Dank Thomas. Ich hab mir wirklich schon 
einen Wolf gesucht. War kurz davor einen Multiplexer zu integrieren um 
nur den TWI0 zu nutzen.

[Thomas F. (tomasf)]

Das ist eine Stolperstelle, die sich durch die ganze ASF-Doku zieht. Zum 
Konfigurieren eines Moduls werden immer Strukturen genommen und diese 
sind in den Beispielen immer global definiert und oft eben nur teilweise 
initialisiert. Dann denkt man sich, dass sieht in einer Funktion viel 
schöner aus und schon sucht man 2 Tage den Fehler.

> War kurz davor einen Multiplexer zu integrieren um
> nur den TWI0 zu nutzen.

TWI ist ist ja aber eigentlich schon ein Bus, an dem mehrere devices 
hängen können oder hast du zwei devices mit den gleichen, nicht 
änderbaren, Adressen?

[Michael (Gast)]

Genau das habe ich mir auch gedacht bei dem ASF. Es ist auch tatsächlich 
das erste Mal für mich wo ich mit dem ASF arbeite. Habe lange überlegt 
ob ich den Weg nach wie vor zu fuß gehe oder nicht. Letztendlich 
versuche ich mich nun mit dem ASF, da ich später noch SD + FAT + evtl. 
Ethernet benötige und ich mir hierdurch etwas weniger Aufwand und 
Fehlerquellen erhoffe.
Wieder was gelernt, sich die Strukturen genauer anzuschauen und sich 
nicht auf die Beispiel Doku zu verlassen.

Zum I2C. Habe ziemlich viele Ein- und Ausgabe-Bausteine (PCA9555PW) auf 
der Hardware. Zum einen reichen hier die 3 Adressbits nicht aus und zum 
Anderen habe ich einen Bus gedacht für Eingabelemente, der relativ 
zeitnah übertragen soll und an dem Anderen Bus sind die etwas 
zeitunkretischen Dinge, wie Anzeigeelemente angeschlossen.

[Thomas F. (tomasf)]

Die ASF ist wohl besser als ihr Ruf und bei den ARMs kommt man wohl auch 
nicht mehr drum herum. Jedenfalls solange sie gewünschte 
Funktionalitäten abdeckt. Gerade das TWI-Modul ist da etwas rudimentär, 
es unterstützt keine interrupt-basierten Abläufe.
Für einfache Sachen, zB. Konfiguration eines PWMs, hat die ASF genau die 
Funktionen, die man sich ansonsten selber schreiben würde.

[Helmut W. (upm)]

Hallo liebe Gemeinde,


ich habe versucht das Beispiel von Michael auf TWI0 anzupassen ohne 
Erfolg.
Ich habe es als .zip in den Anhang gepackt vielleicht kann mir jemand 
helfen. Ich nutze einen ATSAM4E8C. Vielen Dank

VG