Very simple SPI bootloader

RE: Very simple SPI bootloader

Vidar Berg — Mon, 23 Nov 2015 15:12:06 GMT

No problem:) P.S. think new questions not directly related to my answer should be posted as a new questions to better fit the QA format of this page. This should make it easier for others to find a solution while searching for a particular subject. So please accept answer above, and make a separate thread if new questions arises.

RE: Very simple SPI bootloader

mbozic — Mon, 23 Nov 2015 15:02:57 GMT

Ok, will try. Thank you!

RE: Very simple SPI bootloader

Vidar Berg — Mon, 23 Nov 2015 15:01:13 GMT

SD_MBR_COMMAND_INIT_SD forwards interrupts from the MBR to the vector table located at 0x1000. With this the MBR stops forwarding the interrupts directly to the bootloader.

RE: Very simple SPI bootloader

mbozic — Mon, 23 Nov 2015 14:55:29 GMT

Sorry, not sure if I understood right. I have to use SD_MBR_COMMAND_INIT_SD command for MBR when bootloader finishes it's work so that vector table is forwarded from bootloader to application?

Yes, application will transfer data to SPI flash, and bootloader will only transfer/flash the data to nRF. Yes, app and SD should always be compatible, meaning that when we update the SD, we must update the app with it.

RE: Very simple SPI bootloader

Vidar Berg — Mon, 23 Nov 2015 13:55:57 GMT

The CODE_REGION_1_START is stored in the SDs info structure at 0x3000, and thus updated when you have uploaded a new SD. In your case it's the application that's actually receiving the image, and the bootloader will only handle the swapping of images, right? So you need to ensure that your application is always compatible with the SD to allow new DFU attempts. There should not be any need to update the bootloader itself.

RE: Very simple SPI bootloader

mbozic — Mon, 23 Nov 2015 13:46:13 GMT

Hey Vidar, still waiting for a comment. :)

RE: Very simple SPI bootloader

mbozic — Fri, 20 Nov 2015 09:49:05 GMT

My small code example works ok now! UICR->BOOTLOADERADDR was the problem. Thank you!

I would like to make this bootloader totally independent of SoftDevice. Is that possible? Imagine this scenario. There is no SD. App does not use SD. MBR is flashed and valid. How would I jump from bootloader to application? And how would I set interrupt forwarding address (application vector table) to application and vice versa without SD?

If I code a bootloader which will use sd_softdevice_vector_table_base_set(CODE_REGION_1_START), what would happen if you change the address of that function(example: SD becomes bigger than 96kb) in new SD version? My bootloader would become invalid(outdated), correct? And I would have to update a new bootloader also. But the idea is to make this bootloader as MBR, it should never ever need an update. Is that possible? If yes, how?

RE: Very simple SPI bootloader

Vidar Berg — Thu, 19 Nov 2015 13:18:15 GMT

UICR->BOOTLOADERADDR must correspond to the start address of your bootloader so the MBR will start forwarding interrupts to the bootlaoder and "jump" to the bootloader on startup.

You can use sd_softdevice_vector_table_base_set() once you have invoked the softdevice. See the functions that needs to be called to enter the application above in my answer

RE: Very simple SPI bootloader

mbozic — Thu, 19 Nov 2015 13:09:57 GMT

Exactly! Basically I need a simple "app" which can read SPI flash, write nRF flash, blink some LEDs, and print to uart(debug). I've already done something like that but when I change addressees of flash as they are in DFU examples, my bootloader example won't start when flashed. Must I change some other stuff too? Also, vector handling is a problem here since I can't use sd_softdevice_vector_table_base_set(), correct?

RE: Very simple SPI bootloader

Vidar Berg — Thu, 19 Nov 2015 12:53:53 GMT

Ok I see, you want to only use the bootloader to load the images from SPI flash to the nRF51 that previously received over BLE in the application. Then it will be a entirely different implementation of the bootloader than the one we have in our SDK (simpler).

RE: Very simple SPI bootloader

mbozic — Thu, 19 Nov 2015 12:22:52 GMT

