nrf52840 spim, external flash W25Q32JV read/write failed, mcuboot failed

We are using the external flash w25q32jv via SPIM connection. the configuration as below.


arduino_spi: &spi3 {
status = "okay";
compatible = "nordic,nrf-spim";
cs-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;

pinctrl-0 = <&spi3_default>;
pinctrl-1 = <&spi3_sleep>;
pinctrl-names = "default", "sleep";
w25q32jv: w25q32jv@0 {
compatible = "jedec,spi-nor";
reg = < 0 >;
spi-max-frequency = < 8000000 >;
size = < 0x2000000 >;
has-dpd;
t-enter-dpd = < 3000 >;
t-exit-dpd = < 30000 >;
jedec-id = [ ef 40 16 ];
};
};
When performing write/read with only configuration SPI nor flash, it passed. But when integrating into the system with USB_CDC_ACM, PDMIC, zephyr threads. It's very easy to fail write/read flash and mcuboot from external flash. We investigate that the f/w sending the wrong op-code for reading/writing. If we use irq_lock/unlock before flash_area_write(), flash_area_read() in zephyr library. The flash operation is successful and DFU with mcumgr will pass.
But this solution needs to modify the zephyr library (flash_map.c), not easy to commit and apply to our firmware. What should be appropriate solution in this case?
Parents
  • Hi,

    We investigate that the f/w sending the wrong op-code for reading/writing. If we use irq_lock/unlock before flash_area_write(), flash_area_read() in zephyr library. The flash operation is successful and DFU with mcumgr will pass.

    It looks like there is some race condition in your application that is seems solved when you apply this critical section locks in the lower layers of the zephyr library. But applications should apply critical section (lock/unlock of schedulers) not in lower levels but in the app level.

    Based on your explanation, it sounds very much like you managed to solve an application race condition by applying critical sections on lower levels.

    You need to figure out why this workaround (irq_lock/unlock) worked for you. This can be due to any race condition in your application not visible to us.

Reply
  • Hi,

    We investigate that the f/w sending the wrong op-code for reading/writing. If we use irq_lock/unlock before flash_area_write(), flash_area_read() in zephyr library. The flash operation is successful and DFU with mcumgr will pass.

    It looks like there is some race condition in your application that is seems solved when you apply this critical section locks in the lower layers of the zephyr library. But applications should apply critical section (lock/unlock of schedulers) not in lower levels but in the app level.

    Based on your explanation, it sounds very much like you managed to solve an application race condition by applying critical sections on lower levels.

    You need to figure out why this workaround (irq_lock/unlock) worked for you. This can be due to any race condition in your application not visible to us.

Children
Related