AFE4403 antwortet nur jedes zweite mal

[Adam P. (adamap)]

Moin zusammen,

ich habe soeben die Ansteuerung meines AFE4403 per SPI fertig und muss 
feststellen, dass er mir nur jedes zweite mal antwortet.

Nach dem Startvorgang bekommt er eine default Konfig., danach lese ich 
zyklisch das Register "LED2VAL" (Testweise nur das eine).

Dabei spielt es keine Rolle ob ich das nun alle 5ms oder 500ms lese.
Anbei die default Konfig. und Screenshot vom LA.

Habt ihr eine Idee?
Übersehe ich da evtl. etwas?

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

Adam P. schrieb:
> danach lese ich zyklisch das Register "LED2VAL" (Testweise nur das eine).
Und dafür muss man tatsächlich 10 Bytes übertragen?

> dass er mir nur jedes zweite mal antwortet.
Wenn ich im Datenblatt den Abschnitt "8.5.2.1 Writing Data" so lese, 
dann wundert mich das nicht, denn da steht " Data can be loaded in 
multiples of 32-bit words within a single active SPISTE pulse."
Dieses 32-Bit-Alignament kann man auch im "Figure 8-36. Serial Multiple 
Read and Write Operations" sehen.

Und 32 Bits sind nun mal 4 Bytes, 2x32 Bits sind 8 Bytes, du überträgst 
da aber 10 Bytes, also 2,5 solcher 32-Bit Pakete.  zu Konsequenz: erst 
bei jeder 2. Übertragung ist die Adresse wieder an der richtigen 
Bitposition...

[Adam P. (adamap)]

Lothar M. schrieb:
> Und 32 Bits sind nun mal 4 Bytes, 2x32 Bits sind 8 Bytes, du überträgst
> da aber 10 Bytes, also 2,5 solcher 32-Bit Pakete.  zu Konsequenz: erst
> bei jeder 2. Übertragung ist die Adresse wieder an der richtigen
> Bitposition...

Ja, da gebe ich dir recht.
Problem ist jedoch, wenn ich nicht soviel takte, dann bekomme ich nicht 
alles in mein RX Buffer, bzw. bekomme ich in diesem Fall komischerweise 
gar keine Antwort.

Ein ganzes Register ausgelesen bekomme ich nur wenn ich 3 Byte mehr als 
Empfang und 2 Byte mehr als Sende Länge in Auftrag gebe. Find ich auch 
merkwürdig.

spi_master_receive(afe_buf_r.buf, afe_buf_r.len + 3);
spi_master_transfer(afe_buf_w.buf, afe_buf_w.len + 2);

Wenn ich (wie man annehmen sollte) für TX & RX 8 Byte in Auftrag gebe, 
passiert gar nichts.

Da frag ich mich, woher will der AFE wissen wieviel ich noch takten 
werde?
Bild1: zuviele takte, jedoch mit korrekter antwort
Bild2: 2 x 32bit takte, jedoch keine antwort

Irgendwie echt merkwürdig.

Edit:
Ich mach mal Versuche mit blockierenden SPI Funktionen, KISS.
Irgendwo muss ja der Fehler liegen.

[dabalesa (Gast)]

Auszug aus dem Daenblatt:

8.5.2.2 Reading Data

The SPI_READ register bit must be first set to 1 before
reading from a register.
.........

[Adam P. (adamap)]

dabalesa schrieb:
> 8.5.2.2 Reading Data
> The SPI_READ register bit must be first set to 1 before
> reading from a register.

Siehe Bilder, das mache ich bei jedem Lesevorgang.
Register 0 = 0x01

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

Adam P. schrieb:
> Ich mach mal Versuche mit blockierenden SPI Funktionen
Mach auch mal Versuche, den SPISTE aktiver mitwirken zu lassen. Denn 
immerhin hat der es in jedes Timing-Diagramm geschafft. Könnte durchaus 
sein, dass mit SPISTE=high auch der interne Bitzähler zurückgesetzt wird 
(auch wenn das nirgendwo dokumentiert ist). Denn das wäre ein blödes 
Interface, wenn es nach 1 einzigen Störimpuls auf der CLK-Leitung den 
Rest des Tages um 1 Bit versetzt laufen würde...

