FiPy Hangs after Deepsleep - LED stays on

[Cees_Meijer]

This is a follow-up on my post where I assumed that the problem was caused by random 'Guru meditation errors'. Closer monitoring showed that this was not the case. It does actually reboot after such an event, but occasionally completely hangs without any error message.
It is worth noting too that the same software , with the same peripherals and power supply has been running fine on a GPy for several months without a glitch.
The FiPy just every once in while stopped completely and could only be restarted after a hard reset or power cycle. Then I noticed that the blue LED was always ON when the system crashed, so I started to suspect the heartbeat routine. And indeed, switching this off seems to solve the problem. I disabled the 'heartbeat on boot', and just manually blink the LED once (on medium intensity) when the system starts up. Now I also ran a test, with the same software, on a standard PyCom development board, and here it does not seem to happen. So it is probably related to the the wiring and power supply of the peripheral board.
Given the fact that it does not happen on a GPy makes me think that the FiPy is not just simply a GPy with LTE modem, but there is a small difference in the way the LED is connected (different decoupling capacitors?) or power routing on the board. But since the design and schematics of the boards is as secret as the Coca-Cola formula, I'll probably never know.

[Cees_Meijer]

@Gijs : This is the essence of my program:

import time
from machine import Pin

# Read a value from the NVS
def get_value(key='',default=0, min =0, max =0):
    try:
        val = pycom.nvs_get(key)
    except:
        #print("Error while reading from internal storage ["+key+"]")
        val = default
    if min != max:
        if val < min:
            val=min
        if val > max:
            val = max
    return val

def TxDriverPower(on_off=True):
    if on_off == ON:
        print("Tx ON")
        rx_driver_disable.value(1)
    else:
        print("Tx OFF")
        rx_driver_disable.value(0)

try:
    time.sleep(0.5)
    print("Wake up ["+ str(machine.wake_reason()[0]) + "] - Reset [" +str(machine.reset_cause()) +"]")
    location_ID= get_value('ID',0)
    NBIOT = get_value('NBIOT',1, 0, 1)
    
    tx_driver_enable = Pin('P22', mode=Pin.OUT)
    rx_driver_disable = Pin('P21', mode=Pin.OUT)
    TxDriverPower(ON)   ## Switch ON the MAX3227 RS232 Driver chip
    
    #IF IT CRASHES, IT NEVER GETS BEYOND THIS POINT
#
# READ A SENSOR,  SEND DATA THROUGH LTE ETC.
#
  
    print("TEST: Go to DEEPSLEEP ! 300 seconds")
    machine.deepsleep(( 300 )*1000)

# End of Main loop
except Exception:  # Any uncaught exception will trigger a reset
    print("Error in program:"+ str(sys.exc_info()[0]) + str(sys.exc_info()[1]) )
    time.sleep(1)
    machine.reset()

Of course there is much more going on, but if it crashes it is always shortly after the waking from deepsleep. When the FiPy is connected to the MAX3227 (which is enabled in the TxDriverPower(ON) function) it crashes about once every 10-50 measurement cycles. With the FiPy just mounted in the development board (nothing connected) it crashed after about two days.
After disabling the heartbeat, I had 4 systems running for 3 days now without a problem.

[Gijs]

Hi,
Ill do some research around this issue. Can you perhaps provide how you get this issue to occur. I've tried several things but cannot get the heartbeat to occur concurrently with with waking up the module from deepsleep
Best,
Gijs

[Cees_Meijer]

Another observation (I do not know where else to post them..)
The FiPy does hang when running on a standard development board, only it happens less often. This time it happened after two days. So I must conclude there is something wrong with the hardware of the FiPy ! And the workaround is to disable the heartbeat !

[Cees_Meijer]

@Gijs I think it's a hardware thing. It looks like the 3.3V is critical when the system comes back from deepsleep, and the switching of the LED can cause a reset. I have done some intense testing over the weekend, and it looks like switching the heartbeat off solves my problem for now. I did notice though that the FiPy which is running just the software on a standard development board does not suffer from the complete, unrecoverable stop, but it does do an occasional full reset. So I do think there could be a potential problem with the FiPy hardware.

[Gijs]

Is this solution working for you? Or do you believe it is a firmware bug?
Let me know!
Gijs

[Cees_Meijer]

As I'm not allowed to edit the post anymore, I decide to add my findings here:

The board contains a MAX3227 RS-232 driver, which is powered from the 3.3 V connection on the FiPy. When the deepsleep ends, I enable the MAX3227 and this probably causes a short power surge to the 3.3V line since it starts up the internal charge-pumps to generate the + and - 5V. And when this start-up aligns with the first blink of the LED, the FiPy hangs.