FiPy v1.2 Problems



  • In the past I had a problem connecting to FiPy 1.0r over COM port and also over WiFi.
    So I received today FiPy 1.2
    I plugged it into PyTrack which works great with LoPy4 over COM. I upgraded firmware of this PyTrack a few months back....
    Then I upgraded firmware of FiPy 1.2 using pycom_firmware_update_1.16.1.exe that I downloaded from Pycom.
    I disconnected and re-connected the USB cable from/to my laptop in order to restart FiPy, and now am looking into Wireless Networks... I do not anything that resembles FiPy that by default should be 192.168.4.1
    I also used Advanced IP Scanner and do not see 192.168.4.1
    So this is very puzzling - I am getting the same behavior that I was getting with FiPy 1.0r....
    That makes me suspect that I am doing something really wrong...also the fact that on the same PyTrack I have LoPy4 working is puzzling as well.

    So my next step was launching VS Code - It finds COM15 but fails to connect to it:
    It just hangs on "Connecting to COM15..."

    here is my Project Settings:

    {
        "address": "COM15",
        "username": "micro",
        "password": "python",
        "sync_folder": "",
        "open_on_start": true,
        "safe_boot_on_upload": false,
        "py_ignore": [
            "pymakr.conf",
            ".vscode",
            ".gitignore",
            ".git",
            "project.pymakr",
            "env",
            "venv"
        ],
        "fast_upload": false
    }
    

    and here is my Global Settings:

    {
    	"address": "COM15",
    	"username": "micro",
    	"password": "python",
    	"sync_folder": "",
    	"open_on_start": true,
    	"safe_boot_on_upload": false,
    	"py_ignore": [
    		"pymakr.conf",
    		".vscode",
    		".gitignore",
    		".git",
    		"project.pymakr",
    		"env",
    		"venv"
    	],
    	"fast_upload": false,
    	"sync_file_types": "py,txt,log,json,xml,html,js,css,mpy",
    	"ctrl_c_on_connect": false,
    	"sync_all_file_types": false,
    	"auto_connect": false,
    	"autoconnect_comport_manufacturers": [
    		"Pycom",
    		"Pycom Ltd.",
    		"FTDI",
    		"Microsoft",
    		"Microchip Technology, Inc."
    	]
    }
    

    I also tried auto_connect: true with the same result...

    In the past I had advise to use FileZilla - but how can I now when I don't see the 192.168.4.1 ?
    When I try to ping 192.168.4.1 I get:

    ping 192.168.4.1
    
    Pinging 192.168.4.1 with 32 bytes of data:
    Reply from 66.75.161.49: TTL expired in transit.
    Reply from 66.75.161.49: TTL expired in transit.
    Reply from 66.75.161.49: TTL expired in transit.
    Request timed out.
    
    Ping statistics for 192.168.4.1:
        Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
    

    and that's totally weird...

    BTW, my projects boot.py looks like that:

    from machine import UART
    import machine
    import os
    
    uart = UART(0, baudrate=115200)
    os.dupterm(uart)
    
    machine.main('main.py')
    
    

    Any advice? What am I doing wrong? Why can't I see the 192.168.4.1 ?

    EDIT: I also tried to call connect serial COM15 115200 in rshell but that did not work either...
    HELP!!



  • @securigy I am happy to help. But that should not be our task. Pycom should stop building firmware versions which break existing behavior - and that without announcement or documentation.



  • Dear @securigy,

    if you feel lucky, you might want to try our custom build just released on [1]. More background about this is available through [2].

    With kind regards,
    Andreas.

    [1] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/FiPy-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz
    [2] https://community.hiveeyes.org/t/investigating-random-core-panics-on-pycom-esp32-devices/2480



  • @securigy Good to hear this process worked well for you. Good luck with your next steps!



  • @andreas @robert-hh
    Thank you Robert for building Andreas' versions.
    It works now:

    1. First I did
    pycom-fwtool-cli.exe --verbose --port COM15 erase_all
    
    1. Then followed with the flashing of Robert's build (I could not find your build, Andreas) with LittleFS

    and now I can see fipy-wlan-XXXX in available networks list and I can also access REPL over serial and I could Upload the files to FiPy without errors!

    You have no idea how grateful I am to you guys.
    Very excited - finally I can start coding my contraptions!



  • Dear @securigy,

    sorry, I can't tell anything about the default AP mode. Just wanted to help out with flashing the firmware images. However, @robert-hh seems to know more about the details of the features still available with this firmware.

    Sorry for the experience with all that from your perspective. It's really a moving target as it is all over the place with software and systems these days.

    Keep up the spirit!

    With kind regards,
    Andreas.



  • @andreas So I flashed the image I got from Robert's second link.
    With this one I still do not see fipy-wlan in the list of available networks.
    ...and I also lost access to REPL through serial:

    AutoConnect enabled, ignoring 'address' setting (see Global Settings)
    Searching for PyCom boards on serial...
    Connecting to COM15...
    

    Any suggestions?



  • @securigy You will definitively want to use LittleFS. The FatFS will most likely give you file corruption issues in one way or another [1].

    Please be aware that you will loose the content of your filesystem on the FiPy device.

    Please also be aware that you should completely erase your device before, otherwise you might get strange errors from the WiFi subsystem [2].

    On Windows, the required invocations on the command line are

    pycom-fwtool-cli.exe --verbose --port COM11 erase_all
    pycom-fwtool-cli.exe --verbose --port COM11 flash --tar FiPy-1.20.1.r1-0.2.0-vanilla-psram-fix.tar.gz
    

    Please adjust the argument to the --port parameter according to your environment.

    [1] https://community.hiveeyes.org/t/fipy-verliert-programm-nach-power-off-durch-leeren-lipo-file-system-corruption-through-brownout-conditions/2057
    [2] https://community.hiveeyes.org/t/installing-the-recent-pycom-firmware-1-20-1-r1-requires-erasing-the-flash-memory-completely/2688



  • @andreas oh, silly me! Thank you. Will try right away.
    What do I need to chose: FatFS or LittleFS?



  • Dear @securigy,

    you would just use the "Flash from local file" option with that firmware images bundled as tarballs like depicted in

    98041412-34b4-44fa-a422-35e97bc08eb6-image.png

    With kind regards,
    Andreas.



  • @robert-hh Ok, first of all it is a good piece of news - it proves that I am not insane...
    Then I have a bunch of questions:

    1. If the 1.20.1.r1 image screws up automatic AP on boot up and access to REPL over serial, why Pycom is shipping it without providing a word of caution? I wasted enormous amount of time dealing with this...

    2. If 1.20.1.r1 is the problem - will this problem go away if I flash 1.20.1 instead?
      6b74f457-9067-47af-b8e1-676772b5b4fc-image.png image url)
      Actually, this is the 1st step I am going to take....

    3. If I do #2 above - will I lose any functionality or introduce old problems to FiPy (at this point what's important to me is to be able to access REPL over serial and be able to establish AP by default on boot up).

    4. I also downloaded the image you built from the 2nd link in your message. When I unzipped it I got this:
      a09dd71b-286a-48c9-a159-1ba6596a0be3-image.png
      Now, I am not a firmware guy - so what do I do with these files? How do I flash them to FiPy? Is there any tool I can use on Windows 10 in order to do so? Any procedures/manuals? What are these script files? What are they written with?

    EDIT: I flashed 1.20.1 and it fixed the problem of accessing REPL over serial. However, the attempt to upload project files is failing as it was on FiPy 1.0:

    Connecting to COM15...
    
    >>>
    Uploading project (main folder)...
    Not safe booting, disabled in settings
    
    Uploading to /flash...
    Reading file status
    Failed to read project status, uploading all files
    Creating dir lib
    [1/6] Writing file boot.py (2kb)
    Failed to write file, trying again...
    Failed to write file, trying again...
    timeout
    [2/6] Writing file lib/L76GNSS.py (3kb)
    Failed to write file, trying again...
    Failed to write file, trying again...
    timeout
    [3/6] Writing file lib/LIS2HH12.py (6kb)
    Failed to write file, trying again...
    Failed to write file, trying again...
    timeout
    [4/6] Writing file lib/pycoproc.py (10kb)
    Failed to write file, trying again...
    Failed to write file, trying again...
    Upload failed.: timeout Please reboot your device manually.
    

    So I am not out of the woods yet...



  • @securigy It is not an issue of the FiPy, the problem is the new 1.20.1r1 firmware, which includes pybytes. That disables the AP, and also changes the behaviour of the REPL prompt; soft-reset by Ctrl-D is not working any more. See also the (lengthy) discussion here:
    https://forum.pycom.io/topic/5348/gpy-full-flash-erase/28
    And in the thread around that. You find there also a link to a place, where @andreas hosts some images without pybytes, which I have built yesterday: https://packages.hiveeyes.org/hiveeyes/foss/pycom/robert-hh/
    You can disable the autostart of pybytes (see the first link above), but that does not change the soft-reset block. For copying files, you can also use pyboard.py from this place: https://github.com/micropython/micropython/blob/master/tools/pyboard.py. AFAIK, that still works with the pybytes repo.



  • What firmware are you running? On GPYs for example the adhoc 192.168.4.1 wifi is no longer switched on by default in the latest 1.120.1.r1 firmware, something to do with pybytes. Not sure if the same applies to FiPYs?


Log in to reply
 

Pycom on Twitter