The LoRa Developer Forum is now in read-only mode and new content will not be added.
Semtech, in its commitment to enhance user experience and streamline content, has successfully integrated the LoRa Developer Portal content into Semtech.com. As a result of this consolidation effort, the LoRa® Developer Portal Forum will be discontinued on May 1st. After this date, you will be automatically redirected to Semtech.com.
For any technical support related to LoRa, please feel free to reach out to our experts here. If you have sales inquiries, please contact us here.

FORUM

[SX1262] Failure to execute command

Semtech Transceivers SX126x family
#1

Hi,

I’m Trying to communicate with Ebyte E22-900M22S, after resetting the module using The NRESET pin I try to GetStatus() the I receive 0x2 for Chip mode (which seems normal) and 0x5 for Command status which means Failure to execute command according to the datasheet.

I also tried issuing different commands (such as RADIO_SET_STANDBY and RADIO_CALIBRATE) to change the state of the chip but after any command the result of GetStatus() is the same.

Could you please explain more about Failure to execute command and what would cause this error?

Thanks

PS: the result of GetStatus() during reset (when NRESET is low) in 0x0 for both Chip mode and Command status

#2

Just for record, I have found that the problem was with VDD being about 2.8V and not exactly 3.3V.
So, as if fixed the problem in feeding the correct voltage to the module it started to act as expected.

#4

I have the same sx1262 error Failure To Execute Command but voltage is fine 3,4V.
SPI registers reads and writes fine. But GetStatus returns Failure To Execute Command.
That appears only on one board TBeamv1.1.
The same init sx1262 driver works fine in another board.

#5

You are not alone. I am working with an SX1262 on an E22-900M30S module and command GetStatus (0xC0) causes the next status to show command processing error.

#6

Can you please share the command sequence you play? I’d like to understand which command has a processing error.

#7

I’ve worked out that GetStatus 0xC0 followed by clocking out 0xAA for the read causes a command processing error. Clocking out 0x00 instead allows the command to succeed.

The command processing error doesn’t clear until setting the buffer addresses to 00 00

1 Like
#8

How do you set the buffer addresses to 00 00? By calling SetBufferBaseAddress?

#9

Yes, exactly that (using command 0x8F and both offsets as 0x00)

#10

I have this problem as well, and after reading the above I have an additional question:
What should be de commandStatus you read, eg. after reset. As far as I can see, among all the defined values [0x2 … 0x6] there is no simple StatusOk value…

I am reading 0x5, but sometimes also reading 0x1 (which is RFU)

#11

FYI : I have been reverse engineering the ST / Seeed Studio demo application ( Seeed-Studio/LoRaWan-E5-Node at qian (github.com))

Although the Radio driver contains a function SUBGRF_GetStatus(), it is NEVER used throughout the whole application. For me this is strange. Maybe the response from the SX126 is not very reliable, or properly documented… I would think that after sending a command, you would check it was properly executed, but the demo SW does not do this. They just issue commands and assume they work.

#12

I have been working on a port of https://github.com/nopnop2002/esp-idf-sx126x for the Heltec ESP32 V3 Devboard and have also hit a problem with the GetStatus implementation.

After putting the SX1262 into RX mode the status remains 0x2a.

In the meantime, I’ve also had a look at various code exa,ples and have failed to find one that uses the GetStatus function. Has anyone had success with the Heltec V3?

#13

Hello,

I’m currently using LoRa Basics Modem stack v3.3.0 and an SX1262. While checking the various read and write SPI commands sent to the SX1262, I noticed that the first few ones (after the reset) were getting 0xAA as status. The second A means Failure to execute the command. All following commands get 0xA2. 2, which is 1 when looking at bits 3:1, is not documented.

For the Failure to execute the command, as the target board has a TCXO, I thought that perhaps I had to initialize it right after the reset. But this did not change anything: the first few commands still get 0xAA as status.

About the 2 value: is there an error in the SX126x datasheet (section 13.5.1)? Or could it be that I don’t understand how to read the value?

Thanks,
Pascal