-
Notifications
You must be signed in to change notification settings - Fork 395
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
Comments
Pinging @jerabaul29, @apferscher, @sievericcardo. |
Please try the following:
Not sure it will solve your problems, but having a 'NC' as first as not the right way. |
@larswd I was able to replicate the issue with a standalone SX126x (so this is not specific top STM32WL). In actuality, calling I any case, calling 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. |
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 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. |
@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 ( 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:
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 |
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! |
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[] = 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. |
If needed, I can create a new ticket for this but thought it may be related to this existing item. |
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). |
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"? |
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! |
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
To Reproduce
Sketch that is causing the module fail
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):
The text was updated successfully, but these errors were encountered: