Strange behaviour with nRF51822 and S110

RE: Strange behaviour with nRF51822 and S110

Viktor — Mon, 26 Aug 2013 09:22:36 GMT

Now I realized, that it's probably just the normal behavior when debugging with softdevice running, so everything looks to be alright now. Thanks!

RE: Strange behaviour with nRF51822 and S110

Viktor — Tue, 20 Aug 2013 12:38:18 GMT

Unfortunately it looks like there are still some problems :( Basically, right now I have a program that get's stuck if I try to step through it but runs fine when I just hit run. I'll try to document it more and post some details tomorrow, maybe try running GDB from command line and see if that helps as well.

RE: Strange behaviour with nRF51822 and S110

Ole Morten — Tue, 20 Aug 2013 06:40:50 GMT

Sounds good! If you found this answer helpful, I'd be happy if you could click the "Accept as answer" button, to mark this question as resolved. :-)

RE: Strange behaviour with nRF51822 and S110

Viktor — Tue, 20 Aug 2013 05:15:50 GMT

The last comment was mine, just forgot to log in :S

RE: Strange behaviour with nRF51822 and S110

Guest — Tue, 20 Aug 2013 05:15:06 GMT

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.

RE: Strange behaviour with nRF51822 and S110

Bastiaan — Tue, 20 Aug 2013 05:15:06 GMT

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.

RE: Strange behaviour with nRF51822 and S110

Ole Morten — Fri, 16 Aug 2013 10:57:16 GMT

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" 
load
mon reset

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

RE: Strange behaviour with nRF51822 and S110

Viktor — Wed, 14 Aug 2013 13:29:04 GMT

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 )
{
	nrf_gpio_cfg_output(LED_RED);
    nrf_gpio_cfg_output(LED_GREEN);
	nrf_gpio_cfg_output(LED_BLUE);

	nrf_gpio_pin_set(LED_RED);
	nrf_gpio_pin_set(LED_GREEN);
	nrf_gpio_pin_set(LED_BLUE);
}

void leds_set(uint8_t msk)
{
	if(msk & 0x1)
		nrf_gpio_pin_clear(LED_RED);
	else
		nrf_gpio_pin_set(LED_RED);

	if(msk & 0x2)
		nrf_gpio_pin_clear(LED_GREEN);
	else
		nrf_gpio_pin_set(LED_GREEN);

	if(msk & 0x4)
		nrf_gpio_pin_clear(LED_BLUE);
	else
		nrf_gpio_pin_set(LED_BLUE);

}

void app_error_handler(uint32_t error_code, uint32_t line_num, const uint8_t * p_file_name)
{
	// Light up red LED
	leds_set(0x01);
	while(1);
}


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)
{
    BLE_STACK_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_XTAL_20_PPM,
                           BLE_L2CAP_MTU_DEF,
                           NULL,
                           false);
}

int main(void)
{
    leds_init();

    ble_stack_init();

    // Light up red LED
    leds_set(0x04);

    while(1);
}

RE: Strange behaviour with nRF51822 and S110

Håkon Alseth — Tue, 13 Aug 2013 12:19:38 GMT

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