@delta said in Cannot connect to Pygate: problem fixed when I unselected the pybytes option and re-flashed the latest firmware Hi there, A little bit off-topic regarding your actual initial problem, but: I could not connect my LoPy4 device to the Pygate gateway on TTN. I flashed the Pygate with Pybytes disabled, and now the LoPy4 successfully joined the LoRaWAN network held by the Pygate. Thanks for the input!

@peterp thanks for your help, i'll contact the support then.

This bug was fixed in the following version. If you update to the latest version using the firmware updater tool, the issue will be gone Best, Gijs

Hi all, We did not like the idea of sleeping, so we implemented an alternative workaround using two locks, which we believe it to be more robust. import time import _thread class Thread: def init(self, target): self.result = None self.target = target self.lock = _thread.allocate_lock() self.aux_lock = _thread.allocate_lock() def real_call(self): with self.lock: self.aux_lock.release() self.result = self.target() def call(self): self.aux_lock.acquire() _thread.start_new_thread(self.real_call, ()) with self.aux_lock: pass def join(self): with self.lock: pass def demo(): print("Starting") time.sleep(10) print("Ensing") return 42 def main(): t = Thread(target = demo) t() t.join() print("Result: " + str(t.result)) if name == "main": main()

Hi, I am having the same issue. Were you able to resolve the issue? Thanks.

Yes, as @robert-hh suggested, I'm very much looking for a reproduction, or a series of things I can do that make this coredump happen (like running this micropython code in combination with pressing button x). The functions calls listed in this coredump decode happen quite a lot all over the firmware, making me think it could be related to running out of memory, or a memory leak somewhere, but again, it depends on the location and order of your function calls. Also, quick side note, you mention in your previous post you're using a Gpy, but have the firmware.elf path going through WIPY, is that intentional? It is possible to run Wipy firmware on a Gpy, (disabling the usage of the LTE modem). If its not intentional. it might show us the wrong function calls here. Let me know

So it looks like the issue has something to do with the pin being pulled high for too long. If I let the signal stay high while it is booting up, the chip will not run any code. It seems like the easiest solution to this problem is to have the interrupt trigger low side after the interrupt signal is over, or have a signal inverter between your interrupt and the pin.

Someone found a workaround - check out this github here: https://github.com/pycom/pycom-micropython-sigfox/issues/424

@jmarcelino Thank, with sudo It works !!

