Hi Gemeinde,
ich habe einen SI4355 mit Attiny1614 über SPI verbunden. Nach dem
Datenblatt habe ich es so verbunden, dass nur SPI (MOSI, MISO, SCK, CS),
SDN und NIRQ verbunden ist.
Die Funktion vom Attiny (20Mhz) für SPI
Danach habe ich Register 0x44 abgefragt, es kommt 0xFF - passt :)
Danach habe ich Register 0x57 abgefragt, es kommt 0xFF ?!
...
Es kommt immer und überall 0xFF, egal was ich sende oder empfange?!
Was könnte ich falsch machen, ich suche mich dort seit 1 Woche zu tode,
ich bin absolut ratlos und dankbar um jede Hilfe
Markus M. schrieb:> Danach habe ich Register 0x44 abgefragt, es kommt 0xFF - passt :)> Danach habe ich Register 0x57 abgefragt, es kommt 0xFF ?!
Tja, das wär' nun der interessante Teil ... fehlt aber. Insbesondere die
Behandlung von CS ist nirgends zu sehen.
A. B. schrieb:> Markus M. schrieb:>> Danach habe ich Register 0x44 abgefragt, es kommt 0xFF - passt :)>> Danach habe ich Register 0x57 abgefragt, es kommt 0xFF ?!>> Tja, das wär' nun der interessante Teil ... fehlt aber. Insbesondere die> Behandlung von CS ist nirgends zu sehen.
So wird ein Lesebefehl gemacht, ich habe testweise jetzt einfach nur
eine Leseanfrage an 0x57 gemacht (RSSI), aber ist eigentlich egal was
ich mache, SDO bleibt High.
1
uint8_tdata=0;
2
while(1)
3
{
4
*si4x55sys.portSEL&=~(1<<si4x55sys.pinSEL);
5
SPI_MasterTransceiveByte(0x57);
6
data=SPI_MasterTransceiveByte(0x00);
7
*si4x55sys.portSEL|=(1<<si4x55sys.pinSEL);
8
9
usart_itoa(data);
10
usart_putc(10);
11
}
Auf dem Oscar sehe ich korrektes Schalten von SHD, CS und ich erkenne
auch Daten und Takt (SCK und MOSI). MISO (verbunden mit SDO vom SI4355)
hat einen dauerhaften High-Pegel ohne jegliche Änderung?!
- GND durchverbunden, VDD stabil?
- Der 30 MHz Quarz vom Si4355 schwingt auch?
- SPI SCLK polarity und phase stimmen?
- Überprüfe mal das Timing (-> 5. Controller Interface) auf dem SPI Bus
mit dem Oszilloskop.
Insbesondere SCLK <= 10 MHz, t_ss >= 20ns, t_sh >= 50ns und t_sw >= 80ns
(zwischen 2 Übertragungen).
- Was liefert command 0x01 (PART_INFO) und 0x33 (REQUEST_DEVICE_STATE)?
Evtl. liegts auch hieran:
"5.2.1. Shutdown State
The shutdown state is the lowest current consumption state of the device
and is entered by driving SDN (Pin 2) high. In this state, all register
contents are lost and there is no SPI access. To exit this mode, drive
SDN low. The device will then initiate a power on reset (POR) along with
internal calibrations. Once this POR period is complete, the POWER_UP
command is required to initialize the radio and the configuration can
then be loaded into the device."
Joe F. schrieb:> - GND durchverbunden, VDD stabil?
ja, hängt am USB + korrekter LOW ESR Kerkos am Chip
> - Der 30 MHz Quarz vom Si4355 schwingt auch?
ja
> - SPI SCLK polarity und phase stimmen?
Ich hoffe es, aktuell habe ich SPI_MODE_3, wirklich was gefunden habe
ich nicht
> - Überprüfe mal das Timing (-> 5. Controller Interface) auf dem SPI Bus> mit dem Oszilloskop.> Insbesondere SCLK <= 10 MHz, t_ss >= 20ns, t_sh >= 50ns und t_sw >= 80ns> (zwischen 2 Übertragungen).
Das sollte passen, ich takte aktuell mit 160khz, für das testen
einfacher
> - Was liefert command 0x01 (PART_INFO) und 0x33 (REQUEST_DEVICE_STATE)?
0xFF
> Evtl. liegts auch hieran:>> "5.2.1. Shutdown State> The shutdown state is the lowest current consumption state of the device> and is entered by driving SDN (Pin 2) high. In this state, all register> contents are lost and there is no SPI access. To exit this mode, drive> SDN low. The device will then initiate a power on reset (POR) along with> internal calibrations. Once this POR period is complete, the POWER_UP> command is required to initialize the radio and the configuration can> then be loaded into the device."
Habe ich getestet, so müsste das ja korrekt sein, oder? Ist auch alles
mager beschrieben:
Vll. könnte es wirklich der Quarz sein?! Wie messe ich das, mit meinem
Osci ist da 0 Bewegung, kleinste stufe die geht sind 50mV mit 0,25uS.
Angeschlossen ist der an Pin 17,18. Keine Caps gegen Masse als Last wie
bei den Megas üblich. Ist ja auf Seite 10 auch so abgebildet. 30Mhz
Quarz an sich ist es. Ich habe jetzt schon mal einen 20 Mhz den ich hier
liegen habe angelötet, auch keine Bewegung.
Das SPI Diagramm im Datenblatt sieht mir eher nach CPOL=0 und CPHA=0
aus, also SPI mode 0 statt 3.
Um es testweise zusätzlich zu entspannen würde ich nach CS=0 und vor
CS=1 man noch kleine Delays reinsetzen.
Vermutung: Quarz wird evtl. zum Stromsparen abgeschaltet.
Joe F. schrieb:> Und: was ist mit dem SDN pin? Ist der low?
Ja, der ist low. Da mache ich am Anfang nur diesen High/Low Pegelwechsel
einmal für den Reset. Zeiten sind auch beachtet.
Joe F. schrieb:> Das SPI Diagramm im Datenblatt sieht mir eher nach CPOL=0 und CPHA=0> aus, also SPI mode 0 statt 3.> Um es testweise zusätzlich zu entspannen würde ich nach CS=0 und vor> CS=1 man noch kleine Delays reinsetzen.>> Vermutung: Quarz wird evtl. zum Stromsparen abgeschaltet.
Ich drehe durch mit dem Teil. HILFE!
Ich habe jetzt nochmal SPI Modes alle getestet, Delay von 500us zwischen
SEL low und daten senden, ich habe sogar den Power-Up Befehl gesendet
wie ich das über 25 Ecken gefunden habe was da noch hinter steckt. Es
hilft alles nicht?!
Erst SDN Vorgang. Mit vieeel Wartezeit. Dann selektieren, mit Wartezeit.
Dann Power-Up Befehl senden mit Normal Startup und 30 Mhz Quarz. Und
dann in data[9] speichern, ob reade (Wert = 0xFF => ready).
Dann Part Info lesen -> wieder alles 0xFF.
Hallo Markus,
was dir fehlt ist Sichtbarkeit der Vorgänge, in deinem Fall wären das
auf jeden Fall mal ein Logic-Analyser. Da tut es auch schon der
billigste für 5 Euro.
Dann kannst du die Datenleitungen anklemmen. Dann schickst du ein Byte
in schaust mal, ob dieses von deinem Controller überhaupt gesendet wird.
Danach schickst du dein erstes Byte an deinen SPI-Slave. Bei deinem
kannst du an GPIO1-CTS sogar sehen, ob es angekommen ist. Danach
versuchst du die Chip-ID oder ein Status-Byte mal zu lesen. Wenn du
soweit bist, dann erst fängst du mit der eigentlichen Kommunikation an.
Das ist ein bisschen so wie ein Pferd aufzäumen.
Zum thema Cpol. Im Datenblatt steht: The rising edges of SC
LK should be aligned with the center of the SDI dat
Hast du das beachtet:
"To ensure the radio is ready to receive the next command, the host MCU
must pull down the NSEL pin to monitor the status of CTS over the SPI
port. The 0x44 command ID has to be sent, and eight clock pulses have to
be generated, on the SCLK pin. During the additional eight clock cycles,
the radio clocks out the CTS as a byte on the SDO pin. When completed,
the NSEL should be pulled back to high. If the CTS byte is 0xFF, then
the radio processed the last command successfully and is ready to
receive the next command; in any other case, the CTS read procedure has
to be repeated from the beginning as long as the CTS byte is not 0xFF."
Kann es sein, dass 0xFF einfach das CTS-Byte ist? Einfach mal weiter
Bytes rauslesen und schauen was kommt.
Paul schrieb:> Hast du das beachtet:>> "To ensure the radio is ready to receive the next command, the host MCU> must pull down the NSEL pin to monitor the status of CTS over the SPI> port. The 0x44 command ID has to be sent, and eight clock pulses have to> be generated, on the SCLK pin. During the additional eight clock cycles,> the radio clocks out the CTS as a byte on the SDO pin. When completed,> the NSEL should be pulled back to high. If the CTS byte is 0xFF, then> the radio processed the last command successfully and is ready to> receive the next command; in any other case, the CTS read procedure has> to be repeated from the beginning as long as the CTS byte is not 0xFF.">> Kann es sein, dass 0xFF einfach das CTS-Byte ist? Einfach mal weiter> Bytes rauslesen und schauen was kommt.
Das hatte ich auch erst gedacht, aber bspw. bei 0x01 (Part info) bekomme
ich 8 Bytes FF und wenn ich mir SDO anschaue, dort ist dauerhaft High
Pegel.
Logic Analyser habe ich schon gemacht, der ATtiny sendet die Daten
korrekt.
Was mich etwas verwirrt, SPI ist ja quasi ein Schieberegister, die
Aussage vom Datenblatt mit "es müssen weitere Takte erzeugt werden usw"
ist doch so, dass ich dann Dummybytes sende (ich mache 0x00), oder? Weil
ich kann bei SPI ja keinen Takt erzeugen, ohne auch ein Datenbyte zu
senden, richtig? Das sieht etwas komisch aus dort. Andere SPI Chips
hatten das in der Grafik so, dass dort dann stand bspw: Command Dummy
Dummy Dummy, bei den Dummys werden dann Daten vom Chip rausgeschickt.
Beim SI im Datenblatt sieht das ulkig aus, als wenn man nur noch Takt
erzeugen dürfte und nichts senden darf.
Markus M. schrieb:> Beim SI im Datenblatt sieht das ulkig aus, als wenn man nur noch Takt> erzeugen dürfte und nichts senden darf.
Bei SPI kommt die "Antwort" vom Device (MISO) immer um 1 Byte
verschoben, da ja erst dann das Commandbyte auf MOSI komplett übertragen
wurde.
Im Datenblatt ist für die Dummyclocks die MOSI Leitung auf low.
Das hat den Grund - oder günstigen Nebeneffekt - dass CMD 0x00 "NOP"
ist...
Markus M. schrieb:>> Kann es sein, dass 0xFF einfach das CTS-Byte ist? Einfach mal weiter>> Bytes rauslesen und schauen was kommt.>> Das hatte ich auch erst gedacht, aber bspw. bei 0x01 (Part info) bekomme> ich 8 Bytes FF und wenn ich mir SDO anschaue, dort ist dauerhaft High> Pegel.
Ich glaube Paul hat den entscheidenden Hinweis geliefert.
Das 1. Byte auf MISO nach dem CMD Byte ist immer das CTS byte, also
entweder 0x00 (Gerät ist nicht bereit) oder 0xFF (Gerät ist bereit).
Wenn CTS 0xFF ist (was bei dir ja der Fall ist), einfach weiterlesen,
erst das/die dann folgende(n) Byte(s) ist/sind die Antwort vom Device.
Da du immer bereits beim CTS Byte aufhörst zu lesen, bekommst du halt
immer die 0xFF.
Mit dem Oszillator ist es übrigens tatsächlich so, dass der abgeschaltet
ist, bis das Radio aktiviert wird.
Das hier könnte evtl. auch interessant für dich sein:
https://github.com/dvdfreitag/Si4455Radio
Joe F. schrieb:> Markus M. schrieb:>>> Kann es sein, dass 0xFF einfach das CTS-Byte ist? Einfach mal weiter>>> Bytes rauslesen und schauen was kommt.>>>> Das hatte ich auch erst gedacht, aber bspw. bei 0x01 (Part info) bekomme>> ich 8 Bytes FF und wenn ich mir SDO anschaue, dort ist dauerhaft High>> Pegel.>> Ich glaube Paul hat den entscheidenden Hinweis geliefert.> Das 1. Byte auf MISO nach dem CMD Byte ist immer das CTS byte, also> entweder 0x00 (Gerät ist nicht bereit) oder 0xFF (Gerät ist bereit).> Wenn CTS 0xFF ist (was bei dir ja der Fall ist), einfach weiterlesen,> erst das/die dann folgende(n) Byte(s) ist/sind die Antwort vom Device.>> Da du immer bereits beim CTS Byte aufhörst zu lesen, bekommst du halt> immer die 0xFF.>> Mit dem Oszillator ist es übrigens tatsächlich so, dass der abgeschaltet> ist, bis das Radio aktiviert wird.>> Das hier könnte evtl. auch interessant für dich sein:> https://github.com/dvdfreitag/Si4455Radio
Nein leider nicht, das habe ich ja gemacht, ich bekomme nur FF.
PittyJ schrieb:> Ohne Oszi geht da nichts. Nur so kann man sehen, ob etwas beim Slave> ankommt, und ob er etwas zurück schickt.
Habe ich ja gemacht, Master sendet korrekt die Daten raus, Slave bekommt
diese auch (elektrisch). Aber das SDO vom Slave macht keine Bewegung,
das liegt dauerhaft auf 3V
Thread beobachten
Seitenaufteilung abschalten