QuadSPI XIP boot mode and switching SYS_CLK_SEL

[kef2]

Hi,

Are there sys clk vs QSPI clock restrictions? Perhaps sys clk or bus clock has to be higher than QSPI clock? I'm asking because my code hangs when booting in XIP mode at 60MHz QSPI clock. It worked OK at 18MHz. After some debugging I found that the problem is not too slow QSPI memory. At boot time I need to reconfigure core and other clocks. To reconfigure core clock I need to switch SYS_CLK_SEL from PLL_PFD clock (default setting out of boot ROM) to fast clock (crystal oscillator clock). And this is exactly where A5 core runs away. And this is why I wonder about QSPI vs SYS clk clock restrictions or how to properly switch from PLL_PFD clock source to fast clock source.

I found that setting QSPIn_ACCZ=1 in CCM_CGPR, which makes QSPI synchronous to SYS_CLK, helps. With QSPIn_ACCZ=1 I can switch SYS_CLK_SEL with no problem. Any comments on this? Is this the right approach?

Thanks

[naoumgitnik]

Hello Edward,

Before we proceed further, you only provided the QuadSPI bus frequency (60MHz), but is it a DDR or SDR mode, please? - If DDR, I am afraid you are exceeding the limit.

Sincerely, Naoum Gitnik.

[kef2]

Hello Naoum,

No, I'm not exceeding limits, QSPI operates in SDR mode.

I managed to get it working. QSPIn_ACCZ=1 allows reconfiguring core and IPG bus clock. To restore QSPIn_ACCZ=0  (and higher QSPI clock), it seems being necessary to jump RAM and do it there along with QSPI reinitialization.

Regards

Edward

[naoumgitnik]

Hello Edward,

