RM48L952: Hercules Board Rm48L952 - HalCoGen 4.7.00 upgraded drivers from 4.3.00 (different settings)

Hi Tammy,

"Enable EMIF_CLK output" checkbox affects PINMMR29 register. It enables or blocks EMIF_CLK output.
When "Enable EMIF_CLK output" is checked HalCoGen clears PINMMR29[8] bit and in that way EMIF_CLK is enabled.

Thank you for answering Q1, yes then it has the same function as 4.3.00 checkbox but just properly named/described in 4.7.00.

Does anyone have the answers for Q2 or Q3:

2. Under EMIF (EMIF SDRAM menu), in 4.7.00  there is an SDRam init time field that did not exist in 4.3.00. How should this be set? The default is 200 usec

3. We are upgrading to 4.7.00 because we were told that the new emif drivers would now support that the onchip and on board sdram could be accessed as a contiguous memory space for coding purposes via the API. Is this still correct or do we need to download an additional package? Thank you again.

Hello,

2. The SDRAM Init time is not used in the EMIF driver generated through the HALCoGen.
3. We recommend to use the latest version. The internal SRAM starts at 0x0800_0000, but the external SDRAM starts at 0x8000_0000.

Hi QJ, thank you. With the drivers generated with HalCoGen version 4.3.00, when we ran out of memory the OS and code could not access the off-chip sdram like we could the onchip sdram to increase stack space, for variables, etc. We were told that the emif driver was not done yet to support this, and to put anything on the onboard sdram we had to do the #pragma DATA_SECTION(..) for every variable when we ran out of onchip ram and map variable by variable it in the halcogen sys_link.cmd file. We were told that that a HalCoGen would be released with updated emif and memory drivers where we did not have to do this manually when we ran out of on chip ram . Is HalCoGen 4.7.00 the version with this updated memory and emif drivers so we no longer have to manually (no need for #pragma.... ) do anything with the on-board sdram and both onchip and onboard sdram access appears contiguous to the software? Thank you again.

Hello Tammy,

The EMIF driver won't be able to do this kind of job. We can map the variable to SDRAM (0x80000000) in cmd file, and copy the function in "CODE_SECTION" to SDRAM and execute the code from SDRAM. We can use SDRAM for stack too.

Hi QJ, Ok the other TI employee must have misunderstood our question a few years back when he thought there would be an upgrade of the emif driver in the new HalCoGen. Can you give a practical code example of how to change the cmd file to be able to put stacks  and/or functions in the off chip (onboard) SDRAM on the hercules board in that section? Is it similar to how it is done in your bootloader?

The only reason we were going to upgrade to the new halcogen from 4.3.00 was we thought we would get drivers that would let us use the onboard SDRAM like the onchp SDRAM without having to do any manual mapping in the software. Since you wrote that will not be possible (we will always have to do some type of mapping) If the drivers generated by the 4.3.00 are stable otherwise, why would it be worth the risk to upgrade to drivers generated by 4.7.00 halcogen?  Are there any other features or bug fixes that would make it more stable then our 4.3.00 Halcogen drivers? Thank you again.

Hello,

1. copy section from flash to SDRAM
in *.c file:
#pragma CODE_SECTION (flash2sdram, ".flash2SDRAM")
void flash2sdram(..) {
...................
}
In cmd file within SECTIONS{..}:
.flash2SDRAM : RUN = SDRAM, LOAD = FLASH0, LOAD_START(ulLoadStart), LOAD_END(ulLoadEnd),
LOAD_SIZE(ulSize), RUN_START( ulStartAddr ), RUN_END( ulEndAddr )

In *.c file for example main.c, copy .flash2SDRAM section to SDRAM
for(i=0;i<ulSize;i++)
{
((char *)&ulStartAddr)[i] =((char *)&ulLoadStart)[i];
}

2. map the variable and stack to SDRAM in cmd file

MEMORY
{
..............
STACKS (RW) : origin=0x80000000 length=0x00002000
SDRAM (RW) : origin=0x80002000 length=0x000xxxxx
}

SECTIONS
{
..............
.STACK_DATA_svc : {. += 1024;} > STACKS, RUN_START(StackModeSVC)
.STACK_DATA_fiq : {. += 1024;} > STACKS, RUN_START(StackModeFIQ)
.STACK_DATA_irq : {. += 1024;} > STACKS, RUN_START(StackModeIRQ)
.STACK_DATA_abt : {. += 1024;} > STACKS, RUN_START(StackModeABT)
.STACK_DATA_und : {. += 1024;} > STACKS, RUN_START(StackModeUND)
.STACK_DATA_sys : {. += 1024;} > STACKS, RUN_START(StackModeSYS)
.bss : {} > SDRAM
.data : {} > SDRAM
}

