factoryDefault seems to kill the modem

[erazor83]

It seems factoryDefault seems to kill the modem so it'll never respond to any AT.

The module responses correctly after that line and got stuck for the modem.waitForNetwork check for me. I've unplugged it after about 15 minutes while it runs the modem.waitForNetwork loop.

After that it never answered any AT anymore.

[Forairaaaaa]

Hi, I've tried that function like this:

void killing_test()
{
    //** using this kills my modem **
    modem.factoryDefault();

    delay(2000);

    SerialAT.printf("ATE1\r\n");
    Serial.printf("ATE1\r\n");
    while (1) {
        SerialAT.printf("ATI\r\n");
        Serial.printf("ATI\r\n");
        while (SerialAT.available()) {
            Serial.write(SerialAT.read());
        }
        delay(1000);
    }
}

And it really "killed" my dtu haha

Into that function:

bool factoryDefaultImpl()
{
    thisModem().sendAT(GF("&FZE0&W"));     // Factory + Reset + Echo Off + Write
    thisModem().waitResponse();
    thisModem().sendAT(GF("+IPR=0"));     // Auto-baud
    thisModem().waitResponse();
    thisModem().sendAT(GF("&W"));     // Write configuration
    return thisModem().waitResponse() == 1;
}

I've only fonud +IPR=0 in the datasheet: https://m5stack.oss-cn-shenzhen.aliyuncs.com/resource/docs/datasheet/unit/nbiot/SIM7020%20Series_AT%20Command%20Manual_V1.05.pdf which changes Factory setting is "AT+IPR=0"(auto-bauding). That might be why, but I not quite sure

[Forairaaaaa]

I've report it to the fae of the module, to see if they can figure it out

[erazor83]

Ok. So first of all, it's not an hardware issue.

Second, it's possible to kill it via software but currently there seems to be no way to get it running again easily.

Maybe it's ATFZE0 which causes the issue, but then again if it's not listed as a command there should be an error.

I also assumed the modem simply does not understand the AT command cos of an invalid baudrate.

Page 14 of the datasheet says, there should be an RDY on startup where autobaud is not activated - since I'm not getting anything at startup (used a USB-USART interface) it seems like it's still in autobaud. So maybe It's about invalid parities? - I've checked this also with no success.

The modem has some kind of sleep mode which can be deactivated via a LOW on DTR - I've tried this also.

Toggling the Reset PIN doesn't change anything either.

I think the modem has USB - that could be a way to reach it but I'd stop experimenting at this point.

[erazor83]

Just an idea. The command &FZE0&W should most likely be &F0;E0;&W.

Page 15 says, there should be a semicolon between commands. I've no idea if combining without is allowed anyway.

But I think the issue can be FZ instead of F0 - maybe internally in the modem the software does not check for a valid configuration index (I suppose they configured it index based, because of the 0). So it points to a invalid index and the module crashes on startup.

Perhaps a software-update of the modem would help?

[Forairaaaaa]

Good idea, maybe find a way to re-flash it is the best way now

[felmue]

Hi guys,

this is really interesting and I am curious as to what the solution will be.

@erazor83 : I think AT&FZE0&W in single commands would be AT&F, ATZ, ATE0, AT&W. The parameter for AT&F seems to be optional as it is listed in []. But yes, whether the parser in the modem firmware is clever enough to parse the combined commands (w/o semicolon), is an open question. It could very well be like you suspect that the parser incorrectly picked the Z as the optional parameter for the AT&F command.

BTW: Maybe irrelevant, but TinyGSM officially doesn't support SIM7020 yet (only a pull-request). From the README file: More modems may be supported later: ... SIMCom SIM7020 ...

Thanks Felix

[erazor83]

Hi @felmue,

I've been using TinyGSM latest git with 7020 and suppose it even works like "SIMCom SIM7000E/A/G CAT-M1/NB-IoT Module" - so maybe that's why it wasn't necessary to explicitly add 7020. I've seen branches where people added 7020 anyway.

Initially I had a lot of trouble with network registration and that's why I tried modem.factoryDefault()

Has anybody contact with simcom? Currently I can't find anything about how to update their modem firmware. It's also a bit strange their AT-Command-Manual is Version 1.02 while M5 supplies version 1.05.

@Forairaaaaa I also need to wait for the response of M5 team since I have 4 unusable DTU modules now and more or less for me it seems like a warranty case. I need to know how to deal with my supplier. But anyway, I'd keep one module and would like to find a solution since this topic already took a lot of time.

Edit: I'm just happy I'm not the one who wrote the modem firmware ;-)

