SPI-NOR flash devicetree error int_res==16 EBUSY

Dear Nordic Team,

I found a few similar issues in this forum but nothing that then solved my problem which brought me to the conclusion it might be different here.

I try to add an external SPI-NOR flash (MX25R8035F) to nrf52832 project. I started with the example in zephyr/samples/drivers/spi_flash which is for nrf52840 and changed the dts file as follows:


Here I post the "arduino-spi", I also tried with SPI0 and SPI1, same behavior.

nrf52dk_nrf52832.dts:

aliases {
 ...

 ...
spi-flash0 = &mx25r80;
};

arduino_spi: &spi2 {
status = "okay";
cs-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&spi2_default>;
pinctrl-1 = <&spi2_sleep>;
pinctrl-names = "default", "sleep";

mx25r80: mx25r8035f@0 {
compatible = "jedec,spi-nor";
label="MX25R80";
reg = <0>;
spi-max-frequency = <33000000>;
size = <0x800000>;
jedec-id = [c2 28 14];
};
};

my code:

const struct device *flash_dev = DEVICE_DT_GET(DT_ALIAS(spi_flash0));

void main(void)
{
    if (!device_is_ready(flash_dev)) {
        printk("%s: device not ready.\n", flash_dev->name);
    }
    ...
}



The problem:
The flash device gets partly  initialized since flash_dev.state.initialized == 1 and partly not since flash_dev.state.init_res==16 (should be 0). That is why device_is_ready() return false.
I see this in the debugger as below:



I see on my oszilloscope that SPI itself is working because I get responses from the external flash, so I can't be doing everything wrong. But the write and read process is working incorrectly, meaning that if I write something to a location, I get a wrong response when reading again.

Do you have any ideas what the problem could be? 
I also tried to research what EBUSY in the devicetree means in general and found that it often has to do with wrong pins. However, this can't be the case here, since my SPI is working, do you agree?

Thank you very much in advance,
Joanna

Parents
  • Joanna said:
    I am not working with the NCS, but with the plain Zephyr version 3.2. 

    Okay, then it might be worth joining the Zephyr discord and asking the community there if they've seen any issues with the SPI NOR driver there, as I'm not aware of any bugs with the Zephyr SPI-NOR driver from our end, and we generally only work with the nRF Connect SDK.

    Best regards,

    Simon

  • Hi Simon,

    I tested again with the newest nRF Connect SDK v3.2.0. It breaks down to getting the zephyr/samples/drivers/spi_flash to run with the nRF52833.
    The changes I made to get it to run on this other board are the following:

    1) Add file boards/nrf52833dk_nrf52833.conf with CONFIG_SPI_NOR:



    2) Add external flash to devicetree:


    3) Turn on logging:



    I get this UART output showing that the chip can't be found because the JEDEC ID is not read properly. Instead random garbage is coming back:



    This is the oscilloscope showing the "read JEDEC ID" command which is 9F and then the false answer:




    I hope this helps in further narrowing down the problem.


    Also important, I tested the same flash chip breakout board that I made with an Arduino and it works fine.

    Thank you
    Joanna



Reply
  • Hi Simon,

    I tested again with the newest nRF Connect SDK v3.2.0. It breaks down to getting the zephyr/samples/drivers/spi_flash to run with the nRF52833.
    The changes I made to get it to run on this other board are the following:

    1) Add file boards/nrf52833dk_nrf52833.conf with CONFIG_SPI_NOR:



    2) Add external flash to devicetree:


    3) Turn on logging:



    I get this UART output showing that the chip can't be found because the JEDEC ID is not read properly. Instead random garbage is coming back:



    This is the oscilloscope showing the "read JEDEC ID" command which is 9F and then the false answer:




    I hope this helps in further narrowing down the problem.


    Also important, I tested the same flash chip breakout board that I made with an Arduino and it works fine.

    Thank you
    Joanna



Children
No Data
Related