Dual Bank Bootloader Over ESB

RE: Dual Bank Bootloader Over ESB

Hung Bui — Fri, 27 Jul 2018 14:16:36 GMT

If you have the code to read the UICR and don't try to write to it on every boot then it's fine. We also do that with some of our code to enable errata fix or configure Reset pin, NFC pins.

But I don't think you can write to flash by just assigning the value to the pointer. Please look for this line in system_nrf52.c to see how to do it

#if defined (CONFIG_NFCT_PINS_AS_GPIOS)

I'm not sure why you don't want to edit the hex file. The intel hex definition can be found here. You just need to edit the hex to split it into two.

Another option if you don't want to edit the hex is to flash the hex to a chip, then try to read it out using nrfjprog, you can read the application part and the UICR part separately to have 2 hex files. Then you convert the hexes to binary files.

RE: Dual Bank Bootloader Over ESB

TrebleStick — Thu, 26 Jul 2018 13:29:58 GMT

I'm currently trying to change the linker file to write the UCIR data right after my application then on start up have the app write the UCIR values to the correct address, is this a good approach? I'm thinking that this would streamline the updating process a bit more. My linker file and the start up code currently looks like this.

/* Linker script to configure memory regions. */

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

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

SECTIONS
{
  .app 0x000000000 : { *(.app) _eapp = . ;}
  .muicr 0x1000120C :
  AT( ADDR (.app) + SIZEOF (.app) )
  { _uicr = . ;  *(.uicr);  _eucir = . ;  }
  .fs_data :
  {
    PROVIDE(__start_fs_data = .);
    KEEP(*(.fs_data))
    PROVIDE(__stop_fs_data = .);
  } > RAM
} INSERT AFTER .data;

INCLUDE "nrf5x_common.ld"

  //save the UCIR address manully to reduce the size of the bin fin for each applcation
    extern char _eapp, _ucir, _eucir; //beginning of UCIR LMA, beginning of UCIR VMA, end of UCIR VMA
                // __start_fs_data, //data start address
                // __stop_fs_data;  //data end address
    //define pointer to the start of both the load and virtual memory addresses fo the UCIR data
    char *src = &_eapp;
    char *dst = &_ucir;

    //write the UCIR data across on boot, this should be indpendant of the start address of the application
    while(dst < &_eucir){
      *dst = *src;
      *src = 0xFF; //write flash mask to the temp storage address
      dst++;
      src++;
    }

RE: Dual Bank Bootloader Over ESB

Hung Bui — Mon, 23 Jul 2018 08:49:11 GMT

Hi Jack,

I guess in your code you have some data to be written to UICR (0x10001209) ? If you do , would suggest you to split the hex file, so you have separate hex for the main application and separate hex for the UICR. Then you convert them to binary.

If you keep them in one hex file, gcc has no other way of generating binary other than making that 256MB bin file (binary file has no address, to get to the UICR it has to add the 0xFFFFFFFF)

In your DFU application, you then receive 2 files one to be written as application and one to be written to UICR

RE: Dual Bank Bootloader Over ESB

TrebleStick — Fri, 20 Jul 2018 15:06:31 GMT

Hello again, sorry for the late response I've been working on this among other things. So currently I've managed to get the boot commands to work over ESB as far as validating an image and booting from an address, in this case still just 0x00000000.

I have code which will sucsessfully send a binary file and write it into a memory location of my choosing however the binary file produced by GCC is far too large.

From what i understand and from looking at the information on the file in a binary/hex file interpreter, all of the information past 0x00004510 are just zeros. untill you hit the final address in my currently 256MB file 0x10001209, which simply contains 0xFFFFFFFF, which i assume is just storing the flash mask.

My question now is, can i chop my binary file down to 0x00004510 and run it?

Again, thanks in advance

Jack

RE: Dual Bank Bootloader Over ESB

Hung Bui — Wed, 06 Jun 2018 08:50:24 GMT

You can remove the softdevice if you don't plan to use BLE. But you still need the MBR to do the image replacing. What you are planing to do require good understanding on how the MBR works and assessment if a bootloader needed or not. I would suggest you to get familiar with how our bootloader work, how we replace application image and also replace the bootloader itself. How the bootloader is executed and the vector table is forwarded by the MBR.

The start point of your application is defined in the .ld file, as in the blinky example : FLASH (rx) : ORIGIN = 0x0, LENGTH = 0x80000 , start at address 0x00.

The size of your application shows by the compiler after you build it. Or you can find the size using .map file, or convert to binary file.

RE: Dual Bank Bootloader Over ESB

TrebleStick — Mon, 04 Jun 2018 15:04:07 GMT

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.

RE: Dual Bank Bootloader Over ESB

Hung Bui — Mon, 04 Jun 2018 14:55:45 GMT

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.

RE: Dual Bank Bootloader Over ESB

TrebleStick — Mon, 04 Jun 2018 14:25:10 GMT

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?

RE: Dual Bank Bootloader Over ESB

Hung Bui — Mon, 04 Jun 2018 13:59:32 GMT

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 ?

RE: Dual Bank Bootloader Over ESB

