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

RTT repeats output that is meant to be sent only once

Well not my best title. But I hope you can follow this explanation:

I added RTT to my project to replace UART. It works so far. But there is a strange behaviour... Code goes something like this:

int main(void)
{
SEGGER_RTT_WriteString(0, "Hallo!\n");	
    for (;;)
    {
      power_manage();		
			if(test_flag) { SEGGER_RTT_WriteString(0, "ABC!\n");	; test_flag=false;}
}
}

on Connection Event a Timer is started that sets the test_flag every second to true. The Timer is stopped on Disconnection Event.

When I start the device the RTT Viewer prints "Hallo" as expected. When I connect to the device via Bluetooth it starts printing "ABC" every second as expected. But whenever I disconnect it also prints "Hallo" and I can't figure out why?

I could swear there was no such a problem with UART.. but I put a delay for the Hallo now and this code is also repeated after the disconnection.. So it looks like the chip resets after disconnection..(from MCP) Why else it would run all the main() code again? I set a breakpoint inside the error handler and debugged but nothing...

I will restore to a backup without RTT and try the exact same with UART once again. But I can't remember such a problem..

main.c

Parents
  • Looks like

    static void on_ble_evt(ble_evt_t * p_ble_evt)
    {
        switch (p_ble_evt->header.evt_id)
        {       
            case BLE_GAP_EVT_DISCONNECTED:
                m_conn_handle = BLE_CONN_HANDLE_INVALID;
    	    app_timer_stop(m_test_timer_id);
                advertising_start();		<- THIS		
                break;
    

    is causing the reset. Maybe because

    static uint32_t device_manager_evt_handler(dm_handle_t const * p_handle,
                                               dm_event_t const  * p_event,
                                               ret_code_t        event_result)
    {
    
        switch(p_event->event_id)
        {
            case DM_EVT_DISCONNECTION:
                m_conn_handle = BLE_CONN_HANDLE_INVALID;
                advertising_start();         <- It is here also.
                break;
    

    But this is both from the example?

    If it outcomment one everything works as expected... but which one and why?

    When I connect and disconnect from MCP it seems like DM is called before GAP on both actions. (Doesn't matter If I delete bond before or not). Of course I looked them up in the DOC but I don't get why the advertising_start() and also the m_conn_handle = BLE_CONN_HANDLE_INVALID; were duplicated from the beginning?

    In the unchanged multilink_peripheral example of course no systemreset is caused. But I only removed the LED stuff... Maybe it now calls the advertising_start()-function too quickly and it is in defect a mistake? I will edit this answer if someone points it out.

Reply
  • Looks like

    static void on_ble_evt(ble_evt_t * p_ble_evt)
    {
        switch (p_ble_evt->header.evt_id)
        {       
            case BLE_GAP_EVT_DISCONNECTED:
                m_conn_handle = BLE_CONN_HANDLE_INVALID;
    	    app_timer_stop(m_test_timer_id);
                advertising_start();		<- THIS		
                break;
    

    is causing the reset. Maybe because

    static uint32_t device_manager_evt_handler(dm_handle_t const * p_handle,
                                               dm_event_t const  * p_event,
                                               ret_code_t        event_result)
    {
    
        switch(p_event->event_id)
        {
            case DM_EVT_DISCONNECTION:
                m_conn_handle = BLE_CONN_HANDLE_INVALID;
                advertising_start();         <- It is here also.
                break;
    

    But this is both from the example?

    If it outcomment one everything works as expected... but which one and why?

    When I connect and disconnect from MCP it seems like DM is called before GAP on both actions. (Doesn't matter If I delete bond before or not). Of course I looked them up in the DOC but I don't get why the advertising_start() and also the m_conn_handle = BLE_CONN_HANDLE_INVALID; were duplicated from the beginning?

    In the unchanged multilink_peripheral example of course no systemreset is caused. But I only removed the LED stuff... Maybe it now calls the advertising_start()-function too quickly and it is in defect a mistake? I will edit this answer if someone points it out.

Children
No Data
Related