[dabalesa (Gast)]

Auszug aus dem Datenblatt:

To enable this mode, first set the SPI_READ register bit using
the SPI write command, as described in the Writing Data section.

Will heissen du brauchst einen separaten Write-Zyklus, beginnend
mit einem CS low und endend mit einem CS high.

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

dabalesa schrieb:
> Will heissen du brauchst einen separaten Write-Zyklus, beginnend
> mit einem CS low und endend mit einem CS high.
Wie gesagt: es ist im DB absolut nirgends erwähnt, dass der SPISTE 
irgendeine synchronisierende Wirkung hat. Vielleicht haben sich die 
Entwickler gedacht: "weiß ja sowieso jeder"...

[Adam P. (adamap)]

Lothar M. schrieb:
>> Will heissen du brauchst einen separaten Write-Zyklus, beginnend
>> mit einem CS low und endend mit einem CS high.

Sehe ich erstmal nicht so:
S. 59 (8.5.2.3 Multiple Data Reads and Writes)
Figure 8-36

Fussnote B:
"The second write operation must be configured for register 0 with data 
000001h."

Sprich: Mach was du willst, aber bevor du liest, muss der letzte Write 
die 1 auf Reg. 0 beinhalten.

dabalesa schrieb:
> Will heissen du brauchst einen separaten Write-Zyklus, beginnend
> mit einem CS low und endend mit einem CS high.

Werde ich auch mal ausprobieren.

Lothar M. schrieb:
> Mach auch mal Versuche, den SPISTE aktiver mitwirken zu lassen. Denn
> immerhin hat der es in jedes Timing-Diagramm geschafft. Könnte durchaus
> sein, dass mit SPISTE=high auch der interne Bitzähler zurückgesetzt wird
> (auch wenn das nirgendwo dokumentiert ist).

Das teste ich ebenfalls.

[dabalesa (Gast)]

Skuriller Weise hat sich der DaBlaSchreiber eine neue Bezeichung
für die MOSI- und MISO-Signale entgegen der üblichen Bezeichnung
ausgedacht (SIMO und SOMI).

Kann bitte ein Moderator das [/code] in meinem vorangegangenen
Beitrag korrigieren/richtigstellen.

[Adam P. (adamap)]

dabalesa schrieb:
> Skuriller Weise hat sich der DaBlaSchreiber eine neue Bezeichung
> für die MOSI- und MISO-Signale entgegen der üblichen Bezeichnung
> ausgedacht (SIMO und SOMI).

Naja, aus sicht des Slaves würde es ja passen :-D
Aber ja, liest sich echt kacke.

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

Adam P. schrieb:
> Lothar M. schrieb:
>>> Will heissen du brauchst einen separaten Write-Zyklus, beginnend
>>> mit einem CS low und endend mit einem CS high.
>
> Sehe ich erstmal nicht so
Ich zum Glück auch nicht. Lediglich dein Zitat ordnet den Text 
fälschlicherweise mir zu...

[dabalesa (Gast)]

Adam P. schrieb:
> Sehe ich erstmal nicht so:

Dann müsstest du allerdings drei mal 32 Bit in deinem aktiven
(CS low) Zyklus schreiben, was ich bis jetzt nicht erkennen
kann. Hab ich was übersehen?

[dabalesa (Gast)]

Lothar M. schrieb:
> Lediglich dein Zitat ordnet den Text fälschlicherweise mir zu...

Ja gut, ersetze "müsstes du" durch "müsste man" ....

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

Die Protokollbeschreibung im Datenblatt ist echt lausig. Im "Figure 
8-36. Serial Multiple Read and Write Operations" (sehe einen Post weiter 
oben) stehen Anmwerkungen (1,2) und (3,4) und als Fußnoten dann A, B, C 
und D...

