Nicla: Powering from battery issue.

[gutzchi]

Good afternoon.

It seems that the Arduino Nicla does not work properly if powered directly from a battery. If first, it is powered from the USB and then the USB is unplugged while the battery is on, everything is fine.

Moreover, the bootloader seems to work properly as the LED flashes three times every time the reset button is pressed. I am using a 3.7V Li-ion battery.

Has anyone had the same problem?

May it be due to a software configuration of the power IC?

Thank you very much for your cooperation.

[giulcioffi]

Hi @gutzchi,
the issue you are encountering could be related to an erroneous behavior of the bootloader.
Would you mind uploading this new bootloader and provide us some feedback?
NiclaSenseBL.zip
You can update the bootloader from the IDE (Tools->Burn Bootloader). You just need to replace the bl binary file provided inside the core with the new one that I sent you.
Thanks!

[hpssjellis]

@gutzchi off topic, but I notice all Arduino MBED bootloaders have .hex files except the NicolaVision and PortentaH7.

https://github.com/arduino/ArduinoCore-mbed/tree/master/bootloaders

(I have a DAP debugger that needs a .hex file. )

Even the Nano33Ble has a .hex file. Can these be added to the 2 that don't have them? Is that a mistake or should I write a feature request?

Noobie type question: Can we burn any binary file (.elf, .bin .hex) using that little hack or is that just for burning bootloaders?

[giulcioffi]

Hi @hpssjellis, you can actually generate any kind of binary file from the .elf file :)
If you need the .hex file, you can generate it with objcopy -O ihex bootloader.elf bootloader.hex .

About your second question, the Burn Bootloader command executes a recipe to program the bootloader, taking the binary file from its dedicated path inside the core.
If you want to program the board with another binary which is not a bootloader, I strongly suggest you to avoid replacing the bl binary inside the core: it would be very misleading because you would need to keep the same name of the bootloader file used by the recipe.
However you can copy the command line generated by Burn Bootloader, paste it inside a terminal, adjust it with your new binary path and execute it.

[gutzchi]

@giulcioffi I am really sorry for my late reply. My most sincere apologies.

I have burnt the new bootloader with the same results as in the previous case. However, as I am not in my lab, I have tried powering it with a 3.3V voltage source (instead of the battery) and surprisingly, it works fine. This might be a hint.

[giulcioffi]

@gutzchi would you like to try the new core 3.0.0 and let me know if you still have the battery issue? Thanks!

[gutzchi]

@giulcioffi Congratulations! It works properly now! If I may ask, what was the problem?

[giulcioffi]

Oh, finally :) it was due to improper operations done on the Chip Disable pin of the PMIC.

[CiprianFlorin-Ifrim]

Hey there @giulcioffi, I am letting you know that the issue still persits if the hardware UART is in use.
Example: I have a UART connection between a device and the Nicla Sense ME. The cable and the battery are both connected. I upload the code to the Nicla, everything works fine.
I remove the cable, with the battery still attached, it continues to work fine,
I remove both the cable and battery, then I only connect the battery, it does not work. I have tried adding delays in the void setup hoping the issue is created by the battery power-up of the Nicla, it didn't solve anything.

Here is the simple code (although I doubt it matters), the Nicla is attached to a DFPlayer Mini:

#include <Arduino.h>
#include "Nicla_System.h"
#include <DFPlayerMini_Fast.h>

// Create the Player object
DFPlayerMini_Fast myMP3;

void setup() 
{
  delay(5000UL);
  Serial1.begin(9600);
  nicla::begin();
  myMP3.begin(Serial1, true);
  myMP3.volume(30);
}


void loop() 
{
  //playVoice(1, 1);
  myMP3.playFolder(1, 1);
  delay(5000);
}

If I run the LED blink, then it works fine with just the battery, without the cable.
I can post some videos of the issue if you want to.

Edit: I am on MBED 3.0.1
Edit 2: Added video demo of the issue:
https://user-images.githubusercontent.com/94687473/163693733-34d3a2c2-5011-4e5a-b3ae-8a76c91e92d5.mp4

[giulcioffi]

Hi @CiprianFlorin-Ifrim,
I tried a simple Blink with prints on the UART and I don't have any issue powering from battery only.
What do you mean by "it does not work" when you connect only the battery? Does the board at least boot showing 3 blinks on the blue led? I suggest you to add some LED activity in the setup of your sketch to understand if the sketch starts to run and locks somewhere.

[CiprianFlorin-Ifrim]

@giulcioffi Hey, by "it does not work" I mean, as seen in the video, that the LED blinks 3 times, color blue, then it just stops. And this happens with UART to a module, with UART to a PC or a blink it does work for me as well.

In the previous video, you can see the Nicla attached to a DFPlayer Mini which communicated through UART. And it does not work without me reflashing if the battery is connected first, then the usb. If I do the other way around, USB first, then Battery, it does work, after I remove the usb cable.

