The following function get hang in my application.
I can't knows exactly why, because preloader is getting compiled with debug information (Is there a way to Turn it off)?
What I see is:
int cm_basic_init(const cm_config_t *cfg, uint32_t skip_sdram_pll)
Yet, I am not sure what is the exact steps which made it happen...because application is built with -02. (can we change it ?)
We are using bsp-editor, with device ASXFB5 (arria V) with quartus 15.1.
I suspect that it is related to clock input clock1 ? but since debugging behaves a little tricky (I tried to remove some parts, but it behaves in-consistently), therefore I think it would be better if I build with no optimization.
Yet, It always hang cm_basic_init() routine.
I verified the following:
osc1 and osc2 are 50M with scope.
bootinfo register is 0x2b5 (bsel=0x5, csel=0x2).
What can be the reason for preloader hang in cm_basic_init?
In further debugging it seems it get hangs right here:
/* Take all three PLLs out of bypass when safe mode is cleared. */ DEBUG_MEMORY cm_write_bypass( CLKMGR_BYPASS_PERPLLSRC_SET( CLKMGR_BYPASS_PERPLLSRC_ENUM_SELECT_EOSC1) | CLKMGR_BYPASS_SDRPLLSRC_SET( CLKMGR_BYPASS_SDRPLLSRC_ENUM_SELECT_EOSC1) | CLKMGR_BYPASS_PERPLL_SET(CLKMGR_BYPASS_ENUM_DISABLE) | CLKMGR_BYPASS_SDRPLL_SET(CLKMGR_BYPASS_ENUM_DISABLE) | CLKMGR_BYPASS_MAINPLL_SET(CLKMGR_BYPASS_ENUM_DISABLE));
for some reason, I can't put a breakpoint in this line but if I remove the above line from code, then I get into next line and continue debugging.
Any idea what it means ?
These are the next steps I've tried:
/* clear safe mode */ DEBUG_MEMORY cm_write_ctrl( readl(SOCFPGA_CLKMGR_ADDRESS + CLKMGR_CTRL_ADDRESS) | CLKMGR_CTRL_SAFEMODE_SET(CLKMGR_CTRL_SAFEMODE_MASK));
Why should it hang here ?
2. I than tried to skip "cm_basic_init" routine.
Now I manage to continue till the end of preloader before jumping to u-boot.
What does it mean ? Why cm_basic_init fails to configure pll ?
3. I've also noticed the following patch:
Should this patch be applied with quartus 15.1 ?
Note: I try to debug preloader using debugger. Is this the reason for the pll calibration issue ?
I suspect that it is issues of osc1 reference clock.
In our case it is 50Mhz, and csel is 0.
Maybe the actual accuracy of our clock is not sufficient ? I haven't find the precision requirement for osc1 in reference.
I also see that it terrasic DE-10 they use 25Mhz as input with csel=0, maybe 50Mhz is too much near the limitation of csel=0 (10 to 50Mhz) ?
The pll input clock should be 25MHz based on our reference design. Anything below or above might not function properly since there was no test achieved to verify. Is it possible to change the PLL input clock on your board (to make it 25MHz)?
The issue seems to be solved.
The real problem was that in platform designer HPS clock was set as 25M, while the real clock was 50M.
On changing qsys hps clock to 50M , the issue been solved.