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

    Okay, so we found something we should have spotted earlier, and it seems like the two last bits of the JEDEC ID on the nRF side of things are shifted to the left from slave to master. It seems like the 0xC is not shifted though, and that the nRF is just able to sample that pin before it goes low, but it's strange that the slave loses a bit and clocks out the JEDEC code one byte too early.

    Can you send us a picture of how the nRF and flash device are set up and connected? Bit shifts like this are common in bad connections between master and slave or much capacitance on the lines for example, and since the rise time on the nRF52 trace is much slower than on the Arduino setup, one guess is that the wires between them is too long. But then again you shouldn't see the issue when running on lower frequencies if that's the issue.

    Best regards,

    Simon

Reply
  • Hi

    Okay, so we found something we should have spotted earlier, and it seems like the two last bits of the JEDEC ID on the nRF side of things are shifted to the left from slave to master. It seems like the 0xC is not shifted though, and that the nRF is just able to sample that pin before it goes low, but it's strange that the slave loses a bit and clocks out the JEDEC code one byte too early.

    Can you send us a picture of how the nRF and flash device are set up and connected? Bit shifts like this are common in bad connections between master and slave or much capacitance on the lines for example, and since the rise time on the nRF52 trace is much slower than on the Arduino setup, one guess is that the wires between them is too long. But then again you shouldn't see the issue when running on lower frequencies if that's the issue.

    Best regards,

    Simon

Children
  • Hi Simon,

    I was also sick for a few days and am only back today...

    1) The 0xFF is not part of any command, I think. It is just what is on the MOSI line while the master is reading the slave answer. For the arduino it is 0x00 and for the nRF 0xFF, I don't think this should matter.

    2) Yes, you're right, the data is shifted. But, it is not always wrong in the same way. The false data is sometimes this and sometimes other things. Nevertheless, of course, it means that data is clocked out incorrectly. Expecially, if the edges are wrong, then it may read sometimes this and sometimes that.

    3) Here is a picture. I attach everything via jumper wires.


    4) I got a hint from one of your FAEs here in Germany and he proposed to add pull-down resistors to MOSI and MISO as well as a pull-up to CS (all 10kOhm). This strangely made it work "for a while", meaning I was able to read the correct data about 20 times. Then I starting "playing around" again with oscilloscope, rearranging some wires and now it stopped working again. There is nothing particular that I have different now. Also I waited 2h for possible capacities to unload, still not working anymore... I wonder what did the trick for that short moment.


    Best regards,
    Joanna 


Related