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
  • Hi Joanna

    Did you get anywhere from the Pull request that Scott suggests looking at in the Github ticket? The Zephyr driver does indeed assume that all SPI controllers are implemented similarly, but I'd think that at least the MX25R8035 should work very similarly to the one on board the nRF52840 DK.

    Best regards,
    Simon

  • Hi Simon,

    honestly, I do not quite understand the changes in the pull request. Plus, I by far do not understand it enough to apply it to the Nordic controller. I was hoping you might ;-)

    Concerning your comment, I do not think the issue describes the flash memory, since all flash memory with JEDEC standard should behave the same. I think the problem lies on the Zephyr SPI-NOR driver side. The SPI-NOR does not use Nordic specific SPI driver, but some general one. And this causes the problem, because the data coming from the flash is not clocked in right, thus resulting in rubbish. This fits to the behavior I observe. Please correct, if I am wrong.

    Regards,
    Joanna

Reply
  • Hi Simon,

    honestly, I do not quite understand the changes in the pull request. Plus, I by far do not understand it enough to apply it to the Nordic controller. I was hoping you might ;-)

    Concerning your comment, I do not think the issue describes the flash memory, since all flash memory with JEDEC standard should behave the same. I think the problem lies on the Zephyr SPI-NOR driver side. The SPI-NOR does not use Nordic specific SPI driver, but some general one. And this causes the problem, because the data coming from the flash is not clocked in right, thus resulting in rubbish. This fits to the behavior I observe. Please correct, if I am wrong.

    Regards,
    Joanna

Children
No Data
Related