LLCC68 not working with -707

[steven52880]

Hi. I tried my lora module but it can't work. This is my first time using a Lora mudule, so I don't know much about it. The program seems stopped at "radio.begin()". I have read the status codes page on wiki but can not find resolution.

Additional info:

• MCU: ESP8266
• Wireless module type: LLCC68(Ra-01SC)
• Arduino IDE version: 1.8.10
• Library version: 4.5.0

Sketch that is causing the module fail I am using the example"SX126x_PingPong" and change the pin setting.

#include <RadioLib.h>

// uncomment the following only on one
// of the nodes to initiate the pings
//#define INITIATING_NODE

// SX1262 has the following connections:
// NSS pin:   10
// DIO1 pin:  2
// NRST pin:  3
// BUSY pin:  9
LLCC68 radio = new Module(15, 4, 2, 5);

// or using RadioShield
// https://github.com/jgromes/RadioShield
//SX1262 radio = RadioShield.ModuleA;

Hardware setup

LLCC68  NodeMCU 8266

3V3 3V3 3V3
GND GND GND

NSS D8  GPIO15(HCS)
MOSI    D7  GPIO13(HMOSI)
MISO    D6  GPIO12(HMISO)
SCK D5  GPIO14(HSCLK)

BUSY    D1  GPIO5
DIO1    D2  GPIO4
RST D4  GPIO2

Debug mode output

--------------- CUT HERE FOR EXCEPTION DECODER ---------------

Soft WDT reset

>>>stack>>>

ctx: cont
sp: 3ffffdd0 end: 3fffffc0 offset: 01a0
3fffff70:  3ffee330 0000000a 3ffee4b0 402010f9  
3fffff80:  0000000a 00000008 3fcccccd 00000000  
3fffff90:  feefeffe feefeffe feefeffe 3ffee518  
3fffffa0:  3fffdad0 00000000 3ffee4d8 40204aa0  
3fffffb0:  feefeffe feefeffe 3ffe84e4 40100ff9  
<<<stack<<<

--------------- CUT HERE FOR EXCEPTION DECODER ---------------

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3584, room 16 
tail 0
chksum 0xb0
csum 0xb0
v2843a5ac
~ld
[SX1262] Initializing ... M SX126x
CMD 80  
DATW    0   A2  

CMD 80  
DATW    0   A2  

CMD 8F  
DATW    0   A2  0   A2  

CMD 8A  
DATW    1   A2  

CMD 93  
DATW    20  A2  

CMD 88  
DATW    3   A2  16  A2  A   A2  0   A2  0   A2  0   A2  0   A2  

CMD 2   
DATW    3   A2  FF  A2  

CMD 8   
DATW    0   A2  0   A2  0   A2  0   A2  0   A2  0   A2  0   A2  0   A2  

CMD 89  
DATW    7F  A2  

CMD 80  
DATW    0   A2  

CMD 17  
DATR    0   A2  0   0   0   0   

CMD 97  
DATW    0   A2  0   A2  1   A2  40  A2  

CMD 11  
DATR    0   A2  0   1   

Symbol length: 4.10 ms
CMD 8B  
DATW    9   A2  4   A2  3   A2  0   A2  

CMD 11  
DATR    0   A2  0   1   

Symbol length: 4.10 ms
CMD 8B  
DATW    9   A2  4   A2  3   A2  0   A2  

CMD 11  
DATR    0   A2  0   1   

Symbol length: 4.10 ms
CMD 8B  
DATW    9   A2  4   A2  3   A2  0   A2  

CMD 11  
DATR    0   A2  0   1   

CMD D   7   40  
DATW    14  A2  24  A2  

CMD 11  
DATR    0   A2  0   1   

CMD 1D  7   36  
DATR    0   A2  0   D   

CMD D   7   36  
DATW    9   A2  

CMD 8C  
DATW    0   A2  8   A2  0   A2  FF  A2  1   A2  0   A2  

CMD D   8   E7  
DATW    18  A2  

CMD 9D  
DATW    1   A2  

CMD 96  
DATW    1   A2  

CMD 98  
DATW    6B  A2  6F  A2  

CMD 86  
DATW    1B  AA  20  0   0   0   0   0   

failed, code -707

[jgromes]

From the debug output, it looks like it's failing at the frequency calibration stage. That usually suggest incorrect crystal type, TCXO is selected by default.

From the schematic I found for Ra-01SC it looks like it uses XTAL instead. Could you try to specify XTAL usage instead of TCXO, i.e.:

begin(434.0, 125.0, 9, 7, SX126X_SYNC_WORD_PRIVATE, 10, 8, 0);

instead of the default

begin(434.0, 125.0, 9, 7, SX126X_SYNC_WORD_PRIVATE, 10, 8, 1.6);

[steven52880]

:) Thanks for your quickly reply. I replaced my code.

  // initialize SX1262 with default settings
  Serial.print(F("[SX1262] Initializing ... "));
  int state = radio.begin(434.0, 125.0, 9, 7, SX126X_SYNC_WORD_PRIVATE, 10, 8, 0);

But it crashd. It says

ISR not in IRAM!
User exception (panic/abort/assert)

I read another issue and add ICACHE_RAM_ATTR before void setFlag(void) and it seems to work well now.

I will try something later.

[jgromes]

void setFlag(void) is an interrupt service routine, so on ESP32 and ESP8266 it has to executed from RAM, that's why the attribute is needed.

I'm going to close this now since it seems the original issue was resolved.