Dual Bank Bootloader Over ESB

[TrebleStick]

I have two nrf52832 boards, both being developed with SDK v11 and the s132 soft device. 

Board one is given commands over UART to communicate over ESB with board two. Board two also has serial communication with an FPGA that can be reprogrammed sucsessfully over ESB. 

The goal is to be able to update the firmware on board two over ESB. Doing this will also reprogram the FPGA that currently boots from a file flashed along with the board two app via the "incbin" library.

Issues I'm having:

1. When trying to read and write to flash I discovered that DFU_BANK_1_REGION_START is in fact 0x918CB001. From my understanding this is the memory location of external RAM which is not attached and am not intending to attach. Also this not a multiple of four and is therefore not a valid boot address? The way the space for banks 0 and 1 are worked out seems to just be (BOOTLOADER_REGION_START - CODE_REGION_1_START)/2, leaves the available space around 1.75GB per bank for me, which is certainly not correct. I know i need to redefine these, but what is the best way to set the start and end position of both banks?  

2. Getting the bootloader to validate the new image and swap it into bank 0 over ESB? I currently can't try this due to not being able to write into the right places in memory but any advice other than swapping over to BLE comms for bootloading or trying to change code for BLE comms with ESB protocols throughout the DFU example would be appreciated.

Thanks in advance 

Jack

[TrebleStick]

This is what I get, soft device is s132 v2.0.0

2nd image is what i get after re-flashing the soft device, seems to be correct now. Whenever I flash my code however it seems to mess with the soft device. Is there maybe an issue with my linker file or makefile? 

[Hung Bui]

Okey, so maybe your code overwritten the softdevice. 

Where is there start address  of your application (and your bootloader if you have one ?) and where is your bin file located in the flash ?  

[TrebleStick]

The start address of the my app will be CODE_REGION_1_START right? I've not flashed the bootloader yet as I was trying to resolve this issue first. 

I'm not really sure how to locate where my app ends in flash but I know that my hex file is around 240KB. 

I'm using the .ld file form the blinky example which may be the issue, this is what it looks like currently. 

SEARCH_DIR(.)
GROUP(-lgcc -lc -lnosys)

MEMORY
{
  FLASH (rx) : ORIGIN = 0x0, LENGTH = 0x80000
  UICR (rx) : ORIGIN = 0x10001000, LENGTH = 0x0FFFF000
  RAM (rwx) :  ORIGIN = 0x20000000, LENGTH = 0x10000
}

SECTIONS
{
  .uicr 0x1000120C :
  {
	KEEP(*(.uicr))
  } > UICR
  .fs_data :
  {
    PROVIDE(__start_fs_data = .);
    KEEP(*(.fs_data))
    PROVIDE(__stop_fs_data = .);
  } > RAM
} INSERT AFTER .data;

INCLUDE "nrf5x_common.ld"

the origin of flash should maybe be moved to after the softdevice?  

[Hung Bui]

Hi Jack, 

 

No, not really CODE_REGION_1_START is used in the bootloader code to detect where it should swap the old image with the new image. 

But do you need softdevice in your application ? As far as I can see you are using ESB no BLE ? 

If you use softdevice, you application start address has to adjust to be located after the softdevice. Please have a look at any example inside ble_peripheral or in the blinky example adjusted for softdevice:  \examples\peripheral\blinky\pca10040\s132\armgcc 

 

How do you plan to swap image on the board 2 ? You would need to use a bootloader to do the task. 

[TrebleStick]

I see, in which case how do I check the start and end points of my application?

If the soft device is only required for the BLE communication then you're right i wont be needing it, thanks.  I assumed that it would be required to work with the bootloader but I guess not. The plan is to write the new image to the address immediately after the current application and get the bootloader to validate it from there and swap them over. Writing the new image can be done the same way that I am currently receiving the FPGA image, just writing it to an address in flash rather than the FPGA. I'm just not sure which address to write it to.