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

  • 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

  • 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


  • Hi again Joanna

    Thanks for the updates. No, I haven't heard anything of the Arduino drivers being more stable than what's available in NCS, so I don't think that should be it. Let me know the outcome of having PCBs set up. Hopefully that will resolve these connection problems altogether.

    Best regards,

    Simon

  • Hi Simon,

    everything took a little longer here, but we now have our PCB with the flash on it and communication is working fine! So it must have been that the jumper cables were just not stable enough...

    Now, we can continue with our actual goal of running the OTA update with the external flash to have more memory. Is there some example or how-to for that? I found some things here in the forum and also examples but they all seem outdated and I am not sure what to use.

    Best regards,
    Joanna

  • Hi

    Glad to hear that Joanna!

    This has been the subject of many a DevZone ticket before, and I think this one for example has a great answer from my colleague providing an example on how to do DFU with an external flash. Switching between serial and OTA shouldn't be too hard.

    You can also check out other search results on DFU with an external flash earlier. https://devzone.nordicsemi.com/search?q=DFU%20external%20flash 

    Best regards,

    Simon

Related