AM5746: QSPI clock

Hi,

Which SDK and Kernel version is this ?

Regards

Vineet

Hi Vineet,

Thank you for your reply.

My customer commented as follows.

"This is a read on a U-boot, so I don't think it's related to the TI_SDK.
I realize that the QSPI module can work without software,
but why do you need the software version information?"

Could you please reply why you need the software version information, 
and the reason of a QSPI clock stop ?

Best regards,
Kanae.

Hi Vineet and Sitara support members,

My customer commented again that software version information is not needed in this case.

He doesn't think it's a matter of not telling them
because they don't want to disclose the current software version they are using,
but because it's before Linux boots on the U-boot, I don't think it matters.

He thinks this is something that only works with the hardware register settings.
It can also work without software, as described on page 5998 of TRM.

============================================================================

In addition, an interface bridge connects the two ports (configuration port and memory-mapped port)
of the SFI_MM_IF block to the L3_MAIN interconnect. There are no software controls associated
with this interface bridge.

============================================================================

Could you please reply why you need the software version information, 
and the reason of a QSPI clock stop ?

If you need other information to find out the cause of a QSPI clock stop,
Please let me know.

Best regards,
Kanae.

Hi Vineet and Sitara support members,

As Zack Brown comments on 2020-Jun-9 at the following site,
I wonder if this is the cause of the problem my customers are experiencing.

Zack: there might be a delay in updating the busy flag from the memory mapped register.

e2e.ti.com/.../906346

Also, this site is "Solved", am I correct in assuming that this is resolved?
Could you please let me know what you think?

Best regards,
Kanae

Hi Stanley,

Thank you for your reply.

So, as per the post on the above site, am I correct in understanding that
"Switching to using interrupts instead of register polling may help in reducing this unnecessary delay in your code."
in order to eliminate the clock stopping period?

Can I recommend this suggestion to my customers?

Best regards,
Kanae

Sure. Polling the value of register can add additional delay.

Hi Stanley,

Thank you for your support.

My customer has an additional question.
The following E2E site has been marked as "Resolved" due to the significant reduction in gap time.
e2e.ti.com/.../90634

Zack Brown's post on 6/9/2020 shows the possible causes and suggested countermeasure 
as follows, is these countermeasure verified by TI?

>Zack Brown
If CS more closely matches the duration of clock activity,
that tells me there might be a delay in updating the busy flag from the memory mapped register.
Switching to using interrupts instead of register polling may help in reducing this unnecessary
delay in your code.

My customer needs a verified solution, so please let us know the results of your verification.

Best regards,
Kanae

Will check with Zack.

The countermeasure was not verified by TI, but was accepted by the customer as fixing his problem.  I stand by that recommendation when using the QSPI Configuration Port.  But from my reading of the registers given above, this customer is using the SFI interface.  So I don't think the solution in the other E2E thread will work.

Can you confirm that SFI mode is being used when the customer observes this phenomenon?  I'm not sure how much control the user has over timing when SFI mode is being used.  Also, my reading of the registers is different from the description in the original post.  The original post "supposes that CMD 8bit, Address 16bit, and DummyCycle2bytes are before this stopping interval, and data 32bit is after this stopping interval."  However, the registers given would indicate that they are using 8 bits for command, 8 bits for address, and 9 bits for dummy cycles.  Please ask the customer to clarify this.

-Zack

Hi Stanley and Zack,

Thank you for your supports.
We will check the items you pointed out and get back to you.

Best regards,
Kanae

Hi Zack,

I checked the following items from my customer.

===============================================================================
Zack: Can you confirm that SFI mode is being used when the customer observes this phenomenon?

>If SFI mode means that the mode using SFI Translator = access using Memory Mapped Port, then "Yes".

Zack: However, the registers given would indicate that they are using 8 bits for command, 8 bits for address, 
and 9 bits for dummy cycles. Please ask the customer to clarify this.

>As for DummyCycle, the register value was incorrectly written.
Correctly, QSPI_SPI_SETUP1_REG: 0x4b300058 should be "0x00020903".

===============================================================================

If you have unclear part, please point it out. 

Best regards,
Kanae

Kanae,

I understand the QSPI_SPI_SETUP1_REG now.  Thanks for the clarification.  When reading from the QSPI as a memory mapped device, the SFI Translator has control over the state machine.  As such, there's nothing that you can do about the delay between the dummy phase and the data phase.  Please let me know if the customer has any other questions.

-Zack

Hi Zack,

Thanks for your support.

Am I correct in understanding that the delay between dummy and data is the delay that
occurs between #4. and #5. as described below in TRM; 24.5.4.1.2 SFI Translator,
and that there is nothing to do about this delay in SFI mode?

== In 24.5.4.1.2 SFI Translator =======================================

A read sequence is converted into the following actions:
1. SPI chip-select goes active.
2. Read command byte is issued.
3. 1 to 4 address bytes, which correspond to the first address supplied, are issued.
4. 0 to 3 dummy bytes are issued, if “fast read” is supported.
5. Data bytes are read from the external SPI flash memory.
6. SPI chip-select goes inactive.

================================================================

Or am I correct in understanding that the countermeasure you suggest in the following site is effective in this case as well?

"Switching to using interrupts instead of register polling may help in reducing this unnecessary delay in your code."

e2e.ti.com/.../906346

I apologize for my lack of understanding, but I would appreciate your help.

Best regards,
Kanae

Hi Zack,

Thank you for your reply.

I will explain the above to my customer and make sure
that he understands that it is a specification of AM5746.

I appreciate your kind support.

Best regards,
Kanae