Hi QJ, thank you for the practical examples. We will test with this and let you know. Did you see the last question after you wrote we should upgrade to 4.7.00 from 4.3.00? The only reason we were going to upgrade to the new halcogen from 4.3.00 was we thought we would get drivers that would let us use the onboard SDRAM like the onchp SDRAM without having to do any manual mapping in the software. Since you wrote that will not be possible (we will always have to do some type of mapping) If the drivers generated by the 4.3.00 are stable otherwise, why would it be worth the risk to upgrade to drivers generated by 4.7.00 halcogen? Are there any other features or bug fixes that would make using 4.7.00 better/more stable then our 4.3.00 Halcogen drivers? Thank you again.

Hi Sunil,

  Thank you for your message. We were told we had to upgrade to a new halcogen with upgraded drivers to do this, bu it could be there was a misunderstanding of what our question was a few years ago.  Yes I have now downloaded and read section 8.5.5.7 in the spn118u guide.

So, i.e., our section map file below shows we manually allocated certain variables in the onboard SDRAM (SDRAM_CAL) and you can see the onboard ram we do not have a lot of memory left. It looks like it is the .bss section to do Automatic Splitting of Output Sections Among Non-Contiguous Memory Ranges instead of manual allocation in the cmd file and doing pragma statements. Then when RAM is used up the linker would automatically start allocating from SDRAM_CAL?

MEMORY CONFIGURATION

         name                origin            length          used         unused   attr    fill
----------------------       --------            ---------        --------        --------       ----  --------
  VECTORS               00020000   00000020  00000020  00000000     X
  FLASH0                   00020020   0015ffe0    00095c55  000ca38b  R  X
  FLASH1                   00180000   00180000  00000000  00180000  R  X
  STACKS                   08000000   00000900  00000000  00000900  RW  
  RAM                          08000900   0003f700  0003e49d  00001263  RW  
  SDRAM_CAL          80000000   00200000  00001798  001fe868  RW  


SEGMENT ALLOCATION MAP

run origin      load origin   length       init length      attrs members
----------         -----------         ----------       -----------       -----     -------
00020000    00020000    00095c78   00095c78    r-x
  00020000    00020000    00000020   00000020    r-x .intvecs
  00020020    00020020    00094156   00094156    r-x .text
  000b4178    000b4178    00001837   00001837    r-- .const
  000b59b0    000b59b0    000002c8   000002c8    r-- .cinit
08000900    08000900    0003e49e   00000000    rw-
  08000900    08000900    0003e087   00000000    rw- .bss
  0803e988    0803e988    00000416   00000000    rw- .data
80000000    80000000    00001798   00000000    rw-
  80000000    80000000    00001798   00000000    rw- .sdram_cal

So first I would remove the #pragma allocation of variables in the code on the offchip sdram ram and change cmd file from how it looks now:

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_CAL (RW) : origin=0x80000000 length=0x00200000
/* USER CODE END */
}

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 (3) */
   .sdram_cal : {} > SDRAM_CAL
/* USER CODE END */
}

and I would change it to split the .bss section (see section of map file above) for the linker to automatically use the sdram on the board when it runs out of the ram on the rm48 by using the >> feature as indicated in the manual

SECTIONS
{
    .intvecs : {} > VECTORS
    .text    : {} > FLASH0 | FLASH1
    .const   : {} > FLASH0 | FLASH1
    .cinit   : {} > FLASH0 | FLASH1
    .pinit   : {} > FLASH0 | FLASH1
    .bss     : {} >>  RAM | SDRAM_CAL
    .data    : {} > RAM
    .sysmem  : {} > RAM
    
    FEE_TEXT_SECTION : {} > FLASH0 | FLASH1
    FEE_CONST_SECTION : {} > FLASH0 | FLASH1
    FEE_DATA_SECTION : {} > RAM

/* USER CODE BEGIN (3) */
   .sdram_cal : {} > SDRAM_CAL
/* USER CODE END */
}

So this is in the .cmd file is all that is needed to allow our code to automatically allocate from the onboard sdram when the onchip ram becomes full? I can remove all #pragma's and I do not need to manually allocate functions in sdram  in the .cmd file? Do we need to upgrade our compiler or the version of drivers we are using (we are using HalCoGen 4.3.0 and compiler/linker is  version 5.1.6? Thank you again.