Hello,
I’m experiencing a behaviour I cannot understand and I need some help.
I have logging enabled on uart0 (USB), and apparently the board works only if it is connected with the USB cable.
With only the battery It looks like the board resets.
The battery is fully charged (3.7V)

I have tried to connect the USB and not opening the serial terminal, and it looks like it work.
Unfortuately I cannot get information on what’s going on as USB serial port is my debugging console.

Do you have any idea on where to point at?
Many thanks

    Hi PaoloZigoni

    What version of the board to you have. It should be the last two digits: BRD-0015-06. Does it restart immediately or does it run your code for sometime before rebooting? Do you have anything else connected besides the battery? A picture of your setup would be very helpful.

      Hi,

      the board revision is BRD-0015-05.
      I have an nrf52840 dongle attached to VBUS, GND and 3 GPIO (two for UART, one is an input for nrf9160).

      Is there a way to configure UART0 so that it does not use USB as an interface? I would like to have some logging to understand what happens when running with battery.
      Unfortunately i cannot provide precise info on reset behaviour as I only have LED feedback which is also used for other purposes.

      Has 05 revision any problem? We just received 5 new boards, hopefully is 06 version.
      Thanks

        PaoloZigoni the board revision is BRD-0015-05.
        I have an nrf52840 dongle attached to VBUS, GND and 3 GPIO (two for UART, one is an input for nrf9160).

        Can you snap a photo of the connections?

        PaoloZigoni Is there a way to configure UART0 so that it does not use USB as an interface? I would like to have some logging to understand what happens when running with battery.

        Yep! If you create a circuitdojo_feather_nrf9160_ns.overlay file and edit the contents to be something like this:

        &uart0 {
        	pinctrl-0 = <&uart0_alt>;
        	pinctrl-1 = <&uart0_sleep_alt>;
        	pinctrl-names = "default", "sleep";
        };
        
        &pinctrl {
        	uart0_alt: uart0_alt {
        		group1 {
        			psels = <NRF_PSEL(UART_TX, 0, 24)>,
        				<NRF_PSEL(UART_RX, 0, 23)>;
        		};
        	};
        
        	uart0_sleep_alt: uart0_sleep_alt {
        		group1 {
        			psels = <NRF_PSEL(UART_TX, 0, 24)>,
        				<NRF_PSEL(UART_RX, 0, 23)>;
        			low-power-enable;
        		};
        	};
        };

        This would remap the console to the TX and RX pins. If you’re already using them you’ll have to map to other unused pins. Change the last number <NRF_PSEL(UART_TX, 0, 24)>, in this line to map to the pin in question. The silkscreen on the bottom of the boards should match the pin number. Keep in mind that some of the pins on the board are shared with the accelerometer and other functionality. (P0.30/D3 for accel and P0.03/D7 for LED)

        Place that .overlay file in a boards directory along side your prj.conf and CMakeLists.txt and Zephyr should find it. I’d recommend deleting your build folder or doing a pristine build.

        PaoloZigoni Has 05 revision any problem? We just received 5 new boards, hopefully is 06 version.
        Thanks

        They should be version 6. There’s little difference between the boards so you should be OK there.

          Thank you Jared,
          thanks for your quick help.
          Here are a couple of pics (hope you can see):


          I forgot there is also a reed switch attached to RST line.
          Tomorrow will try to switch UART to other GPIOs and see what I get…

            I have an nrf52840 dongle attached to VBUS, GND and 3 GPIO (two for UART, one is an input for nrf9160).

            This may be part of your problem. VBUS is the voltage from USB. When you remove USB, poof, there’s goes the power to your nRF52. You need to power the nRF52840 directly from the 3.3V rail so they’re on the same power rail/potential.

            Are you working on a Bluetooth application using HCI UART?

              Sorry my mystake, the nrf52 is powered from 3v3, otherwise It would have burnt…
              The Bluetooth application is running on nRF52, and uses uart_poll to exchange data throught UART with nrf9160.

              Hello, the problem was caused by the reset PIN, which probably was picking some EMI from the wire attacched to its pin.
              After placing a capacitor in parallel, the problem disappeared.

              Regards

              Terms and Conditions | Privacy Policy