• State Verified Answer
  • Replies 3 replies
  • Subscribers 70 subscribers
  • Views 72 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 339621
Options

UART RX not working after power cycle

Mike Austin (LPI)

I've got a custom board that uses an nRF52832. Firmware was built with NCS v2.6.1.

My hardware uses a MIC826 IC for ensuring the nRF52 is held in reset whenever the power supply is not within spec. This also has the option for a manual reset, which I've implemented with a push button.

I'm running asynchronous UART comms in my firmware in its own thread. This allows me to send config commands to the nRF52, and for it to report status.

When I first power up my board, I can see the VDD level come up to spec, then about 200msec later, the MIC826 will set the reset pin high and the nRF52 will start running. But if I try and send UART commands to it, it doesn't respond. I've confirmed that there are UART signals on the RXD pin of my nRF52.

If I subsequently press my reset button, and the nRF52 boots up after a reset, it will respond to my incoming UART signals as expected.

I've checked the RESETREAS register under both conditions, and it returns the same value for both scenarios, which is what I would expect, as both scenarios are a RESET pin reset.

The rest of the firmware functionality appears to be working as expected after the power cycle, so I can't work out why the UART RXD functionality isn't also. Nor why it suddenly does if I reset the nRF52 via the reset button.

Can anyone help me with a solution?

Cheers,

Mike

Parents
  • +1

    "send config commands to the nRF52" is the key, as this implies a physical connection from an external Host MCU or (say) a Host PC-connected FTDI Tx output pin to the nRF52832 Rx input pin.

    First: Care is required to ensure no Host port pins are driving into the nRF52832 input pins during a nRF52832 power-down period. The externally-powered host Tx output pin will phantom power the entire nRF52832 SoC while high (say 3V, the Host Tx inactive state) while the nRF52832 VDD power is removed; the Host Tx power is connected via the internal schottky diode protection from each input pin connected to the nRF52832 internal VDD. This means that to power-down the nRF52832 SoC the Host Tx drive to the nRF52832 Rx must be removed before the nRF52832 supply is switched off otherwise the nRF52832 SoC may not correctly reset. This can be done by physically removing the FTDI connection, or using the FTDI 3V as the nRF52 VDD power source, or isolating the nRF52832 Rx pin with a SN74LV1T34 Single Power Supply Single Buffer enabled by the nRF52832 VDD.

    Second: Depending on the driver implementation, the nRF52832 requires the Rx pin internal pullup be enabled prior to enabling the UART for the case where the Host Tx pin is not yet connected or the Host UART not yet initialised; if the Rx pullup is not enabled the nRF52832 UART driver may (will) immediately detect a Framing Error and subsequent Break condition which - if using older Nordic example code - is not correctly handled and will cause the UART driver to not recover. Alternatively an external pullup resistor may be connected to the Rx pin, but that is overkill.

    As an aside, this issue applies to most MPUs, not just nRF52.

    Edit: Similar posts:

     nrf52840-fails-to-boot-properly-when-uart-line-is-used-immediately-after-power-cycle

     functionality-if-vdd-does-not-go-to-0v-when-powered-down

     nrf52832-power-supply-over-rx-tx-pins

     ble_app_uart-can-not-start-advertising

  • 0 in reply to hmolesworth

      - thanks.  That all makes sense.

    The issue was I had an external USB-UART device connected up to the nRF52 UART, which I suspect was causing the problem.  If I disconnect that, cycle the power, then reconnect it, I get operational UART comms.  If I leave it connected when I cycle the power, I see the problem I described above.

    Thankfully, the end user is unlikely to have, and certainly won't need, to have any external UART connection to the nRF52 in the event they have to cycle the power, so in an operational sense, its a problem that won't ever present itself in normal use of the end product.

    But good to know what was causing it

    Cheers,

    Mike

  • 0 in reply to Mike Austin (LPI)

    You're welcome. As an aside note that if the UART is left enabled in anticipation of a potential end user connection the pullup will still be required as otherwise (quite apart from the wasted power) If any nRF52832 pin signals are not driven - Rx in this case - further phantom power consumption (100 uA) may occur from feedthrough when the input pin happens to float to the vanishingly small transition voltage where feedthrough occurs. Often better to leave the UART disabled, pullup enabled, and on any falling edge enable the nRF52832 UART 10-1 baud rate clock cycles after the falling edge so that an incoming wakeup character will enable the UART for further reception without a Framing Error.

Reply
  • 0 in reply to Mike Austin (LPI)

    You're welcome. As an aside note that if the UART is left enabled in anticipation of a potential end user connection the pullup will still be required as otherwise (quite apart from the wasted power) If any nRF52832 pin signals are not driven - Rx in this case - further phantom power consumption (100 uA) may occur from feedthrough when the input pin happens to float to the vanishingly small transition voltage where feedthrough occurs. Often better to leave the UART disabled, pullup enabled, and on any falling edge enable the nRF52832 UART 10-1 baud rate clock cycles after the falling edge so that an incoming wakeup character will enable the UART for further reception without a Framing Error.

Children
No Data
Related