Nabend, ich habe hier einen RN4871 auf einem MikroE Clickboard: http://ww1.microchip.com/downloads/en/DeviceDoc/50002489A.pdf https://shop.mikroe.com/rn4871-click Ich versuche seit einer guten Weile dem kleinen eine Antwort zu entlocken. Auf meine Aufforderung, in den Befehlsmodus zu wechseln ($$$+CR) kommt keine Antwort. Auf dem Board existiert auch eine STATUS-LED. Laut Datenblatt hat der Ausgang folgende Funktion: >LED0: Provides indication whether the module is in ON/OFF mode Bezüglich einem "ON/OFF" Mode lässt sich nichts finden, aber es gibt einen Sleep Mode. Um aus dem wieder aufzuwachen, muss "UART RX Indication" auf Masse gezogen werden. > Use this pin to enable communication with the UART when the module is in LowPower mode. When not in Low-Power mode, the module runs on a 16 MHz clock. If Low-Power mode is enabled on the module by using command SO,1, the module runs on a 32 kHz clock thus reducing power consumption. However, in Low-Power mode, the host MCU cannot communicate with the module via the UART since the UART is not operational. If the user intends to provide data or commands via UART in the Low-Power mode, then the UART RX INDICATION pin must be pulled low and the user needs to wait for at least five milliseconds before sending the data. Pulling the UART RX INDICATION pin low allows the module to operate the 16MHz clock and to enable UART. Allerdings hilft es auch nicht, den Pin auf Masse zu ziehen. Das die Daten beim Modul ankommen, habe ich mit dem Oszi geprüft (direkt am Modul). Mir gehen die Ideen aus, kann jemand helfen? Und ja, ich sende mit 115200 Bd, ohne Parität aber mit einem Stoppbit.
Das hast du mal probiert? https://libstock.mikroe.com/projects/view/2067/rn4871-click Welches MikroE Devboard nutzt du denn? Welchen Compiler?
Es geht bisher nur darum, das Ding an einem UART vom PC zum laufen zu bringen. Also über eine Terminalsoftware. Die LIB habe ich mir jetzt mal angesehen (nachdem ich mir MikroE Software zum Entpacken von deren Format herunterladen musste). Leider macht die LIB aber auch nichts anderes als '$$$' zu schreiben.
1 | void RN4xxx_initialize(T_RN4xxx_Write fpWrite, char *pAddr, uint8_t btType) |
2 | {
|
3 | |
4 | fpWriteUART = fpWrite; |
5 | halWrite("$$$"); |
6 | Delay_ms(100); |
7 | halWrite("$$$\r"); |
8 | Delay_ms(1000); |
9 | |
10 | halWrite("SF,1\r"); |
11 | Delay_ms(2000); |
12 | |
13 | |
14 | halWrite("$$$"); |
15 | Delay_ms(100); |
16 | halWrite("$$$\r"); |
17 | Delay_ms(1000); |
18 | [...]
|
19 | }
|
20 | |
21 | static void halWrite(uint8_t *input) |
22 | {
|
23 | uint8_t *ptr = input; |
24 | |
25 | while( *ptr != 0 ) |
26 | fpWriteUART( *ptr++ ); |
27 | }
|
Beitrag #5116377 wurde von einem Moderator gelöscht.
Microchip schreibt im Datenblatt vor, dass ein 10µF Keramikondensator ("Low ESR") an die Betriebsspannung des Moduls soll. Auf dem MikroE-Clickboard ist gar *keine* Abblockung vorhanden. In meinem Testaufbau, kamen die 3,3V über 1m (2m hin und zurück) Bananenleitung vom Labornetzteil. Lustigerweise ist im Stromlaufplan des Moduls eine Kapazität eingezeichnet. Bestückt ist sie nicht, nein es gibt nicht mal einen unbestückten dafür vorgesehenen Footprint. Ich kann mir allerdings schwer vorstellen, dass ich der erste bin, bei dem es nicht funktioniert. Das hätte doch früher auffallen müssen. Wer neugierig ist, kann ja mal auf dem Bild des Boardes nach "C2" suchen. https://download.mikroe.com/documents/add-on-boards/click/rn4871/rn4871-click-schematic-v100.pdf https://shop.mikroe.com/rn4871-click
Übrigens verfügt der große Bruder des RN4871, der RN4870 über den Abblockkondensator. (Auf dem Bild ist er vorhanden und laut Stromlaufplan beträgt sein Wert 10µF). https://download.mikroe.com/documents/add-on-boards/click/rn4870/rn4870-click-schematic-v100.pdf https://shop.mikroe.com/rn4870-click
Danish B. schrieb: > Es geht bisher nur darum, das Ding an einem UART vom PC zum laufen zu > bringen. > Also über eine Terminalsoftware. Dann hänge den doch einfach mal an ein Terminal. Ich habe hier so ein microchip PICtail Board mit dem RN4871. Damit war der ratz-fatz mit Terminal angesprochen. Geht problemlos. BTW: ich dachte beim $$$ ist KEIN >CR< nötig??? Baudrate ok? rgds
Der hängt bisher über einem FTDI 232R an meinem Rechner und gibt keine Antwort aus. Baudrate muss OK sein, da mein Oszi mitplottet, dekodiert und dabei keine Probleme bekommt. Ich gehe derzeit davon aus, dass das Problem an der vollständig fehlenden Abblockung liegt. Ist die USB-Buchse auf dem Pictail vorhanden? Wenn ja, dann wahrscheinlich auf der Unterseite (oder braucht man noch ein Explorer16 Board [o.ä.] ?).
Danish Belal schrieb: > Ist die USB-Buchse auf dem Pictail vorhanden? Wenn ja, dann > wahrscheinlich auf der Unterseite (oder braucht man noch ein Explorer16 > Board [o.ä.] ?). Das Pictail hat einen Seriell-USB Konverter mit drauf und latürnich dann auch die USB-Buchse :) Wir haben das Modul auch schon in einer Applikation in Entwicklung, dort ist bisher zur Abblockung nur ein 4u7 drinnen, geht auch problemlos. Ich vermute mal dass da was anderes hängt. Wie hast Du Pin P20 beschalten? Im Übrigen: Doku mit Schaltplan: http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=RN-4871-PICTAIL rgds
Danish Belal schrieb: > (oder braucht man noch ein Explorer16 > Board [o.ä.] ?). Wenn du nur direkt vom PC auf das Modul willst benötigts Du nix zusätzlich. rgds
Danke für die Antworten. Pin 2_0 ist auf dem Clickboard an einen Schalter geführt, um zwischen Applikations und DFU-Modus zu wechseln. Dieser war natürlich so eingestellt, dass 'High' (3,3V) anliegen. LOW habe ich aber auch mal probiert. Ich habe es einmal geschafft, vom Modul den String "%REBOOT% (o.ä.) zu empfangen. Mehr nicht. Der von Microchip empfohlene 10µF / 6,3V MLCC hat bei ~3V ja nur noch ca 50% der Kapazität. Wenn Ihr einen 4,7µF MLCC mit höherer Spannungsfestigkeit wählt, ist das vom Soll gar nicht so weit weg, wie man meinen könnte.
Danish B. schrieb: > Und ja, ich sende mit 115200 Bd, ohne Parität aber mit einem Stoppbit. Hier mal etwas variiert? Die Schuld auf den Abblockkondensator zu schieben halte ich für wenig zielführend, da sollten dann wenigstens viel mehr sporadische Antworten drin sein.
Variiert habe ich nicht, aber das Startbit (fallende Flanke) muss er ja unabhängig von der eingestellten Baudrate erkennen können. Im Fehlerfall gibt er ja eine Meldung aus. Ob er dies auch bei einem 'Framing Error' tut, weiß ich nicht. Ich habe mittlerweile mal die "richtige" Baudrate 115942 Bd (laut Datenblatt) ausprobiert. Es ergibt genau das gleiche --> nichts.
Danish B. schrieb: > Ich habe mittlerweile mal die "richtige" Baudrate 115942 Bd (laut > Datenblatt) ausprobiert. Es ergibt genau das gleiche --> nichts. Ich halte - wenn die Baudrate tatächlich auf 115kBd steht - weder die geringe Abweichung der Baudrate noch den Kondensator für das Problem. Richtiger COM-Port auf dem PC? Du sagts Du hast ein Scope dran? Mal RX UND TX aunehmen um zu sehen dass das Modul antwortet. Normalerweise ist die Verbidnungsaufnahme einfach. rgds
Danish B. schrieb: > Ich habe mittlerweile mal die "richtige" Baudrate 115942 Bd (laut > Datenblatt) ausprobiert. Es ergibt genau das gleiche --> nichts. Phasenlage der RX/TX richtig - also nicht invertiert? rgds
> Pin 2_0 ist auf dem Clickboard an einen Schalter geführt, um zwischen > Applikations und DFU-Modus zu wechseln. Dieser war natürlich so > eingestellt, dass 'High' (3,3V) anliegen. LOW habe ich aber auch mal > probiert. Hast Du nach nach dem Umschalten einen Reset des Moduls gemacht?
6a66 schrieb: > Ich halte - wenn die Baudrate tatächlich auf 115kBd steht - weder die > geringe Abweichung der Baudrate noch den Kondensator für das Problem. > Richtiger COM-Port auf dem PC? Du sagts Du hast ein Scope dran? Mal RX > UND TX aunehmen um zu sehen dass das Modul antwortet. Normalerweise ist > die Verbidnungsaufnahme einfach. Es gibt bei mir nur einen (sinnvollen) COM-Port. Bei mir (Linux) ist das hier /dev/ttyUSB0. Da ich das Ankommen der Daten mit der RS232 Dekodierfunktion des OSzis bestätigt habe, kann ich diesen Fehler ausschließen. 6a66 schrieb: > Phasenlage der RX/TX richtig - also nicht invertiert? > rgds Habe ich direkt nicht geprüft, aber das Modul hat einmal (!) beim Start mit %REBOOT% geantwortet. Kann ich nachher nochmal prüfen, habe gerade keine Zeit. Robert schrieb: > Hast Du nach nach dem Umschalten einen Reset des Moduls gemacht? Ja klar, der Anschluss wird lt. Datenblatt nur nach einem Reset ausgewertet. In meinem Fall habe ich aber nicht resettet, sondern einfach die Betriebsspannung aus- und eingeschaltet. (Reset Pin ist nicht belegt, bzw. wird vom Clickboard verzögert auf High gezogen; RC-Glied). Vielen Dank für die vielen Ideen.
Danish B. schrieb: > In meinem Fall habe ich aber nicht resettet, sondern einfach die > Betriebsspannung aus- und eingeschaltet. (Reset Pin ist nicht belegt, > bzw. wird vom Clickboard verzögert auf High gezogen; RC-Glied). Schau mal auf die Seite 20. Das Modul müsste identisch sein, nur anderer Name. http://ww1.microchip.com/downloads/en/DeviceDoc/60001372F.pdf rgds
Erscheint das Modul im Scanner von BT-Geräten? Beim Koppeln gibt das Modul doch auch eine automatische Meldung auf UART aus, was ist mit der? Ansonsten tippe ich hier auf einen Verdrahtungsfehler, wenn nicht (inzwischen) das ganze Modul defekt ist.
Hallo Läuft das Modul inzwischen? Habe auch Probleme mit den RN4871. Bei den Modulen gibt es immer wieder Reset Probleme, die dazu führen können, dass das Modul sich völlig verriegelt. Dann hilft nur noch tauschen. Der Reset muss GENAU dem Datenblatt entsprechen. Bin allerdings bei den Teilen auch am verzweifeln.
Bernd schrieb: > Habe auch Probleme mit den RN4871. Schildere es doch mal im Microchip-Forum. Meine Module laufen hervorragend. Anfangs gabs mal ein Problem mit spontanen Disconnects. Dann stellte sich heraus, es war ein zu nah positionierter zweiter BT Stick :)
Bernd schrieb: > Hallo > > Läuft das Modul inzwischen? Ja, seitdem ich das Modul auf der eigenen Leiterplatte nutze funktioniert es einwandfrei. Wie hast du das Modul beschaltet? Es gibt im Datenblatt zwei 'Beschaltungsvarianten' die sich gegenseitig widersprechen. Ansonsten käme mir bei ungewollten Resets als erstes die Stromversorgung in den Kopf. Wie hast du den Reset-Pin beschaltet?
Danish B. schrieb: > Bernd schrieb: >> Hallo >> >> Läuft das Modul inzwischen? > > Ja, seitdem ich das Modul auf der eigenen Leiterplatte nutze > funktioniert es einwandfrei. > > Wie hast du das Modul beschaltet? Es gibt im Datenblatt zwei > 'Beschaltungsvarianten' die sich gegenseitig widersprechen. Ansonsten > käme mir bei ungewollten Resets als erstes die Stromversorgung in den > Kopf. > > Wie hast du den Reset-Pin beschaltet? Hallo Danish, ich habe mit meinem RN4871 ein vergleichbares Problem. Ich bekomme am Anfang "%Reboot%" und dann nichts mehr. Baudrate passt und den einzigen Befehl, den ich verschicke ist "$$$" und der kommt auch an. Reset liegt mit 4,7k auf 3,3V und mit 1 uF gegen Masse. GND auf GND Pin 16 (Mode) auf High und alles andere unbeschaltet. Habt ihr eine Idee? Wie sieht dein Schaltplan aus? Vielen Dank!
Hast du den Chip auf einem Eval Board oder bist du bereits bei einer eigenen Leiterplatte? Kommt "%Reboot%" immer oder nur jedes x-te mal? -- Was mir zum '$$$' als mögliche Ursache noch einfällt wäre die Zeilenterminierung. Da ist der RN4871 sehr streng. Beim Umschalten in den Befehlsmodus darf nach dem '$$$' keine Zeilenterminierung kommen. Daraufhin müssen alle Befehle mit einem CR abgeschlossen werden. Laut DaBla muss glaube ich sogar vor dem '$$$' einmal ein einzelnes Dollarzeichen gesendet und dann 100ms vor dem '$$$' gewartet werden (falls ich mich richtig erinnere).
Danish B. schrieb: > Hast du den Chip auf einem Eval Board oder bist du bereits bei > einer > eigenen Leiterplatte? > > Kommt "%Reboot%" immer oder nur jedes x-te mal? > > -- > > Was mir zum '$$$' als mögliche Ursache noch einfällt wäre die > Zeilenterminierung. Da ist der RN4871 sehr streng. > > Beim Umschalten in den Befehlsmodus darf nach dem '$$$' keine > Zeilenterminierung kommen. > Daraufhin müssen alle Befehle mit einem CR abgeschlossen werden. > > Laut DaBla muss glaube ich sogar vor dem '$$$' einmal ein einzelnes > Dollarzeichen gesendet und dann 100ms vor dem '$$$' gewartet werden > (falls ich mich richtig erinnere). Vielen Dank Danish! Ich hatte zwei Probleme. Ich musste nach dem Reboot länger warten, bis ich mein "$$$" verschicke. Jetzt sind es, willkürlich gewählt, zwei Sekunden (Geht sicher auch weniger, einfach mal testen). Anschließend musste ich die weiteren Befehle, wie von dir beschrieben, mit CR beenden. Jetzt funktioniert es. Danke. :-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.