CX3: any drawback caused by setSysClk400 = CyTrue ?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
NiMa_2741046
Level 1
Level 1

Hello,

my application really needs 2.4 Gbps capture over the D-PHY/CSI-2/GPIF/DMA chain, so I absolutely need to cope with 100 MHz capture with the GPIF.

I therefore needed to change the master clock from 384 MHz (= 19.2 MHz * 0x14) to 403.2 MHz (= 19.2 MHz x 0x15), by setting to CyTrue the setSysClk400 field of the clkCfg parameter of the CyU3PDeviceInit function call.

I'm sure that this is working, since after rising the clock speed I'm not suffering any more (silent) FIFO overflows.

Unfortunately I'm experiencing strange code instabilities (random failures of application-level tests that come and go according to apparently non-correlated changes in the CX3's FW code) in that configuration, that I manage to completely resolve in two very different ways:

1) switching back to the 384 MHz master clock (and testing using a lower rate data source)

2) keeping the instruction cache always disabled instead of enabling it at boot time

The first option is not compatible with my 2.4 Gbps requirement, so it is not a real solution, while the second option so far appears to be fine in (sustained) practice, even if quite weird from a theoretical point of view.

Considering that the CX3/FX3 Technical reference Manual seems to forbid the 403.2 MHz setting for the master clock (as a value of 0x14 is mandated for the FBDIV field of the GCTL_PLL_CFG register), I'm concerned that there is some undocumented side-effect of that configuration, possibly affecting the instruction cache functionality.

Any comment from Cypress or other users ?

Let me also ask if an intermediate master clock frequency of 400 MHz could also be obtained, by setting GCTL_PLL_CFG.REFDIV to 6 and GCTL_PLL_CFG.FBDIV to 125.

That would still be in contrast with the Technical Reference Manual and would require overriding what currently implemented in the SDK.

Thanks and best regards, Nicola.

0 Likes
1 Solution

Hello Nicola,

- GPIF in CX3 is driven by the PCLK. PCLK is generated as per CX3 receiver configuration settings. So, the PCLK should be such that you get the maximum bandwidth i.e. (PCLK = 100 MHz).

- I am not sure about the dependency on Instruction cache. I would like to have more details about your application to dig deeper.

- 403.2 MHz is not forbidden for CX3 applications.

- Please share the firmware you are working on or the changes you made to the existing firmware.

I am trying to reproduce your problem on my side, will get back on this soon. It would be good if you share the details of your firmware.

Information about DLL (Delay Locked Loop)

The DLL in the PIB block should be enabled when implementing Asynchronous GPIF protocols, or Master mode GPIF protocols. It should be left turned off when implementing synchronous slave mode GPIF protocols.

The DLL is disabled for GPIF II in CX3

Regards,

Rashi

Regards,
Rashi

View solution in original post

0 Likes
8 Replies
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello Nicola,

- Please let me know the error (random failures) you are facing when changing system clock to 400 MHz. The application should run fine even after changing the system clock to 400 MHz.

- The PIB clock will reduce if you reduce the system clock which you don't want for the application. It doesn't seem that we can change the system clock to any intermediate value.

Regards,

Rashi

Regards,
Rashi
0 Likes

Hello Rashi,

the failures that I experience when keeping the instruction cache enabled and rising the system clock to 403.2 MHz are time-outs on the PC side that boil down to missing GPIF/DMA interrupts in presence of an active incoming data flow (hsync and vsync toggling). This happens during stress tests, so not systematically, but never happens when switching the instruction cache off or lowering the system clock to the default 384 MHz value.

We actually managed to compile a few fully reliable builds of the FW with the instruction cache enabled and the 403.2 MHz clock, but we realized that very marginal changes to that code (e.g. longer length of some debug message string) lead again to the above described issue; actually this dependency on very small changes to the code is what triggered our apparently successful attempt of switching off the instruction cache.

Best regards, Nicola.

0 Likes

Hello  Nicola,

