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

ble_app_uart example some uart issue on fanstel EV-840 DK

Hi there,

I am using WIN10, Segger studio 4.52c and nRF SDK16. 

I can successfully run ble_app_uart example on PCA10056, but when i try to run same code on fanstel EV-840 dev board, application crashes after uart_init() function, actually APP_UART_COMMUNICATION_ERROR event is received in event handler. (if i comment uart_init() function everything else works fine.. i can connect with phone and all...)

Then i tried Uart example in  examples\peripheral\uart and i got the same behavior as in ble_app_uart.

But when i tried serial_uartes example in examples\peripheral\serial_uartes strangely enough this worked perfectly and i can send data on both the uarts.

So there is no hardware issue in UART for sure and i am using RX on 26 and TX on 27 on EV_840.

Now i am out of options to try out, please suggest what can be wrong and why i can't run ble_app_uart example on fanstel EV-840. 

I am sure i am missing something very basic.

Thanks, Rishi

Parents
  • Hi

    If you take a look at the pin assignments in the nRF52840 product specification, you can see that P1.01-P1.04 are all defined as GPIOs recommended for Standard drive, and low frequency I/Os only. Now, this shouldn't be enough to cause a crash in uart_init() function, but using these pins for UART in an application that uses the radio simultaneously, is likely to interfere with the radio performance on the nRF52840 so I would not recommend that you use these pins as UART pins in the ble_app_uart example.

    Can you tell me where exactly the uart_init() function crashes? Have you tried debugging the device at all to see if you can get an error message that makes any sense? Can you also show me how you've defined these pins in your project?

    Best regards,

    Simon

Reply
  • Hi

    If you take a look at the pin assignments in the nRF52840 product specification, you can see that P1.01-P1.04 are all defined as GPIOs recommended for Standard drive, and low frequency I/Os only. Now, this shouldn't be enough to cause a crash in uart_init() function, but using these pins for UART in an application that uses the radio simultaneously, is likely to interfere with the radio performance on the nRF52840 so I would not recommend that you use these pins as UART pins in the ble_app_uart example.

    Can you tell me where exactly the uart_init() function crashes? Have you tried debugging the device at all to see if you can get an error message that makes any sense? Can you also show me how you've defined these pins in your project?

    Best regards,

    Simon

Children
  • Hi Simon,

    Thanks for this important information, i will make sure we will not use any pin marked as standard drive in our UART application.

    FYI : See I have 3 dev boards : i) PCA 10056 V 0.9.0, 2016.51 ii) PCA 10056 2.0.0, 2020.2 iii) Fanstel BT-EV840

    I definitely get different behavior between two PCA10056 boards. For instance i can use P 1.01 and P1.02 on V2.0.0 board but can use on EV 840 or V 0.9.0 PCA10056. 

    Now coming to the real question : In my previous posts as well i always said i can use P26 and 27 on EV840 board using serial_uartes example but i can not use the same pins in ble_app_uart example. This is really strange for me and if you can think of any reason please let me know.

    Yes i debugged it and after uart_init() function returns i get APP_UART_COMMUNICATION_ERROR and control ends up in APP_ERROR_HANDLER().

    This is how pins are defined :

    #define RX_PIN_NUMBER  NRF_GPIO_PIN_MAP(0,26)
    #define TX_PIN_NUMBER  NRF_GPIO_PIN_MAP(0,27)
    #define CTS_PIN_NUMBER  0 
    #define RTS_PIN_NUMBER  0 

    We are in the process of making custom pcb with fanstel module, I just wanted to be sure that why i am pursuing this question. I know if i can use P26 and P27  on PCA10056 so logically speaking it should work on our custom board as well. But somehow it fails on EV840 so called dev board.

    Best Regards

    Thanks, Rishi

Related