The command $PMTK225,4* is not confirmed on every call.
One of the reason could be related to the noisy signal the L86 is generating on the UART line when the state change. But this is not really sure.
So I have two questions:
is that normal to have this command not responding sometime ? (I hav no external circuitry to switch power down)
how to protect the UART com port on the MCU side against the storm of noisy signals sen on the uart when the L86 mode change ? this is locking the MCU uart on STM32 and I have to reset all the Overflow/NE… flags and some communications get lost.
At first there is no relation between size of use and stability of any product (ex Win95)
Thank you for sharing the ref design, I already had the document and it notice that the circuit powering must be controlled by an external circuit. That’s just kidding when the L86 includes a power control circuit internally, so basically this is deactivating the internal backup mode and makes the L86 equivalent to a L80 on this.
the problem is reported on many places on Internet (google will help you to find) and most of people (like I will) have mount an external power circuit to bypass the internal one. So in that case no need to go on backup mode, no problem … this is the “massive solution”, it’s also a massive overcost in circuit design. Making the addition of the million of unexpected circuit makes by the customer something that could pay engineers for years.
the reason for not receiving the response is the way the UART pin are setup after entering in backup mode: they seems to be connected to ground when the normal idle state for an uart line is Level 1 / Disconnected. It has multiple consequences on the host side you can’t always solve:
a) this is generating a storm of uart errors interrupts on the host. It hangs the UART and in most of the cases it is the reason why the responses are dropped. ON the host side we need to reset the UART on L86 wake up to survive.
b) when the MCU is restarting, it detects this abnormal activity on the serial line as a switch to serial mode bootloading on a STM32. This is avoiding the normal program to restart until you shutdown the L86 and restart it.
Quectel fixed the documentation in version 1.2 of hardware design to indicate the backup consumption is not 7uA but 840uA confirming that the behavior of the powering circuit is not what has been designed initially. I assume that is could be clearly indicated that this feature should not be used at all because consumers are spending many time to trying to fix on host side the bugs of the gnss side.
The only positive things is that this situation, compared to the hundreds of other serial components I’ve connected to an MCU, allowed me to learn new things on STM32/Uart tech details.
Dear disk91,
Sorry for the late reply. These days I’m confirming with my coworkers to see if we can do some optimizations on this issue, such as adding notes in document etc.
If you have more complex questions, please send email to support@quectel.com. So that we can provide more professional support.