Hi Tammy,
The EMIF clock is configured through the clock module, highlighted below
Note I put two arrows - you can see VCLK3 will also affect EMAC and USB when you reduce this frequency to 55MHz or less...
But this is the internal bus clock interface. The clock that controls the USB bus (external) timings and that needs to be 48MHz is VCLKA3.
So don't be (too) concerned about this unless you find it affects your USB bus bandwidth - which I doubt it will..
Reason I point this out is that it alarmed me a bit to see the EMIF and USB tied together in the clock diagram, because I know the USB module needs a 48MHz clock. But the I realized that this is the VCLKA3 clock for the USB core, the clock that is shared with EMIF is for the internal USB register interface. So the only thing that might happen is you may see the USB slow down, although I doubt that you wil because a 50+MHz 32-bit wide internal bus for a 12MBit/s external serial data link still gives a healthy ratio.
The spreadsheet takes the 'ns' parameter values that are pulled from the SDRAM datasheet and calculates the bit field values from them for the EMIF control registers. It's basically a matter of dividng the 'ns' requirement of the DRAM by the EMIF frequency, and then adjusting (usually subtract 1) to match the register bit field format.
HalCoGen also takes the 'ns' parameter values from the SDRAM datasheet and computes the bit field values. So the spreadsheet is something you can use to check your inputs to HalCoGen against; but the SDRAM datasheet is the golden reference.
Most of the other non-'ns' parameters are on the first page of the SDRAM datasheet.
- 4096 refresh cycles every 64 ms (Com, Ind, A1
grade) or 16ms (A2 grade)
-Programmable CAS latency (2, 3 clocks)
(At 55MHz - you can go with only 2 cycles of CAS latency)
- Configuration 1M x 16 x 4 banks
(i.e. 4 banks)
- Column Addresses A0-A7
(i.e. pagesize_256 .. this is 'obscure' in halcogen - but if you look at the TRM description of PAGESIZE in the SDCR register, you can see this means that the memory has 8 column address lines.... )
Hi Anthony. Thank you. I had a breakpoint in CCS as you suggested and after executing emif_SDRAMInit(). WHen I tried to fill some data into the emif SDRAM region, came back with an error. See screen shots below for the Fill and the Error.
Just checked the TI board, the sdram off jumper is not populated, so that looks Ok. So it looks like either there is something off with the board, or with the initialization code we generated with halcogen. Do you have a Rev E version of the RM48L952ZWT board to do a quick check that HalCoGen is producing the same result for you as us, or if we need to go with a different version of HalCoGen code? What about the sys_link.cmd file autogenerated from HalCoGen that we modified manually. Do you think this looks Ok also? Or should we remove the edits that we made?
MEMORY
{
VECTORS (X) : origin=0x00000000 length=0x00000020
FLASH0 (RX) : origin=0x00000020 length=0x0017FFE0
FLASH1 (RX) : origin=0x00180000 length=0x00180000
STACKS (RW) : origin=0x08000000 length=0x00000900
RAM (RW) : origin=0x08000900 length=0x0003f700
/* USER CODE BEGIN (2) */
SDRAM (RW) : origin=0x80000000 length=0x00800000
/* USER CODE END */
}
/* USER CODE BEGIN (3) */
--heap_size 0x7F0000
/* USER CODE END */
/*----------------------------------------------------------------------------*/
/* Section Configuration */
SECTIONS
{
.intvecs : {} > VECTORS
.text : {} > FLASH0 | FLASH1
.const : {} > FLASH0 | FLASH1
.cinit : {} > FLASH0 | FLASH1
.pinit : {} > FLASH0 | FLASH1
.bss : {} > RAM
.data : {} > RAM
.sysmem : {} > RAM
FEE_TEXT_SECTION : {} > FLASH0 | FLASH1
FEE_CONST_SECTION : {} > FLASH0 | FLASH1
FEE_DATA_SECTION : {} > RAM
/* USER CODE BEGIN (4) */
.sysmem : {} > SDRAM
/* USER CODE END */
}
/* USER CODE BEGIN (5) */
/* USER CODE END */
Thank you again.
Hi Anthony. Thank you. Should I remove what we added to sys_link.cmd? We thought from onother TI blog on RM48 SDRAM it was required. I sent you our HalCoGen code already, do you need me to upload this again? Here is the binary (.out in zip file): 2072.BiolasePFB_ProductionBoard.zip
And here is the memory window screen shot after the debugger executes emif_SDRAMInit():
Hi Anthony. There was something weird now we saw. When we run the emif test (test code above) we are putting 56785678 in SDRAM. When we run with CCS and debugging session. The region stays as 0, and we get a fail back, memory browser shows 00000000 and if we keep going SDRAM is never updated. But when we stop the debugger, and do a restart (CTRL SHIFT 5) and hit go, then in the memory browser, the test data is in this region. Why did the test data not show up in the emif SDRAM until after we restarted the debug session? 
Hi Tammy,
It's on the pinmux tab. On the top of this tab, where you have the short cuts for each peripheral (to select all pins for a peripheral at once. To the right of this there is a box with special muxing options.
