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

    Sorry about the late reply, but Susheel is out of office for the time being so I have taken over and I needed a while to get into your case before getting back to you. Since you're not using the QSPI peripheral that can only be used by the SPIM3, it should be fine to move to SPIM2. Although it should also be perfectly fine using the SPIM3 as long as you take into account and implement the workaround:

    Reserve dedicated RAM AHB slave for the SPIM3 transmit buffer, not overlapping with application data used by the CPU. In addition, synchronize so that the CPU is not writing data to the transmit buffer while SPIM is transmitting data.

    Best regards,

    Simon

Reply
  • Hi

    Sorry about the late reply, but Susheel is out of office for the time being so I have taken over and I needed a while to get into your case before getting back to you. Since you're not using the QSPI peripheral that can only be used by the SPIM3, it should be fine to move to SPIM2. Although it should also be perfectly fine using the SPIM3 as long as you take into account and implement the workaround:

    Reserve dedicated RAM AHB slave for the SPIM3 transmit buffer, not overlapping with application data used by the CPU. In addition, synchronize so that the CPU is not writing data to the transmit buffer while SPIM is transmitting data.

    Best regards,

    Simon

Children
No Data
Related