It seems something in the BSP was changed which caused my LoRa library timers to fail after 4295 seconds.
Which is to say 2^32 microseconds…
Arduino has had problems with this before where something was overflowing deep in the code even when the value reported to the sketch-level APIs was in longer time units, eg, millis() used to fail quite quickly on the ESP32 due to the way they were handling dual core consistency issues at a low level. The RP2040 has some rough parallels to the ESP chips in that both are much faster RAM based platform wearing a lot of translation layers to run Arduino-ish code.
we install this new library version
but now have problem during OTAA (we use EU868)
we see join request and join accept but there are no upload data, device return:
16:16:19.576 → OTAA join failed!
What you face is probably not an authorization problem, since join accepts are being generated.
If I were facing this personally, I’d first make sure that the node was not too close to the gateway, as receiver overload can cause issues. Then I’d check the local logs of the gateway and make sure it is actually transmitting, not rejecting the transmit request for some reason, and not the transmit request having gone instead to someone else’s perhaps less reliable gateway.
Then since what this release does is replace the timing mechanism, I’d look for a way to verify that the receive window is still properly opening just a bit before the expected downlink (in this case the join accept) and staying open long enough to have seen a full lorawan pre-amble, with enough extra time on both sides to account for clock error - and for both RX1 and (if nothing is heard there) RX2. It doesn’t look like the radio specific signals are accessible so this would probably take modifying the code to toggle a GPIO at the start/end of transmit and receive.
The reason such tests could be worthwhile even though the new version appears to work is that there are possibilities of edge cases in timing, and also that it’s impossible to predict ahead of time if a network will send the join accept in the RX1 or RX2 window.
we have one gateway nearby, one at a distance
We tried to turn them off one by one - there was no result.
No getway settings have been changed, other devices work fine. And the WisBlock also successfully passed authorization earlier. Nothing has been changed in the firmware either. We just updated the library in Arduino.
When something in a project of mine stops working, after checking that no other conditions have changed, I make a point to personally verify the behavior of the part of the software that is known to have changed.
Though you might first see what happens if you revert to the old version.
Sorry for venting out: I start to hate mbed even more than before.
So I fixed the LoRa library timer (which worked before mbed changed something) and the problem moved to the example code.
Your problem is related to the way the example code is using a timer (again timer problem).
I cannot attach the changed example code here, I will send it directly to you and update the WisBlock repo as soon as possible.