Power supply via MIC 3385 broken

[CsFreiber]

Hi Simen and others,

we have a problem with one of our IoT Cellular mini moduls. When powering up (via USB or VMUX Jumper) the MCU doesn't react. After measuring the power supply for the MCU we detected a too low voltage ( ca. 0.5V) and the MIC3385 heats up. Therefore we assume this voltage regulator is broken. Are there any other possibilities to power the MCU without the MIC3385? There are no external Pins for power supply without through the regulator.
Have somebody had the same problem and can tell what could caused the defect of the MIC3385?
Thank you for your help!
Best regards

CsFreiber

[M65649]

Hello @CsFreiber,

Could you explain more in detail what happened when this occurred? Could you see if forcing the regulator into LDO makes the MCU boot properly? Try to set PB4 logically high. There is an exposed pad on the back of the board in the upper-right corner of the label under D12.

[CsFreiber]

Hi @M65649 aka Simen,

thank you for your very quick answer! The problem accured while my colleague played with the low_power example. However I don't know exactly how.
I have tried your suggestion. At first only holding a jumper cable to the pad. The current changed from the external power supply (from max output current at 900mA to ca 600mA), so then I tried to solder a cable to the pad in order to have a constant HIGH (3,3V) connection. Of course I was not successfull. I tried by holding the cable to the pad again while trying to compile a programm. Unfortunatly the following error code occurs

An error occurred while uploading the sketch
avrdude: usbhid_open(): No device found
avrdude: jtag3_open_common(): Did not find any device matching VID 0x03eb and PID list: 0x2175

Now I can not tell, if the pad (PB4 Pin) is surely on HIGH, due to my bad soldering skill. If you have any other suggestions that could help, let me know. Of course you could just power the MCU through the cut strapes.

Best regards

CsFreiber

[M65649]

I think you need to open up a support ticket and then we can ship you a new kit. Could you apply here: https://microchip.my.site.com/s/supportservice/?

[CsFreiber]

Thank you for your help! We are going to

[CsFreiber]

Hi,
unfortunatly we think, that the powerDown(const uint32_t power_down_time_seconds) function from LowPower class has a bug.
We tested this function on another AVR-IoT-Cellular mini and we had the same issue as with the one in the post above. The MIC 3385 is getting hot and the MCU can not be reseted or newly flashed. By putting the PB4 PIN on logic HIGH did not solve the problem, that we are unable to flash de MCU. Here is a snipet of our code used:

void setup() {
  LedCtrl.begin();
  LedCtrl.startupCycle();
  SerialMon.begin(115200);
  smartWI_startup(); //  Start LTE and MQTT connection
}

void loop() {
  LowPower.powerDownModem();
  LowPower.powerDownCPU(10);
  LowPower.restartModem();

  smartWI_startup();

  (modem.testAT()) ? SerialMon.println(F("modem connection OK")) : SerialMon.println(F("modem connection failed"));
  (modem.isNetworkConnected()) ? SerialMon.println(F("Network connected")) : SerialMon.println(F("Network not connected"));
  (mqttclient.connected()) ? SerialMon.println(F("MQTT connection successful")) : SerialMon.println(F("MQTT connection failed!"));

  delay(5000);
}

In the low_power.cpp

void powerDownModem(void){
 SequansController.writeCommand("AT+SQNSSHDN");
 delay(2000);
 Lte.end();
}

Basically it is the power_down.ino example from the AVR-IoT-Cellular library. The powerDownModem() function shuts down the modem with the respective AT command. The powerDownCPU(10) is basically the same as the powerDown() function but without calling the Lte.end() and the while(!Lte.begin()), as the modem has been already shut down.

However the power_down.ino example seemed to function.
Do you have any idea, what causes this problem? We suggest the PB4 Pin is somehow not disabled again. This can only be the case, when in the powerDownCPU (a.k.a powerDown() ) the cpu doesn't wake up.

[M65649]

I did a factory reset of a test board now and tested with the following sketch (removing Lte.end() and Lte.begin() from LowPower.powerDown()). It should be quite equivalent to your setup:

#include <avr/io.h>
#include <led_ctrl.h>
#include <log.h>
#include <low_power.h>
#include <lte.h>
#include <mqtt_client.h>
#include <sequans_controller.h>

#define MQTT_THING_NAME "someuniquemchp"
#define MQTT_BROKER     "test.mosquitto.org"
#define MQTT_PUB_TOPIC  "testtopic"
#define MQTT_PORT       1883
#define MQTT_USE_TLS    false
#define MQTT_USE_ECC    false
#define MQTT_KEEPALIVE  180

#define RESET_PIN PIN_PC5

void smartWI_startup() {
    if (!Lte.begin()) {
        Log.error("Failed to start modem...");
    } else {
        Log.info("Modem running");
    }

    if (!MqttClient.begin(MQTT_THING_NAME,
                          MQTT_BROKER,
                          MQTT_PORT,
                          MQTT_USE_TLS,
                          MQTT_KEEPALIVE,
                          MQTT_USE_ECC)) {
        Log.error("Failed to start MQTT...");
    } else {
        Log.info("MQTT connected");
    }
}

