bootloader issues using gcc

[wim]

Hi

I have been using the DFU for quite a while. I adapted the boot loader to my hardware and compiled it using Keil. All my other code is written in another environment using gcc, so I wanted to be able to do the boot loader in that same environment.

I managed to get the boot loader compiled and working, however, still got 2 issues:

• apparently, even with the maximum optimization, the size is really at then limit, so I cannot add extra things apparently - is there a way to overcome this?
• a bigger issue for me is that, when using the bootloader compiled with gcc, I cannot start my program after programming boot loader, soft device and application hex files using a JlinkExe script, I need to program the application using the DFU; with the Keil version that was not necessary;

After reading through the forum, it seems that in the gcc version, no valid flag is written tot he BOOTLOADER_SETTINGS flash space. I tried to fix that by including a write of the good value at this position, as suggested here but apparently that flash location was already written to 0, so cannot write to it anymore, that location or page should be erased first.

Can anyone help me solve this issue?

Is there a way of erasing and re-writing a single byte in flash using JlinkExe? And is this 1 byte the only thing checked at startup of the bootloader, or are there some other integrity checks? Or is the only way editing the boot loader hex file? How does the Keil project do this, make sure the application valid flag is already set in the hex file?

For information: I am using SDK7.2.0 on custom hardware, and I am doing all my development on Mac OSX.

dfu_gcc_nrf51.ld Makefile

[wim]

Triggered about your remark about the BANK_INVALID_APP, found my edit in the Keil project : I added something to this line in bootloader_settings_arm.c: const uint8_t m_boot_settings[CODE_PAGE_SIZE] attribute((at(BOOTLOADER_SETTINGS_ADDRESS))) attribute((used)) = {BANK_VALID_APP};

Not sure how to do this in the GCC equivalent. In my GCC project, I have following line in bootloader_settings.c: attribute ((section(".bootloaderSettings"))) uint8_t m_boot_settings[CODE_PAGE_SIZE];

What will cause a default of 0x01?

[Hung Bui]

@wim: Please follow the bootloader_settings.c file in SDK v8.1

if you want to pre-set a value in flash, I think you can try:

uint8_t m_boot_settings[CODE_PAGE_SIZE] attribute ((section(".bootloaderSettings"))) = {BANK_VALID_APP};

[wim]

tried that but that did not seem to change anything. (I guess because it is not declared as a constant?) I am now comparing some things between my code and the SDK8.1 I noticed that in my linker script, there is a difference in the definition of .Bootloadersettings.

in version 7.2 I have:

   /* Ensures the bootloader settings are placed at the last flash page. */
  .bootloaderSettings(NOLOAD) :
  {

  } > BOOTLOADER_SETTINGS

In version 8.1 this is:

     /* Ensures the bootloader settings are placed at the last flash page. */
  .bootloaderSettings :
  {
	
  } > BOOTLOADER_SETTINGS

I am not familiar with the syntax of a gcc link script. What does the "(NOLOAD)" do? Tried to remove it but then I get an error during linking:

section .bootloaderSettings loaded at [000000000003fc00,000000000003ffff] overlaps section .data loaded at [000000000003fbe8,000000000003fc4f]

Also, in my hex file, there seems to be data in the BOOTLOADER settings flash page, here is an extract from the hex file:

:10FBE800FFFF00000500000000000000000000000A
:10FBF80000000000000000000000000000000000FD
:10FC08000000000000000000D8FB03000000000016
:10FC180000000000000000000000000000000000DC
:10FC280000000000000000000000000000000000CC
:10FC380000000000000000000000000000000000BC

Where does that data come from?

[Hung Bui]

Hi Wim,

Sorry I forgot that you need to remove NOLOAD. NOLOAD marks that this section should not be loaded with anything and result that you don't write the BANK_VALID_APP into it.

I tried here with SDK v8.1 and it worked fine for me (after removing NOLOAD). I attached the hex in my answer. If you open you can find the word at the 0x3FC00 address was written 0x01.

I would suggest you to download a fresh copy of the SDK v8.1 and test with that before you move back to you bootloader in SDK v7.1.

[wim]

ok, i will give it a try, but still out of curiosity: the error message that I get, does this suggest that my code is too big? and another question: can I combine the 8.1 bootloader with a 7.3 soft device and and SDK7.2 application?