Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interrupt Receive for STM32WLx example sketch not working in RadioLib v7 #1272

Closed
larswd opened this issue Oct 14, 2024 · 11 comments
Closed
Labels
bug Something isn't working resolved Issue was resolved (e.g. bug fixed, or feature implemented)

Comments

@larswd
Copy link

larswd commented Oct 14, 2024

Describe the bug
A clear and concise description of what the bug is. When applicable, please include debug mode output using the appropriate debug mode.

The interrupt receive sketch for STM32WLx breaks down after the second call to radio.startReceive(). When compiling and uploading the included sketch to a Seeed Studio Wio E5 mini, the receiver manages to correctly receive and print the first radio message, but subsequent messages becomes jarbled and illeglibible on versions 7 and up. The sketch works as intended on version 6.6.0. If we comment out the radio.startReceive() function call, the script works as intended.

Debug mode output

[STM32WL] Initializing ... RLB_DBG:
RadioLib Info
Version:  "7.0.2.0"
Platform: "Arduino STM32 (official)"
Compiled: "Oct 14 2024" "16:33:02"
RLB_DBG: Found SX126x: RADIOLIB_SX126X_REG_VERSION_STRING:
RLB_DBG: 00000320: 53 58 31 32 36 31 20 54 4b 46 20 31 41 31 30 00  SX1261 TKF 1A10.
RLB_DBG:
RLB_DBG: M      SX126x
[STM32WL] Listening ... 
[STM32WL] Received packet!
[STM32WL] Data:         14:34:54 5993946 1072400 218750 133 288CF2190F000058
[STM32WL] RSSI:         -79.00 dBm
[STM32WL] SNR:          11.50 dB
[STM32WL] Received packet!
�s�"X0���f&�]\x␞�       ��-Ao�C6�Cc��mb��k�`�����E�
[STM32WL] RSSI:         -79.00 dBm
[STM32WL] SNR:          10.50 dB
[STM32WL] Received packet!
�s�"X0���f&�]\x␞�       ��-Ao�C6�Cc��mb��k�`�����E�
[STM32WL] RSSI:         -79.00 dBm
[STM32WL] SNR:          10.50 dB

To Reproduce

Sketch that is causing the module fail

#include <Arduino.h>
#include "RadioLib.h"


// RF swiches for the Wio E5 mini
STM32WLx radio = new STM32WLx_Module();
static const uint32_t rfswitch_pins[] = {RADIOLIB_NC, PA4,  PA5,RADIOLIB_NC,RADIOLIB_NC};
static const Module::RfSwitchMode_t rfswitch_table[] = {
  {STM32WLx::MODE_IDLE,  {LOW,  LOW,  LOW}},
  {STM32WLx::MODE_RX,    {HIGH, HIGH, LOW}},
  {STM32WLx::MODE_TX_HP, {HIGH, LOW,  HIGH}},
  END_OF_MODE_TABLE,
};


int transmissionState = RADIOLIB_ERR_NONE;
int baudrate_serial = 115200;
// flag to indicate that a packet was sent
volatile bool receivedFlag = false;

// this function is called when a complete packet
// is transmitted by the module
// IMPORTANT: this function MUST be 'void' type
//            and MUST NOT have any arguments!
void setFlag(void) {
  // we sent a packet, set the flag
  receivedFlag = true;
}


uint8_t sf = 8;
double freq = 868.2;
double bw = 125;
uint8_t cr = 6;
uint8_t power = 15;

void setup(void)
{
  Serial.begin(115200);
  delay(100);
  radio.setRfSwitchTable(rfswitch_pins, rfswitch_table);
  pinMode(PB5, OUTPUT);
  Serial.println(F("Booted!"));

  Serial.print(F("[STM32WL] Initializing ... "));
  int state = radio.begin(freq, bw, sf, cr, (0x12), power,8, 1.7, false);

  // set the function that will be called
  // when packet transmission is finished
  radio.setDio1Action(setFlag);

  // start transmitting the first packet
  Serial.println(F("[STM32WL] Listening ... "));

  // you can transmit C-string or Arduino string up to
  // 256 characters long
  transmissionState = radio.startReceive();
 
}


