Trouble with FiPy code not working

[Dylan]

Hello,

I have a some new FiPys that I am trying to use the same way as I used the LoPy, therefore I am using the exact same code to run the FiPy as I did the LoPy node. For some reason the FiPy executes the code once and never repeats it like the lopy node does.

I feel like there is something obvious that I am missing but I am yet to find it, any tips would be much appreciated.

Cheers

[robert-hh]

@dylan It is hard to believe that this is the reason, because the standard value for sys.path is ['', '/flash', '/flash/lib']. Since main.py resides in /flash, any code to be imported may reside at that place too, like also in /flash/lib or the actual directory (frisdt entry). The latter may be the a cause, if you have multiple copies of your code, good and bad ones, on the file system.

[Dylan]

So I have found where I was going wrong for anyone else who ever encounters this problem.

It appears I was putting all my .py files into where the main.py goes instead of having the separate \lib folder :/. Apparently that did nothing wrong in all firmware versions until 1.16. Anyway, lesson learned.

Cheers everyone for you patience.

[livius]

@dylan said in Trouble with FiPy code not working:

This successfully went into deepsleep (yet to check the mA). However there seemed to be an extra delay for the first time it enters deepsleep of up to 3-5 seconds. (Also would not recommend using 1000ms for a test, I can't hit the ctrl c at the right time to stop the code from work and now it just turns on and off all the time haha... any recommendations there would be much appreciated. )

simply use safe boot mode
https://docs.pycom.io/chapter/gettingstarted/programming/safeboot.html#safe-boot
P12 to 3V3 after reset disable your code execution

[Dylan]

I did some extra testing this afternoon, made the main.py file have just:

from pytrack import Pytrack
import machine
import socket
import binascii
import struct
import time
import array


print("Line 10")
machine.deepsleep(1000)
print("Line12")

This successfully went into deepsleep (yet to check the mA). However there seemed to be an extra delay for the first time it enters deepsleep of up to 3-5 seconds. (Also would not recommend using 1000ms for a test, I can't hit the ctrl c at the right time to stop the code from work and now it just turns on and off all the time haha... any recommendations there would be much appreciated. )

This I guess is sort of good news however it still doesn't answer why upgrading the firmware makes my other code not work. I am trying to make a stripped down GPS using the examples from github however I still seem to have problems with it waking back up.

Cheers for the help.

[livius]

@dylan
can you move line before the loop?
acc = LIS2HH12()

and do you have pytrack libraries up to date?

[Dylan]

@jcaron I just added a Print("Line 88") after the timer to check it. While on firmware 1.11.0.b1 it prints after the 10 second wait then goes back to the Line 51 straight away (as expected). On 1.17.3.b1 it does not print anything after the sleep function and just never wakes up. And feel free to give any tips on the loop, as you can tell its a bit rough.

I'll give that lora.nvram_save a look, sounds like a good idea cheers.

[jcaron]

@dylan Even though sub-optimal in this case, have you tried the Pytrack-controlled deep sleep?

Also, if you're using deep sleep, you should save/restore the LoRa state (lora.nvram_save() before going to deep sleep, lora.nvram_restore() when starting), and avoid joining every time you start.

Ah, with proper formatting I see you actually have a (weird) loop around the sleep. Can you add a trace after the time.sleep, as well as one after the end of the loop?

[Dylan]

@jcaron This problems occurs with both the time.sleep and deepsleep commands. I've used both commands with this exact code below and had the same problem no matter which sleep function I am using.

[jcaron]

@dylan time.sleep is not deep sleep. It will just wait for the given time and then resume execution after that instruction (where deep sleep on the other hand restarts the module on wake up).

So unless you add a loop, it will just finish execution.

What you want is probably machine.deepsleep.

NB: to correctly format your code in posts, add ``` on a line before and after your code.

[Dylan]

@xykon @livius @seb I have re-created the problem and it still exists.

I updated my FiPy from 1.11.0.b1 to the most recent 1.17.3.b1 with the Pycom firmware updater 1.12.0.b0.

The only change I made to anything was upgrading the firmware and now the FiPy no longer wakes up from the time.sleep at the end. The code is here:

from network import LoRa
from pytrack import Pytrack
from coords import Coords
from CayenneLPP import CayenneLPP
from L76GNSS import L76GNSS
from LIS2HH12 import LIS2HH12
import machine
from machine import Pin
from machine import I2C
import socket
import binascii
import struct
import time
import array
# Initialize LoRa in LORAWAN mode.
lora = LoRa(mode=LoRa.LORAWAN, public=1,  adr=0, tx_retries=0)
# Remove default channels
dev_addr = struct.unpack(">l", binascii.unhexlify('269928E2'.replace(' ','')))[0]
nwk_swkey = binascii.unhexlify('7A7E7000000F93BD1BB4693127C374FE'.replace(' ',''))
app_swkey = binascii.unhexlify('F93BD1BBBA53BBF3B4096A72115E9F5D'.replace(' ',''))

for index in range(0, 72):
    lora.remove_channel(index)

    lora.add_channel(index, frequency=918000000, dr_min=0, dr_max=3)

lora.join(activation=LoRa.ABP, auth=(dev_addr, nwk_swkey, app_swkey), timeout=0)
# wait until the module has joined the network


while not lora.has_joined():
    time.sleep(5)

# remove all the non-default channels

for i in range(8, 15):
    lora.remove_channel(i)
# create a LoRa socket
s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)

# set the LoRaWAN data rate

s.setsockopt(socket.SOL_LORA, socket.SO_DR, 3)

# make the socket blocking
s.setblocking(False)
time.sleep(2.5)
while lora.has_joined():
    acc = LIS2HH12()
    print("Line 51")
    xyz = acc.acceleration()
    x = xyz[0]
    y = xyz[1]
    z = xyz[2]
    time.sleep(1)
    py = Pytrack()
    battery = py.read_battery_voltage()
    battery = battery * 10
    cayenne = CayenneLPP()
    time.sleep(1)
    l76 = L76GNSS(py, timeout=10)
    lat1 = str(l76.lattitude())
    lon1 = l76.longitude()
    if len(lat1) > 5:
        lona = lat1
        lata = lon1
        meta = 9500
        lat = float(lona)
        lon = float(lata)
        met = float(meta)
        cayenne.add_gps(4, lat, lon, met)
        cayenne.add_temperature(6, battery)
        cayenne.add_accelerometer(5, x, y, z)
        s.send(cayenne.get_buffer())

    if len(lat1) < 5:
        cayenne.add_accelerometer(5, x, y, z)
        cayenne.add_temperature(6, battery)
        s.send(cayenne.get_buffer())
        print('No fix')
    rx = s.recv(256)
    print("Line 83")
    if rx:
        print(rx)
    print("Line 86")
    time.sleep(10)

To double check everything I just used the firmware updater 1.12.0.b0 to downgrade to 1.11.0.b1 and its now waking up and repeating the code as expected:

Line 51
No fix
Line 83
Line 86
Line 51
No fix
Line 83
Line 86
Line 51
No fix

Just to triple check, I updated it again back to 1.17.3.b1 and it still doesn't repeat the code as it does on 1.11.0.b1
Terminal after 10mins of running:
Line 51
No fix
Line 83
Line 86

I can't think of anything that might be going wrong, its a bit beyond me, but I'm pretty sure it's not a me thing if the only thing I've changed is the firmware.
Feel free to get me to try any tests you need me to run.

[Xykon]

@dylan said in Trouble with FiPy code not working:

I believe the current firmware updater even tells us when it needs its own update so I'm pretty sure everything should be up to date there.

Yes the GUI updater will check for updates on start and tell you if you're using the latest version or if there is an update. It should currently say: "Version: 1.12.0.b0 (latest) on the welcome screen. We also made this version of the firmware updater mandatory so you cannot use an older version and successfully update the board.

[Dylan]

@livius I checked that I was downloading the most recent firmware from the most recent firmware upgrader aswell (excellent work there compared to how it was back in November, very user friendly). I believe the current firmware updater even tells us when it needs its own update so I'm pretty sure everything should be up to date there. But I've been wrong before so I'll double check everything at some point this week. I'll check back in when I've re-created the issue or if it works.

[livius]

@dylan said in Trouble with FiPy code not working:

This was tried on the latest firmware and pytrack updates as these were new FiPys just arrived. I've had a few things go right for me so I have a some spare time, I might update a FiPy and try to recreate the error and work from there.

this does not guarantee that you have recent firmware there

[Dylan]

@seb 1. This is true, I had many prints throughout and I'm reasonably sure I thought of that haha
2. This was tried on the latest firmware and pytrack updates as these were new FiPys just arrived. I've had a few things go right for me so I have a some spare time, I might update a FiPy and try to recreate the error and work from there.

[seb]

@dylan

two things

1. Code after a deepsleep will never run, once the device goes to deepsleep and wakes up it will be just like the reset button was pressed, it does not continue execution from where it went to sleep

2. I see no reason why your module should lock up and not wake from deep sleep with the code sample above, Have you tried the latest firmware?

[Dylan]

@seb Yeah I've been putting print("Line #") to catch the errors, excellent way of debugging. However in this case it makes it all the way to the end, it just never wakes back up from either the deepsleep I have above or the time.sleep(10) I use for quick testing (a print is always on the last line of code to check it makes it there).

[seb]

@Dylan
I would recommend adding some print statements into the code you shared to see where it gets stuck on your fipy

[Dylan]

@mj Very similar, the biggest difference I found is the Run/Upload/Download buttons are down the bottom left and I guess it all looks slightly different ofcourse.

[MJ]

@dylan Is it Visual Studio code work as the same as the Atom? The language using also the same?