Modem crash when deleting or uploading script sometimes

5 thoughts on “Modem crash when deleting or uploading script sometimes”

  1. I’m trying to upload a bunch of Python scripts to a GL865-DUAL but every now and then I run into issues when either deleting the old .pyo file or uploading the new .py file.
     
    From my application:

    [DBG] GL865: Uploading CUHandler.py (2357 bytes)

    [DBG] AT#DSCRIPT="CUHandler.pyo"

    OK
    [DBG] AT#WSCRIPT="CUHandler.py",2357
    [ERR] GL865: Timeout waiting for script upload prompt.
     
    From the modem: 

    SYSendMsg – queue error – err code -46

    13 200
    AT QUEUE FULL 
    Prim 13  Mess         0  Task_Id BA
    Prim 78  Mess    19C85E  Task_Id BA
    Prim 78  Mess    19C88E  Task_Id BA
    Prim 13  Mess         0  Task_Id BA
    Prim 27  Mess    19CF8E  Task_Id BA
    Prim 179  Mess    19C08E  Task_Id BA
    Prim 154  Mess    19C67E  Task_Id BA
    Prim 78  Mess    19C6EE  Task_Id BA
    Prim 106  Mess    19D4AE  Task_Id BA
    Prim 179  Mess    19D56E  Task_Id BA
    Prim 200  Mess    19DFAE  Task_Id BA
    Prim 154  Mess    19E42E  Task_Id BA
    Prim 279  Mess     815F0  Task_Id BA
    Prim 13  Mess         0  Task_Id BA
    Prim 1157  Mess     81E10  Task_Id RR
    Prim 1299  Mess     80E10  Task_Id BA
    Prim 13  Mess         0  Task_Id BA
    Prim 279  Mess     812D0  Task_Id BA
    Prim 13  Mess         0  Task_Id BA
    Prim 13  Mess         0  Task_Id BA
    Last FN 2538042
    Protocols Version: 5.05.000
    System Version: 10.00.154.2-B000
    *** SYExit(10) [ Message fail ] called from B85FEC (task BA) PSW 0042
    MDL  0000 MDH  0000 MDC  0000 CP   FC00 DPP0 0002 DPP1 0022 DPP2 0002 DPP3 0003
    R0   4F10 R1   0002 R2   0022 R3   0002 R4   0003 R5   001A R6   0006 R7   04BE
    R8   FFD2 R9   00C8 R10  0EF6 R11  0022 R12  0022 R13  3C1A R14  0003 R15  4F2C
    System stack (SP 0000FC00, 0 words on stack):
    User stack (USP 00088F10, 128 words on stack):
    000A 0000 0010 00B8 5FEC 0042 0000 0000 0000 FC00 0002 0022 0002 0003 4F10 0002 
    0022 0002 0003 001A 0006 04BE FFD2 00C8 0EF6 0022 0022 3C1A 0003 4F2C 0000 FC00 
    0000 0008 8F10 0080 3C00 0003 0080 3C20 0003 0010 00B8 5FEC 0006 04BE FFD2 00C8 
    00B8 5FEC 000A 00C8 04BE 0067 0010 000D 04BE 0067 0001 0067 00AC 9E32 00C8 0067 
    0003 0000 0006 00C8 0001 0067 00AD DE80 04BE 0067 0000 0596 04EE 04BE 0067 09BE 
    0067 9FC6 0002 0000 0006 001B 0001 0067 00AD D054 04BE 00AD F638 0000 0000 0004 
    0000 0000 0000 0005 0000 00AD 3BB6 0000 0000 0000 0000 0000 0002 0003 0000 0000 
    0000 0000 0000 0000 0000 0000 0000 0000 F000 00C5 A710 04BE 0067 0000 00C5 A756 
    Crash Profile writes 4153 bytes succesfully
     
    Anything I can do to prevent this? Should I take some additional steps before uploading? 

    1. Hi,

       

      do you send the AT#WSCRIPT immediatelly after the AT#DSCRIPT OK response or there is a 2-3 second pause in between?

      I’m asking this because even if #DSCRIPT returns the OK, the delete operation is done in background and it can interfere with #WSCRIPT. 

  2. Aha, I did not know that. I was not waiting before writing so that could very well be it. However, now I can’t upload the script at all:

    [DBG] AT#DSCRIPT="CUHandler.pyo"

     

    +CME ERROR

    [DBG] AT#DSCRIPT="CUHandler.py"

     

    +CME ERROR

    [DBG] AT#WSCRIPT="CUHandler.py",2357

     

    +CME ERROR

     

    I’ll try to switch units to verify that I haven’t broken the old one. 

    1. Hi

       

      just +CME ERROR without any other cause?

      Can you set AT+CMEE=2 and check again the error response?

      AT#RSCRIPT and AT#LSCRIPT are also failing?

       

      Otherwise try AT+CMAR=00000000 to format the NVM and start from a clean situation.

      1. It was just giving error with no more information. I just switched back to the broken unit and for some reason it seems to be working now (of course). I will keep an eye out and try your suggestions if it happens again.

        Thanks!