Why OTA bootloader? I don't need BLE or UART in my bootloader. The application(normal application everyone has) will transfer the update to SPI flash when device is operating normally. Meaning I have SD (BLE usage) only in my app. When application transfers the file it raises the flags and restarts the nRF. Bootloader checks the flags and only uses SPI to transfer data from SPI flash to nRF flash. My bootloader must only have SPI driver for transfer, must be able to flash nRF, it should use timers for LED blinking and UART for debugging(printing on terminal). Bootloader does not use UART or BLE for file transfer, the application does the file transfer when in normal operation. Bootloader just flashes the data. At least that is the idea.

For now, UART does not work, timer using scheduler does not work and SPI does not work. I'll try to debug SPI tomorrow and see what went wrong.

RE: Very simple SPI bootloader

Vidar Berg — Thu, 19 Nov 2015 09:32:42 GMT

I would've based this on the OTA bootlaoder if you're planning to receive the image over BLE to SPI flash. SPI is not really the transport layer for the bootloader if I have understood you correctly.

UART is used by the serial bootlaoder by default, so it's reinitialized after you have enabled app trace. Not sure why SPI did not work though. You can try to debug the bootloader to see what the reason may be.

RE: Very simple SPI bootloader

mbozic — Wed, 18 Nov 2015 16:27:00 GMT

SPI hangs the entire bootloader when trying to initialize it @ spi_master_init_hw_instance(NRF_SPI0, SPI0_TWI0_IRQn, p_spi_instance, p_spi_master_config->SPI_DisableAllIRQ);

RE: Very simple SPI bootloader

mbozic — Wed, 18 Nov 2015 15:33:50 GMT

I've taken "serial single bank bootloader" as my project. When I create and run timer in it, it does not run. When I try to printf (UART put...) nothing happens. I believe SPI won't work either, didn't had the time to test it today.

Any ideas why?

RE: Very simple SPI bootloader

mbozic — Wed, 18 Nov 2015 11:54:59 GMT

I'm working on a "serial single bank" example, although I don't need banks at all for this case, I simply flash directly from SPI flash to chip flash. Yes, larger application space could be required later.

Will ping you if I get some kind of a problem, but for now everything is clear.

Thank you!

RE: Very simple SPI bootloader

Vidar Berg — Wed, 18 Nov 2015 11:31:22 GMT

Yes, the MBR must be kept when doing DFU. Also, just wanted to mention that you can make the standard bootloader use single bank in case you were not aware of it. Just replace dfu_dual_bank.c with dfu_single_bank.c. Assume the reason for using SPI flash is to have enough storage for a larger application?

RE: Very simple SPI bootloader

Vidar Berg — Wed, 18 Nov 2015 10:36:13 GMT

CODE_REGION_1_START is hardcoded in an info structure within the softdevice, see dfu_types.h on how the bootloader reads this address. I don't think there is anything wrong with the approach I proposed, but could I could have forgotten some minor details. I would have to implement this to verify that it will work. Unfortunately, I don't have time to do this. I suggest to just start and get more familiar with the bootlaoder and try to implement the changes, and let me know if any problems arise.

RE: Very simple SPI bootloader

mbozic — Wed, 18 Nov 2015 10:15:15 GMT

One more question. When updating SD directly as mentioned above, I should keep MBR intact, correct? Meaning I should skip first 4096 bytes(address 0x0 - 0x1000) when deleting and writing new SD.

Thank you!

RE: Very simple SPI bootloader

mbozic — Wed, 18 Nov 2015 10:05:58 GMT

Yes, that's it!

application transfers data to SPI external flash, raises flags, restarts
bootloader reads flags and flashes the chip (new SD or new app), clears flags and enters new app

This means I don't have to use vector mapping, since if I use modified SDK bootloader, MBR will always call bootloader 1st. And after bootloading is done, when I call the stuff you wrote, I will have SD flashed so it will work. And since this is very simple bootloader(KISS principle), it will never need updating of it's own.

I think I got it now, I'll wait until you confirm this last few sentences. Just one simple question. If size of SD changes it will change CODE_REGION_1_START address, correct? So I guess I should have this address as a variable which I can write/read and not have it hard-coded in the bootloader?

Thank you very much! This helped me to grasp everything into solution.

RE: Very simple SPI bootloader

Vidar Berg — Wed, 18 Nov 2015 09:46:01 GMT

updated my answer

RE: Very simple SPI bootloader

mbozic — Tue, 17 Nov 2015 14:29:55 GMT

Ok, that helped a bit with some facts.

