Problem mit I2C scan auf Adresse von HTU21D

[M. G. (ixil96)]

Hallo,

ich programmiere gerade die I2C-Schnittstelle (Controller = STM32L476RG) 
zum HTU21D Sensor. Als IDE verwende ich Atollic Truestudio.

Mit dem folgenden Codeschnippsel frage ich die Adresse (sollte lt. 
Datenblatt eigentlich 0x40 sein) ab.

Für die Abfrage verwende ich eine HAL-Funktion und übergebe als 
Parameter i für die Adresse. Die Variable i ist global und beginnt bei 
0:

  /**
    * @brief  Checks if target device is ready for communication.
    * @note   This function is used with Memory devices
    * @param  hi2c Pointer to a I2C_HandleTypeDef structure that contains the configuration information for the specified I2C.
    * @param  DevAddress Target device address: The device 7 bits address value in datasheet must be shifted to the left before calling the interface
    * @param  Trials Number of trials
    * @param  Timeout Timeout duration
    * @retval HAL status
    */
  for (; i<255; i++)
  {
    if(HAL_I2C_IsDeviceReady(&hi2c1, i, 1, 10) ==  HAL_OK)
    {
      HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5);
      break;
    }
  }

Das seltsame dabei ist, dass HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5); nie 
ausgeführt wird (Das Programm bleibt hier auch bei einem Breakpoint 
nicht stehen). Die Abfrage wird aber bei i=128 (0x80) beendet.

[Stefan F. (Gast)]

Welchen Typ hat i und mit welchem Startwert fängst du an?

Ist Dir bewusst, dass I²C Adressen normalerweise nur 7 Bits haben, also 
niemals den Wert 255 haben können?

Dass dein Pin nie getoggelt wird könnte schlicht daran liegen, dass dein 
Sensor nicht antwortet.

Ich würde Dir empfehlen, die Kommunikation mit einem "8ch logic 
analyzer" zu untersuchen. Was du auch noch ganz fix prüfen solltest, ist 
die Spannung an SDA und SCL. Beide Leitungen müssen vor und nach dem 
Programm-Ablauf auf High Pegel liegen, also deutlich mehr als 2 Volt.

[Thomas Z. (usbman)]

M. G. schrieb:
> Die Variable i ist global und beginnt bei 0

eine Schleifenvariable i global zu machen darauf muss man erst mal 
kommen.

Thomas

[M. G. (ixil96)]

Thomas Z. schrieb:
> M. G. schrieb:
>> Die Variable i ist global und beginnt bei 0
>
> eine Schleifenvariable i global zu machen darauf muss man erst mal
> kommen.
>
> Thomas

Ja genau....

Wie soll ich sie sonst beim Debuggen überwachen...?

[M. G. (ixil96)]

Ich habe SCK und SDA mit dem Oszi aufgenommen. Das ist die Übertragung 
der Adresse 0x40.

Ich interpretiere das als START - 0100 0000 ACK - STOP

Somit sollte das denke ich passen...

[Thomas Z. (usbman)]

M. G. schrieb:
> Ja genau....
>
> Wie soll ich sie sonst beim Debuggen überwachen...?

Bedeutung man kann nur globale Variablen überwachen? Wenn das so sein 
sollte würde ich über eine alternative Toolchain nachdenken.

Thomas

[M. G. (ixil96)]

Thomas Z. schrieb:
> M. G. schrieb:
>> Ja genau....
>>
>> Wie soll ich sie sonst beim Debuggen überwachen...?
>
> Bedeutung man kann nur globale Variablen überwachen? Wenn das so sein
> sollte würde ich über eine alternative Toolchain nachdenken.
>
> Thomas

Dann wäre ich dir sehr dankbar, wenn du es mir für Atollic TrueStudio 
zeigen könntest wie das geht!

[Thomas Z. (usbman)]

nun eine Möglichkeit die immer gehen wird wäre z.B die Variable lokal 
als static zu definieren. Und ja mir ist durchaus bekannt dass so ein 
Konstrukt auch eine globale Var erzeugt die halt nur lokal sichtbar ist.

Beispiel:

char foo(void)
{
  char static i = 0;
  ...
  return i;
}

[Stefan F. (Gast)]

M. G. schrieb:
> Wie soll ich sie sonst beim Debuggen überwachen...?

Lokale Variablen kannst du genau so überwachen. üge sie einfach zum 
Watch Fenster hinzu oder setze eine Haltepunkt innerhalb der Schleife 
und zeige dann mit der Maus drauf.

[Joachim B. (jar)]

M. G. schrieb:
> Das ist die Übertragung
> der Adresse 0x40.

und mit 64d kleiner als 127 0x7f

also warum?

M. G. schrieb:
> for (; i<255; i++)

