FiPy and Pytrack



  • I just recently received my FiPy and Pytrack. I've updated the firmware and started looking at pulling data from the Pytrack. Unfortunately, I continuously receive this error:

      Traceback (most recent call last):
      File "main.py", line 2, in <module>
      File "/flash/lib/pytrack.py", line 5, in <module>
      TypeError: cannot create 'module' instances
    

    First 4 lines of main.py:

      #main.py
      from pytrack import Pytrack
      from L76GNSS import L76GNSS
      from LIS2HH12 import LIS2HH12
    

    I have the latest libraries (as of 1/21/18) for the Pytrack in /lib, and pycoproc is in /lib/pycoproc/pycoproc.py I'm certain I'm missing something obvious, but any help would be appreciated.



  • I've had the same error and it was due to some junk files on my Fipy.

    A filesystem reset worked for me:

    >>> import os
    >>> os.mkfs('/flash')
    


  • @kodiak80
    I understand, this indicates some hardware malfunction of the Pytrack. But first some ideas:

    1. don't you happen to have some other Pycom boards (Lopy, Wipy, Sipy) to give another try on this Pytrack
    2. could you try on a Mac, or Windows 10 machine? For this simple scenario, no driver installation is required, just a simple "Serial Terminal" app.
    3. let's try to talk over a screen-sharing "video" call


  • @catalin Regarding the scenario I mentioned: Once I mount the FiPy, simply connecting the board via USB results in no device being displayed in lsusb. If I push the reset button on the pytrack, it does display the Microchip device (04d8:f014) for several seconds, but it then disappears. At no point do I get a /dev/tty device.

    I'm happy to provide more info, just let me know what you need. I'll respond to your PM as well.



  • Hi @kodiak80,

    This scenario, I need to clearly understand.
    Once I mount the FiPy, I get nothing in lsusb. Pushing the reset button (Pytrack), at any time, shows 04d8:f014 for several seconds before it disappears. I also have no valid /dev/tty device once the FiPy is connected.

    It might be a hardware problem. Pytrack would stay in bootloader mode (F014), only if Reset button is kept pressed; and it's quite strange that Fipy would provoke this.
    PS: I have sent you a private message on Chat.



  • @seb I have tried a few different cables, and this one does work with my other fipy/pytrack set. It also seems fine with the pytrack by itself



  • Hi,

    Have you tried a different USB cable? We have had reports of some USB cables not working with the FiPy.



  • @catalin I appreciate the help. With ONLY the Pytrack, I do see both modes (f014 and f013) as you noted. One exception, pressing the reset button when in normal mode does NOT cause the USB device to go away. With only the Pytrack I do get a valid /dev/ttyACM0

    Once I mount the FiPy, I get nothing in lsusb. Pushing the reset button (Pytrack), at any time, shows 04d8:f014 for several seconds before it disappears. I also have no valid /dev/tty device once the FiPy is connected.

    I have verified the FiPy is mounted correctly, and I have used my second FiPy/Pytrack set (that is functioning correctly) to test. The second FiPy, mounted on the non-functioning Pytrack still behaves the same way, and both FiPy boards, when mounted on the one good Pytrack, operate correctly.

    Appreciate your help.



  • Hi @Kodiak80,
    Let's just take a Pytrack board (no Fipy put inside it) and run lsusb.
    You should be able to see (the most important info is bolded):

    • Bus 020 Device 004: ID 04d8:f014 Microchip Technology Inc. Application Specific Device
      ** this is bootloader mode (f014 is USB id), active just for 7-8 seconds, if you pressed Reset button when plugging USB connector
    • Bus 020 Device 005: ID 04d8:f013 Microchip Technology Inc. Pytrack Serial: Pyabcde0
      ** this is normal, application mode (f013 is USB id), of Pytrack, this means the bootloader verified application partition and it's fine
      ** pressing reset at this point, this USB device should go away for ~1 sec, and come back

    At this point, don't you have a valid /dev/ttyx handler that you can connect to?
    Please, tryout using minicom -D /dev/tty, using 115200 baudrate and 8N1 settings; you should be able to connect (can't actually send/receive nothing, as no Fipy is mounted).
    Next, try this with FiPy mounted on Pytrack. The LED on Fipy should be on the same side/direction as micro-USB.



  • Ok, after a lot of fiddling with these boards I'm not sure what to try next.

    PROBLEM
    My FiPy/Pytrack does not appear to boot, when the two boards are connected, and there is no device listed in lsusb or dmesg. I get no LEDs on the FiPy when connected to the Pytrack, but it boots and begins flashing the blue LED when mounted on the Expansion board.

    WHAT I'VE DONE SO FAR

    • Current firmware for FiPy (v1.14.0.b1)
    • Current firmware for Pytrack (0.8) - flashed multiple times with apparent success based on output
    • Verified the FiPy operates as expected when mounted on an Expansion 2.0 board
    • Verified I can see the Pytrack board in lsusb when connected without the FiPy (04d8:f013 Microchip Technology, Inc.)
    • Tried using another computer and USB port in the chance I had a power issue of my current port
    • Successfully configured a second FiPy/Pytrack pair such that the FiPy can see the Pytrack and all appears well
    • Pressing the button on the Pytrack while the FiPy/Pytrack is connected causes the USB device (04d8:f013 Microchip Technology, Inc.) to be listed for approximately 2-3 seconds before it disappears again.

    The behavior really seems like the Pytrack firmware was not flashed correctly. However, I followed the same procedure I used for my other Pytrack, I get a "done" message, and I have attempted the process repeatedly. For what it's worth, I'm using Ubuntu 14.04 for all my work with the Pycom boards. I appreciate any help.



  • @kodiak80
    It looks like your board is not updated properly. I have read somwhere on the forum that sometimes on Windows result of update process show ok but board is not updated.
    Try once again and look if you can get

    from pytrack import Pytrack
    py = Pytrack()
    py.read_fw_version()
    


  • @livius Thank you for that, my actual filesystem had pycoproc.py in multiple places. After a cleanup to match my atom project structure, I've resolved that error. However, I did hit a new one:

      ...
      RTC Set from NTP to UTC: (1970, 1, 1, 0, 0, 4, 429050, None)
      Adjusted from UTC to EST timezone (1970, 1, 1, 2, 0, 4, 3, 1)
    
      Traceback (most recent call last):
        File "main.py", line 26, in <module>
        File "/flash/lib/pytrack.py", line 8, in __init__
        File "/flash/lib/pycoproc.py", line 109, in __init__
      Exception: Board not detected
    

    I tried flashing the firmware to pytrack_0.0.8.dfu, and now my board doesn't even appear to boot. The pytrack is shown in lsusb, and I can reflash the firmware, but as soon as the FiPy module is mounted, the device never boots, no /dev/ttyACM0, and no flashing blue LED. Fortunately I still have a second pytrack, but it generates the same "board not detected" exception.



  • @kodiak80
    are you sure that you have structure like this on the flash?

    /flash
    	main.py
    	/lib
    		L76GNSS.py
    		LIS2HH12.py
    		pytrack.py
                    pycoproc.py
    

    connect to your device by ftp and look like it really looks like



  • @robert-hh I moved pycoproc.py to /lib, and my new error is this:

    Traceback (most recent call last):
    File "main.py", line 11, in <module>
    File "/flash/lib/pytrack.py", line 1, in <module>
    ImportError: no module named 'pycoproc.Pycoproc'
    

    pytrack.py:

    from pycoproc import Pycoproc
    
    __version__ = '1.4.0'
    
    class Pytrack(Pycoproc):
    
        def __init__(self, i2c=None, sda='P22', scl='P21'):
            Pycoproc.__init__(self, i2c, sda, scl)
    

    Again, I appreciate the help.



  • @kodiak80 Micropython looks for import at places given py sys.path. The defaults are '', '/flash', '/flash/lib'. So, you should move pycoproc.py one level up to /lib, or rename it into __init__.py.



  • @robert-hh I appreciate the reply. I actually have pycoproc, from the repo, in /lib/pycoproc/pycoproc.py.



  • This post is deleted!


  • @kodiak80 You need the module pycocproc from the lib: https://github.com/pycom/pycom-libraries/tree/master/lib


Log in to reply
 

Pycom on Twitter