Bugs & Issues

• T

  GPY stuck, no REPL, Telnet refusing connection, Safe-boot fails
  • Tom Weber  

  4
  0
  Votes
  4
  Posts
  21
  Views

  T

  @robert-hh Hello robert thanks for Your feedback, I did a full erase and restore of the firmware (1.20.2.r6),lfs file system, now I am able to access the device REPL is working, telnet and FTP are working over wlan. About the writing, no I had debugging information in earlier versions, but for some time i disabled them completely, no merely no write access to flash occur. So you guess it has to do with the flash writing to get corrupted? Some other ideas, I am using some PINs to access the outside world, not that one of them could interfere with some internal systems; i use: Out: P9,P10,P19 to drive an external RGB LED Out: P20,P11 to drive a relais In: P17,P3 to read thru Pull up the state of 2 external devices Also, if I may, another questions, I see the PIN are, by default or by boot-up in active state, is there a way to have them, by default, during boot, or even if, as in my case, the device is totally stuck, have them always in inactive state, except if I activate them ? Again thanks for Your help very much appreciated, Tom
• N

  Pymakr not starting since Visual Studio Code was updated to version 1.59.0. Wondering if there is any available solution for this: "There was an error with your serialport module, Pymakr will likely not work properly..."
  • nestorld  

  5
  0
  Votes
  5
  Posts
  48
  Views

  N

  Anyone from Pycom should send a response to this. Is there any way to use Pymakr on VS Code without downgrading?
• J

  This topic is deleted!
  • James Pruet  

  1
  0
  Votes
  1
  Posts
  3
  Views

  No one has replied

• M

  Core-dump on modem firmware update
  • Morten Hauan  

  1
  0
  Votes
  1
  Posts
  18
  Views

  No one has replied

• A

  Guru Meditation Error: Core 0 panic'ed (LoadProhibited)
  • Andrea Picillo  

  5
  0
  Votes
  5
  Posts
  27
  Views

  A

  @Yusuf-BAYLAV Ok thank you again for your support. It seems to be quite difficult to me to create a code that generate the error since our source code is quite huge but I'll make a try. Please can you suggest to me some other way to debug my code other than backtracking the core dump? Thank you Andrea
• 

  SCD30 --> OSError: I2C bus error
  • tiborrr  

  7
  0
  Votes
  7
  Posts
  125
  Views

  K

  @tiborrr They even claim up to 150ms, I assume when auto calibration is turned on. Clock stretching period in write- and read-frames is 30 ms, however, due to internal calibration processes a maximal clock stretching of 150 ms may occur once per day https://sensirion.com/media/documents/D7CEEF4A/6165372F/Sensirion_CO2_Sensors_SCD30_Interface_Description.pdf
• A

  Secure Bluetooth communication
  • amstaff88  

  1
  0
  Votes
  1
  Posts
  26
  Views

  No one has replied

• R

  BLE characteristic limit/buffer problems?
  • Robbe Gaeremynck  

  3
  0
  Votes
  3
  Posts
  38
  Views

  No one has replied

• H

  Hard time figuring how to connect DS3231 and MAX9814 to the PyCom FiPy + PyTrack
  • Henrique Goncalves  

  4
  0
  Votes
  4
  Posts
  33
  Views

  A

  Hi , You can connect the DS3231 to the sensor header on Pytrack: https://docs.pycom.io/gitbook/assets/pytrack2-pinout.png This is a simple GND=GND, SDA=SDA, SCL=SCL, VCC=3V3AUX_SENSE. You can even try to connect SQW to SENSOR_INT ... Using an analog mic is somehow difficult with FiPy, instead I would recommend using a digital mic like: Adafruit PDM MEMS Microphone Breakout Product ID: 3492 If you are not using lora/sigfox the you have G12 to G14 available. As far as I know there is no support in code for these devices but the code is open source.... Good luck, avram
• J

  Core dumps that go away when uploading the same scripts again after erasing flash memory with a firmware update
  • jand  

  2
  0
  Votes
  2
  Posts
  27
  Views

  

  Hello, This is Yusuf. The new Solutions Architect/Evangelist for pycom. Your question will be categorized, prioritized and dispatched to somebody from our development team. You will have a response depending on the above classification as soon as possible. We wish you a good day.
