ADXL380 mit SPI auslesen

[Oliver M. (oliver_martens)]

Hallo zusammen,
wir versuchen gerade im Rahmen einer Studienarbeit den ADXL380-1BCCZ-RL7 
via SPI auszulesen und die Beschleunigungsdaten zu protokolieren. Der 
ADXL380 wurde gemäß dem Datenblatt auf Seite 23 (siehe Bild) 
angeschlossen und wird mit dem ESP32-C3-Mini von Espressif betrieben. 
Der Stromverbrauch im Standby-Mode beträgt etwa 7uA und im High 
Performance-Mode messen wir etwa 250uA. Der ESP32 wird mit der Arduino 
IDE 2.3.6 programmiert und in der PDF ist der Leseprozess, den wir mit 
dem Oszilloskop beobachtete haben dokumentiert. Wir versuchen zurzeit 
nur die Beschleunigungsdaten der X-Achse (Register: 0x15 und 0x16) zu 
lesen und bekommen nur eine 0 als Ergebnis. Die Device_ID lässt sich 
allerdings, so wie auch einige andere Register problemlos auslesen. Die 
Ergebnisse wurden mit 2 ADXL380 getestet.

Unser Code:

#include <SPI.h>

const int CS_PIN = 10;

void setup() {
  Serial.begin(115200);

  pinMode(CS_PIN, OUTPUT);
  digitalWrite(CS_PIN, HIGH);

  SPI.begin(6, 2, 7, 10);
  SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE0)); 


  //Soft-Reset
  writeRegister(0x2A, 0b00000010);
  uint16_t softReset = readRegister(0x26);
  Serial.print("Soft-Reset: ");
  Serial.println(softReset);

  //Modus-Wahl
  writeRegister(0x26, 0b00000000); //Standby-Mode
  uint16_t mode1 = readRegister(0x26);
  Serial.print("Mode_1: ");
  Serial.println(mode1);

  writeRegister(0x27, 0b11100000);
  uint16_t dig_En = readRegister(0x27);
  Serial.print("Dig_En: ");
  Serial.println(dig_En);

  writeRegister(0x26, 0b00001100);
  uint16_t mode2 = readRegister(0x26);
  Serial.print("Mode_2: ");
  Serial.println(mode2);

  //Status
  uint16_t status0 = readRegister(0x11);
  uint16_t status1 = readRegister(0x12);
  uint16_t status2 = readRegister(0x13);
  uint16_t status3 = readRegister(0x14);

  //Status
  Serial.print("Status0: ");
  Serial.println(status0);
  Serial.print("Status1: ");
  Serial.println(status1);
  Serial.print("Status2: ");
  Serial.println(status2);
  Serial.print("Status3: ");
  Serial.println(status3);
}

void loop() {
  //x-Achse lesen
  uint16_t ID = readRegister(0x00);
  uint16_t xH_Data = readRegister(0x15);
  uint16_t xL_Data = readRegister(0x16);
  
  Serial.print("ID: ");
  Serial.println(ID,HEX);
  Serial.print("xL_Data: ");
  Serial.println(xL_Data);
  Serial.print("xH_Data: ");
  Serial.println(xH_Data);
  delay(400);
}

//Register write
void writeRegister(uint8_t registerAddress, uint8_t value) {
  uint16_t command = ((registerAddress << 9) | value); // R/W-Bit = 0

  digitalWrite(CS_PIN, LOW);
  
  SPI.transfer16(command);

  digitalWrite(CS_PIN, HIGH);
}

//Register read
uint16_t readRegister(uint8_t registerAddress){
    
    digitalWrite(CS_PIN, LOW);

    uint16_t data = SPI.transfer16((registerAddress<<9) | (0x01<<8));

    digitalWrite(CS_PIN, HIGH);

    return data;
}

Die Ausgabe auf dem Seriellen Monitor:

-> Ausgabe im Setup:
Soft-Reset:   12
Mode_1:   65280
Dig_En:   65504
Mode_2:   12
Status0:   65280
Status1:   65424
Status2:   65436
Status3:   1 

