PIC16f15244 RFM69 sendet nicht

[Frederic B. (freddyskyline)]

Moin zusammen,

für ein Hochschulprojekt sollen Distanzmessungen an einem Pic an einer 
Stelle erfolgen und mittels RFM69HCW (433 MHz) an einen ESP32 gesendet 
werden, der diese Daten zusammen mit einem Videobild über einen 
Webserver zur Verfügung stellt.

Soweit so gut, funktioniert alles - lediglich der RFM69 bereitet uns 
Kopfschmerzen. SPI ist konfiguriert und das Auslesen von Daten aus 
einzelnen Registern funktioniert ebenfalls. Die vom RFM (slave) an den 
Master gesendeten Daten kommen nur nicht im Buffer des Pic an, die 
Kontrlle mittels Logic analyzer zeigt aber, dass der RFM69 die korrekten 
Daten (Standardwerte; aus Datenblatt entnommen) sendet.

Da wir sowieso von dieser Stelle nur senden wollen, war das aber kein 
Beinbruch. Jetzt ist es aber so, dass der RFM am Pic keinen Mucks macht. 
Es sollen recht simple Daten übermittelt werden ( 1 Byte) im Package 
mode. Dazu wird der RFM zuerst in den Standby Mode gesetzt, anschließend 
wird ins FIFO Register geschrieben und mittels Einstellung auf TXmode 
die Daten abgesendet. Beim Receiver kommt allerdings nicht an und es 
schaut auch so aus, als würde nichts gesendet werden (Spymode auf dem 
Receiver bleibt ebenfalls still).

Die verwendete Konfiguration ist identisch zu einer funktionierenden 
Config eines weiteren ESP32, der zum Testen genutzt wurde. Dort können 
zwischen ESP1 und ESP2 problemlos Daten getauscht werden. Wird ein 
ähnlicher Code auf dem Pic implementiert, bleibt es still.

Vielleicht ist hier ja ein RFM69 Experte, der einmal unseren Code auf 
Fehler prüfen kann.



Fosc am Pic ist 1 MHz, optional auf 32 Mhz verstellbar und getestet. 
Entsprechend läuft der SPI auf 250 kHz.

Selbst nach dem zehnten Wälzen des Datenblattes werde ich nicht 
schlauer. Für hilfreiche Antworten bedanke ich mich schon einmal im 
Voraus.

[Max M. (Gast)]

Der PIC klassiker ist es die pins nicht explizit auf digital in zu 
stellen.
Auch wenn Du den ADC oder sonst was an dem multifunction pin nicht 
benutzt, grätscht der rein und kann die lustigsten Sachen machen.
Teilweise halb funktionieren HW ohne jede logig.
Kann man sich totsuchen.

Hatte das auch mal mit PIC und SPI.
Schau Dir an was auf dem Pin sonst noch liegen könnte und schalte alles 
was diesen Pin betrifft in die richtige Betriebsart.
Alte PIC Krankheit über die fast jeder schon mal gestolpert ist.

[Franko P. (sgssn)]

Jo, wie Max schon geschriebn hat:

siehe Datenblatt Kapitel 16.5 ANSELx - Analog Control
Notfalls:
ANSELB = 0; und alles ist digital

Gruß

[Frederic B. (freddyskyline)]

ANSELB sitzt auf 0.
Verwendet werden hier RB4 als Clock, RB6 MISO, RB7 MOSI und RC7 chip 
select. Dort könnte jetzt noch maximal ein Interrupt on Change 
passieren, der aber definitiv nicht konfiguriert ist. Lediglich der RC0 
wird mit IOC genutzt.

Leider keine Besserung bis jetzt. Das Datenblatt des RFM finde ich auch 
recht schlecht strukturiert. Nirgendwo ist im Klartext geschrieben, wie 
so eine Senderoutine step by step auszusehen hat. Ich vermute dort einen 
Fehler. Wie gesagt: Die Funktion rfm_test() liest aus dem Register 0x10 
und bekommt die erwartete 0x24 zurück. Diese landet nur komischerweise 
nicht im Buffer des PIC. Die Kommunikation an sich läuft also. Nur 
senden will er nicht und mir sind so langsam die Ideen ausgegangen.

[Franko P. (sgssn)]

Was steht in dem SSP1CON2 Register? Ist da RCEN=1 ?

