Free memory issues ?

  • Ok guys, my Python skills are nearly 0.5, but this is driving me nuts...
    I did a small script that scans for BLE advertisers and pushes their data thru mqtt. Every scan cycle I also change led color and test free memory, asking for gc() if mem falls below 30000.
    WDT is enabled and feeded after any advertisement received. What i cannot understand is why free memory falls often well below 30000 (seen even only around 1K free), and after a while WDT kicks in and wipy 2 restarts. Why ? What stupid thing am I doing ?

    Thanks for everyone assistance


    from network import Bluetooth
    from binascii import hexlify
    from network import WLAN
    import utime
    import gc
    import pycom
    import machine
    import os
    import sys
    import ujson as json
    from umqtt import MQTTClient
    from machine import WDT
    def settimeout(duration):
    # json.dumps()
    fwver  = os.uname()[2]
    ipaddr = WLAN().ifconfig()[0]
    mymac  = hexlify(machine.unique_id()).decode()
    bt = Bluetooth()
    pubmsg = ""
    free = 0
    wdt = WDT(timeout=20000)
    client = MQTTClient(mymac, "", port=1883)
    client.settimeout = settimeout
    if machine.reset_cause() == machine.WDT_RESET:
        pubmsg = "{\"ts\":" + str(utime.time()) + ",\"fw\":\"" + str(fwver) +"\",\"ip\":\"" + str(ipaddr) + "\",\"mac\":\"" + mymac + "\",\"why\":\"WDT_RESET\"}"
        client.publish("/stat", pubmsg, retain=True, qos=1)
    while True:
            free = gc.mem_free()
            if free < 30000:
            pubmsg = "{\"ts\":" + str(utime.time()) + ",\"fw\":\"" + str(fwver) +"\",\"ip\":\"" + str(ipaddr) + "\",\"mac\":\"" + mymac + "\",\"free\":" + str(free) + "}"
            client.publish("/stat", pubmsg, retain=True, qos=1)
            while bt.isscanning():
                adv = bt.get_adv()
                if adv:
                    mac = hexlify(adv.mac).decode()
                        mfg_data = bt.resolve_adv_data(, bt.ADV_MANUFACTURER_DATA)
                        manu_data = hexlify(mfg_data).decode()
                        manu_data = "no data"
                    name = bt.resolve_adv_data(, bt.ADV_NAME_CMPL)
                    if name:
                        pubmsg = "{\"ts\":" + str(utime.time()) + ",\"mac\":\"" + mymac + "\",\"cli\":\"" + name + "\",\"manu_data\":\"" + manu_data + "\",\"rssi\":" + str(adv.rssi) + "}"
                        client.publish("/tomqtt", pubmsg, retain=True, qos=1)
        except KeyboardInterrupt:
            if bt.isscanning():

  • @duffo64

    (Ops... must wait 10 minutes before posting again).

    I have upvoted your post to prevent this ;-)

  • @livius
    Thanks, will try, but at this point I think that WDT is not to blame. I suppose that watchdog kicks in since the environment becomes clogged due to memory shortage.
    Updates are always welcome, nonetheless :)

    (Ops... must wait 10 minutes before posting again).


  • @RichardTXD

    and... you nailed it. Deletion and recreation seems the key here.
    Even if I am not asking for a whole week of uptime, doing at least a clock round would suffice. What's great is that after following your suggestion I am at three hours on 3 different units, and not a single reboot since. Will see...

    So, big thanks !


  • @RichardTXD said in Free memory issues ?:

    as it says 'sigfox'

    Yes, sigfox in name in my opinion is misleading - but not my choice. And yes this repo catch all boards.

    WDT will timeout I presume?

    I guess so too...

  • @livius
    Thanks - didn't know about the issue tracking. Probably would not have paid it attention otherwise as it says 'sigfox' - maybe that means it is a catch all.

    However, if the Bluetooth crashes the WiPy then the WDT will timeout I presume? Might be relevant?
    He is using different parts of the system tho - it was just my experience with Bluetooth...

  • @RichardTXD
    Crash are different thing and should be analyzed deeply by pycom.
    If you have reproducible test case report it here:

    about WDT - try current firmware 1.7.5 maybe something is changed.

  • @duffo64
    I had similar issues just reading BLE advertising packets and printing them to the console. Nothing clever. After a few minutes or a few hours it would crash. It was somewhat random.

    I did not have a WDT implemented.

    I tried gc in various forms, manual, automatic etc here and there, also watched free memory, various combinations all failed. I think about 3 hours was the best I did with this.

    What worked for me.... I told it to scan for just 10 seconds ( I see you set 30 seconds... I used 10for no good reason... didn't try 30). When it stops scanning, you can detect that, deinitizlise the ble object, reinitialize it and start scanning again. It does this really quite quickly.

    I got the above (sadly not clever) scheme to run for 6+ days without a hiccup on a WiPy 2 and expansion board. We have a lot of beacons in the office, it was getting about 8 to 10 packets a second. That seemed to be the best it would do.

    Hope it helps. Something to try anyway. I've not tried by ble code on the last 2 firmware revisions tho.

  • Thanks for your reply, Livius.
    Unfortunately, feeding after start_scan causes the wdt to kick in even more:


    After less than 15 seconds, another reboot:


    ... and so on.

    At this point I cannot understand if it's me, the wdt, the garbage collector, or what.

  • @duffo64 said in Free memory issues ?:


    what if you feed it after above line?

Log in to reply

Pycom on Twitter