TrebleStick — Mon, 04 Jun 2018 13:37:01 GMT

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?

RE: Dual Bank Bootloader Over ESB

Hung Bui — Mon, 04 Jun 2018 13:22:31 GMT

Hi Jack,

Could you let which S132 version you used ?

It looks pretty strange. The structure of the softdevice information is defined in Chapter 13 in S132 SDS v6.0

The size of the softdevice is located at word 2nd meaning address 0x3008 (SOFTDEVICE_INFO_STRUCT_ADDRESS + 8)

This is what I see when I flash the board with S132 v6.0 and use nrfjprog to read:

0x26000 matched with the size of the softdevice (+MBR) of 152kB.

RE: Dual Bank Bootloader Over ESB

TrebleStick — Mon, 04 Jun 2018 09:32:40 GMT

I re-flashed the soft device and read this

CODE_REGION_1_START = 0x32FFF04F

0x3000 = 0x2311D001

any ideas?

Sorry for the delayed response.

RE: Dual Bank Bootloader Over ESB

Hung Bui — Fri, 18 May 2018 16:43:56 GMT

CODE_REGION_1_START doesn't seem to be correct. Usually it's just the size of the softdevice which is written inside the softdevice (SOFTDEVICE_INFO_STRUCT_ADDRESS)

You can find this address usually by reading the address 0x3000 after you flash the softdevice.

RE: Dual Bank Bootloader Over ESB

TrebleStick — Fri, 18 May 2018 14:34:25 GMT

Hi Hung,

Correct, the FPGA image is sorted out within the app on board #2. The plan is to use existing code for sending new FPGA images to board #2 from board #1. It works over some ESB commands controlled using matlab with realterm as a serial communication to board #1. I've included the library that is being used for writing to flash for that. Once i've got a valid bank 1 to write to i plan to just use the bootloader library to validate the image and boot.

These are the relevant defines from the dfu_types.h file in the bootloader_dfu library and the respective values i get returned for them.

#define NRF_UICR_BOOT_START_ADDRESS         (NRF_UICR_BASE + 0x14)      

#if defined(NRF52)
#define NRF_UICR_MBR_PARAMS_PAGE_ADDRESS    (NRF_UICR_BASE + 0x18)      
#endif

#define CODE_REGION_1_START                 SD_SIZE_GET(MBR_SIZE)   //0x2311D001    
#define SOFTDEVICE_REGION_START             MBR_SIZE                //0X00001000    

//nrf51 definitions

#elif NRF52

#define BOOTLOADER_REGION_START             0x0007A000                 
#define BOOTLOADER_SETTINGS_ADDRESS         0x0007F000                  
#define BOOTLOADER_MBR_PARAMS_PAGE_ADDRESS  0x0007E000                  

#define CODE_PAGE_SIZE                      0x1000                      

#else

#error No target defined

#endif

#define DFU_REGION_TOTAL_SIZE           (BOOTLOADER_REGION_START - CODE_REGION_1_START)             //0XDCF5CFFF            

#ifndef DFU_APP_DATA_RESERVED
#define DFU_APP_DATA_RESERVED           CODE_PAGE_SIZE * 0                                          //0X00000000   
#endif

#define DFU_IMAGE_MAX_SIZE_FULL         (DFU_REGION_TOTAL_SIZE - DFU_APP_DATA_RESERVED)             //0XDCF5CFFF    

#define DFU_IMAGE_MAX_SIZE_BANKED       (((DFU_IMAGE_MAX_SIZE_FULL) - \
                                        (DFU_IMAGE_MAX_SIZE_FULL % (2 * CODE_PAGE_SIZE)))/2)        //0X6E7AE000    
                                        
#define DFU_BL_IMAGE_MAX_SIZE           (BOOTLOADER_SETTINGS_ADDRESS - BOOTLOADER_REGION_START)        

#define DFU_BANK_0_REGION_START         CODE_REGION_1_START                                         //0x2311D001                    
#define DFU_BANK_1_REGION_START         (DFU_BANK_0_REGION_START + DFU_IMAGE_MAX_SIZE_BANKED)       //0X918CB001

The issue seems to be the BOOTLOADER_REGION_START value when calculating DFU_REGION_TOTAL_SIZE, as it is less than CODE_REGION_1_START. How do you suggest changing this?

devzone.nordicsemi.com/.../flashwriting.c

Thanks again :)

RE: Dual Bank Bootloader Over ESB

Hung Bui — Fri, 18 May 2018 13:45:11 GMT

Hi Jack,

Leave the FPGA aside, I assume that you just need to flash a particular binary image to board #2 and the FPGA board will automatically be reprogrammed with the new image located on board #2 ?

Could you check and find why DFU_BANK_1_REGION_START = 0x918CB001 in your case ? It doesnt seem correct. Could you trace back and find what cause it to be >2GB ?

DFU_BANK_1_REGION_START by default equals (DFU_BANK_0_REGION_START + DFU_IMAGE_MAX_SIZE_BANKED)

How did you modify the bootloader to receive the image via ESB ? If you can manage to add a new dfu transport layer using ESB, then the bootloader should do its job to validate new image and swap the new image.