So basically I can modify "serial single bank bootloader" template and make it read stuff from external flash over SPI. But, how to make MBR read data directly from external flash? I guess there is no way? I would have to copy data for SD to chip flash and then tell MBR to overwrite it?

The problem is I will have my own file from which SD will be updated. Where can I read some info about how SD firmware file must look like in temporary bank(bank 1) so MBR will be able to update it on it's own from bank 1 to bank 0?

Is there a source code for "sd_softdevice_vector_table_base_set()" function? Why not use that function each time we go from bootloader to application and vice versa so we don't need to use a solution as it was mentioned on the link you provided above?

Thank you!

RE: Very simple SPI bootloader

Vidar Berg — Tue, 17 Nov 2015 11:37:45 GMT

Correct the MBR is loaded at address 0 and is included as a part of the SD binary. On startup the MBR will forward execution to the address stored in UICR->BOOTLOADERADDR if set. In our examples we place the bootloader above the application, see memory layout.

Replacing the SD itself will be handled in the MBR without involvement from the bootloader, and will not return execution to the bootloader before its finished (will also handle unexpected resets).

RE: Very simple SPI bootloader

mbozic — Tue, 17 Nov 2015 09:14:04 GMT

Hm, I've already taken a look at link and still a little fuzzy about it.

Regarding sd_softdevice_vector_table_base_set() and MBR, I don't get it at all. Where is MBR located, in SD or must I flash it separately? If MBR goes at the address of 0x0000 then I must flash the bootloader on some offset(0x0000 + MBR size)? Any document in which I can read about this? How to write flash without SD? I've seen a function "sd_flash_write()" but where are functions for flash write without SD? Or, how to do this "an easier approach may just be to use the SD to forward interrupts to your bootloader/application" when SD is deleted and I'm writing over it. How to use SD for anything when you have deleted it to update it?

There are so many questions I can't find an answer to.

RE: Very simple SPI bootloader

Vidar Berg — Mon, 16 Nov 2015 10:35:03 GMT

Maybe the example mentioned in this thread here can give you some pointers on how to handle interrupt forwarding without the softdevice. However, an easier approach may just be to use the SD to forward interrupts to your bootloader/application (sd_softdevice_vector_table_base_set()). Then use the MBR to enable update of the SD itself.

EDIT 17.11

Think I have a better idea of what you want to do now after reading your question again, but please correct me if I'm wrong:

First you want to receive the image over BLE and store it to external flash over SPI. Then once finished, use the bootloader to load the received FW image into application or SD space on the nRF51.

So if my understanding is correct I think I would have used the SDK bootloader as a basis, and modify it so it runs independent of the Softdevice once a FW image is successfully loaded to the SPI flash. That is, don't call ble_stack_init() or use any of the sd_ flash APIs (pstorage). When the bootloader is running independent of the softdevice you can access the the NVMC module directly (example). Thus, delete and update the softdevice from the bootloader without using the MBR (MBR can't access "SPI" memory).

Update sequence:

FW image is uploaded over BLE, only difference is that it's loaded to SPI flash (softdevice enabled at this point).
Bootloader verifies integrity of received image. CRC and image size received from init packet and start packet respectively.
Set a flag in bootloader settings to indicate new FW image is ready to be swapped. Similiar to what we already do when updating the softdevice/bootloader.
Bootloader does a system reset (soft reset - NVIC_SystemReset)
MBR forwards execution directly to the bootloader without invoking the softdevice
Bootloader checks for update in progress flag on startup, similiar to if (bootloader_dfu_sd_in_progress()) in existing example.
Prepare flash region (delete) and start loading the image from "SPI" flash to Softdevice/App region.
Update flags in bootloader settings when complete and reset.
Go into DFU mode or start application if it's present and valid.

Also, before you enter the application the following functions must have been called:

sd_mbr_command_t com = {SD_MBR_COMMAND_INIT_SD, }; // MBR starts forwarding interrupts to SD

uint32_t err_code = sd_mbr_command(&com);
APP_ERROR_CHECK(err_code);

interrupts_disable();

err_code = sd_softdevice_vector_table_base_set(CODE_REGION_1_START); // Set interrupt forwarding address (application vector table)
APP_ERROR_CHECK(err_code);

bootloader_util_app_start(CODE_REGION_1_START); // ASM routine to branch to app reset handler.

Note that I have not had a chance to test the approach I described above, so it is possible that I've missed something.