Hi, I can imagine that. I have put it on the bugs-list for Pymakr online a while back (when you first mentioned it), but it might be some time before we get to it (there's always more..) . I think the issue is related to having such a large file not fitting in the receive buffer of the device, though Im not sure. At the moment I cannot think of a quick-fix for this issue, except for splitting the files into multiple smaller files, I think that should work

I solved the problem. I've been using Heltec nodes and it appears the default code for US915 was using subband 1. A correction to the Heltec code to use subband 2 and I am now getting fantastic results!

@Gijs will try, i dont have much experience with the cli. Any positive results i will post here. Meanwhile any others tips are welcome

As stated in my other post, you can get started here: https://docs.pycom.io/advance/coredump/

Hi, Have you tried this 'getting started' guide and example: https://docs.pycom.io/pybytes/pymeshintegration/provisioning/ https://docs.pycom.io/pybytes/pymeshintegration/example/ Best, Gijs

@cfaessler did yoy fix this issue?

@peterp I'm not sure if anyone has actually reproduced the issue yet, so I am posting another output transcript where this program has failed in the hope it could shed some light as to what's happening. In summary the output below shows the script terminating, followed by some manual lte commands via the REPL terminal, followed by calling machine.reset() and some more lte commands that now succeed. Then restarting the original script which runs for 9 loops until it terminates again. It is worth noting that on the re-run, ALL 9 ticks were actually received by the echo server even though several of the replies never made it back. ================================================== Tick: 42 Initialising LTE ... OK Attaching to LTE network .. OK Connecting on LTE network OK Sending UDP Packet Waiting for Reply . Got Reply: tick42 Disconnecting LTE ... OK De-initialising LTE ... OK Sleeping for 60 secs ================================================== Tick: 43 Initialising LTE ... OK LTE is attached Connecting on LTE network Abort: LTE no longer attached Disconnecting LTE ... OK De-initialising LTE ... OK Sleeping for 60 secs ================================================== Tick: 44 Initialising LTE ... OK LTE is attached Connecting on LTE network ♦Traceback (most recent call last): File "<stdin>", line 110, in <module> File "<stdin>", line 39, in connect_lte OSError: the requested operation failed ♦> Pycom MicroPython 1.20.2.r1 [v1.11-a5aa0b8] on 2020-09-09; GPy with ESP32 Type "help()" for more information. >>> >>> lte.isattached() Traceback (most recent call last): File "<stdin>", line 1, in <module> OSError: the requested operation failed >>> lte.isconnected() False >>> lte.reset() Traceback (most recent call last): File "<stdin>", line 1, in <module> OSError: the requested operation failed >>> lte.attach() Traceback (most recent call last): File "<stdin>", line 1, in <module> OSError: the requested operation failed >>> lte.detach() Traceback (most recent call last): File "<stdin>", line 1, in <module> OSError: the requested operation failed >>> lte.deinit() Traceback (most recent call last): File "<stdin>", line 1, in <module> OSError: the requested operation failed >>> lte.init() >>> lte.attach() Traceback (most recent call last): File "<stdin>", line 1, in <module> OSError: the requested operation failed >>> import machine >>> machine.reset() ets Jun 8 2016 00:22:57 rst:0x7 (TG0WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff8020,len:8 load:0x3fff8028,len:2140 ho 0 tail 12 room 4 load:0x4009fa00,len:19760 entry 0x400a05bc Pycom MicroPython 1.20.2.r1 [v1.11-a5aa0b8] on 2020-09-09; GPy with ESP32 Type "help()" for more information. >>> from network import LTE >>> lte = LTE() >>> lte.attach() >>> lte.isattached() True >>> lte.connect() >>> lte.isconnected() True >>> lte.deinit() >>> Running d:\svn\other\pycom\smh_test\test_lte5.py >>> >>> Begin ================================================== Tick: 1 Initialising LTE ... OK Attaching to LTE network .... OK Connecting on LTE network OK Sending UDP Packet Waiting for Reply ..........Retry Sending..........Timeout Disconnecting LTE ... Failed De-initialising LTE ... OK Sleeping for 60 secs ================================================== Tick: 2 Initialising LTE ... OK LTE is attached Connecting on LTE network OK Sending UDP Packet Waiting for Reply ..........Retry Sending..........Timeout Disconnecting LTE ... Failed De-initialising LTE ... OK Sleeping for 60 secs ================================================== Tick: 3 Initialising LTE ... OK LTE is attached Connecting on LTE network OK Sending UDP Packet Waiting for Reply .. Got Reply: tick3 Disconnecting LTE ... OK De-initialising LTE ... OK Sleeping for 60 secs ================================================== Tick: 4 Initialising LTE ... OK LTE is attached Connecting on LTE network OK Sending UDP Packet Waiting for Reply ..... Got Reply: tick4 Disconnecting LTE ... OK De-initialising LTE ... OK Sleeping for 60 secs ================================================== Tick: 5 Initialising LTE ... OK LTE is attached Connecting on LTE network OK Sending UDP Packet Waiting for Reply .. Got Reply: tick5 Disconnecting LTE ... OK De-initialising LTE ... OK Sleeping for 60 secs ================================================== Tick: 6 Initialising LTE ... OK LTE is attached Connecting on LTE network OK Sending UDP Packet Waiting for Reply ..........Retry Sending..........Timeout Disconnecting LTE ... Failed De-initialising LTE ... OK Sleeping for 60 secs ================================================== Tick: 7 Initialising LTE ... OK LTE is attached Connecting on LTE network OK Sending UDP Packet Waiting for Reply . Got Reply: tick7 Disconnecting LTE ... OK De-initialising LTE ... OK Sleeping for 60 secs ================================================== Tick: 8 Initialising LTE ... OK LTE is attached Connecting on LTE network OK Sending UDP Packet Waiting for Reply ..........Retry Sending..........Timeout Disconnecting LTE ... Failed De-initialising LTE ... OK Sleeping for 60 secs ================================================== Tick: 9 Initialising LTE ... OK LTE is attached Connecting on LTE network OK Sending UDP Packet Waiting for Reply ..........Retry Sending..........Timeout Disconnecting LTE ... ♦Traceback (most recent call last): File "<stdin>", line 115, in <module> File "<stdin>", line 53, in disconnect_lte OSError: the requested operation failed ♦> Pycom MicroPython 1.20.2.r1 [v1.11-a5aa0b8] on 2020-09-09; GPy with ESP32 Type "help()" for more information. >>> Summary: Tick 42 - Perfect Tick 43 - Aborted because isattached() returned false while waiting for isconnected() after connect() Tick 44 - Crashed during connect() Manual lte.isattached() - OSError Manual lte.isconnected() - Returned false Manual lte.reset() - OSError Manual lte.attach() - OSError Manual lte.deinit() - OSError Call machine.reset() Manual lte.attach() - OK Manual lte.isattached() - True Manual lte.connect() - OK Manual lte.isconnected() - True Manual lte.deinit() - OK Run Script Ticks 3,4,5,7 - Perfect Ticks 1,2,6,8 - Ok but didn't get replies even though echo server did receive data. Tick 9 - Died with OSerror in lte.disconnect()

@tlanier yes this is intentional. We're running low on storage capacity for the firmware, so we released this beta version without sqnsupgrade. We're looking into ways to get it back in, but we didn't want to delay the release of a beta version to get some idf4 feedback