• State Verified Answer
  • Replies 5 replies
  • Subscribers 62 subscribers
  • Views 1816 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 115394
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Why does using P0.0 as uart RX cause BLE stack to hang?

JimG

I have a custom board that doesn't use the external 32Khz crystal. The engineer that designed it chose to use P0.0 as UART RX. (I know, poor choice.) I have set up a custom_board.h file with the RC oscillator and if I set the RX as P0.8, it works fine. If I only change the RX port to P0.0, it hangs in ble_init(). Is there a reason that P0.0 can't be used as a UART with the BLE stack? I am running S132 on SDK 11.0 with a BMD-300 module using an nRF52832 processor.

Thanks for any insight that you can provide.

Edit: The port works fine when I run it without the BLE stack.

Parents
  • 0

    I tested this on the DK and got the same problem, using pin 0 or 1 as UART RX would cause the device to hang at the next SoftDevice call it seemed.

    After some investigation I found out that it was actually the UART event handler calling the APP_ERROR_HANDLER because of a APP_UART_COMMUNICATION_ERROR event. Defining DEBUG in the preprocessor symbols showed that the application would go into the error handler and stop the execution.

    The problem is that when using pin 0 or 1 for UART RX the UART peripheral will get an error event as soon as it is enabled, which will lead to the UART event handler calling the error handler. The solution is to ignore the first APP_UART_COMMUNICATION_ERROR and not call APP_ERROR_HANDLER(p_event->data.error_communication).

    The problem is not related to the SoftDevice. I tested without enabling the SoftDevice and got the same error.

    I will report this internally so that we can fix this. Thank you for noticing the issue.

  • 0 in reply to Ole Bauck

    Thanks! That helps a lot. I still think it is something in the SoftDevice. To test on the DK, you would have had to disconnect the external crystal by cutting the SB1 and SB2 traces and soldering SB3 and SB4. Doing that, it does not generate an error without the SoftDevice. If you initialize the SoftDevice to use the RC oscillator (since the crystal is disconnected), an interrupt is generated on P0.0 that causes the Communication Error. If you use a different pin for the receiver, the interrupt is not generated.

    At any rate, once I ignore that first communication error, it all seems to work fine. Thanks again!

Reply
  • 0 in reply to Ole Bauck

    Thanks! That helps a lot. I still think it is something in the SoftDevice. To test on the DK, you would have had to disconnect the external crystal by cutting the SB1 and SB2 traces and soldering SB3 and SB4. Doing that, it does not generate an error without the SoftDevice. If you initialize the SoftDevice to use the RC oscillator (since the crystal is disconnected), an interrupt is generated on P0.0 that causes the Communication Error. If you use a different pin for the receiver, the interrupt is not generated.

    At any rate, once I ignore that first communication error, it all seems to work fine. Thanks again!

Children
No Data
Related