Gruß

[Max M. (Gast)]

Frederic B. schrieb:
> Diese landet nur komischerweise
> nicht im Buffer des PIC

Debugger mit Einzelschritt und bei jedem Schritt die Register ansehen.
Breakpoints setzen, schauen ob er durch die Routinen läuft oder irgendwo 
festhängt.

Schau Dir Miso, Mosi, CLK und SS mit dem Logiganalyser an.
An welcher Flanke wird ausgegeben und an welcher wird gesampelt?
Muss passen.

Schau Dir die PIC Register nochmal genau an.
Musst Du z.B. den Buffer lesen, damit ein Bit rückgesetzt wird, weil er 
sonst kein weiteres Wort empfängt?
Es sind solch kleine Sachen an denen man sich festbeisst.

PIC ist Master, RFM der Slave?

[Franko P. (sgssn)]

ach, Blödsinn, kann den Beitrag nicht löschen. SSp1COn2 ist nur für 
I2C...

[Max M. (Gast)]

Frederic B. schrieb:
> Nur
> senden will er nicht

???
Ich habe Dich so verstanden das der RFM sehr wohl sendet, das auch am 
PIC ankommt, aber bei Dir nicht im SSPxBUF Register ankommt.

Das Bild auf S250 des PIC DB hast Du gesehen?
Es gibt nur ein SSPxBUF für senden UND empfangen.
Nicht das Du Dir selbst den Buffer löscht ...
Der PIC muss was senden um empfangen zu können.

[Frederic B. (freddyskyline)]

@Franko

SSP1CON2bits.RCEN ist 0.

@Max

Da kommen wir zum nächsten Problem, das mich schon das ganze Projekt 
begleitet. Das PICkit4 unterstützt zwar das Schreiben, der Debugging 
Mode funktioniert allerdings nicht mit 16F15244. Debugging ging also nur 
per UART und LED. Mein Prof. saß da auch einige Zeit dran und  kam auch 
nicht zur Lösung (Manchmal liest er hier mit, hallo :)  ). Und danach 
habe ich mir auch keine Hoffnung mehr gemacht, das Debugging zum laufen 
zu kriegen.

Habe mal ein Bild vom Analyzer angehängt. Hier wird das Register 0x10 
adressiert und prompt kommt die Antwort (für die natürlich dummydaten 
gesendet wurden).

Laut Datenblatt des RFM soll ja CPOL=0 und CPHA = 0 sein. Ist so 
eingestellt (wenn ich nicht Irre) und funktioniert, wie ihr ja an der 
Antwort des RFM sehen könnt.

Dass es nur einen Buffer gibt, habe ich gesehen. Nach der Testroutine 
bleibt der Buffer trotzdem leer.

