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?

[tyrelkostyk]

After a power cycle, the UART line is pulled high after being initialized as such in the main MCUs software. However, after a reset (i.e. reset line pulled low, not a power-cycle), that UART line stays high. This is a property of our MCUs hardware architecture, and isn't necessarily unexpected.

In the former (power-cycle) case, the BLE Peripheral only behaves properly if we add a delay between pulling the UART line high and sending data over it. In the latter (reset line) case, the BLE peripheral works no matter what; presumably because that UART line is held high well ahead of time. 

After figuring that out, it seems that the UART line needs to be held high (and undisturbed) for a short amount of time at/during the BLE Peripheral's boot up sequence. After a power cycle, there was virtually no time between when the main MCU was pulling the UART line high, and when it began sending data over said UART line.

Are you aware if the BLE Peripheral uses that line for some sort of initialization / configuration? If so, then this behaviour would make sense.

Some documentation / clarification surrounding that possibility would be awesome :)

Thanks!

[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?