[giulcioffi]

Hi @CiprianFlorin-Ifrim, I don't have a DFPlayer Mini, but I uploaded your sketch with some LED activity in the middle, to highlight if the sketch stops somewhere or not

#include <Arduino.h>
#include "Nicla_System.h"
#include <DFPlayerMini_Fast.h>

// Create the Player object
DFPlayerMini_Fast myMP3;

void setup() 
{
  delay(5000UL);
  Serial1.begin(9600);
  nicla::begin();
  nicla::leds.begin();
  myMP3.begin(Serial1, true);
  nicla::leds.setColor(green);
  myMP3.volume(30);
  nicla::leds.setColor(blue);
}


void loop() 
{
  //playVoice(1, 1);
  myMP3.playFolder(1, 1);
  delay(5000);
  nicla::leds.setColor(red);
  delay(5000);
  nicla::leds.setColor(blue);
}

I also connected Nicla Sense UART to a MKR board to read the messages and I see Nicla Sense blinking and the messages exchanged in all the powering setups.
I am not sure about what's going on in your setup. I cannot really understand how the two boards are connected from your video. Is the GND shared between the two boards?
You could try the same test that I am running, this can help you debug your issue.

[CiprianFlorin-Ifrim]

Hi @giulcioffi, the DFPLayer's UART is connected to Nicla's UART, the Busy pin from DFPlayer to Nicla's GPIO3/P0_10. GND common, and the VIN from DFP to the battery, the battery also connected to the Nicla Sense.
That's all.

In my case, if I add an LED blink in the loop, the code stops just before "myMP3.playFolder(1, 1);". Afterwhich the code is supposed to go from LED blue to LED led, and it does not happen.

[giulcioffi]

If the LED turns blue and never changes again, then the sketch got stuck inside the playFolder().
How do you handle the Busy pin from the sketch? Please notice that nicla::begin() sets GPIO3 as an OUTPUT with HIGH level.

[CiprianFlorin-Ifrim]

@giulcioffi
Yes, I have noticed that Nicla begin sets GPIO3 to high, in the example code provided, I am not using the Busy pin, so it should not matter.

In my main sketch, the Busy pin is set to input and LOW, in the Void setup after nicla::begin() and then I have "while (!digitalRead(GPIO3)); which simply blocks the code while the audio file is playing.

Nevertheless, the code does not work with the initial example code which does not make use of the busypin/while etc. However, it does work if the USB is connected first, then the battery 1 sec later. Which is the problem I am having.

From the led I understood the issue is that as soon as it needs to send the hex code(representing the file to play) to the DFPlayer through UART, it stops.

As a separate question, why does the GPIO3 needs to be set high by Nicla:begin and does it affect the board if then in my sketch I have pinMode(GPIO3, INPUT) and digitalWrite (GPIO3, LOW), therefore, reverting the pinmode and digitalwrite from the nicla::begin?

[giulcioffi]

If the issue in on the UART communication, it's a bit strange that the myMP3.volume(30); call goes fine since UART messages are sent also in that case.
About the GPIO3, nicla::begin() configures it in that way to make Nicla Sense usable as a shield on top of a MKR board. On a MKR board that pin is a RESET pin, so we need to set it in this way.
Anyway, you can configure it as you want AFTER the nicla::begin() call.
I also noticed a bit of confusion in what you wrote before: if you set that pin as an input, you can read it with digitalRead(pin), while if you set it as an output you can drive it with digitalWrite(pin, value). From what you wrote before, it looks like you are mixing these combinations.

[CiprianFlorin-Ifrim]

@giulcioffi
In regards to the digitalRead and Write, you misunderstood.
I am doing:

void setup () {
nicla::begin();
digitalWrite(GPIO3, LOW);                     // already set as output in the library
pinMode(GPIO3, INPUT);

Serial1.begin(9600);
myMP3.begin(Serial1, true);                            // the true boolean is to enable debug mode 
myMP3.volume(30);
}

void loop() {
myMP3.playFolder(3, 5);                // this means folder 3, file 5
while (!digitalRead(GPIO3));
}

I have also checked the voltage from the DFplayer to see that there is no issue. The busy pin and UART have a high of 3.34volts and a low of 0.04 volts. So that should be alright.

I also tried disabling/enabling DEBUG mode for the DFPlayer, same situation.
It seems to work fine with my Arduino Mega 2560.

Indeed the volume is sent fine, but then it gets stuck in the loop. I have tried 3 different DFPlayer MINI libraries made by the company of the module, and the 2 from 2 users. And all behave the same way.
I have also tried 5 different DFplayer modules, all behave the same. Also tried a fake DFPlayer and a clone MP3-TF-16P.

Thanks for letting me know in regards to the MKR Board and why it is setup like that by default.