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 again

Thank you for the update. And when it's back to "not working" you're seeing the same shifted bits again, or are you running into some other error. The pull-downs sound like a good idea. But since there are so many wires to handle here, my guess is that one or more of the wires or resistors aren't connected properly or perhaps the oscilloscope pins are causing the issue. Have you tried removing them again to see if the nRF52 and the external flash start playing nicely again?

Best regards,
Simon

[Joanna]

Hi Simon,

yes, "not working" means shifted bits (not always shifted by 1, but some kind of rubbish comes out, I have not checked if it is then shifted by e.g. 2).

Concerning the bad connections: I also think this is an issue since it does make it better with the pulldowns and without the oscilloscope pins. However, like I said, it still only works about 50% of the time. 
BUT with the Arduino the same setup is not a problem at all, I never saw it fail. So for me, this leads to the question: Is the Arduino driver for some reason more stable and if so, why?

We are designing a PCB at the moment, so hopefully the connection issues will be gone after that. Will let you know the outcome, but this is not until a few weeks. Still, it seems weird that the Arduino is fine...


In the end, I want to use the external flash for the OTA update. I found a few posts on the topic but have troubles how to adapt the nrf52840 example to the nrf52833. I will post my my question on another thread.

Regards
Joanna