-> Ausgabe beim lesen:
ID:   AD
xL_Data:   0
xH_Data:   0

Zusätzlich zu dem vorliegenden Code haben wir ebenfalls versucht die 
anderen Achsen und die Temperatur auszulesen und haben ebenfalls nur 0 
als Ausgabe bekommen. Vielleicht hat jemand eine Idee oder ein paar 
Tipps.
LG OLLI

[Keks F. (keksliebhaber)]

Bit Shift um 8 bzw. 7 machen. Zaunpfosten Fehler.

[Oliver M. (oliver_martens)]

Danke für deine schnelle Antwort,

ich habe mal das Datenblatt beigefügt, auf Seite 49 wird dort das 
schreiben und lesen per SPI erklärt. Ich habe das Datenblatt so 
gedeutet, dass die Adresse insgesamt 7 Bit lang ist und in die Bits 9-15 
geschrieben wird, weswegen ich in meiner Funktion auch die Adresse um 9 
Bit shifte (von Bit 0 auf Bit 9) und der Read/Write Befehl liegt auf Bit 
8, weswegen ich das dann um 8 shifte. Vielleicht habe ich da auch einen 
Denkfehler. Könntest du mir deinen Ansatz etwas genauer erläutern.
LG Olli

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Probiers mal so:

  :
