Open quentin-ol opened 6 years ago
Extra info: Those behaviours appeared with version 1.10.0b1
@danicampora Any idea ? Btw, is there any documentation on how to attach a debugger to the PyCom, that would help immensely.
Well, reverting to 1.9.2.b2, the code above works flawlessly.
Something fishy happened in the commit 54e3269474bd0952a5137a79ec27056460c455b2
Without help, nor any documentation on how to attach a debugger to the LoPy, I'm stuck with debugging with printf which, I'm sure, is one way to create weird timing issues...
I'd appreciated if the PyCom staff could dedicate a bit more time to answering/helping on issues posted here. Right now, this place feels like a desert.
BTW, don't get my wrong, I'm not expecting every issue to be answered/solved by PyCom and I'd be more than happy to help/contribute. Just give me a nudge into the right direction, tell me where to look at.
Hi @quentin-ol sorry you felt your questions aren't being answered, we do see all these issues and when possible aim to offer a fast reply however please understand your question is quite complex and - as you found- it is to do with the recently released firmware we're currently reviewing.
Also at the moment - for a number of reasons - there is a reliable way to use a JTAG debugger to debug the MicroPython stack, that is something still being worked on and when available it'll be documented.
@jmarcelino you make me happy. This, an honest answer, is all I was looking for. Even if it doesn't solve the issue.
As said above, I'd be happy to help. Don't hesitate to ping me if there is anything I can help you with.
Please include the following information when submitting a bug report:
note: I applied the fix described in #96.
Exact steps to cause this issue:
After several (read lost of) trials, I've identified two types of behaviours:
behaviour 1:
behaviour 2:
In the first case (behaviour 1), the timer is called in time (20 000ms after its initialisation). The execution goes through all the steps I'm expecting BUT the time it spent in the uplink function means there is something very bad happening: 1s is not enough for a 40-bytes payload to be sent using SF12 + 2 RX windows. I strongly suspect that this 1s is the time the code spent sleeping ( which is set to 1s).
In the second case (behaviour 2), the timer is called late (20 0001ms after its initialisation). The execution is stuck in the while loop (print), and event_handler is never called.
Both cases strongly hints toward a bad port of the timer librairie used in LoRaMac. I will investigate this further.