Issues with QSPI module on custom PCB

[Aviv Okon]

Hi

I'm working on a custom PCB based on nRF52840 soc and SDK version 16.0

currently I'm trying to interface my MCU with an external flash of model MT25QL01GBBB

my system is working with FreeRTOS, so I implemented a system similar to that of the QSPI example, but with a semaphore instead of the while loop on the flag to signify the end of the transaction. from what I can see, while I am able to read the device ID correctly, I am unable to do any write operations in my code (it seems like the code is stuck waiting for the semaphore which is released by the qspi event handler, but the event never seems to happen)

I made sure that I am configuring the pins as per the PCB (though I have a reset pin that I can't find how to configure), but I can't see any transactions when recording the data on those pins with a logic analyzer

After seeing as I can't get this to work, I tried running the QSPI example on my PCB

that did seem to work, in the sense that I do see data transactions, though I have encountered several issues

first of all, the example doesn't seem to have the QSPI pins configured, yet I do see data on the PCB pins when recording with the logic analyzer

second, I am getting mismatched data, where the received data always begins with two bytes of 136 before the actual data, which is a data shift I am unable to explain

I would really appreciate some help at least figuring out the issue with the example, though if someone has any suggestions on what to do with my actual project, what tests I can perform etc, that would be truly helpful

If I could provide any extra data that would help, please let me know and I'll do my best to provide it

thanks in advance

[haakonsh]

After seeing as I can't get this to work, I tried running the QSPI example on my PCB

that did seem to work, in the sense that I do see data transactions, though I have encountered several issues

first of all, the example doesn't seem to have the QSPI pins configured, yet I do see data on the PCB pins when recording with the logic analyzer

I guess the example uses the default pin configuration, most likely set in sdk_config.h
I suggest we stick to the bare QSPI example until we've solved all our problems there, before adding it to your FreeRTOS project.
 

second, I am getting mismatched data, where the received data always begins with two bytes of 136 before the actual data, which is a data shift I am unable to explain

I would really appreciate some help at least figuring out the issue with the example, though if someone has any suggestions on what to do with my actual project, what tests I can perform etc, that would be truly helpful

If I could provide any extra data that would help, please let me know and I'll do my best to provide it

Can you share the received mismatched data as well as a logic trace of the same transfer?
Can you also share the sdk_config.h as well as your main.c?

[Aviv Okon]

Hi haakonsh

I've attached the main.c and sdk_config.h of the example as I'm using it, as well as an image of the output on the terminal and a recording of the transfer via my Saleae logic analyzer (I hope you can open that format, if not please let me know what to send to you)

I did however notice something a bit strange when testing this. my external flash has a reset pin that is currently not being used by the program, as no pins are configured. however, when I tried recording that pin as well on the logic, I lost all data. not sure if the logic changes the state of the pin when trying to read it, but I can't really explain this behavior.

also I checked the schematics of my PCB again, and it seems that all QSPI pins are attached to the dedicated QSPI pins of the SOC, which is probably why configuring these isn't required

I hope this provides you with enough usable information, though please let me know if there is anything else I can provide

thanks a lot

Aviv

QSPI Test.7z

[Aviv Okon]

I'll have access to a scope next week, so I'll test and upload the results

I'll also do this on my own project's code, to see if my code has a similar issue

I'll send the results your way, maybe we could figure out the source of the issues

[Aviv Okon]

Hi haakonsh

I've recorded the clock signal alone with the logic and with an oscilloscope, and I'm providing the results

I hope you can open the csv data recordings of the scope, so that you'll have more data to look at

what I've noticed is that on the logic the clock looks better when recorded alone at 100MB\S, though it still doesn't seem to have a consistent frequency

on the scope it does look consistent as far as I can tell, though I do see spikes on the signal that has me worried, so I will appreciate any input you can provide on the matter

note that these measurements were done with the same code I've provided previously, and the data output on screen is consistent with the output I've provided previously

thanks for all the help

Aviv

QSPI Test 2.7z

[haakonsh]

So it seems the results from the logic analyzer with regards to the clock signal are just aliasing, but the oscilloscope has got me a bit worried. There appears to be a noise signal that is half the peak-to-peak value of the signal, that's not good. It does not appear to be inductive ringing as that would have larger amplitudes near the flanks.

The frequency of the noise is 1Hz/(8/500ns) = 1Hz/ 62,5ns = 16MHz. 

This would lead me to believe that the 16MHz peripheral clock is mixed with the SPIM's CLK output. 

I think the next step would be for an HW review of your schematics and layout. Do you mind opening a new private ticket where your reference this one and ask for a HW review? I'd like to keep the current ticket public so that others can see how to troubleshoot similar issues. 

-Håkon

[Aviv Okon]

Hi Hakon

I'm currently bringing this issue up with our HW team, to see what could be done

I'll direct them to this ticket, so that they could follow our conversation, and see how they wish to proceed

thank you very much for your help thus far, and for any future help we may need in this matter

[haakonsh]

Some of my colleagues recommends that you play around with the RXDELAY in the IFTIMING register. Try incrementing it and see what happens.