void writeRegister(uint8_t registerAddress, uint8_t value) {
  uint16_t command = (((uint16_t)registerAddress << 9) | value); 
  :
uint16_t readRegister(uint8_t registerAddress){
  uint16_t data = SPI.transfer16(((uint16_t)registerAddress<<9) | (0x01<<8));
  :

Das sollte der Compiler zwar von sich aus tun, aber hey, wer weiß. Das 
Oszi wäre hier wieder super, um zu sehen, ob auf dem Bus auch das 
unterwegs ist, was du erwartest.

Noch Tipp: die Bits 15..8 im empfangenen 16-Bit-Wort sind "undriven". 
Die solltest du also sinnigerweise spätestens bei der Anzeige 
ausblenden. Oder einfach nur 8 Bits zurückgeben:

uint8_t readRegister(uint8_t registerAddress){
:
    uint8_t data = SPI.transfer16((registerAddress<<9) | (0x01<<8));
:
    return data;

Interessant wäre hier auch, dass die Clockphase sicher zum Datenblatt 
passt. Denn sonst schreibst du evtl. die Adresse um 1 Bit versetzt.

[Oliver M. (oliver_martens)]

Das ist jetzt unser aktueller Code. Die Ausgabe ist jetzt etwas 
formatiert und ich habe die Verbesserung mit uint8_t bei readRegister() 
übernommen. Die Datentypkonvertierung mit (uint16_t) ist eine gute Idee 
gewesen, aber leider hat das auch keine Verbesserung ergeben.
Wir erhalten weiterhin bei allen Achsen 0 als Ausgabe und lesen derzeit 
alle 4 ID´s aus, wobei eine ID vom Datenblatt abweicht. Die ID unter der 
Adresse 0x03 sollte den Wert 0xC2 widergeben und wir erhalten eine 0xC1. 
Allerdings ist in dem Applications Examples (GitHub) in der ADXL38x.h 
auf der Analog Devices Seite zum ADXL380 auch als Rückgabewert 0xC1 
beschrieben.
Des weiteren haben wir den Status 0-3 weiter ausgewertet und haben 
"EFUSE-Fehler" lesen können:

Erweiterter Reset + NVM Control

writeRegister(0x2A, 0x52); //Seite 69
… 
delay(10);
//NVM Control
writeRegister(0x29, 0b11000000);
delay(10);

Ausgabe:

Soft-Reset:     0x2  0b10
Mode_1:          0x0  0b0
Dig_En:          0xE0  0b11100000
Mode_2:          0xC  0b1100
Status0:  0x40  0b1000000
Status1:  0x80  0b10000000
Status2:  0x9C  0b10011100
Status3:  0x1  0b1

Erweiterter Reset

writeRegister(0x2A, 0x52); //Seite 69
…
delay(10);

Ausgabe:

Soft-Reset:     0x2  0b10
Mode_1:          0x0  0b0
Dig_En:          0xE0  0b11100000
Mode_2:     0xC  0b1100
Status0:  0x40  0b1000000
Status1:  0x80  0b10000000
Status2:  0x9C  0b10011100
Status3:  0x0  0b0

Erweiterter Reset mit Startdelay

delay(10);
writeRegister(0x2A, 0x52); 
…
delay(10);

Ausgabe:

Soft-Reset:     0x2  0b10
Mode_1:          0x0  0b0
Dig_En:          0xE0  0b11100000
Mode_2:          0xC  0b1100
Status0:  0x40  0b1000000
Status1:  0x80  0b10000000
Status2:  0x9C  0b10011100
Status3:  0x0  0b0

Soft-Reset

writeRegister(0x2A, 0b00000010); 
…
delay(10);

Ausgabe:

Soft-Reset:     0x0  0b10
Mode_1:          0x0  0b0
Dig_En:          0xE0  0b11100000
Mode_2:          0xC  0b1100
Status0:  0x0  0b0
Status1:  0x80  0b10000000
Status2:  0x9C  0b10011100
Status3:  0x1  0b1

Bei dem "erweiterte" Reset schreiben wir in das Reset-Register die 0x52, 
was einen sofortigen Reset zur Folge hat (S.69 im Datenblatt).
Zu erkennen ist, dass wir ohne "erweiterten" Reset NVM_Done (Bit 6) in 
Status 0  nicht gesetzt wird. Ansonsten haben wir das Problem bei alle 
Versuchen das Status 1  einen Error mit Bit 7 zum EFUSE Controller 
ausgibt und Status 2 mit Bit 3 einen EFUSE CRC Error ausgibt. Vielleicht 
haben wir auch eine Denkfehler, aber ich sehe gerade keine anderen 
Problem mehr und verstehe die EFUSE-Errors nur bedingt. Ich werde noch 
einmal den SPI-Bus mit dem Oszilloskop untersuchen und mich dann nochmal 
melden.

[Rainer W. (rawi)]

Oliver M. schrieb:
> Ich werde noch einmal den SPI-Bus mit dem Oszilloskop untersuchen

Je nach dem, was du für ein Oszilloskp hast, kann das möglicherweise als 
Logikanalysator das SPI-Signal selbst dekodieren.
In dem Analyse-Dokument ist es wegen der geringen Zeitauflösung und der 
Überlagerung von Clock und Daten arg mühselig, irgendwelche Details 
bzgl. des Timings abzulesen.

[Thomas R. (dontmoan)]

Moin,
ich kenne diesen Chip nicht, aber für die SPI Kommunikation ist kein 
eigenes Frame Format angegeben.
Bei anderen Chips heisst das, das exakt das I2C Frame Format benutzt 
werden muss. Also Byte1 Devadr+r/w, Byte2 regadr, byte2 Data.
Du machst nur 16bit transfers.
Und die Device Adresse sollte ja fix sein, je nachdem wie ASEL0/1 
stehen.
Könnte es daran liegen?

[Rahul D. (rahul)]

Thomas R. schrieb:
> Also Byte1 Devadr+r/w, Byte2 regadr, byte2 Data.

SPI braucht keine DeviceAddress.
Das R/W-Bit wird an das Command-Byte (obere sieben Bit) als LSB 
angehängt.
Kapitel "Serial Communicatiom" im Datenblatt 
(https://www.analog.com/media/en/technical-documentation/data-sheets/adxl380.pdf 
- Seite 49)
Ob der Baustein ein Adress-Autoinkrement unterstützt, habe ich auf die 
Schnelle nicht gefunden. Normalerweise / von anderen Bausteinen wird 
sowas ja unterstützt.