The flow you said is correct. AT+CFM=1 is optional and shouldn’t be enable in all end-devices. It will required confirm downlink which is frequently used, will not be healthy for the scalability of the LoRaWAN Network.
The parameters are stored in internal flash of the module. There is no external EEPROM.
If BOOT is high (3.3V) then you reset, you will enter UART bootloader mode of STM32WL. This is chip level bootloader and not RUI3. You need to use STM32CubeProgrammer for this and upload the RUI3 .hex file.
If you are just using RUI3 to upload Arduino sketch, you do not need to pull up the BOOT. Else, your application will not run because you enter STM32WL UART Bootloader.
It looks like a bug. I tried it on my end and seems to be ok.
On your AT commands, it appears that the device suddenly goes from a confirmed uplink to unconfirmed uplink without changing it manually via AT+CFM. Do you have a running custom firmware on your device?
Hi, i am back
Yes,
If package is greater than 22 BYTES,
AT+SEND=2:484848484848484848484848
i got
AT_PARAM_ERROR
+EVT:TX_DONE and the CHIRPSTACK receive …“data”,null}
yes, change to unconfirmed
If package is less or equal than 22 BYTES,
AT+SEND=2:4848484848484848484848
i got
OK
+EVT:SEND_CONFIRMED_OK
and the CHIRPSTACK receive the correct data
Thank you for providing the whole set of AT commands set. It seems this is not just about size but related to payload + mac commands size which appears to be a wrong total uplink packet size. We added some fix related to this on 4.0.6. I will send you in direct message a pre-release 4.0.6 firmware files so you can test.
It is really strange that you will get error on AT+BAND=6. Have you tried other rejoin? Joining probably fails because the region is incorrect. (But this is different issue on what we have about the AT+SEND)
