The green LED LD1 (LED1) will not light up when adapting ble_blinky_c for nRF52840 dongle.

[gfmoore]

Sorry in advance for the length and possible irrelevance of some of what I have written here

So I am trying to figure out how the ble software works. I have the ble_app_blinky as server and which has a definition for working with pca10059 the board for the nrf52840 dongle board and am adapting the ble_app_blinky_c  as client. This only has a defined board pca10056 for the nRF52840 mk board (which I do not yet have, but have now purchased as it is going to be very difficult to develop with just a dongle...) The code builds fine, no errors (now that I have a set of defines for VS Code that seem to work) and I can flash soft device and application or separately as required.

The apps work, except...

On the ble_blinky_c I think the green led 1 LD1 which has the value 0 in the code won't come on. It should come on I think at startup whilst waiting to connect to the other board (that does come on green whilst advertising) I have swapped the boards round to check that the green led (LD1) does come on on both boards, so not a hardware fault.) I noticed that there is a very brief flash of LD1 though it looks red? Not enough voltage????

I just want to be able to light LD1.

I did try to chase the code - but it's spaghetti and with no debugger I'm not getting anywhere, but I did want to show I tried...

I also tried using a low level line of code in main.c that could light the LD2 led colours, but not the LD1.

I tried doing this by just doing

    //bsp_board_leds_on();  

    //nrf_gpio_pin_clear(0);

    

    bsp_board_led_on(0);

    //nrf_gpio_pin_set(0);

    nrf_delay_ms(3000);

after the inits.

Will work for    bsp_board_led_on(1);  //and 2,3 (red, green, blue)

 

Thinking that perhaps one of the intialise routines has done something I put the led on code after leds_init(), but no joy

    log_init();

    leds_init();

    bsp_board_led_on(0);

    nrf_delay_ms(3000);

I suspect that the LD1 is not getting configured/Initialised properly, but surely that common code is fine?

Is there something in the code that works fine for the pca10056 board, but screws things up in pca10059?

The rest of this post is probably irrelevant, but here is my trace through

main.c: --> 

leds_init(); -->

bsp_board_init(BSP_INIT_LEDS); -->

boards.h-->

#define BSP_INIT_LEDS    (1 << 0)