Please let me know the details of the application you are working on ((e.g Resolution, fps, output format).

Are you debugging through UART? UART is slow peripheral. Increasing the size of debug prints can make the system slow.

It is recommended not to keep debug print function calls in the call back functions. Please confirm.

I am not able to understand the dependency on instruction cache enable or disable. First we can work with instruction cache enable and reducing the debug prints length.

Regards,

Rashi

Regards,
Rashi
0 Likes

Hello Rashi,

we use debug prints in set-up code only, not in callbacks; the code that is very sensitive to little and theoretically 'transparent' changes versus instruction cache enablement is the set-up one (including D-PHY/CSI-2 and GPIF reset/configuration), not the callbacks' one. Code execution slowness is not the issue anyway, as, experimentally, we have full stability when the instruction cache is disabled rather than enabled.

The application is for a non-imaging sensor, still based on D-PHY/CSI-2; the data stream-out is fully equivalent to RGB888, 2048x512, 100 MHz pixel rate, 30 kHz line rate, 5 Hz frame rate (no embedded data, no LS/LE short packets, continuous clock).

If possible I would like to have a comment about the fact that this 403.2 MHz setting is forbidden by the CX3/FX3 Technical Reference Manual while implemented by the SDK (though not by default): is it an issue of the manual or of the SDK ?

Thank you and best regards, Nicola.

0 Likes
AnYa_2483746
Level 3
Level 3
First like received

This may or may not be what you are having issues with. I had something similar to where i was running at a lower clock and everything was ok, but then i implemented the full clock and had occasional glitches within the FX3 which would cause a timeout on Windows in my application.

After tons of testing i narrowed the problem down to the DLL (Delayed Lock Loop) configuration on the FX3. Once that was configured as specified in this guide (Configuring EZ-USB® FX3™ GPIF-II DLL - KBA210733 ) glitches went away and it works reliably now.

-Andriy

0 Likes

Thank you Andriy for you reply, but the device that I'm working with is the CX3, that is different compared to the FX3 specifically to the implementation of the GPIF interface (afaik form the existing documentation). In any case a problem with the GPIF clocking would not directly explain the dependency on instruction cache enablement/disablement.

Anyway I will try to dig in SDK's code in order to check if and how this DLL block gets configured in my case.

Best regards, Nicola.

0 Likes

Hello Nicola,

- GPIF in CX3 is driven by the PCLK. PCLK is generated as per CX3 receiver configuration settings. So, the PCLK should be such that you get the maximum bandwidth i.e. (PCLK = 100 MHz).

- I am not sure about the dependency on Instruction cache. I would like to have more details about your application to dig deeper.

- 403.2 MHz is not forbidden for CX3 applications.

- Please share the firmware you are working on or the changes you made to the existing firmware.

I am trying to reproduce your problem on my side, will get back on this soon. It would be good if you share the details of your firmware.

Information about DLL (Delay Locked Loop)

The DLL in the PIB block should be enabled when implementing Asynchronous GPIF protocols, or Master mode GPIF protocols. It should be left turned off when implementing synchronous slave mode GPIF protocols.

The DLL is disabled for GPIF II in CX3

Regards,

Rashi

Regards,
Rashi
0 Likes

Hello Rashi,

it was my understanding as well that the GPIF is programmed in slave mode inside the CX3, but could not be fully sure on top of existing documentation. I then will not spend time on those DLL settings.

On the other hand, I need to insist on the fact that the 403.2 MHz setting is forbidden by CX3/FX3's Technical Reference Manuals, as already stated in my original post here. CX3's TRM is just a  "Supplement to the EZ-USB FX3 Technical Reference Manual" and FX3's TRM states

Capture.PNG

The SDK (1.3.4) programs this FBDIV field with the 0x15 value when setSysClk400 is set to true.

I will not publish my full FW here and we implemented many changes compared to the SDK examples (while always sticking to the documented API). I could provide the source code privately to Cypress for an informed code review, but I doubt that the problem can be reproduced on a different HW (we have our own board) without code changes.

Best regards, Nicola.

0 Likes