• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 2320 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMDSRM48HDK: Trouble accessing SDRAM on RM48 HDK

yi cui
Prodigy 140 points
Part Number: TMDSRM48HDK
Other Parts Discussed in Thread: HALCOGEN

I try to access SDRAM on RM48HDK. I cannot find any example from HalCoGen. The HalCoGen version I am using is 04.06.00. I search the forums and I find one example build on HalCoGen version 3.02. But the HalCoGen change a lot between version 4 to version 3. I can not make it work on 04.06.00. Can anyone post an update EMIF example project to read and write to SDRAM using  HalCoGen 04.06.00 or 04.07.00?

Thanks,

  • 0
    TI__Guru 59540 points
    Hello Yi,

    Have you had a look at these posts? Each provides fairly decent step by step instructions on how to setup and use the EMIF to access the SDRAM on the HDK.

    e2e.ti.com/.../237341
    e2e.ti.com/.../180728

    I believe that you may have seen the thread in the second link above and that this is where you downloaded the v3 Halcogen project. Even though this is from Halcgoen v3.x you should still be able to open it and regenerate the code in version 4.07.00 without issue.
  • 0 in reply to Chuck Davenport
    Prodigy 140 points

    Hello Chuck, 

    The 5164.7215.EMIF.zip from 180728 is the example i am using. I can run it with V3 Halcogen and SDRAM is good. After that, open  REAplan_2D_V1b.hcg with Halcgoen V4 and regenerate the code. I also follow 180728 to add: 

    systemREG1->GPREG1 |= 1u << 31; 

    Insert in the sys_link.cmd the SDRAM as needed.

    I use memory browser to check the SDRAM from 0x80000000, but i get all 0 no matter what i write to there. I am no idea how to fix it and any suggest is welcome. 

  • 0 in reply to yi cui
    TI__Guru 59540 points
    Hello Yi,

    I will have a look at this in more detail tomorrow since I don't have access to my bench today. In the meantime, can you compare the output from v.4 and V3 Halcogen projects to identify what the difference is?
  • 0 in reply to Chuck Davenport
    Prodigy 140 points

    Thank you to help to find the issue.  i try to compare the output files from Halcogen V3 and V4. for emif.c is not too many different. we do not need call emif_SDRAMInit() anymore. The new one emif_SDRAM_StartupInit() is called from system.c.  

    Thanks,

  • 0 in reply to yi cui
    TI__Guru 59540 points
    Hello Yi,

    Once you do the compare and make the adjustments, does the code work now and resolve your question?
  • 0 in reply to Chuck Davenport
    Prodigy 140 points
    I try what I can, but it does not work.
    thanks,
  • 0 in reply to yi cui
    TI__Guru 59540 points
    Hello Yi,

    I apologize but I have not been able to check on your post for a few days. Can you update me on the status on this?

    Once you have aligned everything between the different versions of code, it is still not working? Can you send me both the working project and the failing project so I can compare here as well and help debug?
  • 0 in reply to Chuck Davenport
    Prodigy 140 points

    Hi,

    i still can not fix this issue. they are the project file for both of them. the V3 one is working, but the V4 does not.

    thanks,

    6175.EMIF_HCG_V4.zip0572.EMIF_good_HCG_V3.zip

  • 0 in reply to yi cui
    TI__Guru 59540 points

    Hello Yi,

    First I apologize for the delay in getting back but I believe I have located the source of the issue.

    In the projects you posted, the V4 project initializes EMIF_CLK (VCLK3) to 40MHz which causes a significant difference in the calculated values to write to the SDTIMR register. When I open the working project in Halcogen V4.0.7, the EMIF_CLK is set to 80MHz which results in the same values being written to SDTIMR except for the value being written to T_WR which is too large for the T_WR field causing it to overflow into a reserved bit (Bit19). If take into account the usable bits of the defined T_WR in the code (14 or 0x0E) it is actually writing a value of 6 into T_WR.

    I suspect if you update the T_WR =75ns in either the V4 project (40MHz EMIF_CLK) or the good V3 project (80MHz) opened with V4 and re-generate the code, it should work. Also note that the maximum frequency for long term reliability of the EMIF is 60MHz so the project running at 80MHz may work in a bench environment, it might have trouble at the max or min temperature specifications and/or max or min voltage specified.

    The screen shot below shows how the EMIF SDRAM Config should be updated to match the working project.

    In the case of EMIF_CLK = 40MHz, SDTIMR initialization will look like this:

    emifREG->SDTIMR  = (uint32)((uint32)5U << 27U)|
			             (uint32)((uint32)1U << 24U)|
			             (uint32)((uint32)0U << 23U)|
			             (uint32)((uint32)1U << 20U)|
			             (uint32)((uint32)0U << 19U)|
			             (uint32)((uint32)6U << 16U)|
			             (uint32)((uint32)3U << 12U)|
			             (uint32)((uint32)5U << 8U)|
			             (uint32)((uint32)0U << 7U)|
			             (uint32)((uint32)1U << 4U)|
			             (uint32)((uint32)0U << 3U);

    In the case of EMIF_CLK = 40MHz the SDTIMR register will be initialized as below:

    emifREG->SDTIMR  = (uint32)((uint32)2U << 27U)|
		                     (uint32)((uint32)0U << 24U)|
		                     (uint32)((uint32)0U << 23U)|
		                     (uint32)((uint32)0U << 20U)|
		                     (uint32)((uint32)0U << 19U)|
		                     (uint32)((uint32)3U << 16U)|
		                     (uint32)((uint32)1U << 12U)|
		                     (uint32)((uint32)2U << 8U)|
		                     (uint32)((uint32)0U << 7U)|
		                     (uint32)((uint32)0U << 4U)|
		                     (uint32)((uint32)0U << 3U);

  • 0 in reply to Chuck Davenport
    Prodigy 140 points

    Hello Chuck,

    thank you for explain the EMIF_CLK. I try your suggestion to change it, but  it is still not working on my side. Maybe my project has other error.  If you try it on RM48HDK, please post your project here and everyone can use it as reference. 

    Thanks,

  • 0 in reply to yi cui
    TI__Guru 59540 points

    Hello Yi,

    I was doing some additional investigation and reviewing some older posts and noticed one that indicated that the EMIF CLK is not enabled by default and you must check this option on the PINMUX tab under "Special Muxing Options." See my screen grab below. When I import your V.3 project to the latest Halcogen 4.0.7, this option is not checked so the EMIF_CLK will not be enabled.

  • 0 in reply to Chuck Davenport
    Prodigy 140 points

    I try this fix and it is better than before. I can see the SDRAM value change according my code. but it change all memory location to the same value. in my code, I only update 256 bytes. I think we are very close to solve this issue. if you have any idea, please let me know.

    Thanks,