Please, take a look at "e6235" in the Vybrid Errata (http://cache.freescale.com/files/32bit/doc/errata/VYBRID_1N02G.pdf) if this is not similar to what we are discussing.

I found in some private materials how to properly apply e6235 (on the example of switching ANADIG_PLLx_CTRL[DIV_SELECT] from 0 to 1):

• select 24MHz external crystal as clock source instead of PLL (CCM CCSR, SYS_CLK_SEL = 0),
• select PLL1 main clock PLL1_PFD_CLK_SEL =0,
• change PLL1 setting in Anadig (DIV_SEL = 0; MFD = 100; MFN = 83),
• wait for lock PLL1,
• select PLL1 as clock source SYS_CLK_SEL = 4.

Regards, Naoum Gitnik.

(jiri-b36968)

[kef2]

Hello Naoum

e6235, or unstable PLL clock issue doesn't apply. PLL clock is stable before and after changing PLL settings, verified with scope on CKO pin. I've seen unstable PLL clock with other settings than provided with e6235, but no problems with PLL, it is stable out of reset after boot ROM, it is stable after my PLL init routine. Vybrid hangs at first step from your solution for e6235, when executing from QSPI. No problems doing the same when executing from RAM. Vybrid RM gives no clue why there could be a problem switching core and bus clock (SYS_CLK_SEL=0) and leaving QSPI clocks not changed! And this is what I'd like to know to mark thread solved. Is it not allowed to switch core/bus clock while executing from QSPI? I would accept it if answer is yes. Is there a proper way to set SYS_CLK_SEL=0 while executing from QSPI? I'd love to see it documented.

So no, issue is not solved. What I have is DIY workaround for the issue, but I don't know why it is not safe to SYS_CLK_SEL=0 while executing from QSPI. It seems being safe to CCM_CGPR QSPIn_ACCZ=1, and then SYS_CLK_SEL=0. Switching SYS_CLK_SEL back to PLL while executing from QSPI is again not safe, unless QSPIin_ACCZ=1. This makes it hard to restore high QSPI clock after reconfiguring core/bus clock! To solve it seems being necessary to need to jump away from QSPI (for example to RAM) and complete clock init there. This kind of breaks luxury of QSPI XIP boot mode, I still need code in RAM to complete initialization.

Regarding issue conditions. I didn't test all possible settings when it happens, perhaps it appear not only at 60MHz QSPI clock, but also at 18MHz. I don't know how I/D-cache enable./disable could affect it, I've caches enabled even for QSPI area. That is what I have. And I want to receive commend on why could SYS_CLK_SEL=0 break reading QSPI. That's the most important question.

If you wonder why do I think problem is in SYS_CLK_SEL=0, and back to SYS_CLK_SEL=N - I ruled out all other lines in my code, I'm sure it is SYS_CLK_SEL=0. It is also not defective QSPI memory or its PCB traces. It is tower board. With my workaround applied I see no issues operating QSPI in SDR mode up to 100MHz, also with all possible initial boot speed settings.

Regards

Edward

[naoumgitnik]

Hello Edward,

Our Vybrid IC Design team is working on your issue; as of now, they are not ready yet to approve programming ACCZ to 1, but would like to get additional information to finalize the issue.

Some part of it might be provided in our correspondence here and there, but may you do us a favor and provide the below data in a single "block", please?

1. Source of QuadSPI clock before change?
2. Source of QuadSPI AHB clock before change?

We really appreciate your help in finding potential issues in the product.

Sincerely, Naoum Gitnik.

[kef2]

Hello Naoum,

Thank you for working on issue, but please don't forget that it is not urgent for me and I'm going further.

A1. QuadSPI clock source is defined by Vybrid boot ROM. According to Table 19-10 Vybrid RM rev5, it should be either PLL3_MAIN or PLL3_PFD4. I said you it was 60MHz, but it seems depending on what SW is doing. See below

A2. I'm not sure what QuadSPI AHB clock is. Vybrid RM is fuzzy about it. Is it IPG clock? Anyway it is still defined by Vybrid boot ROM.

I managed to reproduce the issue in smaller DS-5 project. SW needs to be installed in QSPI memory on Vybrid Tower card. It is supposed to show QSPI0 clock /10 on TP12 and run LED lights to one direction first. When user presses SW2 button, SYS_CLK_SEL=0 is executed and LED light shouid start running in opposite direction at slower speed. There should be no change in QSPI clock monitored on TP12. But in fact lights freeze and I see something on TP12. See attached.

Regards

Edward

[naoumgitnik]

Hello Edward,

Our IC Design team is still working on your issue, and below is their preliminary reply:

• I have not been able to find the root cause for this by code review and need some more time  to get this test-case replicated in verification environment.
• Would it be possible for you to check pll3.main_clk, quadspi_4x_clk, quadspi_2x_clk as well on CKO1/2?
• Also see if “Platform Bus clock” switches to 24MHz once you switch to fast clock.

Do you think you will be able to provide these data, please?

Sincerely, Naoum Gitnik.

[kef2]

Hello Naoum

PLL3, QSPI 4X and 2X clock are high frequency clocks and I need >=2 divider to both make CKO pin able to output original clock and be able to see it clearly on o-scope. If the problem is a glitch in one of these clocks on SYS_CLK_SEL->0, I doubt I would be able to see that glitch behind >=2 CKO divider. It is not trivial and time consuming to chase without a 99% promising hint from Vybrid HW designer. Sorry, I don't have time for it, unles you have a good idea of what could be wrong.

Executing from RAM there's no problem switching SYS_CLK_SEL, CKO output confirms with 24MHz fast clock source.

Regards

Edward

[naoumgitnik]

Hello Edward,

Below is reply from our IC Design team:

-----------------------------------------------------------------

1.

I have run a simulation and not seen any issue when switching the system clock from PLL to Fast Clock.

I have just followed the basic programming as mentioned in the Reference Manual, so I am not sure as to why the user is facing issues.

Here are few things I think can ask the user to tell me:

1.      1. What is the value in CCM_CCSR reg. he is writing when he  switches the  system clock to FIRC?

2.      2. Is he still programming the ACCZ bit, and to what value [set or clear]?

3.      3. What is the value of CCM_CCM_CSCDR3 reg. before the switch of system clock source?

4.      4. What is the value of CCM_CSCMR1 reg. before the switch of system clock source?

5.      5. Is the clock configuration difference between working and non working program only about the setting of bits[2:0] of reg. CCM_CCSR ? if NO, what are the other difference w.r.t. clock configuration?

2.

A small debug program which he can try (with a working program - I see that a case working out of RAM is working fine):

1.      Configure CCM_CCOSR reg. to view either PLL3 main clock, or PLL3 PFD4 clock, or PLL2 PFD4 clock, or PLL1 PFD4 clock on the CKO2 pad (the user may want to get a divided clock on these pads instead of direct full frequency clock).

2.      Depending on which clock is made observable on CKO2 pad, configure the bits [23:22] of reg. CSCMR1 to:

a.      2'b00 if PLL3 main clock is made observable on CKO2 pad

b.     2'b01 if PLL3 PFD4 clock is made observable on CKO2 pad

c.      2'b10 if PLL2 PFD4 clock is made observable on CKO2 pad

d.     2'b11 if PLL1 PDF4 clock is made observable on CKO2 pad

3.      ACCZ bit is cleared.

4.      CCM_CSCDR3 bit no 4 is set.

5.      Configure the CKO1 pad to make QSPI0 Serial x2 Clock visible.

6.      Wait for some time. A time loop, may be.

7.      Clear bits [2:0] of CCM_CCSR reg. to 0s.

8.      See if the clock is still visible of PAD CKO1.

-----------------------------------------------------------------

I am sorry it is taking more time and effort on both sides to verify this issue than probably expected, but this is quite common while analyzing issues of such nature.

Sincerely, Naoum Gitnik.

[kef2]

Hello Naoum,

1.

I have run a simulation and not seen any issue when switching the system clock from PLL to Fast Clock.

I have just followed the basic programming as mentioned in the Reference Manual, so I am not sure as to why the user is facing issues.

Here are few things I think can ask the user to tell me:

1.      1. What is the value in CCM_CCSR reg. he is writing when he  switches the  system clock to FIRC?

3.      3. What is the value of CCM_CCM_CSCDR3 reg. before the switch of system clock source?

4.      4. What is the value of CCM_CSCMR1 reg. before the switch of system clock source?

I don't know. Please see code provided previously in QSPI_XIP_SYS_CLK_SEL_ISSUE.ZIP and perhaps Vybrid BootROM source code.

2.      2. Is he still programming the ACCZ bit, and to what value [set or clear]?

5.      5. Is the clock configuration difference between working and non working program only about the setting of bits[2:0] of reg. CCM_CCSR ? if NO, what are the other difference w.r.t. clock configuration?

I'm using ACCZ in my workaround. But please don't spread our attention in additional directions. The most important question is why QSPI_XIP_SYS_CLK_SEL_ISSUE code hangs when I press button and SYS_CLK_SEL is set =0.

2. A small debug program which he can try (with a working program - I see that a case working out of RAM is working fine):

Hm, i don't see such program attached. Naoum, I don't mind if you stop investigating the issue. I still don't see any promising information, am busy and thus can't spend more time on it. Thanks

Regards

Edward

[naoumgitnik · Accepted solution]

Hello Edward,

§  No problem, we can stop here if you are feeling comfortable enough to do so.

Regards, Naoum Gitnik.

[kef2]

Yes, we can stop here if you wish. It seems being better to not bother reporting an issue next time, unless it is a fatal showstopper and no idea for workaround. At least I think so. Full code was provided, which needs to be installed to QSPI memory and booted to show the issue. What I get is “we tried it in simulator and it was OK, please keep coding”. Thanks, but I’ll better stop here.

Regards

Edward

[naoumgitnik]

Hello Edward,

• Thanks for your answers! I will forward them to the IC design team.
• The small debug program is not attached but described step-by-step in part #2 of my last message ("A small debug ... PAD CKO1.").

Regards, Naoum Gitnik.

[naoumgitnik]

Thanks for detailed explanation, Edward!

I with talk to our IC Design team about it.

Regards, Naoum Gitnik.

[naoumgitnik]

Hello Edward,

Thanks for your clarification.

Does "I managed to get it working"  mean the issue can be considered resolved and closed? Or is there still something to be done on our side?

Regards, Naoum Gitnik.