USB bootloader for NRF24LU1+ issue

[eugenePi]

Dear all,

I have an issue using USB bootloader for NRF24LU1+ device.

I've used a USB dongle and programmed USB bootloader to chip via SPI using external programmer.

The bootloader HEX file is taken from here: nRFgo SDK 2.3.0.10040\precompiled_hex\keil\boot24lu1p-f32.hex

After this the bootloader works OK and the chip can be flashed via USB using nRFGo Studio.

But when I try to use the bootloader from my own firmware, it's not working (not enumerates as USB device, etc.)

I use the following test code (compiled under Keil 5.11.2.0) to call the bootloader, but with no success:

void main()
{
#pragma asm
     LJMP 0x7800
#pragma endasm
}

What am I doing wrong?

Thanks in advance!

[Håkon Alseth]

Hi,

 

Note that the bootloader will place itself in RAM (xdata area), so if your firmware uses the flash region where the bootloader is located, it will be overwritten with your application content. 

This is because the bootloader is aimed for ease of programming during production, so that you can use USB instead of SPI to fully program a chip.

 

Is your device a 32k variant (nRF24LU1P-F32) or a 16k variant (nRF24LU1P-F16)? This can be read out on the chip markings:

32k markings:

NRF BX
24LU1P
1010AA

 

16k markings:

NRF BX

LU1P16

1010AA

 

Not sure why the jump instruction does not work, but you could try this function pointer implementation (please note the EA=0, important if parts of your running firmware uses interrupts!):

typedef code void (code *init_bootloader_t)(void);
const init_bootloader_t jmp_bootloader = (init_bootloader_t)BOOTLOADER_ADDRESS;
  
void main(void)
{
  while ( 1 )
  {
    // Push button P01 to enter bootloader
    if (!P01)
    {
      EA = 0;
      jmp_bootloader();
    }
  }
}

 

Kind regards,

Håkon

[eugenePi]

Hi, thanks a lot for answering!

The markings are as follows:

NRF E

LU1P16

1535A0

So this is 16k variant, right?

Does this affect the bootloader jump address?

My test firmware does just jumping to bootloader and it's all. So no interrupts, and almost zero code size (limited to 0x0000..0x7800 range not to overlap the bootloader).

Precompiled bootloader is built for 32k variant to occupy 0x7800..0x8000 range and it works on my 16k variant.

P.S. I just tried the code you've suggested but with no success.

[Hung Bui]

Hi Eugene, 

Håkon is on vacation so I will step in here. 

What do you mean by "bootloader is built for 32k variant to occupy 0x7800..0x8000 range and it works on my 16k variant."  I'm not sure how it work when the flash start address is configured for 32k variant ? 

If you have 16k variant, wouldn't you need to change the start address of the bootloader to 0x3800 ? 

[eugenePi]

Hi Hung,

I've just rebuilt the bootloader for 16k memory map. It works well. But my simplest firmware cannot call the bootloader. Is there something with memory map?

Here are the linker settings for bootloader:

CLASSES (CODE (C:0x3800-C:0x3FFF), CONST (C:0x3800-C:0x3FFF),
ECODE (C:0x3800-C:0x3FFF), HCONST (C:0x3800-C:0x3FFF) ,
SROM ( C:0x39A0),
CODE_BOOTLOADER(C:0x8000) [ ],
CONST_BOOTLOADER(C:0x8700) [ ])
SEGMENTS ( ?C_C51STARTUP(C:0x3800) )

And these settings are for my firmware:

RESERVE (0x3800-0x3FFF)
CLASSES (XDATA (X:0x8000-X:0x87FF), HDATA (X:0x8000-X:0x87FF), CODE (C:0x0-C:0x37FE), CONST (C:0x0-C:0x37FE),
ECODE (C:0x0-C:0x37FE), HCONST (C:0x0-C:0x37FE))

The code of my firmware is what just Hakon suggested. BOOTLOADER_ADDRESS is 0x3800.

[Hung Bui]

Hi Eugene, 

I am not sure what could be wrong. It's been a few years since the last time I touched the nRF24LU1P bootloader. But I attached here the project we used to demonstrate how to jump from application to bootloader. It's for 32kB variant but you can modify the BOOTLOADER_ADDRESS to match what you have. 

HAAL_reuse_bootloader.zip

Let me know if it works for you.