Interrupts on DIO1 line every 10ms after JoinRequest
Closed this issue · 1 comments
Hello,
got stuck with some strange problem. After sending JoinRequest (join is accepted by the network server), I observe interrupts on the DIO1 line every 10 milliseconds.
We checked SPI communication - signals look good on an oscilloscope. Poorman's bit-banging implementation gives exactly the same result. The logic analyzer shows that data transmitted on SPI lines match the logs.
Anomaly detected: SPI transmission starts a way late after putting NSS down, still subject to investigation.
EVK: SX1262MB1DAS (also tried SX1262MB1CAS)
MCU: BL706 (RISC-V)
Excerpt from the logs
0.989 [TRACE] bsp_spi.c:89 > SPI out with length:23 data:00dbe804d07ed5b370fd08fd080042e8b43a0dcee6c87b
0.996 [TRACE] bsp_spi.c:89 > SPI out with length:4 data:83000000
1.004 [TRACE] lorawan_display.c:117 > MLME-Request // MLME_JOIN
1.009 [TRACE] lorawan_display.c:132 > STATUS: OK
2.488 [TRACE] bsp_spi.c:89 > SPI out with length:2 data:1200 <<<<< it will repeat every
2.493 [TRACE] bsp_spi.c:109 > SPI in with length:4 data:00010201
2.499 [TRACE] bsp_spi.c:89 > SPI out with length:3 data:020201
2.505 [TRACE] bsp_spi.c:89 > SPI out with length:2 data:8404
2.513 [TRACE] bsp_spi.c:89 > SPI out with length:2 data:c000
2.519 [TRACE] bsp_spi.c:89 > SPI out with length:2 data:1200 << 10ms
It looks like we are hanging in the loop here
#1 0x2301747e in SX126xCheckDeviceReady () at middleware/LoRaMac-node/src/radio/sx126x/sx126x.c:138
#2 0x2301e3f8 in SX126xWriteCommand (command=<optimized out>, buffer=0x4202ad17 "\001\245\245\245\245 \203\270\355H\255\002B\026\035\001#", size=<optimized out>) at LoRaMac-node-port/sx1262-onboard.c:194
#3 0x23017f12 in SX126xSetPacketType (packetType=PACKET_TYPE_LORA) at middleware/LoRaMac-node/src/radio/sx126x/sx126x.c:520
#4 0x23011d16 in RadioSetModem (modem=MODEM_LORA) at middleware/LoRaMac-node/src/radio/sx126x/radio.c:578
#5 0x23012e44 in RadioSetPublicNetwork (enable=true) at middleware/LoRaMac-node/src/radio/sx126x/radio.c:1217
#6 0x2300bae2 in LoRaMacMibSetRequestConfirm (mibSet=0x4202adac) at middleware/LoRaMac-node/src/mac/LoRaMac.c:4510
#7 0x2300039a in LmHandlerInit (handlerCallbacks=0x23063c04 <LmHandlerCallbacks>, handlerParams=0x42020aa8 <LmHandlerParams>) at middleware/LoRaMac-node/src/apps/LoRaMac/common/LmHandler/LmHandler.c:308
Full log:
https://drive.google.com/file/d/1_VCCP30sow-QS1OxxPvKw6PrI2N1edyq/view?usp=share_link
LA DSView data:
https://drive.google.com/file/d/1ZB5-zN6_H6RxC__M3n38mU_9s-_DO7kO/view?usp=share_link
This looks to be a porting issue to a new platform.
As such it does not look to be a real issue related to the examples provided by this project. If you don't mind I move this issue to the Discussions tab. In addition you may get better support by posting your question on Semtech developer portal forum
Not being able to observe the issue it is hard to debug and help you as I am not able to reproduce the issues you are observing myself.
The tasks I would do to understand what is going one are:
- Check and recheck that the wiring between the MCU and the Radio is correct.
- Disable all the log printings.
Printing something on a UART takes time which may cause a lot of problems if not done with special care and a lot of thinking. As you know the LoRaWAN protocol handling is very time critical therefore adding logging information at the wrong places may cause unexpected behaviors.
To observe and debug the SPI exchanges between the MCU and the Radio it is better to use a logic analyzer / Oscilloscope. - Try to reduce the problems scope by implementing a simpler application such as a ping-pong. With such apllication you will be able to ensure that the communication between the MCU and the Radio is correct and behaves as expected. Once this debug is finalized you can give another try to a LoRaWAN example.