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

Strange behaviour with nRF51822 and S110

Hello, I'm trying to develop with the nRF51822 Eval kit and GCC and Eclipse. I've been getting some strange behavior and errors lately. I'm not really sure how to describe it better, because I'm not sure what the problem is but I think it's related to SoftDevice being incorrectly flashed. So let me just give you an example of what's happening:

I flash SoftDevice using the nRFGo studio and start debugging the example project ble_app_hrs. After the program reaches the end of the is_first_start() if block, I get the following:

ble_app_hrs Default [GDB Hardware Debugging]	
	GDB Hardware Debugger (13.08.13 10:47) (Suspended)	
		Thread [1] (Suspended)	
			1 <symbol is not available> 0x00000000	
	arm-none-eabi-gdb (13.08.13 10:47)	
	C:\workspace\Nordic Semiconductor\nRF51 SDK_v4.3.0.27417\Nordic\nrf51822\Board\pca10001\ble\ble_app_hrs\gcc\_build\pricetag_bin_s110_xxaa.out (13.08.13 10:47)	

I terminate the debug session and check what's going on in the nRFGo studio - It tells me to recover, so I do that and flash the softdevice again.

I try debugging again but this time I comment out the line


to see what happens. Then the program runs and I see the LED blinking but, as far as I can tell, it's not advertising (I checked with three different combinations of BTLE HW and SW, so I'm actually pretty sure it's not advertising).

So at this point I terminate the debug session and run it one more time. This time I get and assert from the BLE_STACK_HANDLER_INIT macro. Error number 8194 (= 0x2002), line 508.

My best guess is that the SoftDevice gets incorrectly flashed and that causes all these errors, but I have no idea what causes it, or how to fix it. Help would be appreciated.

  • Hi Viktor,

    That error (specified in nrf_error_soc.h) translates to: NRF_ERROR_SOC_NVIC_INTERRUPT_PRIORITY_NOT_ALLOWED

    The softdevice does not allow interrupt priority set to '0' or '2', only '1' and '3'. Try setting all your interrupts to either '1' or '3' before enabling the BLE-stack, using this function: NVIC_SetPriority(my_IRQ, x);

    Best regards Håkon

  • Hello, I have tested everything a bit more and it seems that I get different program behavior when I'm using the debugger and when the device is running on it's own. Also, I am getting one kind of errors when running a debug session right after starting the GDB server and a different errors in subsequent runs. Sometimes, I have to re-flash the softdevice because nRFGo studio can't detect it and the J-Link GDB server can't connect to the board. I guess it get's corrupted in the memory somehow. All of this leads me to believe that the debugger is not functioning properly and is the cause of all this trouble. I have made a post earlier about having some trouble getting the debugger to work and I thought it was solved but it seems that there are still some problems. I would be grateful if you could give me some pointers about how to set it up properly, because developing without a debugger is far from ideal.

    I'm attaching a simple program for PCA10000 that demonstrates the weird behavior - When I run it on it's own it lights up the blue LED. During the first debug session after starting the GDB server it lights up blue too but during the subsequent sessions it lights up red. With more complex programs I get incorrect behavior even during the first debug session - for example advertising seems not to be working.

    #include <stdint.h>
    #include <string.h>
    #include "nordic_common.h"
    #include "nrf.h"
    #include "app_error.h"
    #include "nrf51_bitfields.h"
    #include "ble_stack_handler.h"
    #include "nrf_gpio.h"
    #define DEAD_BEEF   0xDEADBEEF
    #define LED_RED		21
    #define LED_GREEN	22
    #define LED_BLUE	23
    void leds_init( void )
    void leds_set(uint8_t msk)
    	if(msk & 0x1)
    	if(msk & 0x2)
    	if(msk & 0x4)
    void app_error_handler(uint32_t error_code, uint32_t line_num, const uint8_t * p_file_name)
    	// Light up red LED
    void assert_nrf_callback(uint16_t line_num, const uint8_t * p_file_name)
        app_error_handler(DEAD_BEEF, line_num, p_file_name);
    static void ble_stack_init(void)
    int main(void)
        // Light up red LED
  • I've seen this error sometimes, but I've had troubles with reproducing it consistently. However, my current theory is that this has something to do with how Eclipse launches GDB. I've never seen it when running GDB manually from the command line.

    It seems to possibly be caused by Ecliipse not doing a reset of the chip after loading the new firmware, and hence causing confusion. I have unfortunately not found an easy way to make it do so, but as far as I've seen, changing the startup commands to just this:

    file "c:\full\path\to\your\file.out" 
    mon reset 

    and removing the checkboxes for loading symbol table and binary file, seems to make it work.

  • Thanks! Seems to work so far but I'm going to test it a little bit more to make sure no more unexpected errors pop up.

  • Thanks! Seems to work so far but I'm going to test it a little bit more to make sure no more unexpected errors pop up.