New firmware with Zephyr and old bootloader

[Stefano1984]

HI,

two years ago I started my adventure with the nRF52840 microcontroller. I started using SEGGER Embedded Studio for ARM as my development IDE. I created a peripheral BLE device and am able to update the firmware via bluetooth following the pca10056_s140_ble_debug example of the SDK.

Now I want to use Zephyr OS.

My question is: can I still use the bootloader I used previously?

If not, how can I update my device with the new firmware developed with the Zephyr?

Thank you.

[Sigurd Hellesvik]

Stefano1984 said:

doesn't work.

However with the instruction CONFIG_FLASH_LOAD_OFFSET=0x27000 with bootloader IT WORKS.

What could my problem be?

This expected.

I already kinda explained this over here. CONFIG_FLASH_LOAD_OFFSET is the red arrow in this picture:

Read the link I provided and let me know if what you see makes sense then

[Stefano1984]

Hi,
bear with me but I still don't understand where I'm wrong.

I understand that CONFIG_FLASH_LOAD_OFFSET=0x27000 moves my application to address 0x27000.
I read the documentation you gave me at the link but I couldn't find a solution to my problem. So I'll ask you some questions.

1) Why when I enter CONFIG_FLASH_LOAD_OFFSET=0x27000 my application (without bootloader) doesn't work at all? Shouldn't it still work without a bootloader?

2) in the documentation you indicated to me at the link there is no reference to the use of CONFIG_FLASH_LOAD_OFFSET and how to use it. Did I miss something?

3) in the documentation you gave me at the link, MCUboot is used. This however is not my case. I want to use the bootloader provided by nRF5_SDK_17.1.0 (pca10056_s140_ble_debug). Is there an example that fits my situation?

I hope you can help me.

Thank you.

[Sigurd Hellesvik]

Stefano1984 said:

1) Why when I enter CONFIG_FLASH_LOAD_OFFSET=0x27000 my application (without bootloader) doesn't work at all? Shouldn't it still work without a bootloader?

MCU starts executing from 0x000.
If nothing is at 0x0000, it will fail.
So either bootloader or app must start on 0x000.

Stefano1984 said:

2) in the documentation you indicated to me at the link there is no reference to the use of CONFIG_FLASH_LOAD_OFFSET and how to use it. Did I miss something?

I suggest that you read the entire page instead of Ctrl+F through for what you need. It gives some good background knowledge which can help you understand the root of your issue.
The part I specifically referred to was this sentence:
" When an nRF chip powers on, it will start executing code from address 0x00000000. Because of this, applications without a bootloader are stored from address 0x00000000 and onward. "

Stefano1984 said:

3) in the documentation you gave me at the link, MCUboot is used. This however is not my case. I want to use the bootloader provided by nRF5_SDK_17.1.0 (pca10056_s140_ble_debug). Is there an example that fits my situation?

Yes, but the concept of a bootloader is the same for the nRF Connect SDK and the nRF5 SDK.

Basically: The bootloader and the application does not really know about each other.
The only thing is that the bootloader knows which address the application starts at, and then it hands over execution to that addr.

The nRF5 SDK is a bit special, as it has the MBR that is at 0x000 which then hands over to the bootloader before the nRF5 bootloader starts the application.

I think it will be beneficial if you do your project here in steps.
Here are the steps I suggest. After each step, see that everything works as planned.

1. Use MCUboot and NCS application. Flash merged.hex to the device, as this has both app and bootloader.
2. Use MCUboot and NCS application. Flash hex files for MCUboot and application separately.  Use "west -vvv build ..." to see which files are used to make merged.hex.
3. Use MCUboot and NCS application. Change start addr for application. Flash hex files for each.
4. Use nRF5 application and nRF5 bootloader. Flash entire nRF5 project to device
5. Use nRF5 application and nRF5 bootloader. Flash application and bootloader hex files each on their own.
6. Use nRF5 bootloader and NCS application. Flash each hex file on their own.
7. Then start looking into DFU.

[Stefano1984]

Thanks, I'll do as you said and let you know.

[Stefano1984]

Hi Sigurd Hellesvik ,

I'm following your instructions starting from step 1: Use the MCUboot and NCS application

I read the bootloader guide here and was able to put the MCUboot on my NCS application.

Following the example "Exercise 3 – FOTA over Bluetooth Low Energy" is very simple, just add the following lines to the prj.conf file:

CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

Everything works perfectly. The only difference is that I don't use the merged.hex file, instead I use the app_update.bin file as indicated in the guide.
At this point, before going any further, I have some questions:
1) with the old bootloader (nRF5 bootloader) I had to define a private key in the dfu_public_key.c file. I guess it's to encrypt the DFU packet. Regarding the MCUboot, is there a private key to set?

2) I can't use the west command. I use VSCode to compile the code and in fact VSCode uses the west command. For example:

west build --build-dir c:/GitHub_Repository/spi_flash/build c:/GitHub_Repository/spi_flash

I installed west with package manager (pip3) but when I use the same command I get the following error:

west: unknown command "build"; do you need to run this inside a workspace?

I run the west command in my workspace. How do I solve the problem?

Thank you.