• G

  Unexepected behaviour of print(str(var))
  • goldfishalpha  

  3
  0
  Votes
  3
  Posts
  21
  Views

  G

  Thanks @jcaron. My questions belies my limited understanding of Python then. I thought it might be a Micropython implementation quirk. I guess Python has gotchas due to "informal" assumptions just like Javascript, but that's another discussion. TBH, the solution I ended up using is the most efficient (in term of lines of code at least), this was just "weird" behaviour I came across on my travels. I was just looking for a way of converting the bytes object to a usable form. It had been a long day of debugging so probably hadn't thought this through completely before posting the question.
• A

  Exp. Board user push button
  • almeos  

  3
  0
  Votes
  3
  Posts
  36
  Views

  N

  @almeos Thank you! This is one of the mysterious things that you can not find in Pycom's documentation. This was useful to me today :-)
• A

  LTE deinit() not working.
  bugs • • akshayjames  

  3
  1
  Votes
  3
  Posts
  884
  Views

  G

  @akshayjames and for those reading this ~4 years later. The line lte=LTE() is the init. The modem doesn't init LTE on boot by default. Sorry, my bad on this one. I didn't spot this: @akshayjames said in Root causes of high deep sleep current [LoPy1, WiPy2 and SiPy], all the new modules **do not have deepsleep issues**: @incognico Hi The high current during deepsleep is due to the LTE module. LTE is started automatically during boot. You need to deinit LTE separately before calling deepsleep as LTE is not stopped automatically during deepsleep. I had the same issue. My FiPy module was drawing 49mA during deepsleep. After I called LTE deinit, the current draw reduced by a lot at that time itself. After that deepsleep worked as expected. :) from network import LTE lte = LTE() LTE.deinit() Hope this helps.
• J

  DevNonce has already been used (OTAA Join request)
  • jand  

  6
  0
  Votes
  6
  Posts
  40
  Views

  J

  I now figured out that this problem only occurs when the lopy4 is mounted on a PCB that I developed AND at the same time also connected to a Pycom expansion board (only Vin, GND, 3V3, p0, p1) that is connected to a laptop so I can debug the script in the Pymakr console (VSCode). Strange enough everything including the LoRa commands work fine if the lopy4 is only mounted on the PCB and powered from a battery (but not also connected to the expansion board). And the entire script but with the LoRa commands made inactive also works fine when the lopy4 is mounted on my PCB and also connected to the expansion board. Not clear why this problem occurs. But at least I know how I can avoid the problem: not to connect to the expansion board. It just makes the debugging harder.
• V

  Can software cause hardware defect on expansion board V3?
  • Verkehrsrot  

  20
  0
  Votes
  20
  Posts
  161
  Views

  C

  You may try to insert a USB power meter in between to check both voltage and current drawn and see what it says.
• J

  TLS handshake fails over LTE
  • jorun vanmelle  

  8
  0
  Votes
  8
  Posts
  45
  Views

  J

  @jcaron Thank you, I found the problem, I had a buffer overflow, which caused large data packet transfers to fail. It had nothing to do with TLS but only happened with TLS because my packets were larger there. Increasing the buffer size fixed my problem. Thanks for the support!
• M

  Wify connecting via WPA2 Enterprise
  • Michael Hickland  

  4
  0
  Votes
  4
  Posts
  25
  Views

  M

  @Alexander-Pilhar brilliant, worked a treat cheers
• S

  Send only manufacturer_data (BLE advertisement)
  • smarok  

  2
  0
  Votes
  2
  Posts
  74
  Views

  J

  Hi @smarok , did you figure it out ?
• T

  Random Core dumps - GC may be ?
  • Tom Weber  

  1
  0
  Votes
  1
  Posts
  21
  Views

  No one has replied

• T

  Random but often Core Dumps
  • Tom Weber  

  8
  0
  Votes
  8
  Posts
  49
  Views

  T

  In the meanwhile I found out when I deactivate the NFC (meaning not including the libraries and not listening on NFC) there are a whole lot less crashes. Which is now not executed are stuff like from pycoproc_1 import Pycoproc from MFRC630 import MFRC630 py = Pycoproc(Pycoproc.PYSCAN) nfc = MFRC630(py) nfc.mfrc630_cmd_init() nfc_discovery_thread=_thread.start_new_thread(nfc_discovery_loop,(nfc,0)) and a function checking for NFC def nfc_discovery_loop(nfc,id): if (nfc): try: atqa = nfc.mfrc630_iso14443a_WUPA_REQA(nfc.MFRC630_ISO14443_CMD_REQA) if (atqa!=0): [...] But it still crashed, but far less. Maybe a hint for somebody ?