Dear All,
Currently, my customer is developing the product using i.MX287.
Their board has SPI-SRAM.
It is connected by using SSP as SPI-Master mode.
Though SPI access works correctly, it halts operation rarely.
Their program waits for HW_SSP_CTRL0_RUN bit = 0, in order to check whether transfer was completed or not.
However, it is not rarely set to 0.
Is polling HW_SSP_CTRL0_RUN bit = 0 correct in order to detect the completion of transfer?
Please let me know if you came up with something our mistake.
Best Regards,
George
解決済! 解決策の投稿を見る。
Hi George
polling bit HW_SSP_CTRL0_RUN is correct for checking
whether transfer was completed or not. One can look at SPI-NOR patches
where this is used.
How to enable SPI NOR boot for i.MX28 (Spansion s25fl256s)
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi George
polling bit HW_SSP_CTRL0_RUN is correct for checking
whether transfer was completed or not. One can look at SPI-NOR patches
where this is used.
How to enable SPI NOR boot for i.MX28 (Spansion s25fl256s)
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Dear Igor,
My customer had already referred to above-mentioned patch for the SPI access sequence.
They did continuous write test to connected SPI-SRAM.
It works almost correctly, but the access hangs very rarely.
According to their investigation, in the following, it keeps being HW_SSP_CTRL0_RUN bit = 1.
*HW_SSP_CTRL0_RUN bit is not set to 0.
while( HW_SSP_CTRL0_RD( m_Index ) & BM_SSP_CTRL0_RUN ) {
}
And then they have found not seeing the symptoms by reading a status register as follow.
volatile UINT32 tmp ;
while( HW_SSP_CTRL0_RD( m_Index ) & BM_SSP_CTRL0_RUN ) {
tmp = HW_SSP_STATUS_RD( m_Index ) ;
}
Is this workaround available?
I recommended to take in a timeout mechanism which is in linux-code as follow.
count = 10000;
while ((__raw_readl(ss->regs + HW_SSP_CTRL0) & BM_SSP_CTRL0_RUN)
&& count--)
continue;
if (count <= 0) {
printk(KERN_ERR "%c: timeout on line %s:%d\n",
write ? 'W' : 'C', __func__, __LINE__);
break;
}
What should we do with the recovery sequence when being timeout?
*I can not find it in linux-code.
Best regards,
George
Hi George
seems one can try to reset SSP
Best regards
igor
Dear Igor,
What do you think about the way of poling RUN bit and reading STATUS register?
Thnaks,
George
Hi George
for its usage one can look at SPI-NOR patches in first answer.
Best regards
igor
Dear Igor,
I tell my customer checking it.
Thanks,
George