RT1064 - Flex Qspi - AHB Communication Failure to do consecutive FPGA data acquisitions 2

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

RT1064 - Flex Qspi - AHB Communication Failure to do consecutive FPGA data acquisitions 2

209 Views
scottydoesntknow
Contributor I

Sorry if this shows up twice, was not sure if forums are linked.

Hi Everyone,

Looking for guidance on the Flex-Qspi operations.

I currently have a project that communicates with a FPGA, and I have been successful using the AHB to get and set registers on that FPGA. The issues occur when I am in a for-loop requesting data consecutively. I can see on the scope, the Flexspi control line is not always being toggled and the read returns with the same data that it had on the last read cycle (on failure). It seems like some times it gets 3 reads in a row successfully and then it would skip 1 and only issue a read on the following attempt.

I have been able to add "NOP" wait states to my for-loop to delay the next data request and it seems to remedy the situation. I just dont have an answer to why that is the case.

Here is a brief overview of my configuration for the data transfer:

Using DDR, Caching is Disabled, Prefetch is Disabled, Clearing is turned On after read.

scottydoesntknow_3-1725907718211.png

scottydoesntknow_4-1725907740253.png

 

Here is a look at what my transmission looked like:

scottydoesntknow_2-1725907697983.png

 

Transmissions without NOP wait states:

scottydoesntknow_1-1725907665621.png

 

 

 

Transmissions with NOP wait states added:

scottydoesntknow_0-1725907638006.png

 

 


Can anyone offer any idea as to why the AHB is not triggering the data transmissions?

Thanks.

Labels (1)
0 Kudos
Reply
3 Replies

185 Views
scottydoesntknow
Contributor I

Okay I believe I have a understanding of what is occurring.

My FPGA State machine is setup and based on 11 SClk cycles.
My Lut Table is also configured for this.

scottydoesntknow_0-1725975326285.png

If i use the "FLEXSPI_TransferBlocking()" function to perform the read, it issues 11 SClk cycles, and I get the correct data.

scottydoesntknow_1-1725975358879.png

If i use the AHB method, I only get 10 SClk cycles.

scottydoesntknow_2-1725975450736.png


A colleague pointed out in the Reference manual. The READ_DDR instruction in the Lut table is ignored for AHB mode.

scottydoesntknow_3-1725975607985.png

I guess a follow-up question to my original question is, how are data bytes supposed to be retrieved from an external device when using AHB? There is not enough SClk cycles to do any more than a byte at a time. which, we currently are using a 2 Byte Data transfer. Which explains my failure. 

Thanks for your time.


0 Kudos
Reply

137 Views
diego_charles
NXP TechSupport
NXP TechSupport

Hi @scottydoesntknow 

Thank you for sharing this information. 

What is the size of your AHB read buffer? With the NOP are you consistenly reading all the requested data?

Diego

0 Kudos
Reply

88 Views
scottydoesntknow
Contributor I

Hi @diego_charles 

There were two different things I was dealing with...

  1. Missing SClks
    I had expected to always get 11 SClks and I could not figure out why.

    My AHB buffer sizes are the default settings in the fsl_flexspi.c driver:

    Buffer0 = 0.
    Buffer1 = 0.
    Buffer2 = 256.
    Buffer3 = 256.
    scottydoesntknow_0-1727273208787.png

    I eventually discovered that I could get different sclk counts by reading/writing different byte counts.

    So if I read:
    unsigned char = 10 SClks.
    Unsigned short int = 11 SClks.
    unsigned int = 12 SClks.

    scottydoesntknow_1-1727273557000.png
    I am not sure what underlying mechanism is controlling the AHB Data Byte Count to SClk Generation Relationship. I suppose now that I know of this, this issues is less critical. But would have been helpful to read in the reference manual.
  2. AHB Data Caching

    I discovered that if I poll for the same address multiple times in a row, the data was not always the most up to date value. I setup a simple test in my FPGA to prove this. Every time the address is read, I increment a counter that I read out when the address is targeted.

    So, if I read an address 10 times in a loop:
    I expected 1, 2, 3, 4, 5, 6, 7, 8, 9, 10.

    I actually got 1, 2, 2, 3, 3, 4, 4, 5, 5, 6.

    On the Scope:
    I observed that instead of 10 FlexSPI Data transmissions, I only seen ~6. So the AHB/Flex SPI is not issuing the request.

    Things that worked:
    A) If I added "NOP" wait states to my for-loop, I was able to get all 10 FlexSPI Data Transmissions. This is not practical, because I would need to remember to do this in all areas where I poll for data as well as other members who would make additions to this code.

    Example:
    unsigned short int bData[10];
    for(int i=0; i < 10; i++)
    {
         bData[i] = (*((unsigned short int *) 0x60000000));
         _asm_("nop");
         _asm_("nop");
         _asm_("nop");
         _asm_("nop");
         _asm_("nop");
         _asm_("nop");
         _asm_("nop");
         _asm_("nop");
         _asm_("nop");
         _asm_("nop");
         _asm_("nop");
         _asm_("nop");
    }

    B) If I changed the address, I was able to get all 10 Flex SPI Data Transmissions.
    On the FPGA I setup for my counter to increment every time 1 of 2 addresses were read.

    Example:

    unsigned short int bData[10];
    for(int i=0; i < 10; )
    {
         bData[i++] = (*((unsigned short int *) 0x60000000));
         bData[i++] = (*((unsigned short int *) 0x60000002));
    }

    For the configuration, I did make sure prefetch and caching were both disabled. so im not sure what is causing this behavior.


    Thanks for your time.
     



 






0 Kudos
Reply