I tried adding that but it was unsuccessful- however, the repl is staying open (not giving me a >>>) on my server after receiving a message, so it isn't finishing out whatever it's stuck open doing I think. I don't see any reason why it shouldn't finish out though? Doesn't the clientsocket.close() kill the thread?

I fixed this: "I ended up adding wifi connect back into boot and lo and behold I now get the error message from the display library issue. So now I have the wifi connect in two places and I can't understand why WiPy is the way it is. I really think this deserves a fix in the firmware to stop blowing away boot." If you run this once: pycom.pybytes_on_boot(False) it will no longer behave like this.

@robert-hh said in I2C bus error when using _threading: @techykermit I assume that both threads try to use the bus at the same time. That is not possible. So you must serialize the access, e.g. by using a semaphore. For that, the _thread class provides the lock methods. Note that the acquired lock has to be a global object visible to both threads. Aha, I see. I will look into the lock method then, thank you for your help!

@nekoluka You can always start over be erasing flash and reloading the firmware. Only on the expansion board 2.x you have to enable the bootloader mode manually. For that, connect P2 to GND and push the reset on the WiPy3. P2 is labeled G23 on the expansion board. Once uploading is finished, disconnect P2 and push reset again. For updating the firmware, use the Pycom updater tool https://pycom.io/downloads/#firmware

Hi, at the moment, it is not possible to use P12 as a regular GPIO pin, as it is connected to the antenna switch. On the OEM modules, it is possible to use this pin. To solve your issue, you could take a look at the tiny IC close to the antenna circuitry which is the RF switch, but I cannot give you any support in that. Gijs

Hi, Im sorry if I accidentally ignored your coredump post. You notice that this post is from 2018 and that there is no added value in solving this issue anymore right? Now, let me start by mentioning it is never okay for the controller to present a coredump and they should be avoided at all costs. The issue with these coredumps is that they can have a variety of reasons, and that debugging them takes a lot of effort, as I need to know the exact firmware version used (incl development board version), the coredump parameters (top section) and it is very useful to see the python code and learn about its workings and when it breaks (if it breaks at the same location every time). Even then, it is still a wild goose chase. There can be many reasons for a coredump (including inadequate power supply, incorrect use of threading, firmware errors etc.) What we can do, is provide you with better tools to research the coredump and I will be working on that. Note that I have already started a documentation page here: https://docs.pycom.io/advance/coredump/, but I want to do better. Please let me know how we can improve the situation! Best, Gijs

Thanks so much @robert-hh , that solves my problem!

Ah yes, I forgot to mention, always save your project files before uploading, as unsaved changes will Not get uploaded

@dbada Sorry for the late reply. Yes for me the first problem was that I tried to make two MQTT connections one for sub/pub topics one for shadows. You need to first init the AWSIoTMQTTShadowClientand than access the MQTT client with pycomAwsMQTTShadowClient.getMQTTConnection() The next thing is to make sure that the certificate is Activeted. Go to AWS IoT Core console, your thing/security/certificates/Action/Activate And then it works. Code for setting up AWS pycomAwsMQTTShadowClient = AWSIoTMQTTShadowClient(CLIENT_ID) pycomAwsMQTTShadowClient.configureEndpoint(AWS_HOST, AWS_PORT) pycomAwsMQTTShadowClient.configureCredentials(AWS_ROOT_CA, AWS_PRIVATE_KEY, AWS_CLIENT_CERT) pycomAwsMQTTShadowClient.configureConnectDisconnectTimeout(CONN_DISCONN_TIMEOUT) pycomAwsMQTTShadowClient.configureMQTTOperationTimeout(MQTT_OPER_TIMEOUT) pycomAwsMQTTClient = pycomAwsMQTTShadowClient.getMQTTConnection() pycomAwsMQTTClient.configureOfflinePublishQueueing(OFFLINE_QUEUE_SIZE) pycomAwsMQTTClient.configureDrainingFrequency(DRAINING_FREQ) pycomAwsMQTTClient.configureConnectDisconnectTimeout(CONN_DISCONN_TIMEOUT) pycomAwsMQTTClient.configureMQTTOperationTimeout(MQTT_OPER_TIMEOUT) pycomAwsMQTTClient.configureLastWill(LAST_WILL_TOPIC, LAST_WILL_MSG, 1) print("Trying to connect to AWS") try: while not pycomAwsMQTTClient.connect(): print("Connecting to AWS...") time.sleep(0.5) except Exception as e: print("Exception: Can't connect to AWS") print(e) print('AWS connection succeeded') I am planning on writing a detailed Medium Article, I'll link it here if you have any more problems.

@soopieng said in UART Pins for Pytrack with WiPy3: @Erick-Falcon Hi, I am looking for similar solution as well. May I know what do you mean on making a shield on your solution? I am planning to use FiPy on Pytrack, and i need I2C and UART features from FiPy as well. There is a external IO header on Pytrack board, with some GPIO pins and power signal available. Can we configure one pair of the GPIO as UART for my purpose? or the external IO header is used for other application? hi, I new using these devices. I´ve been work with this around three months. when I said "make a shied" I mean make a pcb what allow you to use fipy, pytrack and sensors, without need to solder extra pins on pytrack. I am testing to see how viable and efficient this solution is.

Hi, As the board only has a shared WiFi / BT antenna / radio, it is not possible to use them concurrently. I must admit I have never tried it before, so I quickly drafted this up: from network import WLAN from network import Bluetooth import time wlan = WLAN() wlan.init(mode=WLAN.AP, ssid="hello world", auth=None) print(wlan.ifconfig(id=1)) time.sleep(10) print('scanning bt') bt = Bluetooth() bt.start_scan(10) time.sleep(10) print('scandone') print(bt.get_adv()) And connected my computer to the AP. It did temporarily lose connection, but was quickly recovered after the 10 seconds of BT scanning. I am not exactly sure of the speed you need, but if I must guess it takes as long as establishing a normal WiFi connection? Best

@gada-kashyap micropython is based on a garbage collector. There will be an arbitrary delay each time you run out of memory. call the GC by your own, so you have a little more controll Refactor your code to use as less allocations as possible -> don't use micopythons string operations, avoid floats, ... Stay as long with a working firmware version as you can. Seems easy but it isn't. ESP32/MicroPthon/Pycom are still young projects. They are fixing a lot of issues and had made great steps in the past. But great improvements include big changes to the timings as well.

@robert-hh duh!!! I should have realised that! I'll try that and hopefully that will solve my problem!

@MisureMeccaniche The firmware is here: https://github.com/pycom/pycom-micropython-sigfox together with instructions to get the Pycom specific IDF and to build the firmware. A Linux environment works best for the purpose.

@nigelwattrus once a script is started, you can use the USB interface to exchange data. It is a serial interface. You can access it as UART 0 with micropython, or using sys.stdout.write() for sending from the WiPy, and sys.stdin.read() to receive data at the WiPy. Note that sys.stdin.read() is blocking, but uart.read() is not. Nevertheless, the sys.stdxxx methods are preferred. I do not know about an existing software package like zmodem for WIPy to use that interface. For other micropython boards I have seen that. Simple upload and download of files via USB can be done with ampy (retired), rshell, pyboard.py, and IDE's like mpfshell, .... Besides that you can use WiFi or Bluetooth for data exchange with the WiPy, which is the preferred way.