wenn es eh höhere Adressen gibt I2C Erweiterung muss man die oberhalb 
anders ansprechen.....
http://gedankenlyrik.bplaced.net/www/studium/seminararbeit_2008.pdf

nun gilt noch zu klären wie deine SW I2C ansprechen möchte,

entweder mit 7-bit

  for(address = 1; address < 127; address++ ) 
  { //The i2c_scanner uses the return value of
    //the Write.endTransmisstion to see if
    //a device did acknowledge to the address.
    Wire.beginTransmission(address);
    error = Wire.endTransmission();

    if (error == 0)
    { DEBUG_PRINT(F("I2C found at Add. 0x"));

oder mit 8-bit +R/W

if(!i2c_start(PCF8574A_0+I2C_READ))  //;  // set device address and write mode

[Stefan F. (Gast)]

M. G. schrieb:
> Ich interpretiere das als START - 0100 0000 ACK - STOP

Das neunte Bit hat High Pegel, das ist ein NACK. Dein Sensor hat nicht 
geantwortet.

[M. G. (ixil96)]

Stefanus F. schrieb:
> M. G. schrieb:
>> Ich interpretiere das als START - 0100 0000 ACK - STOP
>
> Das neunte Bit hat High Pegel, das ist ein NACK. Dein Sensor hat nicht
> geantwortet.

Danke für die Info! Das habe ich wohl falsch interpretiert... 1 = NACK, 
0 = ACK.

Die Initialisierung habe ich über CubeMX gemacht. Eingestellt ist eine 
7-Bit Adressierung.

  hi2c1.Instance = I2C1;
  hi2c1.Init.Timing = 0x10909CEC;
  hi2c1.Init.OwnAddress1 = 0;
  hi2c1.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT;
  hi2c1.Init.DualAddressMode = I2C_DUALADDRESS_DISABLE;
  hi2c1.Init.OwnAddress2 = 0;
  hi2c1.Init.OwnAddress2Masks = I2C_OA2_NOMASK;
  hi2c1.Init.GeneralCallMode = I2C_GENERALCALL_DISABLE;
  hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_DISABLE;

Ich habe jetzt 3 Sensoren mit unterschiedlichen Pull-up Widerständen 
(2k2, 4k7 und 10k) getestet.

[Stefan F. (Gast)]

Bis auf das fehlende ACK sieht dein Oszilloskop-Bild gut aus. Am 
Programm kann es daher nicht liegen.

[M. G. (ixil96)]

Wer lesen kann ist klar im Vorteil...

The device 7 bits address value in datasheet must be shifted to the left 
before calling the interface.

Naja, eine gemeine Falle

/**
  * @brief  Checks if target device is ready for communication.
  * @note   This function is used with Memory devices
  * @param  hi2c Pointer to a I2C_HandleTypeDef structure that contains
  *                the configuration information for the specified I2C.
  * @param  DevAddress Target device address: The device 7 bits address value
  *         in datasheet must be shifted to the left before calling the interface
  * @param  Trials Number of trials
  * @param  Timeout Timeout duration
  * @retval HAL status
  */
HAL_StatusTypeDef HAL_I2C_IsDeviceReady(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint32_t Trials, uint32_t Timeout)

[Stefan F. (Gast)]

M. G. schrieb:
> The device 7 bits address value in datasheet must be shifted to the left
> before calling the interface.

Guter Hinweis,
dann hätte der Sensor auf die Adresse 0x80 (128) reagieren müssen.

was zu dieser Aussage passt:

> Die Abfrage wird aber bei i=128 (0x80) beendet.

M.G. vielleicht musst du einfach noch ein bisschen üben, den Debugger zu 
bedienen!? Fange mal damit, die Optimierungsstufe des Compilers auf -Og 
oder -O0 zu ändern. Hat deine Projekt nicht genau dafür zwei 
unterschiedliche Konfigurationen vorbereitet? Zumindest bei der System 
Workbench wäre das standardmäßig der Fall.

Siehe 
http://blog.atollic.com/how-to-create-and-modify-a-build-configuration-video-tutorial

[M. G. (ixil96)]

Mit übergabe von 0x80 sieht die Sache schon besser aus...

jetzt noch den Rest mit Auslesen usw.

@ Stefanus F. Da hast du recht! Üben muss ich noch ganz viel. Ich 
arbeite mich erst in die ganze STM32 Geschichte und TrueStudio ein.

[Stefan F. (Gast)]

M. G. schrieb:
> it übergabe von 0x80 sieht die Sache schon besser aus...

Na also, geht doch! Erste Hürde geschafft. Jetzt spiele mit dem Debugger 
herum, bevor du weiter programmierst. Denn den wirst du noch öfter 
benutzen wollen.