BMD-341 (nRF52840) fails to boot properly when UART line is used immediately after power cycle

[tyrelkostyk]

Hello,

Our team has narrowed down a particularly interesting issue with the boot sequence / initialization of our BMD-341 chip, which itself runs the nRF52840 SoC. For context: we are using the S140 v7.0.1 SoftDevice, with SDK16.0.0. We are using the ble_app_uart demo project, which has been very slightly modified for our project's needs.

The issue we are seeing is: We are not able to connect and communicate with our BLE Peripheral (ever) if we send it data from the Main MCU over the UART line immediately after a power cycle. If we perform any sort of non-power cycle reset (i.e. something that pulls the reset line low), the BLE peripheral begins behaving like expected, even when data is sent over the UART line immediately.

We were able to narrow down the triggering of this error (on our end) to the fact that our program instantly begins sending data to the BLE peripheral (over UART) almost instantly after the program starts; if we add in even a 1ms delay, operation is not negatively affected, and the peripheral behaves as normal in all cases.

We are curious if any other development teams have found the root cause of this particular issue? We have not been able to find any documentation that mentions the inability to receive UART data on startup.

For reference: we are using pins 22 (P0.06) and 24 (P0.08) for the UART RX and TX lines (respectively).

Also: despite the BLE peripheral refusing to connect or communicate, it does properly advertise its presence. So we believe that the peripheral is not fully crashing, it's simply existing in an erroneous state.

Thank you in advance! Cheers,

Tyrel Kostyk

[ketiljo]

Is the UART line high before the nRF is powered up?

[hmolesworth]

Maybe not your issue, but in general early enabling the uart Rx line to the nRF52 - which is of course a Tx output on the main MCU - is a bad idea. Why? Because assuming the main MCU and nRF52 share the exact same power supply they behave differently. The main MCU powers up immediately but the nRF52 has internal regulators, either LDO or DC-DC; both of these take time to rise the voltage on the internal Vcc to the pin drivers. If the main MCU enables the main MCU Tx (Rx at nRF52) then the nRF52 phantom powers the nRF52 and all bets are off in initialising the uart and indeed the nRF52 reset may never happen. If the main MCU also has internal regulators then a test can be performed by driving a spare unconnected output pin high-low on both main MCU and nRF52 before any other code runs; it's a race - who wins?

[tyrelkostyk]

Thank you for your response.

I hear what you're saying - that enabling the UART line at startup is bad because it may induce race conditions within the nRF52's internal startup initializations. However, what my post is trying to convey is the exact opposite of that suggestion. If we do delay enabling the UART Tx line, the BLE peripheral literally does not turn on until that delay is over. i.e., the nRF52 does not turn on until we enable that UART Tx line.

[hmolesworth]

Hmm, I'm not following your description .. what does "nRF52 does not turn on" mean? Is there an nRF52 LED showing when it's on, or something else?

[tyrelkostyk]

Yes, there is an LED that flashes when it is advertising or when "activity" is going on (i.e. messages or being sent/received). If we don't enable that UART Tx line, we also can't see the BLE Peripheral on any host BLE devices (tablets, etc). We can once that line is enabled (presumably because the nRF52 finishes "turning on". We are making some assumptions in this scenario, but only because we have been unable to find any documentation explaining the behaviour

[hmolesworth]

Ah, I think you are seeing an effective break condition. This can be fixed if so by enabling the internal pull-up in the nRF52 Rx by setting the pin pull-up after initialising the uart ie at the end of uart_init().

Without this pull-up enabled the uart handler effectively sees the line-break and a framing error, which can cause a repeated reset thus:

        case APP_UART_COMMUNICATION_ERROR:
            APP_ERROR_HANDLER(p_event->data.error_communication);
            break;

 

The two options are 1) enable the pull-up or 2) comment out the error handler line above. Problem with 1 is that the uart is enabled before you can enable the pull-up, unless you modify the Nordic APP_UART_FIFO_INIT code which doesn't enable the pull-up, before setting the Enable.