I use Arduino IDE on MAC M1. I Purchased a few RAK3172S modules for development and
verification. They are flashed and powered using a standard UART/USB connector.

When delivered they all have SDK3.53 on board and I can use AT commands to JOIN the boards.

I install the most-recent RAK3172 SDK 4.0.1 via IDE board manager and flash the original RAK OTAA example but randomizing the Keys. Now I get an error on the devices.

After 5 seconds the JOIN terminated with +EVT:JOIN_FAILED_TX_TIMEOUT while it should terminate
with JOIN_FAILED_RX_TIMEOUT after 10…15 seconds. Also, I don’t see any packets on the LORA
gateway anymore. Hard reset does not have any impact. I also tried to power the device with
an extra battery to eliminate the impact of UART Power supply - no success.

I am out of options and need your help. What causes this error message ?

Welcome to RAK forum @Annemarie ,

With you RAK3172, I suggest to validate the following:

  1. OTAA parameters are same on LNS and device - DEVEUI, APPKEY and APPEUI. Have you tried to regenerate the eui/keys then rejoin again?
  2. Is the band configure correct?
  3. If using US915, did you set the correct channels via AT+MASK=0002?
  4. Is there any changes on the gateway or LNS?
  5. Are the antenna ok on both device and gateway

Hi, thanks for replying.

  1. I use EU868 and I tested the HW with the original firmware on delivery and AT commands and it worked. I see the correct events and the JOIN packet can be seen.
  2. Same hardware, same antenna, same setup, same gateway, only flashing rui3 firmware with OTAA example from your SDK, just changing the Keys to avoid any strange things when joining (lines 21…23 of course example code).
  3. So far I am assuming that I am free to pick any random dev eui, app eui, appkey - no checksum within the key.
  4. Not sure what you mean by “regenerate keys”. I am using app call api.lorawan.appkey.set(node_app_key, 16)), etc. for setting the keys. I call them back to check if the keys are set correctly and they are.
  5. I can add debug printf into the code if this helps, e.g. on SUBGRF_WriteCommand( SUBGHZ_RadioSetCmd_t Command, uint8_t *pBuffer, uint16_t Size ) function

Hi @Annemarie ,

The situation you have is strange since my modules are working ok on latest RUI3 versions 4.0.0 and 4.0.1.

Assuming all requirements are met (gateway, LNS, OTAA eui/key, band, etc), the suggestion left to my mind is to perform full chip erase using STM32CubeProgrammer then upload the .hex firmware using STM32CubeProgrammer as well.

Actually, I did this already and indeed it works (using AT commands). But the moment I load the OTAA example I end up in the same situation. So let’s conclude: (1) it’s not the hardware, because I used different ones and you used it. (2) its not the GW, since there is not even one packet sent out to the GW. (3) Its likely not the code since we both use the LoRaWAN_OTAA example from SDK 4.0.1. What’s missing is the compiled code. Can we exchange the binaries to see the difference? (if you use Arduino IDE plus ymodem for flashing you just need to add a print(zip_file) at line 749 at uploader_ymodem.py to get the full path of the binary. Can you please share your working binary with mine. You can get my binary (4.0.1. with the bug described). You can download my bin file from one-drive Microsoft OneDrive - Access files anywhere. Create docs with free Office Online. (186KB). Thanks again for looking into this. Without your help, this cant be solved.

Hi @Annemarie ,

Exchanging bin files might not work since the eui/keys are embedded on the compiled source code.

If you can regenerate a .bin file with the following OTAA parameters and US915 region. I can try it on my device.

#define OTAA_BAND     (RAK_REGION_US915)
#define OTAA_DEVEUI   {0x70, 0xB3, 0xD5, 0x7E, 0xD0, 0x05, 0x9D, 0x63}
#define OTAA_APPEUI   {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
#define OTAA_APPKEY   {0xBA, 0x83, 0x8A, 0xAF, 0x31, 0xDB, 0x34, 0xFF, 0xEC, 0x95, 0x92, 0x86, 0x00, 0x06, 0xA5, 0x87}

Her we are: Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.. I replaced the 4 lines with yours - same result by the way: 18:34:58.899 → Wait for LoRaWAN join…+EVT:JOIN_FAILED_TX_TIMEOUT

Other issue. I wonder why I get so many compiler warnings of the kind (this is just ONE example)

In file included from /Users/annmarie/Library/Arduino15/packages/rak_rui/hardware/stm32/4.0.1/variants/WisDuo_RAK3272-SiP_Board/pin_define.h:4,
from /Users/annmarie/Library/Arduino15/packages/rak_rui/hardware/stm32/4.0.1/cores/STM32WLE/component/service/nvm/service_nvm.h:18,
from /Users/annmarie/Library/Arduino15/packages/rak_rui/hardware/stm32/4.0.1/variants/WisDuo_RAK3272-SiP_Board/rtc-board.c:37:
/Users/annmarie/Library/Arduino15/packages/rak_rui/hardware/stm32/4.0.1/variants/WisDuo_RAK3272-SiP_Board/variant.h:30: warning: “NUM_ANALOG_INPUTS” redefined
30 | #define NUM_ANALOG_INPUTS (2u)
In file included from /Users/annmarie/Library/Arduino15/packages/rak_rui/hardware/stm32/4.0.1/variants/WisDuo_RAK3272-SiP_Board/pins_arduino.h:25,
from /Users/annmarie/Library/Arduino15/packages/rak_rui/hardware/stm32/4.0.1/variants/WisDuo_RAK3272-SiP_Board/variant.h:15,
from /Users/annmarie/Library/Arduino15/packages/rak_rui/hardware/stm32/4.0.1/variants/WisDuo_RAK3272-SiP_Board/pin_define.h:4,
from /Users/annmarie/Library/Arduino15/packages/rak_rui/hardware/stm32/4.0.1/cores/STM32WLE/component/service/nvm/service_nvm.h:18,
from /Users/annmarie/Library/Arduino15/packages/rak_rui/hardware/stm32/4.0.1/variants/WisDuo_RAK3272-SiP_Board/rtc-board.c:37:
/Users/annmarie/Library/Arduino15/packages/rak_rui/hardware/stm32/4.0.1/variants/WisDuo_RAK3272-SiP_Board/pins_arduino_analog.h:36: note: this is the location of the previous definition
36 | #define NUM_ANALOG_INPUTS 0

Even if there is no hard evidence that something goes wrong its quite unusual not to eliminate this in a released code.

Hi @Annemarie ,

I tried your bin file and used WisToolBox to upload your firmware. I initially used RAK3172 but when I checked the FW version, it was compiled for RAK3172-SiP.

So I uploaded it to RAK3172-SiP and It was able to join and send uplink payload.

Regarding the warnings, I can’t see it on my Arduino compilation by default. Only when I select all warnings.

These are redefinition warnings and doesn’t cause any error in compilation. It is good to remove them by adding header guards on the h files. However, these redefinitions are only related to pin naming on WisBlock (ADC, SPI and I2C pins) so it wont affect any functionality related to LoRa/LoRaWAN.

Thank you for your support. This gave me the final hint. If HW, FW and GW are equal only one option left is the surrounding air and VCC. And indeed, both of my USB/UART devices had a problem with VCC. Thanks for the support and thr work,

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.