void loop() {
  // check if the flag is set
  if(receivedFlag) {
    // reset flag
    receivedFlag = false;

    String str;
    int state = radio.readData(str);


    if (state == RADIOLIB_ERR_NONE) {
      // packet was successfully received
      Serial.println(F("[STM32WL] Received packet!"));

      // print data of the packet
      Serial.print(F("[STM32WL] Data:\t\t"));
      Serial.println(str);

      // print RSSI (Received Signal Strength Indicator)
      Serial.print(F("[STM32WL] RSSI:\t\t"));
      Serial.print(radio.getRSSI());
      Serial.println(F(" dBm"));

      // print SNR (Signal-to-Noise Ratio)
      Serial.print(F("[STM32WL] SNR:\t\t"));
      Serial.print(radio.getSNR());
      Serial.println(F(" dB"));

    } else if (state == RADIOLIB_ERR_CRC_MISMATCH) {
      // packet was received, but is malformed
      Serial.println(F("CRC error!"));

    } else {
      // some other error occurred
      Serial.print(F("failed, code "));
      Serial.println(state);

    }

    // put module back to listen mode
    radio.startReceive();
  }
}

Expected behavior
I expect the sketch to work as a continous radio receiver, as the sketch is intended to do.
Screenshots
If applicable, add screenshots to help explain your problem.

Additional info (please complete):

@larswd
Copy link
Author

larswd commented Oct 14, 2024

Pinging @jerabaul29, @apferscher, @sievericcardo.

@StevenCellist
Copy link
Collaborator

Please try the following:

static const uint32_t rfswitch_pins[] = {PA4, PA5, RADIOLIB_NC, RADIOLIB_NC, RADIOLIB_NC};
static const Module::RfSwitchMode_t rfswitch_table[] = {
  {STM32WLx::MODE_IDLE,  {LOW,  LOW}},
  {STM32WLx::MODE_RX,    {HIGH, LOW}},
  {STM32WLx::MODE_TX_HP, {LOW,  HIGH}},
  END_OF_MODE_TABLE,
};

Not sure it will solve your problems, but having a 'NC' as first as not the right way.

@jgromes
Copy link
Owner

jgromes commented Oct 14, 2024

@larswd I was able to replicate the issue with a standalone SX126x (so this is not specific top STM32WL). In actuality, calling startReceive after readData used to be necessary in older versions of the library (as readData used to put the radio to standby), however, that is no longer necessary (finding the actual commit/PR changing is left as an excercise to the reader ...). It looks like when this was changed, the SX126x examples were update accordingly, however, STM32WLx were not.

I any case, calling startReceive for a second time definitely shouldn't cause reception to break. I tried adding a call to standby to startReceive, and that resolves the issue. I'm thinking that the module for some reason does not handle setting mode to Rx while already in Rx (possibly the FIFO pointers are getting confused and returning garbage data).

I pushed a fix addressing this (and also update to the STM32WL example). Thank you for the detailed report! I would also suggest following @StevenCellist advice and checking the switching pins, it seems like there's some copy/paste error there.

@jgromes jgromes closed this as completed Oct 14, 2024
@jgromes jgromes added bug Something isn't working resolved Issue was resolved (e.g. bug fixed, or feature implemented) labels Oct 14, 2024
@larswd
Copy link
Author

larswd commented Oct 15, 2024

Hi again @jgromes and @StevenCellist, and thank you for the swift response and clarification. I will then proceed without redundant callings to the startReceive()-function. And thank you for the tip regarding the ordering of the rfswitch_pins. Although, I was wondering if I could ask for a slight clarification on what the significance of the pin ordering in the rfswitch_pins variable is? I tried to read through the source code, but I had no luck in figuring it out.

In the standard example, the ordering is {PC3, PC4, PC5, RADIOLIB_NC, RADIOLIB_NC}, and on the Wio E5 mini, PC4 is rechristened PA4, and PC5 has the new name PA5, while the PC3 pin does not exist as far as I can see, hence the start by RADIOLIB_NC. I have checked, and I am able to receive signals with the new configuration {PA4, PA5,RADIOLIB_NC,RADIOLIB_NC,RADIOLIB_NC}. I apologise in advance if this is a lot to ask, or if I have overlooked some really basic detail somewhere.

@jgromes
Copy link
Owner

jgromes commented Oct 15, 2024

@larswd the RF switch mapping is generic - for each entry (=RF switch mode) in the RF switch table, the provided RF switch pins will be set to the states specified by that mode. You can set any combination of any pins for any of the modes, whatever your hardware requires. However, the switch states (LOW/HIGH) are assigned to GPIO pins based on the order in RF switch pin table, so you cannot start with an unconnected pin.

Think of the RF pin array as a "header" for a table, where each row corresponds to a different state of the RF switch. Taking the original example with PC3:

State PC3 PC4 PC5
Idle LOW LOW LOW
Rx HIGH HIGH LOW
Tx LP HIGH HIGH HIGH
Tx HP HIGH LOW HIGH

It follows that if you only have two switching pins, each row of your table can have at most 2 pin states. There's quite a bit written on the RF switch configuration in the docs: https://jgromes.github.io/RadioLib/class_module.html#ac308fa817a5c36c5dc724a0d15cefd4d

@larswd
Copy link
Author

larswd commented Oct 15, 2024

Thanks again for the great explaination, and link to the documentation (How I missed that part of the docs is a bit of a mystery to me, but alas, I did). What is interesting is that I am still able to send and receive messages, but maybe that is more dumb luck than anything else? I will take a look into cleaning up my rfswitch table. Thanks again!

@Dems1984
Copy link

I am having an issue compiling my code using the newest library of 7.1.0. I get the following error when compiling within Arduino IDE:

Compilation error: 'STM32WLx' does not name a type; did you mean 'STM32L0'?

I changed the code to what StevenCellist suggested but still get the same error. It could be from other libraries I updated but this used to work before updating and I think it may be related to this topic and RadioLib. I did try reverting back to 6.4.2 but that didn't fix it. The simplified code I have is the following. The first error stops on STM32WLx radio line:

#include <RadioLib.h> // 6.4.2 https://github.com/jgromes/RadioLib

STM32WLx radio = new STM32WLx_Module(); //error occurs here during compiling.

static const uint32_t rfswitch_pins[] = {PA4, PA5, RADIOLIB_NC, RADIOLIB_NC, RADIOLIB_NC};

//static const uint32_t rfswitch_pins[] =
// {PA4, PA5, RADIOLIB_NC}; // Internal LoRa E5 Mini UART pins to SX126X radio
static const Module::RfSwitchMode_t rfswitch_table[] = {
{STM32WLx::MODE_IDLE, {LOW, LOW}},
{STM32WLx::MODE_RX, {HIGH, LOW}},
{STM32WLx::MODE_TX_HP, {LOW, HIGH}}, // for LoRa-E5 mini
END_OF_MODE_TABLE,
};

I feel like the reference is missing in RadioLib.h but could be totally wrong.

Thank you.

Using the same board, Arduino IDE, RadioLib as larswd posted.

@Dems1984
Copy link

If needed, I can create a new ticket for this but thought it may be related to this existing item.

@StevenCellist
Copy link
Collaborator

It sounds like either you didn't select the correct board (it only works with STM32WL... boards), or an update happened to STM32duino and they changed a compiler flag (but I don't see release notes that would suggest that). Please share your setup (which hardware is used, what selections you've made for compiling, which IDE etc).

@larswd
Copy link
Author

larswd commented Nov 13, 2024

I have gotten this error message before, and it is as StevenCellist say whenever the board has been incorrectly set in Arduino IDE (Sometimes it resets or don't remember between projects. Can you check if you have set the Board as "LoRa Boards" and board part number as "LoRa-E5 mini"?

@Dems1984
Copy link

Thank you for the quick responses! Yes... The board wasn't specified specifically.... LOL.... I had chosen LoRa Boards in Arduino under Tools->Board->STM32 MCU based boards->LoRa boards but the under Tools->Board part number, LoRa E5 mini was not chosen but the top of the list. It may have reset after upgrading Arduino to 2.3.3.

That fixed the one compiling error of " Compilation error: 'STM32WLx' does not name a type; did you mean 'STM32L0' ". Changing the code for the radio switch pins to:

static const uint32_t rfswitch_pins[] = {PA4, PA5, RADIOLIB_NC, RADIOLIB_NC, RADIOLIB_NC};

from

static const uint32_t rfswitch_pins[] = {PA4, PA5, RADIOLIB_NC};

fixed the other error during compiling after the upgrade to 7.1.0.

Last question... just for info....

What was added to RadioLib 7.1.0? It looks like new functionality for the switch pins or is it just standardizing code within RadioLib across all models of boards? I know the E5 mini doesn't seem to have all the pin configurations that other LoRa boards mentioned here have.

Thank you so much for the help! Appreciated!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working resolved Issue was resolved (e.g. bug fixed, or feature implemented)
Projects
None yet
Development

No branches or pull requests

4 participants