One of our products currently in production uses the EM7565 cellular module (USB 2.0). We have observed occasional firmware corruption in the module, which we believe occurs due to sudden power loss while USB communication is active. Our system provides a 250 ms hold-up time on the 3.3V power supply for the cellular module. Since the product is already in production, extending this hold-up time to 8 or 21 seconds to properly suspend USB communication is not feasible.
We understand that the USB interface remains active during both Normal and Low Power modes.
Query1: Are the USB 2.0 Power-On/Off timing parameters listed in Table 4-6 applicable only to Normal and Low Power modes?
Currently, we are testing a method to transition the module from USB active (Normal/Low Power mode) to USB deactivated (Sleep, Off, or Disconnected mode) within the 250 ms hold-up time, based on the module’s capabilities. Our plan is to deactivate the USB interface immediately upon activation of the hold-up circuit and then assert the Full_Card_Power_Off# signal.
Query 2: Would this approach be sufficient to prevent firmware corruption?
Query3 :Additionally, could you please advise how this USB deactivation can be implemented through a firmware change using the DPR pin?
Query 4 :Is DPR pin good enough to be used for controlling the different modes of Cellular module during power off ?
I am not sure if your method can help to prevent such problem when unexpected power cut as it is not completely following the power down sequence in specification.
BTW, will your host platform have enough space for storing the firmware?
If yes, I will suggest you also implement firmware redownload when seeing module stuck in download mode after unexpected power cut.
Since the issue is in service unit, In order to upgrade the firmware, i would need some details on below.
Is there any changes in the latest firmware with respect to power up /power down /versus modes of operation ?
Is there any way of controlling the different modes of cellular from SW , which ensures to move it to sleep mode automatically as the power supply is becoming less than the threshold ?
What will happen if Full_Card_Power_Off is asserted while the module is booting up ?
FYI : Here in lab we are trying to recreate the failure scenario , only by powering on and off continuously . And once in 400 times while doing this turn on & off , it enters in QDL mode.
Is there a way to generate the log from the corrupted module , to analyze at which stage this firmware corruption happened ?
Can you please explain , if the firmware is already existing in the module , what are the reasons for it to again go into BOOT ?
if it was the sudden power loss and not meeting the timing diagram , it would have happened every time. and this would have happened on every unit. We tried to recreate this but it doesn’t recreate everytime?If its a HW fault it would have happened every time , but it only occurs on few units that too occasionally on field.
Can you tell me what all scenarios can the unit be stuck in low power mode? And if it is so whether re- Firmware download is possible.
