nRF52 DK UART RX pin

[tmloos]

I have been having two issues (possibly related) with the RX pin of the nRF52 DK (PCA10036) using the ble_app_uart example. I have been trying to characterize the problem so that this post makes as much sense as possible - and I don't waste anyone's time.

Background: My goal is to use the nRF52 DK as a BLE bridge between a phone/tablet app and an existing product that I work on. The product uses a Microchip PIC16 and has a UART hooked to a command parser, or, call it a simple shell. I chose the ble_app_uart project to use on the DK for obvious reasons and figured I could repoint the RX and TX pins to the header, turn off flow control, hook up TX/RX/GND, and then simply send and receive characters from the phone app.

I have had some success with this, although, I have experienced some issues which I will explain.

Disclaimer: I am an Embedded Software Engineer. I am not an Electrical Engineer although I know enough to get myself in to trouble.

Issues: (1) I chose pin 22 for TX which seems to work fine. The problem is with the RX pin. Pin 23 does not work at all for some reason, and I don't see anything else that already uses it. (Maybe this is a third problem.) When I choose a different pin, say Pin 24, I see this behavior:

If the UART in the DK is hooked up to the UART on the PIC on power-up, sometimes, the board will not boot. When I say "will not boot", I do not see LED1 blinking indicating "advertising". If I boot the board with nothing connected, LED1 will blink fine. As soon as I plug a jumper wire in to the Pin 24 slot on the header, LED1 goes out - as if the board is dead. This happens even if there is nothing connected to the other end of the jumper.

I can eventually get things working by alternating how I power up both sides and when I connect the UARTs together but it is not repeatable and therefore is bad for a customer demo.

(2) This problem may be related to (1) - and I have the same problem on the PIC side. If I power up the DK with the coin-cell and try to pull the cell to cycle power, LED1 will continue to blink as if power were being sourced through the UART. Again, as stated above, I am not an EE so perhaps this is a common behavior. To me, though, it is common to hook up two systems via UART and send messages back and forth.

Thanks for taking the time to read this - hopefully you have some thoughts...

[RK]

What do you mean by Pin 22/23/24? Do you mean pin on the chip (pins 23 and 24 on that are the ARM serial debug) or do you mean a pin number on one of the headers counting from 1 or do you mean P0.22, the GPIO pin number?

P0.21, 22, 23 and 24 are hooked up to the LEDs on the DK (see the schematic or the manual) and have resistors to VCC, so they aren't a good choice for UART pins.

[tmloos]

I have the schematic printed out for the DK and LEDs are P0.17 - P0.20. What schematic are you looking at?

When I say Pin 22/23/24, I mean P0.22 GPIO pin numbers.

[RK]

It's me not reading the question properly - sorry - I saw 'DK' and thought nRF51-DK, now I see you're talking about the nRF52 DK and indeed P22 etc are free, well they're used for SPI0 by default but only if you're using the SPI, which I'm sure you're not.

Do you have a debugger on the board when it stops advertising, where is it?

[tmloos]

no problem at all... I do have a debugger, I'm switching between Eclipse/GCC and Keil. Keil is much friendlier and the debugger seems to work (I think). I set optimization to 0 and try to step through and there seems to be a lot of disassembly going on. I have never tried to step through code with the soft device so I'm not sure what to expect. When trying to start from main with the rx pin plugged in, it won't run at all. If I unplug, hit Run and then plug in the cable the light stops blinking and when I hit Stop. It is stuck in disassembly again but seems to be in the softdevice_handler.c -> softdevice_handler_init() function. It gets stuck and it's not behaving like I expect.

[tmloos]

I submitted this issue to Nordic and it was determined that the RX pin was floating causing the Uart to enter the APP_UART_COMMUNICATION_ERROR case. This would prevent LED1 operation and would basically hang the system. I am going to see what can be done to the Uart driver to make it a little more tolerant to errors so that the system continues to function even though the Uart may be in an error condition.