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
  • Joanna said:
    ll 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). 

    I'm not sure I understand what you're saying here, but if something happens to the last bit there might be a config error on the SPI bus. Although that seems strange as well since you're using a standard device we have a driver for. The MX25R80 should indeed be compatible with the nRF52 and NCS as far as I know. Any chance you could upload the plot from the oscilloscope here so we could have a look? It would be interesting to see for example when you try reading something from the flash, so we can see how it responds exactly.

    UPDATE: I just saw your latest reply as well, and you might indeed be onto something here. Do you still see the same exact behavior after implementing this fix on your end?

    Best regards,

    Simon

  • Never mind about the 1s, I don't think it means anything :-)


    Yes, I have the same behavior if I add the fix from  https://github.com/zephyrproject-rtos/zephyr/pull/51662/files 



    Firstly, because in my case it does not jump into the if clause.

    Secondly, even if I comment the if-clause and force a wait, I get the same behavior. Although, I see while watching the debugger that first it intializes correctly (int_res == 0), then it waits and then suddenly before starting the main it switches to false (int_res == 16).

    So to me, I need to find a different way of resetting/ waiting than described in the Github issue.
    But nevertheless, it could be the same sort of problem in the end!



    I am off on vacation for a week now, but will look into it when I am back.

Reply
  • Never mind about the 1s, I don't think it means anything :-)


    Yes, I have the same behavior if I add the fix from  https://github.com/zephyrproject-rtos/zephyr/pull/51662/files 



    Firstly, because in my case it does not jump into the if clause.

    Secondly, even if I comment the if-clause and force a wait, I get the same behavior. Although, I see while watching the debugger that first it intializes correctly (int_res == 0), then it waits and then suddenly before starting the main it switches to false (int_res == 16).

    So to me, I need to find a different way of resetting/ waiting than described in the Github issue.
    But nevertheless, it could be the same sort of problem in the end!



    I am off on vacation for a week now, but will look into it when I am back.

Children
  • Hi Simon,

    I continued trying without success. I tried out different flash devices (MX25R8035 and AT25SF081B).

    Both did work on a few rare tries!!!

    But mostly the behavior is like this:

    - Initialization does not work: here, I tracked it down and the reason why it fails is because it cannot read the Jedec ID correctly. It reads garbage instead. So this comes down to incorrect communication in the end.

    - Write and then read data brings back random garbage as well.

    - I tried reading the status register, but this also gives back garbage.

    I can force a wait-until-ready as described above by commenting out the if-clause. But this function polls the status register and checks if the WIP (write in progess) bit is set. However, how can I trust this if reading out the status register is not working?

    Conclusion to me is now, that the communication in general is not working correctly. The oscilloscope shows the correct write data but then the flash gives back the garbage. I do not know how to procede since I cannot even work with the status register (which is also needed for the wait function.


    Any further ideas?


    Regards,

    Joanna


    UPDATE:
    The title to the question is misleading. I made a mistake: 16 should be init_res==0x16 to indicate hexadecimal or init_res==22 in decimal. And the error is EINVAL (invalid argument). Sorry about that.



     

  • Hi there,

    I found this issue with the nor spi driver. The Zephyr spi-nor driver does not fit all board's spi drivers. Could this be a problem for Nordic chips as well?

    https://github.com/zephyrproject-rtos/zephyr/issues/45441

    Regards

    Joanna

  • Hi Joanna,

    Simon is out of office and will be able to respond to you in the next week. Thank you for having patience.

    Regards,
    Naeem

Related