if u-boot configures QSPI for AHB reads, the M4 must clear the
QUADSPI_BFGENCR register during its init to bring it back to a well
known state.
Solved! Go to Solution.
As mcu-sdk moved to github we moved request as PR there. It was already merged:
https://github.com/NXPmicro/mcux-sdk/pull/4
Hi quentincabrol,
Can you help us with my previous comment?
Regards,
Karan Gajjar
Hi quentincabrol,
Did you get a chance to look at the last comment?
Regards,
Karan Gajjar
Which source code are you talking about? Could you tell me the location of the source code.
What is the version of it?
Thanks.
Hi @jimmychan , as mentioned in header the issue is in fsl_qspi.c. We observed this issue in sdk2.6, sdk2.7 and sdk2.8(newest one). Currently we need add this one line manually.
Solution is showed inside code snippet inside !!!!!!!!!!!!!!!!! ... !!!!!!!!!!!!!!!!
it is qspi driver used in our case in imx7ulp
Our expert have a few queries regarding the patch you have mentioned.
===========================
The customer has explicitly written 0 to BFGENCR (Buffer generic configuration register) in the QSPI reset function.
Has the customer faced any issue while resetting his application or the EVK? If yes, can he provide the steps for the same?
Has the customer tried with the sample QSPI driver provided by the NXP?
Can the customer confirm whether the below note is applicable to his scenario?
This note in imx7ULPRM connects to the patch in which the customer has reset the value of SEQID by writing 0.
============================
My colleague is saying that the case was when uboot run before m4. M4 inits QSPI (m4 assume it comes from reset), that value wasnt set to its default;
Below are our additional observations:
/*
* There are two different ways to read out the data from the flash:
* the "IP Command Read" and the "AHB Command Read".
*
* The IC guy suggests we use the "AHB Command Read" which is faster
* then the "IP Command Read". (What's more is that there is a bug in
* the "IP Command Read" in the Vybrid.)
*
* After we set up the registers for the "AHB Command Read", we can use
* the memcpy to read the data directly. A "missed" access to the buffer
* causes the controller to clear the buffer, and use the sequence pointed
* by the QUADSPI_BFGENCR[SEQID] to initiate a read from the flash.
*/
=> md.w 0x410a5110 2
410a5110: 0007 0000
while (1)
{
PRINTF("RBCT Reg: 0x%x\n",QSPI_ReadRBCT_Reg(EXAMPLE_QSPI));
qspi_polling();
int tmp = 200000000;
while(tmp--);
}
inline int32_t QSPI_ReadRBCT_Reg(QuadSPI_Type *base){
return base->RBCT;
}
QSPI example started!
Erase finished!
Program data finished!
Program through QSPI polling succeed!
RBCT Reg: 0x7
Erase finished!
Program data finished!
Program through QSPI polling succeed!
RBCT Reg: 0x7
Erase finished!
Program data finished!
Program through QSPI polling succeed!
RBCT Reg: 0x7
Erase finished!
Program data finished!
Program through QSPI polling succeed!
RBCT Reg: 0x7
Erase finished!
Program data finished!
Program through QSPI polling succeed!
So, if you have any specific scenario or application, do let us know the steps or provide us with the application to test on.