Access External Flash as Raw/low-level device. No file system wanted

I wanted to add this info to my previous ticket, but there was no option to reply. Just an FYI, here is the link:

https://devzone.nordicsemi.com/f/nordic-q-a/84225/expert-advice-on-best-flash-interface-for-the-nrf9160dk-and-clarification-of-the-devicetree

So after doing some more research I found a link (from Hakon) where he had attached a littlefs.zip that shows how to configure the 64MB flash device as a file system. That was very beneficial, but I really don't want the file system. I'd prefer to access the flash using low-level calls like:

flash_area_open(FLASH_AREA_ID(storage), &my_area

-or-

flash_dev = device_get_binding(DT_CHOSEN_ZEPHYR_FLASH_CONTROLLER_LABEL)

flash_read(flash_dev, ...,...);

Is there a way I can modify the overlay to provide that type of access for the external flash? Here is the overlay I'm using:

/ {
chosen {
nordic,pm-ext-flash = &mx25r64;
};
};

&spi3 {
status = "okay";
sck-pin = <13>;
mosi-pin = <11>;
miso-pin = <12>;
cs-gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
mx25r64: mx25r6435f@0 {
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <8000000>;
label = "MX25R64";
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>;
};
};

  • Hi Kevin,

    You would need to change the name of "littlefs_storage" section to a generic "storage" section in pm_static.yaml . Afterwards, you could access the storage using flash_area_open().

    Best regards,
    Dejan

  • Too keep things Dejans, I've decided to just use the littlefs on the 64MB external flash. The reason being is I want to have access to both the storage area storage area on the 1MB SiP flash for config info. And I want to store app data on the 64MB external flash device. And I won't need to access the littlefs at boot time. 

    But if I add the pm_static.yml that came with the littlefs.zip, then my application crashes with the following messages at boot:

    Programming 75.4 KB of addresses 00020200 — 00032f9b
    J-Link: Flash download: Bank 2 @ 0x00000000: 1 range affected (143360 bytes)
    J-Link: Flash download: Total: 4.545s (Prepare: 0.146s, Compare: 0.032s, Erase: 3.062s, Program & Verify: 1.225s, Restore: 0.077s)
    J-Link: Flash download: Program & Verify speed: 114 KiB/s
    Download successful
    Stopped by vector catch
    Stopped by vector catch
    Stopped by vector catch
    Stopped by vector catch

    If I remove the pm_static.yml file, my app builds and runs OK. But the littlefs sample code accesses the storage area of the 1MB flash, not the 64MB external flash. 

    So I assume the reason for the "stopped by vector catch" message is because pm_static.yml doesn't have the correct config for my build_nrf9160dk_nrf9160_ns application. I tried to attach the pm_static.yml file, but it doesn't seem to be working. Maybe it's my browser? (I'm using MS Edge if that matters). So instead, I'm pasting the YAML below. And by the way, I always re-run CMake when adding or removing the YAML file. Thanks in advance for your help.

    app:
      address: 0x20200
      end_address: 0xfa000
      region: flash_primary
      size: 0xd9e00
    external_flash:
      address: 0x100000
      end_address: 0x100000
      region: external_flash
      size: 0x00000
    littlefs_storage:
      address: 0xea000
      device: MX25R64
      end_address: 0x100000
      region: external_flash
      size: 0x16000
    mcuboot:
      address: 0x0
      end_address: 0x10000
      placement:
        before:
        - mcuboot_primary
      region: flash_primary
      size: 0x10000
    mcuboot_pad:
      address: 0x10000
      end_address: 0x10200
      placement:
        align:
          start: 0x8000
        before:
        - mcuboot_primary_app
      region: flash_primary
      size: 0x200
    mcuboot_primary:
      address: 0x10000
      end_address: 0xfa000
      orig_span: &id001
      - mcuboot_pad
      - spm
      - app
      region: flash_primary
      size: 0xea000
      span: *id001
    mcuboot_primary_app:
      address: 0x10200
      end_address: 0xfa000
      orig_span: &id002
      - app
      - spm
      region: flash_primary
      size: 0xe9e00
      span: *id002
    mcuboot_secondary:
      address: 0x0
      device: MX25R64
      end_address: 0xea000
      placement:
        align:
          start: 0x4
      region: external_flash
      size: 0xea000
    nrf_modem_lib_ctrl:
      address: 0x20010000
      end_address: 0x200104e8
      inside:
      - sram_nonsecure
      placement:
        after:
        - spm_sram
        - start
      region: sram_primary
      size: 0x4e8
    nrf_modem_lib_rx:
      address: 0x200124e8
      end_address: 0x200144e8
      inside:
      - sram_nonsecure
      placement:
        after:
        - nrf_modem_lib_tx
      region: sram_primary
      size: 0x2000
    nrf_modem_lib_sram:
      address: 0x20010000
      end_address: 0x200144e8
      orig_span: &id003
      - nrf_modem_lib_ctrl
      - nrf_modem_lib_tx
      - nrf_modem_lib_rx
      region: sram_primary
      size: 0x44e8
      span: *id003
    nrf_modem_lib_tx:
      address: 0x200104e8
      end_address: 0x200124e8
      inside:
      - sram_nonsecure
      placement:
        after:
        - nrf_modem_lib_ctrl
      region: sram_primary
      size: 0x2000
    otp:
      address: 0xff8108
      end_address: 0xff83fc
      region: otp
      size: 0x2f4
    spm:
      address: 0x10200
      end_address: 0x20200
      inside:
      - mcuboot_primary_app
      placement:
        before:
        - app
      region: flash_primary
      size: 0x10000
    spm_sram:
      address: 0x20000000
      end_address: 0x20010000
      inside:
      - sram_secure
      placement:
        after:
        - start
      region: sram_primary
      size: 0x10000
    sram_nonsecure:
      address: 0x20010000
      end_address: 0x20040000
      orig_span: &id004
      - sram_primary
      - nrf_modem_lib_ctrl
      - nrf_modem_lib_tx
      - nrf_modem_lib_rx
      region: sram_primary
      size: 0x30000
      span: *id004
    sram_primary:
      address: 0x200144e8
      end_address: 0x20040000
      region: sram_primary
      size: 0x2bb18
    sram_secure:
      address: 0x20000000
      end_address: 0x20010000
      orig_span: &id005
      - spm_sram
      region: sram_primary
      size: 0x10000
      span: *id005

  • BTW Dejan, I was wondering if the nrf9160DK_nrf9160_ns.yaml file is where the external flash changes should be placed, versus the pm_static.yml file? Here are the entries in the nrf9160DK_nrf9160_ns.yaml file:

    identifier: nrf9160dk_nrf9160_ns
    name: nRF9160-DK-NRF9160-Non-Secure
    type: mcu
    arch: arm
    toolchain:
    - gnuarmemb
    - xtools
    - zephyr
    ram: 128
    flash: 192
    supported:
    - arduino_gpio
    - arduino_i2c
    - i2c
    - pwm
    - watchdog

  • Hi Kevin,

    It is not necessary to put all partitioning information in pm_static.yml. Most of the work can be handled automatically by NCS itself.

    Could you try to build a sample and let me know if there are any warnings/errors in the build output by sharing the build log?

    Best regards,
    Dejan

  • Hi Kevin,

    This would not be the proper place for partitioning information. They should reside in partition.yml (pm.yml), or in your case pm_static.yml.
    <your_board>.yml file contains metadata used for testing as explained in board porting.

    Best regards,
    Dejan

Related