›

Power Profile MetaMotion R

alessandromontanarialessandromontanari
edited May 2017 in Hardware
Hi,

I am trying to analyse the power profile of a meta motion r using a Monsoon power monitor.
The problem is that if I provide 3.7V to the +bat pin through the power monitor the device does not start.
It starts only if I connect a USB cable while the +bat pin is still connected and powered by the power monitor. In this configuration however the power monitor does not show any current profile.
As soon as I unplug the USB the device stops so I cannot see the power profile.
I have an SD card attached to it.

Any idea?

Thanks!

Comments

  • MattMatt
    alessandromontanari

    How do you have the power monitor attached to the MMR board?  Our R series boards have no problem operating from an external power supply across +Bat.

    If the board is functioning with the USB connected, this is likely supplying more current than the monitor source is capable of.  That or the internal impedance of the monitor is causing issues.

    Is the SD card attached to the MMR board?  SD cards can consume upwards of 100mA in some of their modes and may be the source of an issue.
  • alessandromontanarialessandromontanari
    Hi Matt,

    I am attaching the output of the power monitor directly to +Bat and Gnd on the metamotion. The SD card is attached but I don't think the supplied current is a problem given that the power monitor is capable of providing 3A. Also, in the past I did the same with the metawear R, with an SD card attached and I didn't have any problems.

    I forgot to mention that I am running a custom firmware. Maybe I need to enable the brown-out detection or something similar?

    Thanks 
  • MattMatt
    alessandromontanari

    There should not be a problem with how you've connected the monitor.

    The 3V supply is regulated down from the 3.0-4.2V of the battery source, so any current demands on the 3V supply would be limited by that regulator.

    Can you check the +Bat input and 3V rail with a multimeter or scope?
  • alessandromontanarialessandromontanari
    Hi Matt,

    when I set the power monitor to 3.7V I get 3.7V on +Bat, 3V on the 3V rail and 1.25V on the Vusb pin. The current I see on the monitor is constant at about 9mA.

    I also noticed that if I short the +Bat with the Vusb the device boots correctly and I see the power profile on the monitor. 
    Isn't this strange?

    Thanks
  • MattMatt
    alessandromontanari

    Have you tried feeding 3.7V from a lab power supply or similar?  The boards are normally operated from only a battery at 3.0-4.2V and there are no issues.  Vusb is designed to be floated when not charging so it should not be a problem.  Is the device running the factory firmware?
  • alessandromontanarialessandromontanari
    I tried also from a lab power supply and it's the same.
    I am using a custom firmware but I will try with another board that has the stock firmware on it.
    Maybe I need to enable something in the firmware?

    Thanks
  • alessandromontanarialessandromontanari
    With the stock firmware it works fine, when I apply power to +bat the board boots correctly.
    What could cause this problem in my firmware?
    Once it started it works fine.
  • MattMatt
    @alessandromontanari

    The battery charger seems to be misbehaving in some way.  It could be how your pins which interface the charger are configured.

    The 5V sense pin should only be set as an input.  Setting it as output high may pull the charger input voltage high enough for it to misbehave.

    The charge status input should be used as input with a pull up resistance.  You may also need to be careful with this pin if you use the pin change notification hardware of the nRF SDK.  In some cases -- namely operating off USB without a battery -- the charger switches on and off fast enough (kHz+) to bog down the SoC handling the interrupts.  It definitely causes resets on the nRF51, and possibly the nRF52.

    Also, there is a UICR register to turn the NFC pins into GPIO pins you may want to look at, there could be a negative interaction if it isn't configured -- I don't recall off the top of my head which pins it affects.
  • alessandromontanarialessandromontanari
    I have configured pin 21 (5v present) and pin 16 (battery charging) as inputs. The first with no pull and the second with pull up. I have also defined CONFIG_NFCT_PINS_AS_GPIOS in my Makefile which is used to configure the NFC pins as GPIO.
    However, if I just plug in a battery the device does not start and I need to plug in also the usb to make it start. Once started I can remove the usb and it remains on. 

    I am not monitoring any of the pins mentioned before (5v, charging and battery voltage), I just configured them as input but I am not using them.

    Am I missing anything else?

    Thanks.
  • MattMatt
    @alessandromontanari

    That should mirror the default configuration of our devices.

    You said you had an SD card attached.  How is it wired and is anything else externally connected?
  • delaerpriestdelaerpriest
    Hello @Matt and everybody else!
    I'm new to the forum and my organization (RISE Interactive, Sweden) has just made an order of 70 pieces of the Metamotion R. We want to modify the boards to have a physical on/off switch. 
    alessandromontanari. In my organisation we want to run a custom firmware that we are developing ourselves. I'm aware that you don't give support on that aspect. But i think the problem might be related to how the hardware is wired? 
    In any case I'm experiencing the same problem as mentioned above, where the board only powers on if connected to usb. Switching on/off with a switch connected between battery and vbat will not turn on the board.
    Is there perhaps an enable pin (or similar) of the voltage regulator connected to vusb? What voltage regulator is used on the metamotionR?

    Note: I've done the aforementioned steps of configuring pin 21 as floating input and 16 as input pullup. No success.
    Any advice would be very much appreciated.
  • MattMatt
    What do you mean when you say "plug in a battery"?  It is very easy to trip the over current protection on these small LiPo batteries, when in this state they stay cut off until they are applied a charge voltage.  Once you "plug in" the battery, verify Vbat and V3v on the board.


    The device comes up just fine running our native firmware and bootloader -- this is very unlikely to be specifically a hardware problem.  How the firmware initializes the sensors and SoC -- definitely.

    The voltage regulator (low 1uA iq) is hard wired on to Vbat.

    First, confirm that the NFC pins are set to GPIO mode in the UICR.  This caused our manufacturing test firmware to fail with a similar signature.  Information:

    Next, I would confirm that early in the firmware boot process all of the pins connected to chip selects are properly de-asserted.  This should include CSb high on Acc/Gyro, Mag, and NOR Flash.  Drive the write protect pin on the NOR Flash low.  Enable internal pull ups on the I2C.

    If that does not resolve the issue, please provide us with some information on rail voltages after your kill switch is turned on -- namely Vbat and V3v.
  • delaerpriestdelaerpriest
    Thank you for the answer @matt!
    Very informative. I did actually earlier today verify together with a colleague that the voltage regulator indeed is providing 3V, thus ruling out my earlier speculations about some kind of enable pin on the voltage regulator. The error is most likely related to some error in the boot process as you say. I do configure the NFC pins to GPIO with define flags in the makefile (-DCONFIG_NFCT_PINS_AS_GPIOS). But I will look into the other pin configurations you mention as soon as I return to work! I will then report if that resolves the issue.

    BTW. When you say "early" in the boot process, do you mean early in the main loop? We're using the softdevice and i'm not aware of any points in the boot process where it's possible to execute code until the softdevice initiates the main application. Sorry, I know this last question is out of scope for your support, but at least I wanted to ask.
  • MattMatt
    @delaerpriest

    I would read back the contents of flash to verify that the NFC pin configuration gets written.  The UICR is in a different memory segment and may require extra steps to program.

    When I say early, I mean shortly after initialization but definitely before you start the radio stack.  That being said, our bootloader is unaware of the sensor enables, and it does not have this issue.
  • alessandromontanarialessandromontanari
    Hi all,
    sorry for the delay on this.

    Usually I have a custom PCB attached to the Metamotion that contains the SD card slot and other stuff.
    However, I also tried to disconnect everything and configure the pins as you said:
    int main(void)
    {
        // Read back UICR
        uint8_t nfc_pins =  NRF_UICR->NFCPINS & UICR_NFCPINS_PROTECT_Msk;

        // Configure the pins for the Metamotion
        nrf_gpio_cfg_input(21, NRF_GPIO_PIN_NOPULL);
        nrf_gpio_cfg_input(16, NRF_GPIO_PIN_PULLUP);

        nrf_gpio_cfg_output(5);
        nrf_gpio_pin_set(5);
        nrf_gpio_cfg_output(23);
        nrf_gpio_pin_set(23);
        nrf_gpio_cfg_output(20);
        nrf_gpio_pin_set(20);
        nrf_gpio_cfg_output(9);
        nrf_gpio_pin_clear(9);

       // My code
    }

    And still nothing, if I physically reconnect the battery (I have a JST connector on the Metamotion and I plug/unplug the battery from there) the board won't start until I plug also the USB. Now the board is configured just to advertise and scan.
    With output on UART I verified that nfc_pins is zero so the NFC pins are configures as GPIOs.
    The rails voltages are as expected, 3v, battery voltage (e.g. 4.16v) and 1.25 for the 5v rail.
  • MattMatt
    alessandromontanari

    Can you confirm that the 3v rail is driven immediately after connecting the battery, before connecting USB?

    The only thought that comes to mind to explain why inserting USB matters if is if the battery protection overcurrent circuit is triggered during the insertion -- the inrush current to charge the bulk capacitors might be able to trip this but I would be surprised.  If the rail is driven after insertion it is definitely not this.  We didn't notice any issues with this when wiring in a slide switch on the batteries.  The connectors probably bounce more than a switch but this still seems implausible.

    If the 3v rail is driven post insertion, then the CPU is powered and should be executing.  It should not have anything to do with hardware.

    If you have the capability, I would try using a debugger on the device when it is in this state to pull some register values from the device.  It is possible to connect the debugger without triggering a reset, we have done this before using KEIL.  You should be able to find out what code it is executing via the program counter.  There are other registers such as the reset reason that might be useful.

    I know for a fact that some of the default fault handlers are set to infinite loop on exception in some of the Nordic example projects and could the problem here.

    It would probably be advisable to test the most primitive firmware application possible here.  i.e. no soft device, all interrupt vectors point to system reset, and do something extremely simple to indicate that it is in fact powering up and executing like turning on one of the LEDs and going to sleep.
  • alessandromontanarialessandromontanari
    Hi @matt,

    I can confirm that the 3v rail is driven immediately after connecting the battery with no USB but the board seems not to run.

    Unfortunately, I cannot look into using the debugger and trying a minimal firmware at the moment. I will let you know when I do it.

    @delaerpriest do you have any news on this?
This discussion has been closed.