Pymesh crashes Lopy

[Danne]

Thanks @catalin!

(it seems to have mesh up until rc11, at least I'm using that one )

While we wait I use the old legacy firmware to play with Loramesh.

However, this issue reported with instrFetchProhibited seems to happen on some boards and not others (regardless of firmware version) so it would still be nice to be able to build my own version of the firmware do investigate it further while I wait for your release... is there a version of the FW-sourcecode with openmesh included?

For future reference, if the issue remains...
The following code does cause the problem on some Lopy4 boards

from loramesh import Loramesh
from network import LoRa
import pycom
pycom.wifi_on_boot(False)
pycom.heartbeat(False)
lora = LoRa(mode=LoRa.LORA, region=LoRa.EU868, bandwidth=LoRa.BW_125KHZ, sf=7)
print("pre loramesh")
mesh = Loramesh(lora)
print("Lora mesh complete")

[andreas]

Dear @Jordan-Reyes and @Danne,

we also have been annoyed by different random core panics people from our community have been observing.

@lars_r also experienced core panics on his LoPy4 and we have been able to help him out of being stuck with it just today [1]. However, the fixes improve general stability which is not specific to any mesh networking features. Saying this, it might still improve things for you.

Please read [1] carefully regarding the erase_all step and how to eventually restore your LoRa MAC. Thanks again to @robert-hh for his knowledge on how to do that.

With kind regards,
Andreas.

[1] https://github.com/pycom/pycom-micropython-sigfox/issues/361

[catalin]

Hi @andreas, let's keep things real and not indirect people to false solutions (fyi the solution you proposed is for a Pybytes release, which is not the case here).

I agree with erase_all risk.

The issues from this topic are related to miss-match between Lopy4 (or Fipy) binary and the Pymesh micropython library. All the Pymesh releases(until the licensed v1.20.1.r2 one) were for experimenting and trying Pymesh. Instability came from incompatible micropy scripts.

[robert-hh]

@catalin No python script should cause a crash dump. If it does, there is a problem with the firmware, which requires analysis, as you most likely did with the early Pymesh firmware.
The Pybytes firmware is more a pain for the users, because different to the Pymesh firmware it claims to be 'standard' firmware, but breaks existing behaviour and for some people it causes the firmware to crash, which in turn points at bugs in the firmware.

[andreas]

Hi there,

@robert-hh said in Pymesh crashes Lopy:

No python script should cause a crash dump.

I believe the Python snippets outlined within this topic by @Jordan-Reyes and @Danne will perfectly work for many people.

Unfortunately, I haven't been able to create and publish a short and concise Python program which deterministically reproduces the indeterministic core panics some people are observing in various conditions. In fact, many things are involved here beyond the sole scope of the MicroPython interpreter.

While I can't say this matches the observations of @Jordan-Reyes and @Danne in this particular case, the issues are going down to the silicon level. To be clear on that detail: Let's not blame Pycom here, I believe they are doing a great job of keeping things running but the nitty gritty details within "turtles all the way down" are more than overwhelming.

@robert-hh said in Pymesh crashes Lopy:

For some people it causes the firmware to crash, which in turn points at bugs in the firmware.

That is probably the case here. We have investigated potential issues thoroughly during the past two months and tried to report about them as good as possible on [1].

However, wrapping things up requires more dedication and we are running out of everything on these details. So, I am currently trying to get in touch with @daniel and @Xykon in order to discuss further details. Maybe @catalin is also the right person to talk to as I just found out he is also member of Pycom [2].

With kind regards,
Andreas.

[1] https://community.hiveeyes.org/t/investigating-random-core-panics-on-pycom-esp32-devices/2480
[2] https://github.com/orgs/pycom/people

[andreas]

Hi there,

@catalin said in Pymesh crashes Lopy:

Since 1.20.0.rc9, the Pymesh component was excluded from development firmware releases.

I have not been aware of that detail. Thanks for telling us, @catalin. That said, I am afraid you will not have any fun with the custom builds coming from our pen unless the updates might have been mainlined.

So, sorry for the noise everybody!

With kind regards,
Andreas.

[ricardolima]

@catalin
Hello all,
i'am trying to implement a mesh using your new release and I had tried to send a message from one node to the border router. But I think i'am getting some problem in configuring the border router.
To configure the border router I uncommented "pymesh.br_set(PymeshConfig.BR_PRIORITY_NORM, new_br_message_cb)", "new_br_message_cb" function, connected the device to the wifi and running the codes it returns

State: True BR:  []
Force add BR
BR:  [(net='2001:cafe:cafe:cafe::/64', preference=0)]
done Pymesh init, forever loop, exit/stop with Ctrl+C multiple times

Which seems like it is working. But now I have two problem:
1 - It is getting blocked (the node br)

Neighbors: Router MAC 0x70B3D5499F8MASTER, rloc16 0x7800, coord (51.45, 5.45313), neigh_num 1, ts 126
MAC 0x70B3D5499SENDER, rloc16 0x3000, role 3, rssi -16, age 98

And this does not pass from where.. it is really blocked, even if I press enter it does not change anything.

2 - Then in the other node, the one how is spamming messages I tried

while True:
    #print("sent to br")
    #ip = "1:2:3::4"
    #port = 5555
    #pymesh.send_mess_external(ip, port, "Hello World number 2)
    pymesh.send_mess(0x70B3D5499F8DBDD0, "Hello World number 2")
    time.sleep(3)

the option with pymesh.send_mess was working, but then it stopped and I don't know why .. using the function pymesh.send_mess_external it gives the error "no BR (mesh-external IPv6) found"

Any idea ? sorry for the long post

Thank you

[catalin]

@ricardolima After declaring the BR, do you see in the network the nodes starting to have a new IPv6 unicast address with prefix `2001:cafe:cafe:cafe:'?

The error no BR (mesh-external IPv6) found comes from not being able to find this ipv6 prefix.

If this is the case, probably I should start investigating this issue.

[ricardolima]

@catalin
the node sending to the br says

Role 4, Single False, IPv6: ['fdde:ad00:beef:0:0:ff:fe00:fc00', 'fdde:ad00:beef:0:0:ff:fe00:1400', 'fdde:ad00:beef:0:0:0:0:3bda', 'fdde:ad00:beef:0:cb3d:2abf:bcb3:839', 'fe80:0:0:0:72b3:d549:9b77:3bda']
Neighbors: Router MAC 0x70B3D5499B773BDA, rloc16 0x1400, coord (51.45, 5.45313), neigh_num 1, ts 485
MAC 0x70B3D5499777124D, rloc16 0x5800, role 3, rssi -26, age 11

And the br says

Role 3, Single False, IPv6: ['fdde:ad00:beef:0:0:ff:fe00:5800', 'fdde:ad00:beef:0:0:0:0:124d', 'fdde:ad00:beef:0:6b76:e43d:813b:f49d', 'fe80:0:0:0:72b3:d549:9777:124d']

What do you think? it is a issue?

Thank you

[ricardolima]

@catalin
No news about this ?
Happy new year for all

[catalin]

@ricardolima
Sorry for the late answer. I am investigating this, seems from the last openthread update, some BR functionality fails.

[ricardolima]

@catalin Ok thank you.
Waiting for news :D

[catalin]

@ricardolima
Yes, the BR functionality was re-factorized in a new module, and it was fixed.
LoRaWAN coexistence with Pymesh, is also being exposed in the micropython API.
Refreshing the base software (probably esp32 idf v.3.3.1) will also be integrated.
I am targeting this week(Th) to re-release Pymesh.

[ricardolima]

Ok thank you ! You will resend the file to all users that have asked permission to use Pymesh ?

[catalin]

@ricardolima Yes, I'll make an email list with everyone that already signed the licence.

[jclo13]

hello @catalin, I I have followed the procedures to download the latest firmware through Pybytes and I am using pymesh microphyton API, the problem I have is that with the following code the system chashes or not connect whit the other nodes, I do not know if it is a firmware problem or what it is due to, I will appreciate your help.

from network import LoRa
from mesh import LoraMesh
import ubinascii
import socket
import utime
from  LoraWan import lorawan
import cayenneLPP
import config
import machine
from machine import SD

pycom.rgbled(0x0000ff)                  #blue
time.sleep(0.2)

pycom.rgbled(0x000000)

sd = SD()
os.mount(sd, '/sd')
f= open('/sd/reenvio.csv', 'a+')
r= open('/sd/reenvio.csv', 'r')
os.listdir('/sd')



while True:

    print('##################### Conectando  MESH ##################')
    lora = LoRa(mode=LoRa.LORA, region=LoRa.US915, frequency = 904300000, bandwidth=LoRa.BW_125KHZ, sf=7)
    masterkey = ubinascii.unhexlify("12345678")
    pymesh = lora.Mesh(key=masterkey)
    pymesh.border_router("2001:dead:beef:caff::/64", 0)
    time.sleep(5)
    print("IPv6 unicast addresses: %s"%pymesh.ipaddr())
    print("4")
    pycom.rgbled(0xff00)                 #GREEN
    time.sleep(0.3)
    pycom.rgbled(0x000000)
    #IP=mesh.ipaddr()
    #ipBR=str(IP[0])

    #creando sockets:

    s_EID = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
    s_EID.bind(config.puertoEID)

    s_BR = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
    s_BR.bind(config.puertoBR)

    s_mesh=[]
    s_mesh.append(s_EID)
    s_mesh.append(s_BR)

    data= "hola"
    id=0
    ip=0
    cont=0

    #escuchando mesh
    while cont<config.acumulador:
        time.sleep(4)
        paquete= Loramesh.receive_pack(s_mesh)
        if paquete!=None:
            data=paquete[0]
            ip=paquete[1]
            port=paquete[2]
            print("-----------PAQUETE:%d-------"%cont)
            print ('datos recividos:  %s'% (data))
            pycom.rgbled(0xff00)                 #verde
            time.sleep(0.2)
            pycom.rgbled(0xff00)                 #verde
            time.sleep(0.2)
            pycom.rgbled(0x000000)
            time.sleep(2)
            f.write('{},{},{}\n'.format(data,port,utime.localtime()))
            cont+=1