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.

6678 I2C EEPROM programming procedure for new / custom board



TI experts-

We want to program the I2C EEPROM for the first time on a new board.  We're using an XDS560v2 emulator.  A few questions:

1) It looks like .gel files and docs for this are in the MCDSK download.  Is that correct?  I did find the "BIOS MCSDK RECOVERING FACTORY DEFAULT IMAGES" guide document, but that's for programming all 3x non-volatile devices (EEPROM, NOR, NAND) and we're not to that point yet. 

2) Can we accomplish this using only .gel files and existing .out and .bin files for the EVM 6678?  We do need to make some changes to the DDR3 boot parameter table, but other than that, for peripherals that vary from the EVM, we're not concerned at this point.

3) Initially we want to do this through CCS.  We don't want to use DSS and/or Javascript for the time being -- is that possible?

-Jeff
Signalogic

  • Hi Jeff,

    1) Yes, the GEL files and docs for this are in the MCSDK. You will find the GEL file for evmc6678l in C:\ti\mcsdk_2_01_02_06\tools\program_evm\gel and the docs for programming I2C EEPROM in C:\ti\mcsdk_2_01_02_06\tools\writer\eeprom\docs.

    2) I believe the I2C EEPROM on the EVM is a 24-bit device. As long as this is also true of your custom board, the same .out and GEL files should work (NOTE: it sounds like you are already aware of needing to make changes for DDR. Those will have to made in the GEL, as well, for DDR GEL initialization). Here you can find schematic and bill of materials information for the EVM: http://www.advantech.com/Support/TI-EVM/6678le_of.aspx

    3) Yes, following the README in the docs directory, you will be able to load and use the eepromwriter_evm6678l.out to the device in CCS and program the I2C EEPROM.

    Hope this helps.

    -Jon

  • Jon-

    1) Unfortunately the gel file you reference (C:\ti\mcsdk_2_01_02_06\tools\program_evm\gel\evmc6678l.gel) does not have a script (menu function) that can write the I2C EEPROM (to be specific, it has only a partial I2C reference, the variable i2cprog is never set to 1, and there is no DDR3 parameter boot table).

    2) Our I2C device is identical to the EVM 6678 board, organized as 128k x 8..  Can you clarify your reference to a "24 bit device" for the I2C EEPROM?  To what are you referring?

    Thanks.

    -Jeff

  • Jeff,

    1) The GEL files are not written to be able to write to the I2C EEPROM. There are scripts for initializing the board, DDR, etc, if needed.

    In C:\ti\mcsdk_2_01_02_06\tools\writer\eeprom\evmc6678l\bin there is a file called eepromwriter_evm6678l.out. (There is a ReadMe.txt in C:\ti\mcsdk_2_01_02_06\tools\writer\eeprom\docs with instructions on how to use this program, please take a look at this document). This .out file is the code used to program the I2C EEPROM. You will boot the device into No Boot mode, connect to the device and load this program. In the ReadMe, there are instructions on where to put your image, how to name it, and guide you on any changes needed for the .txt file in the bin directory that the eeprom writer uses. It will also guide you on where to load your image into memory (using the Memory Browser in CCS).

    2) Forgive me, that should have been deleted. If your EEPROM is the same as the EVM, then the MCSDK tools should work.

  • Jon-

    You mean the program_evm.js Javascript for the EVM board?  If so that's fine for a working EVM board that needs to be re-flashed, or needs to boot a different OS from NOR Flash.  But it's not fine for a new / custom board.  As I say, we're in a development stage, and we're bringing up sections of the board one at a time, and we need debug/memory visibility at each stage, which is not possible with the re-Flash Javascript.

    Currently we're pulling out I2C EEPROM related sections from program_evm.js and adding to our Gel file, including menu items for:

      -reading the I2C binary image into C66x memory
      -setting DDR3 boot parameter table (and other tables)
      -writing the I2C EEPROM

    I'm surprised Advantech and/or TI doesn't already have this, it's basic stuff.  For new board bring-up, simpler is better.  There are enough things that can go wrong as it is.

    -Jeff

  • Hi Jeff,

    Let me clarify the steps that Jon is asking you to follow. The C6678 EVM currently has a secondary bootloader(IBL) on the I2C EEPROM  with Out of box demo boot images on NOR And NAND. When you run the DSS script to restore the EVM to factory settings, the script uses the target configuration file for the platform to connect to the device and load and the run the binaries that write the images to I2C EEPROM, then on NAND and NOR On the device.

    The same can be done without the script. You need to create a target configuration file in CCS with the appropriate emulator and add the GEL file for initializing the device when CCS connect to the device. The GEL contains initialization of main PLL, DDR PLL, PSCs etcs but doesn`t contain the I2C programming option. Once the device is initialized you can load the eeprom_writer on the device and write to the EEPROM. An example to write a binary image to the I2C EEPROM is the process of programming the I2C EEPROM on the EVM. This has been described in the ReadMe.txt document provided to user in MCSDK under the path C:\ti\mcsdk_2_01_02_06\tools\writer\eeprom\docs.The eeprom writer is provided in source so you can modify it based on how you have connected the I2C EEPROM. Is this not what you are trying to achieve on your custom board?

    Regards,

    Rahul

  • Rahul-

    Yes I had found this over the weekend.  It should be very helpful, thanks.

    Is there a similar .txt file or Wiki that shows where I can look in C66x memory -- after loading the .dat or .bin file, but prior to writing the I2C EEPROM -- and see/modify the DDR3 boot parameter table?

    Thanks.

    -Jeff

  • Hi Jeff,

    You can look into C66x memory by using the memory browser (Under the Tab View) in the debug view of CCS. Once you open the memory browser, you can see the contents of the memory by simply entering an address in to the text box and clicking enter.

    DDR3 table used for boot has been provided in the C6678 datasheet. YOu can either choose to initialize DDR3 through RBL or have a multistage boot where you initilaize DDR in the first stage and re-enter boot. An example of this is provided in the MCSDK with the SRIO boot but you can do the same with I2C boot as well. The example can be found under the path ti\mcsdk_2_01_02_06\tools\boot_loader\examples\srio\srioboot_ddrinit

    Hope this helps

    Regards,

    Rahul

  • Rahul-

    Thanks very much for your fast reply.  Yes we know how to use memory view and what settings we will need for DDR3 boot parameter table.

    But at what mem address does the DDR3 boot parameter table start?  I.e. at what address can we see it after loading memory with the .bin file?

    Also which bin file to load, eeprom51.bin or i2crom_0x51_c6678_le.bin ?  Thanks.

    -Jeff

  • Rahul-

    This question:

      "At what mem address does the DDR3 boot parameter table start?
      I.e. at what offset from 0x0C000000 can we see the table after loading memory with the .bin file?"

    is crucial for us.  I can't find it any docs.  Thanks.

    -Jeff

    PS. We're using eeprom50.bin.  We can successfully write/read I2C EEPROM, so now we're trying to perform correct boot, including DDR3 initialization.

  • Jeff,

    The DDR table that the RBL uses to configure DDR starts at 0x00873500 and has a length of 0x100.

    The struct and parameters you'll need are defined in tiboot_c66x.h located in ti\mcsdk_2_01_02_06\tools\boot_loader\ibl\src\device\c66x.

    Regards,

    -Jon

  • Jon-

    This address (0x00873500) is L2 mem, where the RBL copies the DDR3 config table from I2C EEPROM?  If so where is the offset from 0x0C000000 after loading the .bin file?

    I want to modify the DDR3 table prior to writing the EEPROM (i.e. prior to running eeprom writer .out program).

    Thanks.

    -Jeff

  • Hi Jeff,

    The RBL while booting is probing the location 0x00873500 for a valid DDR configuration table. The DDR configuration table is user provided and there is no default DDR configuration table loaded in by the ROM.

    So if you look at the srio_ddrinit example in MCSDK, it loads a first stage code into Device internal memory and then does a memcopy of the DDR configuration table to the location 0x00873500 and then re-enters ROM using RBL rentry address. When it re-enters the RBL the ROM detects non-zero value in the location where it expects the DDR configuration table and starts initializing the DDR based on values it finds in that location.

    The same thing can be achieved by defining a section in your code that places the DDR configuration table at location 0x00873500 while loading the the code.  We don`t have an example of the second approach but I will try to provide pseudo code so that you can try this with your setup.

    In you source file add the following code

    // Refer to the EMIF4_TBL_T in the tiboot.h file for C6678 provided in MCSDK (as pointed in Jon`s post.)

    #pragma  DATA_SECTION (emif4Cfg, ".emif4Cfg")

    const BOOT_EMIF4_TBL_T  emif4Cfg ={

    <DDR configuration parmaeters>

    };


    In your linker command file place this section to the location where the RBL wants the DDR configuration table to be loaded.

    MEMORY
    {
        DDR_CFG   :  origin = 0x873500, length = 0x100 <- memory section where the DDR config table is loaded
        L2MAGIC   :  origin = <device magic address>, length = 0x4

        DDR       :  origin = 0x80000000, length = 0x2000
    }


    SECTIONS
    {
        .emif4Cfg > DDR_CFG //Place #pragma datasection you created in the code and place it in DDR_CFG section
                                                  // Note always place this section above all other sections that need to be loaded in DDR.
        .stack > DDR
        .msmc  > DDR
        .data  > DDR
        .far   > DDR
        .text  > DDR
        .const > DDR
        .cinit > DDR
        .lmagic > L2MAGIC
        

    }

    Hope this helps understand the process of DDR initialization using the RBL. RBL doesn`t perform leveling accurately so u need to initialize with lower DDR speeds and then correct the leveling and DDR speeds from your source code.

    Regards,

    Rahul

  • Rahul-

    Thanks for this guidance, these are helpful.

    Currently I'm in a customer location and there is time pressure to test I2C boot.  What I need to know is where in the .bin file, after it's loaded to memory at 0x0C000000, is the DDR3 configuration table?

    We are loading eeprom50.bin, the same file as used for the EVM 6678.  I only need to change the parameters having to do with memory organization (number of banks) since this part of our board is different than the EVM.

    Once I have the offset from 0x0C000000 I can change the parameters as needed, write the I2C EEPROM, and verify boot with DDR3 initialization.

    Thanks.

    -Jeff

  • Jeff,

    eeprom50.bin is Binary boot file for booting the Power On Self Test (POST). The code for that example runs from L2 and tests NAND read , External memory read/write test, NOR read test, EEPROM read test, UART write test , Ethernet loopback test, LED test .

    Since the code is loaded in L2, this example doesn`t use the DDR config table. I mean that DDR initialization for that example is not done using the RBL, it is done using code provided in the PDK software package so you can`t just simply change the values in the bin file to change the DDR settings. You will need to modify the code for post example and chnage the DDR setup using the APIs defined in PDK folder and rebuild the image.

    If you look at the post.c file in the post example you will see the tests that are runs and the platform_init call in the main function sets up the PLL and the DDR configuration for the platfrom. In the PDK software package you can look at th file platform.c under C6678 to see how the DDR initialization is performed.

    If your objective is to just test the DDR with your configuration, I recommend that you modify the GEL file for the EVM to incorporate the settings for your platform and then validate the DDR is being initialized accurately, you can then include this in your boot image using DDR config table or use the code in the PDK.

    Regards,

    Rahul

    Useful wiki links to read description of POST

    http://processors.wiki.ti.com/index.php/BIOS_MCSDK_2.0_User_Guide#Power_On_Self_Test_.28POST.29

    http://processors.wiki.ti.com/index.php/Program_EVM_UG

  • Rahul-

    Thanks again.  We've already tested DDR3 mem from GEL file settings and it works Ok.

    It does appear that some data from eeprom50.bin is copied to L2 address 0x00873500 during the boot process.  For example if I set this area to zeros, it is re-written after boot (in the correct boot table format, with 3 PLL values, but no DDR3 register values).

    Do you know from where in 0x0C000000 memory the POST program copies data to 0x00873500?  Even if it's just "no DDR3 init" data, I can change this.

    Another question, are there instructions showing how to modify the POST program to add a DDR3 memory test?  The Wiki you mentioned gives an overview of POST, but not how to modify it.

    Thanks.

    -Jeff

  • Hi Jeff,

    The entire post example loads the code in L2 mmeory. There is no code loaded in the MSMC in the post example. Please refer to the map file in the post example for C6678 under directory C:\ti\mcsdk_2_01_02_06\tools\post\evmc6678l\bin. The map file at the top will show you what device memory is used to run the application.

    MEMORY CONFIGURATION

             name            origin              length          used          unused      attr    fill
    ----------------------  --------               ---------        --------         --------  ----  --------
      L2SRAM                00830000   00050000  000147ce  0003b832  RW X
      L1PSRAM             00e00000   00007fff      00000000  00007fff     RW X
      L1DSRAM             00f00000    00007fff      00000000  00007fff     RW X
      MSMCSRAM         0c000000   00200000  00000000  00200000  RW X
      LINKRAM              10820000   00000200  00000010  000001f0   RWIX
      CPPIRAM              10820200   00000200  00000080  00000180  RWIX
      PKTRAM                10820400   00000800  00000400  00000400  RWIX
      DDR3                     80000000  10000000   00000000  10000000  RW X

    The code only uses L2SRAM and L1D and L1P on the DSP and some part of the LINK, CPPI and PKT memory. The MSMC and the DDR3 memory is not used for loading code. SO no data is loaded at 0x0c00 0000 or copied over to the location of the DDR3 config table.

    The DDR memory test is already part of the POST source code. Look at the file post.c. The external memory test is invoked using the function call test_result = post_test_external_memory(); //line 1149

    The platform initialization used in that example applies to the EVM so you need to modify it for your platform. The platform init code is part of the file platform.c in the PDK package under the path PDK_INSTALL_DIR/packages/ti/platforms/evmC6678l/platform_lib/src/platform.c. We don`t have a wiki to demonstrate how the post example can be modified but all of the code is provided in source in the MCSDK for users to modify.

    Regards,

    Rahul

  • Rahul-

    Rahul Prabhu said:

    There is no code loaded in the MSMC in the post example.

    I think we still have some misunderstanding.   I'm referring to MSMC mem *before* POST runs, during the process of loading eeprom50.bin into MSMC mem and writing it to EEPROM.  Then, at boot-time when POST runs, I've noticed that either RBL or POST writes default DDR3 initialization data to 0x00873500 (effectively setting no registers, but using the correct boot format).  So my question is:  where in eeprom50.bin image is this default DDR3 data?
    Rahul Prabhu said:

    The DDR memory test is already part of the POST source code. Look at the file post.c. The external memory test is invoked using the function call test_result = post_test_external_memory(); //line 1149

    Please clarify -- you mentioned before that DDR3 initialization and test is not included in the EVM POST.  Here you're saying that it is?  Or you're saying that it's part of the source, and we can enable it and rebuild to create a new EVM POST?

    Thanks Rahul.

    -Jeff

  • Jeff,

    Thanks for the clarification. Now I understand your MSMC reference better.

    The POST application doesn`t  write any data to the location0x00873500. This location is only initially populated by the RBL with the chip`s default EMIF timing and register settings. The default table is part of the ROM and not part of your eeprom50.bin so you can`t change values in your bin file to change the DDR settings.


    For your second question, I meant the post example doesn`t perform DDR3 initialization using ROM code but the test source code does initialize the DDR3 using source code using the APIs from the PDK software and then performs a read write test. So to change the DDR3 settings, you will need to modify the post/PDK source code.

    Regards,

    Rahul

  • Rahul-

    Thanks, all makes sense.  After booting I do indeed see memory at 0x00873500 (and other areas) being set by RBL as expected.

    Questions:

    1) In CCS, to re-run POST after booting, is it sufficient to select CPU Reset and Resume (F8) ?  This seems to be working, but I want to be sure it's correct procedure.

    2) Where in C66x memory does POST store results?  We don't have the LEDs on our board that the EVM has, so we need an alternate way to see POST results.

    Thanks.

    -Jeff

  • Rahul-

    Ok we have I2C EEPROM boot and POST working now.  We can see POST results on 6678 UART output, using our UART-to-USB bridge (this part of our board design follows the EVM 6678 board very closely).

    As follow-up notes to my entry above:

    1) After connecting to the 6678 in "mid stream" (i.e. after I2C boot), and regardless of what program we are loading (EEPROM writer, manual download of POST, etc) either Resume (F8) or Free Run works fine.

    2) We used post_i2crom.bin, not eeprom50.bin.  Although I'm not sure if this is the correct choice for Rev 1.0 silicon boards, it seems to work.  We keep byte swap disabled.

    -Jeff