Control Stuck at Soft device region 0 address at 0x6b0(sometimes at 0x640)

[nagaraj]

Hi,

   We are using nrf51822 QFAAH00 with SDK 110 v8.1.0 in our project, the application will hangs or not work when control stuck at address 0x6b0 (sometimes at 0x640) programmer in debug mode.

Sometimes code hangs in hardware fault loop,if i put break point before that instruction code where it is hangs, control has to be stop at break point instruction, But  when we view from call stack register control is stuck after the break point.

Linker Configuration  .icf configured as below :

define symbol __ICFEDIT_intvec_start__ = 0x00018000;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__ = 0x00018000;
define symbol __ICFEDIT_region_ROM_end__ = 0x0003FFFF;
define symbol __ICFEDIT_region_RAM_start__ = 0x20002000;
define symbol __ICFEDIT_region_RAM_end__ = 0x20003FFF;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__ = 0x800;
define symbol __ICFEDIT_size_heap__ = 0x200;
/**** End of ICF editor section. ###ICF###*/  

Thank,

Nagaraj

[FormerMember]

What does the application do before it starts hanging? Which functions are being called?

If you use logging over UART/RTT what is going on before the application hangs?

Does this problem only occur in debug mode?

[nagaraj]

Hi Kristin,

Our Application will send battery status to central Device (Mobile app), able to communicate with central device but sometimes hangs in Soft-Device address.  

We have tried with increasing the C-stack size up to 3 Kb for Soft-device and Application. When we comment the advertising part the code didn't hang in this case.

We are not able to exactly locate the cause for the issue as sometimes the code will  not hang for hours, but sometimes the code will hang immediately as soon as we reset the board.

This problem occurred in Debug mode as well as in release mode also.

Let me know if you want more details.

                                                                                                                

                                                                                                                   

Thanks,

Nagaraj

[nagaraj]

Hi,

     Waiting for your reply, Application  hangs in control hard-fault and sometimes in soft-device lower address, This is happening not while Bluetooth stack initialization. 

Thanks,

Nagaraj

[FormerMember]

Could you upload the code here? (If you want to keep the code confidential, you can switch the case to a private case.)

Is there any difference in running the application when the chip has newly been fully erased, and when it has not? (In terms of how much time it takes before the application crash.)

[nagaraj]

Hi,

As per Company policy we cannot share the source code, Application will run sometimes more than hour or sometimes hangs after 5-10 mintues. Application will work without softdevice .

We using the I2C0, UART0, TIMER2 ,GPIOTE which are interrupt based, In Application every 2sec we reading registers through i2c.

We tried different priority level with  I2C0, UART0, TIMER2 , GPIOTE, results in same control hardfault loop, when we check debug mode in call stack after hardfault sometimes control stuck in i2c read function. 

• I2C Priority Level: 1, UART Priority Level: 3, TIMER2  Priority Level: 3, GPIOTE Priority Level: 3
• I2C Priority Level: 1, UART Priority Level: 3, TIMER2  Priority Level: 1, GPIOTE Priority Level: 3
• I2C Priority Level: 3, UART Priority Level: 3, TIMER2  Priority Level: 3, GPIOTE Priority Level: 3
• I2C Priority Level: 1, UART Priority Level: 1, TIMER2  Priority Level: 1, GPIOTE Priority Level: 1

Thanks,

Nagaraj

[FormerMember]

Okay, I see. By priority level, does the priority levels correspond to these priority levels?

#define _PRIO_SD_HIGH       0
#define _PRIO_SD_MID        1
#define _PRIO_APP_HIGH      2
#define _PRIO_APP_MID       3
#define _PRIO_SD_LOW        4
#define _PRIO_SD_LOWEST     5
#define _PRIO_APP_LOW       6
#define _PRIO_APP_LOWEST    7
#define _PRIO_THREAD        15

typedef enum
{
#ifndef SOFTDEVICE_PRESENT
    APP_IRQ_PRIORITY_HIGHEST = _PRIO_SD_HIGH,
#else
    APP_IRQ_PRIORITY_HIGHEST = _PRIO_APP_HIGH,
#endif
    APP_IRQ_PRIORITY_HIGH    = _PRIO_APP_HIGH,
#ifndef SOFTDEVICE_PRESENT
    APP_IRQ_PRIORITY_MID     = _PRIO_SD_LOW,
#else
    APP_IRQ_PRIORITY_MID     = _PRIO_APP_MID,
#endif
    APP_IRQ_PRIORITY_LOW     = _PRIO_APP_LOW,
    APP_IRQ_PRIORITY_LOWEST  = _PRIO_APP_LOWEST,
    APP_IRQ_PRIORITY_THREAD  = _PRIO_THREAD     /**< "Interrupt level" when running in Thread Mode. */
} app_irq_priority_t;

 What happens if you set the priority of  I2C0, UART0, TIMER2 , GPIOTE to APP_IRQ_PRIORITY_LOWEST and the softdevice to APP_IRQ_PRIORITY_LOW? So that the softdevice and the softdevice events always will have higher priority?