void powerDownModem(void) {
    const ResponseResult response = SequansController.writeCommand(
        "AT+SQNSSHDN");

    if (response != ResponseResult::OK) {
        Log.error("Failed to write shutdown command");
    }

    delay(2000);
    Lte.end();
}

void restartModem(void) {
    digitalWrite(RESET_PIN, HIGH);
    delay(10);
    digitalWrite(RESET_PIN, LOW);
    delay(10);
}

void setup() {
    LedCtrl.begin();
    LedCtrl.startupCycle();

    Log.begin(115200);

    smartWI_startup();
}

void loop() {
    powerDownModem();
    LowPower.powerDown(10);
    restartModem();

    smartWI_startup();

    const ResponseResult response = SequansController.writeCommand("AT");

    if (response != ResponseResult::OK) {
        Log.error("Failed to AT");
    }

    delay(5000);
}

This resulted in the following current measured over VMUX:

I haven't been able to break the regulator (yet) with this setup.

[CsFreiber]

Hallo Simen,

thank you for your efforts! Sorry for my late answer, I was not working. This is very strange. At first site you did the same as we did. At this moment I do not have any idea, why this happened with us twice. However we keep investigate the issue and let you know, if we found something.

Best regards

CsFreiber

[M65649]

Please let me know if you find anything.

[CsFreiber]

Hello Simen,

I just wanted to let you know, that we haven't found the cause of this problem. At our current setup we do not need the LDO for power supply. So for the sleep modus we ignore the functions, which manipulate the LDO. Maybe in the future we have got some time and can further investigate, but at this moment it is not necessary for us and therfore has no priority.
We thank you for your support and hope I/we can ask you any other upcoming questions.

Best regards

CsFreiber

[M65649]

Thanks for the update. We haven't been able to find anything either. It's somewhat unfortunate as you get far lower power consumption with the LDO.

Please ask if there's anything else.

[CsFreiber]

Hi Simen,

unfortunatly we have experienced again the same issue on an other AVR-IoT-Cellular device. This time we have only used your power_save example. We have made only the change to comment out the enableLDO() and disableLDO() functions in the LowPowerClass::powerDown, as we have made bad experiences with it (see mentioned above). The library version of AVR-IoT-Cellular is 1.3.9, of the DxCore is 1.5.11. Sadly the MIC3385 for the power managment gets really hot, so we immediatly cutted the power supply (was via an USB C cable to the laptop).
The seriel number of the board is: A09-3437/06 sn1800001232

This time the board seems to function well (the sketch is running and you can flash it), however we haven't powered it for a long time, as we don't want to damage it completly. I have tried your suggestion with connecting the PIN on the back to the GND, but it didn't help. I have uploaded other sketches (for example debug_modem.ino), which doesn't require the low power functions, but the MIC gets extremly hot no matter what.

At this moment we don't think it is our software bug, as we haven't used our code but the one from the example. But as the problem occurs even with an other software, maybe it is really a hardware problem.

I asssume you haven't experienced this issue yet, but maybe someone has? Regardless of trying new software out, the problem should be solved, when you flash a code from the examples (as the configurations should be alright). We are really helpless, especially our student, which is trying the low power functions as it is part of his bachelor thesis.

I know it is a burden, but can you show again, if you get a board in the same bad situation as our already 4 or something boards?
If you need more information let me know and thank you for your help!

Best regards

CsFreiber

[CsFreiber]

Hello Simen,

sorry for my late answer, I had to disscuss the whole cirumstances with my collegue. Here are the answers for your questions:

• We didn't have any other devices connected to the board as this issue occured
• We have only powered this board via the USB. We are in our Digital.Lab and we have no known ESD issues
• We are probing the boards at our ESD workplace
• We have tested the PB4 pin with connecting to the board internal GND or VCC but there is no change to the LDO. The regulator is getting hot in a few seconds

I have contacted the Microchip support (Jeevitha from the support team), the last time you suggested it. They have only wanted to know the circumstances and said we should contact our distributor, to get a replacement. This happend and we got a new board.
However this requires to contact our company purchaser. This results to more costs, then simply buy new devices.
The final answer from the support was: "However, it's important to highlight that the issue concerning the low-power example remains unresolved. The root cause of this problem is currently unclear to us. Therefore, we kindly advise against attempting to use the GitHub code on your new board."
However the thesis of our student is about power managment and the optimization our IoT device for energy consumtion. That's the reason why we are trying the examples out.

I hope I could answer all your question. We could send you the broken board to you, if you like, for further investigation.

Best regards

CsFreiber

[M65649]

Hello,

We will contact the team that has designed the regulator to see if we can get more information from them and to hear if they have experienced this before.

Best,
Simen

[CsFreiber]

Hello Simen,

thank you so much for your quick support and help! We hope we can contribute in this way a design failure or bug so this do not happen to someone else. We are looking forward for your further news

Best regards

CsFreiber

[M65649]

Hello again @CsFreiber. I just want to let you know that we are still working on this but that things are moving a bit slow.

[CsFreiber]

Hello Simen,

thank you for your Update! It is not urgent, as we do not use the LDO at the moment. If you are going to have some news and solutions or if we can help you in some way, let me know.

Best regards

CsFreiber