boards.c-->  (I don't think I have a board with the DFU trigger (yet) so I ignored that code as did VS Code? (how) Another define I should be aware of?

    #if LEDS_NUMBER > 0

    if (init_flags & BSP_INIT_LEDS)

    {

        bsp_board_leds_init();

    }

    #endif //LEDS_NUMBER > 0

//then an interesting bit of code

static void bsp_board_leds_init(void)

{

    #if defined(BOARD_PCA10059)

    // If nRF52 USB Dongle is powered from USB (high voltage mode),

    // GPIO output voltage is set to 1.8 V by default, which is not

    // enough to turn on green and blue LEDs. Therefore, GPIO voltage

    // needs to be increased to 3.0 V by configuring the UICR register.

    if (NRF_POWER->MAINREGSTATUS &

       (POWER_MAINREGSTATUS_MAINREGSTATUS_High << POWER_MAINREGSTATUS_MAINREGSTATUS_Pos))

    {

        gpio_output_voltage_setup();

    }

    #endif

    uint32_t i;

    for (i = 0; i < LEDS_NUMBER; ++i)

    {

        nrf_gpio_cfg_output(m_board_led_list[i]);

    }

    bsp_board_leds_off();

}

I'm assuming this gets set as I can turn on all the leds for LD2 (red green blue)

This line seems to be key:

 gpio_output_voltage_setup();

static void gpio_output_voltage_setup(void)

{

    // Configure UICR_REGOUT0 register only if it is set to default value.

    if ((NRF_UICR->REGOUT0 & UICR_REGOUT0_VOUT_Msk) ==

        (UICR_REGOUT0_VOUT_DEFAULT << UICR_REGOUT0_VOUT_Pos))

    {

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;

        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

        NRF_UICR->REGOUT0 = (NRF_UICR->REGOUT0 & ~((uint32_t)UICR_REGOUT0_VOUT_Msk)) |

                            (UICR_REGOUT0_VOUT_3V0 << UICR_REGOUT0_VOUT_Pos);

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren;

        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

        // System reset is needed to update UICR registers.

        NVIC_SystemReset();

    }

}

#endif

but I can't believe this doesn't work???

also there is

nrf_gpio_cfg_output(m_board_led_list[i]);

m_board_led_list is an array of the following (I don't understand this pattern.)

LEDS_LIST is an array of the 4 leds

#define LED1_G         NRF_GPIO_PIN_MAP(0,6)

#define LED2_R         NRF_GPIO_PIN_MAP(0,8)

#define LED2_G         NRF_GPIO_PIN_MAP(1,9)

#define LED2_B         NRF_GPIO_PIN_MAP(0,12)

These look fine according to the dongle documentation (and I know this board works for the ble_app_blinky app or just plain blinky)

Still in boards.c, call this function for each led

nrf_gpio_cfg_output() --> nrf_gpio.h

Calls 

__STATIC_INLINE void nrf_gpio_cfg_output(uint32_t pin_number)

{

    nrf_gpio_cfg(

        pin_number,

        NRF_GPIO_PIN_DIR_OUTPUT,

        NRF_GPIO_PIN_INPUT_DISCONNECT,

        NRF_GPIO_PIN_NOPULL,

        NRF_GPIO_PIN_S0S1,

        NRF_GPIO_PIN_NOSENSE);

}

calls 

__STATIC_INLINE void nrf_gpio_cfg(

    uint32_t             pin_number,

    nrf_gpio_pin_dir_t   dir,

    nrf_gpio_pin_input_t input,

    nrf_gpio_pin_pull_t  pull,

    nrf_gpio_pin_drive_t drive,

    nrf_gpio_pin_sense_t sense)

{

    NRF_GPIO_Type * reg = nrf_gpio_pin_port_decode(&pin_number);

    reg->PIN_CNF[pin_number] = ((uint32_t)dir << GPIO_PIN_CNF_DIR_Pos)

                               | ((uint32_t)input << GPIO_PIN_CNF_INPUT_Pos)

                               | ((uint32_t)pull << GPIO_PIN_CNF_PULL_Pos)

                               | ((uint32_t)drive << GPIO_PIN_CNF_DRIVE_Pos)

                               | ((uint32_t)sense << GPIO_PIN_CNF_SENSE_Pos);

}

The nrfgpio_pin_port_decode calls

__STATIC_INLINE NRF_GPIO_Type * nrf_gpio_pin_port_decode(uint32_t * p_pin)

{

    NRFX_ASSERT(nrf_gpio_pin_present_check(*p_pin));

#if (GPIO_COUNT == 1)

    return NRF_P0;

#else

    if (*p_pin < P0_PIN_NUM)

    {

        return NRF_P0;

    }

    else

    {

        *p_pin = *p_pin & 0x1F;

        return NRF_P1;

    }

#endif

and this started going into the hal (hardware abstraction layer?) and at this point I almost lost the will to live.

So I tried an alternative approach, though I suspect that if the LEDs are not initialised properly all bets are off

I noted this routine

bsp_board_leds_off();

I figured there was also one for bsp_boards_leds_on();

and there is in boards,c

It calls 

bsp_board_led_on(i); for each led 0 to 3

This calls 

ASSERT(led_idx < LEDS_NUMBER);

nrf_gpio_pin_write(m_board_led_list[led_idx], LEDS_ACTIVE_STATE ? 1 : 0);

I have no idea what ASSERT does?

but the nrf_gpio_pin_write looks interesting  (LEDS_ACTIVE_STATE is 0 i.e. to light a led take the pin low

This then leads to 

nrf_gpio_pin_clear(pin_number); 

This calls in nrf_gpio.h

__STATIC_INLINE void nrf_gpio_pin_clear(uint32_t pin_number)

{

    NRF_GPIO_Type * reg = nrf_gpio_pin_port_decode(&pin_number);

    nrf_gpio_port_out_clear(reg, 1UL << pin_number);

}

I'm assuming that pin_number is simply a 0,1,2 or 3 

and then I started to get lost as I think this is now getting into actual hardware manipulation.

However, basically I did this to ask how the hell are we supposed to work with the dongle if it doesn't have a debugger and what sort of twisted genius? developed all this crud just to light a led!!!!

[ovrebekk]

Hi 

The dongle was never intended to be a development tool on the level of the development kit, but rather a companion device you can use for hardware prototyping, field testing etc. Getting a DK is definitely the way to go

Regarding your issue I believe it is caused by the UART logging still being enabled. On the PCA10059 dongle there is no USB to UART converter like on the DK, and trying to output log data to the UART will cause an assert in the code. 

Could you try to set NRF_LOG_ENABLED = 0 in sdk_config.h and rebuild your project? 

Then it should work fine. At the start the yellow LED should light up, until you connect to it at which point the red LED turns on instead. 

Best regards
Torbjørn

[gfmoore]

Okay, now I can see the LED lit up green (yellow???).

Also noted that going lower level I should use  

nrf_gpio_pin_clear(NRF_GPIO_PIN_MAP(0,6));  //set low to light led

just in case anyone else wants to do that sort of thing! ;)

However, though I understand your point about having a dk, [though I am currently unemployed and was just wanting to learn stuff (and I've now ordered a dk though I can't really/didn't want to afford it!)], many people will want to know how they convert the dk code into the dongle code. Was there some place I could have gone to find out that information? I certainly never expected that I would need to unset that flag!

Thanks anyway.

 

[ovrebekk]

My bad, green might be correct. My own dongle didn't work, and I had to get someone else to test it for me ;)

One of my colleagues wrote a blog explaining the main steps needed to convert a project for use with the PCA10059:
https://devzone.nordicsemi.com/nordic/short-range-guides/b/getting-started/posts/nrf52840-dongle-programming-tutorial

Unfortunately it doesn't mention the logging issue (since most examples don't use UART logging by default), but I have mentioned this to him in case he wants to update the blog with this information later. 

Best regards
Torbjørn

[gfmoore]

Thanks.

Yes I've read that article (many times) Always worth re-reading when you are starting out.

This can be closed as far as I'm concerned. 

[ovrebekk]

I am happy to help Gordon, I will consider the case resolved then.