[felmue]

Hello @erazor83

The FOTA document describes how to upgrade modem firmware.

However it requires the modem to still accept AT commands...

Thanks Felix

[erazor83]

@Forairaaaaa any update on this?

[Forairaaaaa]

@Forairaaaaa any update on this?

FAE from Simcom says they're starting a test already, should be some updates soon I hope

[erazor83]

@Forairaaaaa Any update? Weeks have passed...

[Forairaaaaa]

@Forairaaaaa Any update? Weeks have passed...

I'm sorry, we still working on it

[felmue]

@Forairaaaaa

any news? Tick tack, tick tack, ...

Thanks Felix

[felmue]

Hello guys

I bought two SIM7020G modems (Hat and AtomDTU) and tested with the above compound AT command, e.g. AT&FZE0&W. Both modems responded with ERROR to the command, but more importantly both did not break and are still responding to AT commands.

Testing the AT+IPR=0 command is next.

Thanks Felix

[erazor83]

@felmue Maybe there is a newer firmware on these modules? How good is the net registration? I was barely able to get my modems into the cellular network.

@Forairaaaaa is there any way to update the firmware of the modem?

[felmue]

Hello @erazor83

Re firmware AT+GMR: SIM7020 Hat: 1752B02SIM7020 SIM7020 AtomDTU: 1910B03SIM7020

So all I can say is that the Hat has older firmware than the AtomDTU.

Did you by happenstance read the firmware version of your modems before they became unresponsive?

Registering the modem to the celluar network can be tricky dependent of the distance to the tower. But normally (provided the correct APN is set) the connection from a cold start is quite quick for me.

BTW: Restricting the band AT+CBAND (if applicable) can help with scan time.

Thanks Felix

[felmue]

Hi @erazor83

I've sent the three command lines from factoryDefaultImpl posted by @Forairaaaaa multiple times to both of the two SIM7020 modems, but so far it did not make them unresponsive. So either the two modems are running a firmware which is not affected by this issue or maybe the timing is wrong or something.

Thanks Felix

[felmue]

Hi guys

I finally managed to break (and fix) my SIM7020G modem.

Short answer: my SIM7020G switched to a baudrate of 1'500'000. So give that baudrate a try.

Long answer: using the complete code from factoryDefaultImpl for the SIM7020G, e.g.

    bool factoryDefaultImpl()
    {
        sendAT(GF("&F0"));     // Factory
        waitResponse();
        sendAT(GF("Z0"));     // Reset
        waitResponse();
        sendAT(GF("E0"));     // Echo Off
        waitResponse();
        sendAT(GF("&W"));     // Write
        waitResponse();
        sendAT(GF("+CSOSENDFLAG=0"));     // Disable TCP Send Flag
        waitResponse();
        sendAT(GF("+IPR=0"));     // Auto-baud
        waitResponse();
        sendAT(GF("+IFC=0,0"));     // No Flow Control
        waitResponse();
        sendAT(GF("+ICF=3,3"));     // 8 data 0 parity 1 stop
        waitResponse();
        sendAT(GF("+CSCLK=0"));     // Disable Slow Clock
        waitResponse();
        sendAT(GF("&W"));     // Write configuration
        return waitResponse() == 1;
    }

and power cycling the modem made it unresponsive on UART1 as it switched baudrate.

I then soldered some wires to UART2 (which still was using baudrate 115200) and found the modem is alive on that serial port. Unfortunately I did not find a way to reset the baudrate of UART1 from UART2.

But I found that when the modem is turned off via PWR KEY it would send a NORMAL POWER DOWN message which was readable on UART2 but looked like garbage on UART1. The good thing was that the garbage always looked the same.

So using an oscilloscope to measure the length of the message and compare the two I realized that the baudrate on UART1 was higher than the default 115200. Unfortunately my measurement wasn't precise enough (1700 uS vs 105 uS) which gave me a too high baudrate, e.g. 1'865'142 and still garbled output.

So I switched to trying out different higher baudrate one by one. Luckily I found this list here and starting from the top I got the one UART1 has switched to.

Interestingly reading the baudrate using AT+IPR? returned 268'509'284. How this number results in a baudrate of 1'500'000 I don't know. Maybe you have an idea?

@erazor83 : let me know if using that baudrate helps with your unresponsive SIM7020s.

Thanks Felix

[erazor83]

Hi Felix, thanks for debugging this. I'll have a look but am quite busy at the moment.

I'll let you know. Have a great weekend!

[felmue]

Hi @erazor83

just wondering. Are your modems back alive?

Thanks Felix