Die Funktion sieht ja wie folgt aus:

 void rfm_test () {  //should return 0x24 on miso
    
    LATCbits.LATC7 = 0;  // pull down chip select 
    SSP1BUF = 0x10;
    while (!SSP1STATbits.BF);
    SSP1BUF = 0x00;
    while (!SSP1STATbits.BF);
    LATCbits.LATC7 = 1;  // pull up chip select

Danach sollten die Daten ja im Buffer liegen. Tun sie aber nicht. Oder 
habe ich hier einen Denkfehler? Aber nichtsdestotrotz brauche ich die 
Empfangen Funktion nicht. Wäre nice2have, aber muss nicht sein für die 
Funktion - höchstens nochmal zum Auslesen der Einstellungsregister wäre 
es ganz gut.

RFM69 ist Slave, PIC ist Master - ja.

[Frederic B. (freddyskyline)]

Max M. schrieb:
> Ich habe Dich so verstanden das der RFM sehr wohl sendet, das auch am
> PIC ankommt, aber bei Dir nicht im SSPxBUF Register ankommt.


Korrekt. Habe mich wohl missverständlich ausgedrückt. Was ich damit 
meine ist, dass der RFM die Daten, die ich ins FIFO schreibe nicht per 
Funk versendet. Es bleibt einfach still.

Also nochmal zusammengefasst: Daten per SPI an RFM schicken --> Läuft. 
RFM per SPI an PIC--> läuft.

 Vom RFM gesendete Daten aus Buffer des PIC holen--> läuft nicht. An RFM 
gesendete Daten, die zu übertragen wären, per Funk losschicken --> läuft 
nicht.

[Franko P. (sgssn)]

Wenn ich nicht mehr weiterkomme, versuch ichs immer mal mit dem MCC von 
MPLAB X. Lass dir doch mal den Code für SPI erzeugen und schau was der 
dir da fabriziert.

Gruß

[neuer PIC Freund (Gast)]

Bitte nochmal in Kapitel 18 schmökern.

Ohne PPSLOCK-Prozedur schreibt es sich schlecht auf RxyPPS.

Gruß

[Franko P. (sgssn)]

Das könnte aber tatsächlich falsch sein:

SSP1DATPPS = 1;

lt datenblatt Kapitel 18.8.1 xxxPPS

müsste da stehen
SSP1DATPPS = 0x0e; (001 PORTB + 110 PORTx Pin 6 (Rx6)

Wie kommst du auf 1?

[Frederic B. (freddyskyline)]

So, hatte die letzten Tage mit Klausuren und einem anderen Projekt viel 
zu tun. Danke für eure Antworten, habe das mal getestet und entsprechend 
korrigiert.

Zitat aus dem Datenblatt:

>The PPSLOCKED bit is clear by default (PPSLOCKED = 0), which allows the PPS 
selectionregisters to be modified without an unlock sequence.


PPS Unlock sequence ist also nicht nötig.
Bei dem SSP1DATPPS war ich mir nicht sicher. Habe entsprechend 
korrigiert.

Trotzdem vermute ich den Fehler nach wie vor irgendwie in der 
Ansteuerung des RFM - nicht im SPI selbst. Dieser funktioniert ja.

Noch jemand eine Idee?

[Frederic B. (freddyskyline)]

@Franko

Der Tipp mit dem SSP1DATPPS hat auf jeden Fall dazu geführt, dass bei 
mir im SPI Buffer die Daten ankommen, die ich erwarte. Das bestätigt 
erneut meine These, dass die Grundlegende Kommunikation funktioniert. 
Wenn ich 0x10 adressiere liegt anschließend, wie erwartet, 0x24 im 
Buffer.

Trotzdem kriege ich den Transmitter nicht ans senden. Habe zwischendurch 
nochmal geprüft, ob es an Masse und Versorgung liegen kann. Dazu habe 
ich auf einem anderen Board (PCB, kein Breadboard - versorgt mittels 
DC-DC Booster und einer 18650 Li-Ion) den Code hochgeladen. Gleiches 
Spiel --> Kein Signal.

Irgendwo im Code, bzw in meiner Konfiguration muss ein Fehler verborgen 
sein. Und ich finde ihn einfach nicht. RIP

[Franko P. (sgssn)]

hast du's hier schon mal versucht?
https://github.com/LowPowerLab/rfM69/
oder hier:
https://codebender.cc/example/RFM69/Node#Node.ino


Gruß

[Frederic B. (freddyskyline)]

Schaue da morgen mal rein, ob ich da was heraus gewinnen kann. Die 
Dinger sind natürlich alle für die Arduino IDE gemacht.

Hab gerade mal mein Konfigurationsarray nach dem übermitteln ausgelesen.
Im Anhang seht ihr die übermittelten Daten (links) und die nachher 
ausgelesenen (rechts bei MISO).

Das deckt sich überhaupt nicht. Teilweise sind dort lauter nullen. Hab 
ich  beim hochladen des Arrays was falsch gemacht? Konnte im Datenblatt 
nichts zu einem Lock der Konfigurationsregister finden...nutzt niemand 
den RFM69 und hat damit Erfahrungswerte?

Hier einmal mein Konfigurationsarray. Hab da sogar schon ein dickes 
Delay reingemacht zwischen den Befehlen.

 
void rfm_config2(void) {
    
    
    static uint8_t CONFIG[][2] =
    {
 
 {0x1 , 0xC },
 {0x2 , 0x0 },
 //{0x3 , 0x1A },  //change bitrate to default
 //{0x4 , 0x0B },   //LSB bitrate
 //{0x5 , 0x00 },     //
 //{0x6 , 0x52 },
 //{0x7 , 0x6C },
 //{0x8 , 0x40 },
 //{0x9 , 0x0 },
 //{0xA , 0x41 },
 //{0xB , 0x0 },
 //{0xC , 0x2 },
 //{0xD , 0x92 },
 //{0xE , 0xF5 },
 //{0xF , 0x20 },
 //{0x10 , 0x24 },
 {0x11 , 0x7F },
 //{0x12 , 0x9 },
 //{0x13 , 0xF },
 //{0x14 , 0x40 },
 //{0x15 , 0xB0 },
 //{0x16 , 0x7B },
 //{0x17 , 0x9B },
 //{0x18 , 0x8 },
 //{0x19 , 0x42 },
 //{0x1A , 0x8A },
 //{0x1B , 0x40 },
 //{0x1C , 0x80 },
 //{0x1D , 0x6 },
 //{0x1E , 0x10 },
 //{0x1F , 0x0 },
 //{0x20 , 0x0 },
 //{0x21 , 0x0 },
 //{0x22 , 0x0 },
 //{0x23 , 0x0 },
 //{0x24 , 0xFF },
 {0x25 , 0x40 },
 {0x26 , 0x47 },
 {0x27 , 0xB0 },
 {0x28 , 0x8 },
 {0x29 , 0xDC },
 {0x2A , 0x0 },
 {0x2B , 0x0 },
 {0x2C , 0x0 },
 {0x2D , 0x3 },
 {0x2E , 0x88 },
 {0x2F , 0x2D }, //sync first byte 45
 {0x30 , 0x64 }, //sync scnd byte100
 {0x31 , 0x0 },
 {0x32 , 0x0 },
 {0x33 , 0x0 },
 {0x34 , 0x0 },
 {0x35 , 0x0 },
 {0x36 , 0x0 },
 {0x37 , 0x90 },// variable length and crc on
 {0x38 , 0x42 },
 {0x39 , 0x0 },
 {0x3A , 0x0 },
 {0x3B , 0x0 },
 {0x3C , 0x8F },
 //{0x3D , 0x10 },
 {0x3E , 0x0 },
 {0x3F , 0x0 },
 {0x40 , 0x0 },
 {0x41 , 0x0 },
 {0x42 , 0x0 },
 {0x43 , 0x0 },
 {0x44 , 0x0 },
 {0x45 , 0x0 },
 {0x46 , 0x0 },
 {0x47 , 0x0 },
 {0x48 , 0x0 },
 {0x49 , 0x0 },
 {0x4A , 0x0 },
 {0x4B , 0x0 },
 {0x4C , 0x0 },
 {0x4D , 0x0 },
 {0x4E , 0x1 },
 {0x4F , 0x0 },
{255, 0}};
    
    for (uint8_t i = 0; i != 255; i++) {
        
    rfm_reg_write(CONFIG[i][0], CONFIG[i][1]);
    __delay_ms(5);
    
    
     }

[Rfm (Gast)]

Ich habe RFM69 in Betrieb die bei voller Sendeleistung nicht senden. Ich 
dachte zuerst, dass es an der einstellbaren Stromüberwachung liegt. Aber 
es passiert auch bei abgeschaltet Stromüberwachung. Ich behelfen mir mit 
mehrfachem Senden mit unterschiedlicher Sendeleistung. Gemessen wurde 
das Ganze mit einem SDR Empfänger, so dass ich sicher sein kann, dass 
wirklich keine HF rauskommt. Ich habe das bis heute nicht verstanden. 
Alles funktioniert einwandfrei, man darf nur nicht volle Pulle senden.

[Frederic B. (freddyskyline)]

Soo, falls jemand vor dem selben Problem steht:

Ich nutze hier das Adafruit RFM69 Breakout board. Das ist das Problem an 
dem ganzen Spaß. Hätte ich vielleicht erwähnen sollen, dann wäre jemand 
darauf gekommen.

Der Reset Pin ist beim Breakout Board per default auf high. Dieser muss 
manuell auf Low gezogen werden. Hab also die ganze Zeit unter Reset 
Bedingungen auf die Register geschrieben. Jetzt frisst er definitiv alle 
Werte.

Nachzulesen ist das ganze hier 
https://learn.adafruit.com/adafruit-rfm69hcw-and-rfm96-rfm95-rfm98-lora-packet-padio-breakouts/pinouts 
.

Senden tut er zwar immer noch nicht, das muss jetzt aber ein Problem in 
der Konfiguration sein. Ich melde mich, sobald ich den Fehler habe :)