SPI-NOR flash devicetree error int_res==16 EBUSY

[Joanna]

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

[Simonr]

Hi

Okay, a few suggestions. First off, can you show me the snippet of code you're using to write data onto the SPI device, and what data are you trying to write onto the external flash. Also, if you've just plainly copied the dts, please also make sure that the JEDEC ID that is set matches the JEDEC ID of the MX25R8035F datasheet, as this is specific to each NOR Flash device.

Also, if you probe the TX lines with your oscilloscope you should be able to see if the data that the device writes out on th SPI TX pin is correct and not just jibberish.

Best regards,

Simon

[Joanna]

Hi Simon,

this is the code:

#define SPI_FLASH_TEST_REGION_OFFSET   0x020000

const uint8_t expected[] = { 0x12, 0x34, 0x66, 0x99 };

const size_t len = 4;

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

main

{

...

    flash_write(flash_dev, SPI_FLASH_TEST_REGION_OFFSET, expected, len);

...

}


1) Yes, I set the JEDEC ID from the Datasheet. C2 28 14 althoug it says in the jedec,jesd216.yaml that it is not required.
2) Yes, the write data on the oscilloscope is correct.
3) Another observation: I tried writing different data. All data that has only 1s at the end in binary form (like 0x01, 0x03, 0x07, 0x0F) is read back correctly, as in the erase case (0xFF). 

4) Is it possible that MX25R80 is not compatible? How can I tell which parts are?


Regards
Joanna

[Joanna]

Hello,

I did some deeper research on flash memory in general and found this issue: https://github.com/zephyrproject-rtos/zephyr/issues/51713 

and this fix to it: https://github.com/zephyrproject-rtos/zephyr/pull/51662/files 

The problem is that the program tries to read the JEDEC ID from the flash during initialization of the device (before the actual program starts). If the flash is still performing some task, like read/write/erase, then it does not answer correctly. This can especially happen during debugging since a controller soft reset does NOT imply a reset on the flash device.

This all makes a lot of sense to me. However, the solution presented (including a wait during initialization) does not solve the issue for me. Still, I will try logging and finding out more because this does seem like it could be the right track...

Regards 

Joanna