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

  • 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



  • Hi

    I'm sorry about the late reply, I've been out of office for a course the past few days and am only now getting to my backlog. There's definitely something fishy with how the nRF52833 is reading back from this device, but the scope plot you've uploaded is very hard to read when all the lines are put on top of each other. Is there any chance you could provide a plot where the lines are separated from each other so we don't have to guess what line is what exactly, and can see how each of them behaves.

    If you are also able to get a plot of how it communicates with the Arduino we can compare them and likely get an idea of what the difference is exactly.

    Best regards,

    Simon

  • Hi,
    I will have to do that tomorrow. One question, can you look at Picoscope .psdata waveform files? That is what I can get out of my oscilloscope and then you could zoom in/out and I will check if you can enable/disable certain lines. Otherwise, like you said, it is hard to make out the details with just pictures.

  • Hi Simon,

    here are some better pictures. I recorded the data such that the MOSI/MISO are above the CLOCK. I hope you can see it.

    First a 0x05 command for read-status-register is sent and then the 0x9f command for read-JEDECID. I zoomed into the second because this is the interesting one. 

    Note that the arduino sends data with a voltage level of 5V and the nRF52833 with 3.3V.


    SPI configuration:




    Arduino:




    nRF52833:





    I can't upload the .psdata-files. Let me know if you can use them and maybe I can upload them somewhere else.

    Regards,
    Joanna


Related