dabalesa schrieb:
> Dann müsstest du allerdings drei mal 32 Bit in deinem aktiven
> (CS low) Zyklus schreiben, was ich bis jetzt nicht erkennen kann.
Korrekt. Der Text zum obigen Bild lässt ahnen, was falsch läuft. Da 
steht
"Perform _two writes_".

Und dabei muss
"the SPI readbit enabled during the second write operation" sein.

Danach kann gelesen werden: "In the next command,
specify the SPI register address with the desired content to be read."

[Adam P. (adamap)]

Lothar M. schrieb:
> Seis drum, der Text dazu lässt ahnen, was falsch läuft. Da steht
> "Perform _two writes_".
>
> Und dabei muss
> "the SPI readbit enabled during the second write operation" sein.
>
> Danach kann gelesen werden: "In the next command,
> specify the SPI register address with the desired content to be read."

Soll das etwa bedeuten ich muss dem Reg 0 erst sagen das ich es 
beschreiben will um es dann zu beschreiben, dass ich lesen möchte?

:-D

Das klingt so bescheuert, dass es evtl. richtig sein könnte?
Probier ich gleich mal aus.

[Adam P. (adamap)]

Also,

am Chip Select liegt es nicht.

Ich aktiviere nun den CS und belasse ihn dauerhaft aktiv.
Dann beschreibe ich 1x das Reg 1 mit einem Wert.
Danach Endlosschleife mit Read auf Reg 1 -> funktioniert.
(Mit blockierenden SPI Funktionen)

Dann funktioniert es so grundsätzlich.

Edit:
Ich habe so das Gefühl, da passt was mit dem DMA nicht.
Theoretisch funktioniert es nun per DMA auch mit RX & TX je 8 Byte.
Jedoch ist das Verhalten jetzt ganz anders.

Es wird Zeit fürs WE, aber ich berichte (vollständigkeitshalber) sobald 
ich das Problem lokalisiert habe.

[Adam P. (adamap)]

Ich bin mir nun zu 100% sicher, dass es am DMA liegt.
SAMC21 (Cortex-M0+)

Im Anhang mal mein SPI Modul inkl. DMA Init.

1)
Register 1 wird mit 0x12 und 0x34 beschrieben.
Register 2 wird mit 0x56 und 0x78 beschrieben.

TX Buffer:

01 00 12 34 02 00 56 67

Jetzt wird es merkwürdig:

2)
- Beide Buffer sind 16 Byte groß.
- RX Buffer wird mit 0xAA initialisert um zu erkennen ob 0x00 gelesen 
wurde (vor jedem Lesevorgang).
- TX & RX DMA Job mit je 8 Byte (Bild 1) wird gestartet.

1. Lesevorgang, RX Buffer:

00 00 00 00 00 00 00 00 aa aa aa aa aa aa aa aa

2. und weitere Lesevorgänge liefern:

12 34 00 00 00 00 00 00 aa aa aa aa aa aa aa aa

Als würden 2 Bytes irgendwo noch in Shift-Registern hängen.

3)
- TX & RX DMA Job mit je 12 Byte (Bild 2) wird gestartet.

1. Lesevorgang, RX Buffer:

00 00 00 00 00 00 00 00 12 34 00 00 aa aa aa aa

2. und weitere Lesevorgänge liefern:

56 67 ff ff ff ff ff 00 12 34 00 00 aa aa aa aa

Weiterhin ist mir aufgefallen, dass man +1 Byte schon mal mehr für RX 
angegeben müsste, da nach dem DMA Init. direkt 1 Byte aus dem DATA Reg. 
gelesen wird.
Ein Dummy-Read nützt hier leider nichts.
Evtl. gibt es hier noch eine andere Möglichkeit?

Hat von euch jmnd eine Idee?
Per Software Datenübertragung funktioniert es wie es soll, der DMA 
bereitet mir echt Kopfschmerzen.

Jetzt wären wir wieder da, dass ich mehr getakt habe als vorgeschrieben, 
da ich sonst an die letzten Bytes nicht rankomme.