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

[haakonsh]

Hey Aviv, 
Sorry for the late reply, we've had a national holiday on Monday and had a big backlog on Tuesday. 

I've taken a look at the corrupted data and logic trace, it seems like the clock signal is malformed as the period of the clocks alternate between 25ns and 50ns. It's a bit hard to see exactly how bad the signals are on a digital trace, can you hook up an oscilloscope to the clock signal and one of the data lines? I suspect that the SPI lines are capacitively loaded, so it would be best if you used active probes with the oscilloscope.  

I am getting mismatched data, where the received data always begins with two bytes of 136 before the actual data,

From the readout of the terminal it seems there's a lot more than 2 bytes that are corrupt, was this transfer done while the logic probe was attached? I ask because that would suggest that the traces are capacitively loaded as adding the 10pF Saleae probes increased the scope of the issue.  If so I suggest you compare the data when the logic probe is attached to when it is not for a few transfers, and see if the addition of the logic probe definitely affects the issue or not. If it does then we're most likely looking at an HW issue and we can proceed to a schematic and layout review (in private).

[Aviv Okon]

Hi Haakonsh

I've done tests of the input data with and without the logic probes, and received the exact same data. the only thing which showed more corrupt data was when I added a probe on the reset pin of the external flash, which caused the data to show quite a few bytes of '136', and the rest being zeroes

surprisingly enough, since I posted this I have continued working on my own project, and managed to use the external flash with the QSPI driver without any issues (the issues I experienced were from some misunderstanding of how to use the QSPI API with FreeRTOS, and errors I've had with using some modules within my project, unrelated to any official nRF drivers \ modules)

I don't quite understand the issue with the example code, but so far my own project seems to function fine with the external flash. I am worried that I do have similar issues that I'm just not seeing due to not performing more extensive tests of the module, but it might be just fine so that we may not need to continue investigating the example

As such, I think that for now there is no need for further investigation on the matter, as much as the example code issue irks me. if you do have suggestions of tests I could perform to try and determine the source of the problem (and see if I have the same issue in my own project), I'll be glad to perform them as I am able and report my finding

thank you for the help so far

Aviv

[haakonsh]

I don't know. That clock signal looked quite bad, I'd still scope it with an oscilloscope just to be sure.