This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

Parents
  • 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!

Reply
  • 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!

Children
No Data
Related