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

Wakeup the nrf51422 with UART pins.

Hello All,

Currently i am working on nrf51422 DK board(PCA10028). I am using SDK 12.3.0 ,from this i have referred the ble_app_uart  example for implementing the UART and it is working fine.

As per our application i want to the wakeup the BLE from system off using RX or TX pin. I referred the example for waking up the BLE using the GPIO pins and test it ,the ble will wakeup by driving the pin low. 
So for configuring the wakeup for BLE i approach with below steps.

1. Configuring the rx or tx as gpio input  and configuring the gpio as wakeup pin with sense low during the startup of ble.

2 Read the  GPIO status, if it is low than  deint the gpio using nrf_gpio_cfg_default API than  init that pin as uart tx or else go to system off mode if the status is high.

The problem is occurring that when it wakes up from the system off mode and when it try to configure the wakeup pin as uart the system reset occur.

But if i change the pins it works fine. Can anyone help me out for what approach should i use to wake up the BLE using UART ? I have code snippet as below.

/********************************************************************************************************************/

int main(void)
{

    uint32_t err_code;

    // Initialize.
   APP_TIMER_INIT(APP_TIMER_PRESCALER, APP_TIMER_OP_QUEUE_SIZE, false);
  ble_stack_init();

  nrf_gpio_cfg_input(13,NRF_GPIO_PIN_PULLUP);
  nrf_gpio_cfg_sense_input(13, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_SENSE_LOW);


  if(nrf_gpio_pin_read(13))
 {

   sd_power_system_off();

  }
else
{

  nrf_gpio_cfg_default(13);
  uart_init();

}
gap_params_init();
services_init();
advertising_init();
conn_params_init();

sd_ble_gap_adv_data_set((const uint8_t*)data,sizeof(data),NULL,NULL);


err_code = ble_advertising_start(BLE_ADV_MODE_FAST);
APP_ERROR_CHECK(err_code);
// Enter main loop.

  for (;;)
  {
     power_manage();
  }
}

/*******************************************************************************************************************/

Any help will be greatly appreciated.

Regards,

Amit 

Parents
  • Hello Amit,

    The problem is occurring that when it wakes up from the system off mode and when it try to configure the wakeup pin as uart the system reset occur.

    Is that the  APP_UART_COMMUNICATION_ERROR event inside your uart event handler that resets the controller? If so, can you try to just print out the p_event->data.error_communication in the log (or debug to see what it is), instead of passing it into the APP_ERROR_CHECK(p_event->data.error_communication)? 

    Printing it just to see what reason it is. What I really want to know is whether it behaves properly if you just remove the APP_ERROR_HANDLER(p_event->data.error_communication); inside the APP_UART_COMMUNICATION_ERROR event in your uart event handler.

    Best regards,

    Edvin

  • Dear Edvin,

    Thanks for your Kind Response!!!

    Yes ,the APP_UART_COMMUNICATION_ERROR  event inside the uart event handler causing the reset of the controller.

    The value i got from  p_event->data.error_communication is 12 ,i don't know what it means. I also comment the APP_ERROR_CHECK(p_event->data.error_communication) ,still it reset the controller Kindly give your feedback for the same.

    Regards,

    Amit 

  • Hello,

    Looking at the struct app_uart_evt_t in app_uart.h on line 118, it says that the APP_UART_COMMUNICATION_ERROR event contains the value of the ERRORSRC from the UART peripheral, which you can see in Table 279 in the reference manual.

    So, 12 = 0xb1100, meaning D=1, C=1, B=0, A=0 (in the table).

    D means that it is a break, which is what you are seeing. C means "Framing error", which is caused by that the data doesn't seem to fit with the baudrate of the UART. This is probably because it takes some time to start up the UART, and the nRF thinks that the first bit is too short. 

     

    Amitkumar said:
    still it reset the controller Kindly give your feedback for the same.

     Can you try to:

    1: disable optimization in your project, and

    2: define DEBUG in your preprocessor defines.

    Then set a breakpoint on line 76 in app_error.c. Does it stop at this breakpoint? If so it should point to a place in your project. What is .line_num, p_file_name, and .err_code? and what is the function that returned the err_code that was passed into APP_ERROR_CHECK() on this place in your project?

  • Dear Edvin,

    Thanks for response.

    I have changed the Optimization level to zero and it's working fine. It wake up on driving low and also sending strings through uart after initialization.  However i have few question regarding this.

    1. is it okay to comment the   APP_ERROR_CHECK(p_event->data.error_communication) ?

    2. Why the code is working fine after changing optimization level?

    Regards ,

    Amit

  • 2)

    I only suggested changing the optimization level in order to see what the p_event->data.error_communication value was when you were debugging. Does the issue disappear if you only change the optimization level, and not comment out the APP_ERROR_CHECK(p_event->data.error_communication)?

    1)

    What APP_ERROR_CHECK(err_code) does is to reset the device if (err_code) is not 0. It may be desirable in some cases, but not necessarily all. If you are aware that this will happen there is no need to reset the device, but rather use this event to tell the application that something happened.

    One classic example is when you queue too many packets in BLE, and you get the return value NRF_ERROR_RESOURCES from the sd_ble_gatts_hvx(), and pass this into APP_ERROR_CHECK() the device will reset. In this case it would be better to use this return code to know that the last packet was not queued, and try to queue it later, rather than restarting the device, causing the BLE link to disconnect, and start from scratch.

    So unless a restart solves the issue, it is better to just be aware of these events, rather than restarting. However, it is quite useful during development, to make sure that the developer is aware of these events.

    Sorry for the digression. Back to the issue. Does only changing optimization level solve the issue? Or does it only go away if you also comment out that APP_ERROR_CHECK()?

    If only optimization level does the trick, what compiler do you use (if armgcc, what version)?

    It may also be related to compiler warnings if optimization level changes the behavior. Try to rebuild your project from scratch, and see if you get any compiler warnings. 

  • Dear Edvin,

    Yes the system reset is doen't occur only when the i comment APP_ERROR_CHECK() at uart handler.

    I am compiling the code in  IAR v8.30.

    Kindly give your feedback for the same.

    Regards,

    Amit

  • Amitkumar said:
    Kindly give your feedback for the same.

     I'm not sure I understand.

    But yes. Then it was the communication error event that caused the reset. So now that you know the reason for this event, you can at least "ignore" the first time this occurs after a system_off wakeup.

    Best regards,

    Edvin

Reply Children
Related