I am doing some development where I use the external flash for storage external to my application. When I enable MCUboot, I can no longer access the external flash. This is on an nrf52840. Pretty new to Zephyr, so I think I've got my overlay configured correctly. flash0 looks to be all on the mcu flash partitions, so unsure at the moment why I can't access the external flash. If I disable MCUboot, I can access external flash again.
Any help is appreciated.
Thanks
Hi Kenny,
Could you show how you access the external flash ?
Also please show the partition configuration (pm_static.yml or the partitions.yml in the build folder) . Usually the partitions configuration will show how the mcuboot occupy the flash/external flash.
Which error do you see when you try to access the flash ?
Hi Kenny,
Could you show how you access the external flash ?
Also please show the partition configuration (pm_static.yml or the partitions.yml in the build folder) . Usually the partitions configuration will show how the mcuboot occupy the flash/external flash.
Which error do you see when you try to access the flash ?
Hi Hung,
Thanks for the prompt reply. I implemented a command line to direct access the flash functions, using SPI transfers. I started with the nrf52840dk and now working with a custom board so I have an overlay. I am currently using it in standard x1, rather than quad.
My overlay defines SPI config as follows:
Here are the partitions.yml contents:
Hi Kenny,
The nRF52840dk device tree defined mx25r64 external flash on qspi in nrf52840dk_nrf52840.dts:
&qspi {
status = "okay";
pinctrl-0 = <&qspi_default>;
pinctrl-1 = <&qspi_sleep>;
pinctrl-names = "default", "sleep";
mx25r64: mx25r6435f@0 {
compatible = "nordic,qspi-nor";
reg = <0>;
/* MX25R64 supports only pp and pp4io */
writeoc = "pp4io";
/* MX25R64 supports all readoc options */
readoc = "read4io";
sck-frequency = <8000000>;
jedec-id = [c2 28 17];
sfdp-bfp = [
e5 20 f1 ff ff ff ff 03 44 eb 08 6b 08 3b 04 bb
ee ff ff ff ff ff 00 ff ff ff 00 ff 0c 20 0f 52
10 d8 00 ff 23 72 f5 00 82 ed 04 cc 44 83 68 44
30 b0 30 b0 f7 c4 d5 5c 00 be 29 ff f0 d0 ff ff
];
size = <67108864>;
has-dpd;
t-enter-dpd = <10000>;
t-exit-dpd = <35000>;
};
};
If you are not using the same flash you should disable it.
But we would need to know more debug information when you no longer be able to read. Have you checked if there is any signal on SPI pins ? Any error in the code?
From what I can see in the partition file MCUBoot doesn't use the external flash for image storing so I am not sure why it affect your SPI communication.
Could you find the .config file(s) in the build folders before and after you enable MCUBoot. We can take a look at what's changed and see if we can find anything. The .config file is the generated file for all the configuration of the application.
Hi Hung,
Probing the SPI pins, there are no signals coming out. Hence, rx buffer returning all 0s.
I have also gone through to disable the external flash and disabled QSPI as well from the original dts/dtsi files with no luck.
When building without the mcuboot configured, I don't have any .config files under the build directory. After adding mcuboot in prj.conf, a pm.config file gets generated. Contents below:
PM_MCUBOOT_OFFSET=0x0
PM_MCUBOOT_ADDRESS=0x0
PM_MCUBOOT_END_ADDRESS=0xc000
PM_MCUBOOT_SIZE=0xc000
PM_MCUBOOT_NAME=mcuboot
PM_MCUBOOT_ID=0
PM_mcuboot_ID=PM_MCUBOOT_ID
PM_mcuboot_IS_ENABLED=1
PM_0_LABEL=MCUBOOT
PM_MCUBOOT_PAD_OFFSET=0xc000
PM_MCUBOOT_PAD_ADDRESS=0xc000
PM_MCUBOOT_PAD_END_ADDRESS=0xc200
PM_MCUBOOT_PAD_SIZE=0x200
PM_MCUBOOT_PAD_NAME=mcuboot_pad
PM_MCUBOOT_PAD_ID=1
PM_mcuboot_pad_ID=PM_MCUBOOT_PAD_ID
PM_mcuboot_pad_IS_ENABLED=1
PM_1_LABEL=MCUBOOT_PAD
PM_MCUBOOT_PRIMARY_OFFSET=0xc000
PM_MCUBOOT_PRIMARY_ADDRESS=0xc000
PM_MCUBOOT_PRIMARY_END_ADDRESS=0x86000
PM_MCUBOOT_PRIMARY_SIZE=0x7a000
PM_MCUBOOT_PRIMARY_NAME=mcuboot_primary
PM_MCUBOOT_PRIMARY_ID=2
PM_mcuboot_primary_ID=PM_MCUBOOT_PRIMARY_ID
PM_mcuboot_primary_IS_ENABLED=1
PM_2_LABEL=MCUBOOT_PRIMARY
PM_MCUBOOT_PRIMARY_SPAN="mcuboot_pad app"
PM_APP_OFFSET=0xc200
PM_APP_ADDRESS=0xc200
PM_APP_END_ADDRESS=0x86000
PM_APP_SIZE=0x79e00
PM_APP_NAME=app
PM_APP_ID=3
PM_app_ID=PM_APP_ID
PM_app_IS_ENABLED=1
PM_3_LABEL=APP
PM_MCUBOOT_PRIMARY_APP_OFFSET=0xc200
PM_MCUBOOT_PRIMARY_APP_ADDRESS=0xc200
PM_MCUBOOT_PRIMARY_APP_END_ADDRESS=0x86000
PM_MCUBOOT_PRIMARY_APP_SIZE=0x79e00
PM_MCUBOOT_PRIMARY_APP_NAME=mcuboot_primary_app
PM_MCUBOOT_PRIMARY_APP_ID=4
PM_mcuboot_primary_app_ID=PM_MCUBOOT_PRIMARY_APP_ID
PM_mcuboot_primary_app_IS_ENABLED=1
PM_4_LABEL=MCUBOOT_PRIMARY_APP
PM_MCUBOOT_PRIMARY_APP_SPAN="app"
PM_MCUBOOT_SECONDARY_OFFSET=0x86000
PM_MCUBOOT_SECONDARY_ADDRESS=0x86000
PM_MCUBOOT_SECONDARY_END_ADDRESS=0x100000
PM_MCUBOOT_SECONDARY_SIZE=0x7a000
PM_MCUBOOT_SECONDARY_NAME=mcuboot_secondary
PM_MCUBOOT_SECONDARY_ID=5
PM_mcuboot_secondary_ID=PM_MCUBOOT_SECONDARY_ID
PM_mcuboot_secondary_IS_ENABLED=1
PM_5_LABEL=MCUBOOT_SECONDARY
PM_SRAM_PRIMARY_OFFSET=0x0
PM_SRAM_PRIMARY_ADDRESS=0x20000000
PM_SRAM_PRIMARY_END_ADDRESS=0x20040000
PM_SRAM_PRIMARY_SIZE=0x40000
PM_SRAM_PRIMARY_NAME=sram_primary
PM_NUM=6
PM_ALL_BY_SIZE="mcuboot_pad mcuboot sram_primary app mcuboot_primary_app mcuboot_secondary mcuboot_primary"
Is it possible the bootloader (mcuboot) is doing something with those pins and fails to reconfigure when loading the application?
I might have to recreate my custom board on the nrf52840dk for easier debugging. I should also create a custom board instead of using the overlay.
Thanks
Hi Hung,
Update. Doing some digging, I don't think it's CONFIG_BOOTLOADER_MCUBOOT=y that is causing the issue but rather CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y causing basic SPI to no longer function. Then I found this thread:
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU doesn't work with SPI NOR
Looks like a workaround until it gets addressed. It also looks like CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU is using external flash. What is the easiest way to configure it for internal flash?
Thanks
Hi Kenny,
Thanks for the info, from what I can see in NCS v2.8.0 the NORDIC_QSPI_NOR imply is removed. Please try to update to the latest NCS.
From what I can see in the MCUBoot partition you provided, the MCUBoot is using internal flash.
Please try to check the partitions.yml after build.