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.

c6678 EMIF16 boot qusention

Other Parts Discussed in Thread: PTH08T220W

Dear TI Engineer:

I have question about the c6678 emif16 boot, the followings are my understanding of the boot process and the problem I have encountered. Would you give me some suggestions, thanks!

  1. A.     Reference

From TI <<sprugy5b.pdf>>, on page 10:

“The ROM Boot Loader (RBL) is DSP code that transfers application code from slow non-volatile external memory or from an external host into high-speed internal memory for execution after the DSP is taken out of reset. The RBL is permanently stored in the internal ROM of the DSP starting at the base address of ROM 0x20B00000.”

 

From TI <<sprugy5b.pdf>>, on page 18:

“The RBL uses the BOOTCOMPLETE register, which controls the BOOTCOMPLETE pin status, to indicate the completion of the ROM boot process. Due to legacy implementation, the BOOTCOMPLETE bit is set before the image is loaded in the CorePac0.”

 

From TI <<sprugy5b.pdf>>, on page 24:

“In EMIF16 boot mode, the ROM code configures the EMIF16 interface and sets the boot complete, then branches to the EMIF CS2 data memory at 0x70000000. No return is expected. No memory is reserved by the bootloader.”

 

.Note: The Boot Complete Register (address:0x0262013C) is shown in Figure 3-8 and described in Table 3-10 from TI <<sprs691c.pdf>>, on page 78.

 

 

Conclusions

Then, according to the above descriptions by TI’s user guide, can I make these conclusions:

1, The boot sequence is started automatically after each power-on reset, warm reset, and system reset;

2, The boot process by the RBL executes an initialization code using the device configuration .pins,and then branches to the desired address for example 0x70000000;

3, When the board was powered on correctly and the dsp out of reset, the RBL .will complete automatically, and set he BOOTCOMPLETE register to indicate the completion of the ROM boot process.

 

 

  1. B.     My work

The following is my work environment and tools:

1, I use the TMS320C6678ACYPA DSP to design my own board;

2, The board’s schematics was designed reference to ti’s TMDXEVM6678L EVM. Board;

3,I want to use the EMIF16 boot mode for single core boot;

4,The nor flash for boot is S29WS256P of SPANSION company, on dsp ce0,as 0x70000000

5, ccs5.3 software

 

The following is my test steps:

1,Make sure the power value and power up sequence for DVDD18→CVDD→CVDD1→DVDD15→and others are good,.

2, Make sure the clock for CORE,DDR,PA and others are good

3, Set the device configuration pins to the EMIF16 boot mode, then the BOOTMODE[12:0] value is 011011xxxx000

 

  1. C.     Question

 

If my conclusions are right, when I power on the board, and after the DSP out of reset, the RBL will boot complete, and the BOOTCOMPLETE register will be 1.

1, But when I connect the emulator, viewing that the BOOTCOMPLETE register is 0;

2, Besides, no matter in which boot mode, the register is always 0.

So, is my understanding not correct, or, why the RBL do not execute completely? What reason may cause the RBL not done, or the BOOTCOMPLETE register not be set to 1.?

Thanks!

  • Gang,

    For debugging issues like this, you need to use a Target Configuration that does not have a GEL file attached to it. The normal GEL files we use will do things to the chip and board to make it easier to develop code on the platform. But for hardware debug, that needs to be removed.

    In the Debug Properties of CCS, make suer there is no automatic running, such as Go Main, after a program is loaded.

    If you try an emulation reset, you should see the Program Counter set to 0x20B00000 which is the start of the RBL. You can then read the DEVSTAT register to see if it has the correct values.

    Set a hardware breakpoint at 0x70000000 and Run/Resume. Do you reach that breakpoint?

    If the C6678 is not running right in the RBL, then you most likely have something wrong in some clock, power, or configuration pin. When the hardware is not working on a new board design, there are many possibilities that can be wrong. Your debug skills will be tested.

    Regards,
    RandyP

  • Hi, RandyP

    Thanks very much for your reply. Yes, I did check the DSP status followed your advice. As below, I will give my test results:

     

    The following is my test step and result:

    1. Build a new Target Configuration that does not have a GEL file attached to it;
    2. Make sure there is no automatic running;
    3. When the Program Counter set to 0x20B00000 which is the start of the RBL, the value of the DEVSTAT register is 0x00001B01, this should be right;
    4. Set a hardware breakpoint at 0x70000000 and run/resume, but I can’t reach that breakpoint.

     

    Other Test Results:

    1. When set the BOOTMODE to NOBOOT, I can still connect the DSP normally and use it correctly with a led on and off project.
    2. When set to EMIF16 boot mode, after my board powered up, and connect the emulator, I find the pc register stays at 0x20B01154 all the time.

    I am sure that the power, clock output are both in right, but I have a suspicion of the three reserved pins

     

    From TI <<sprz334e.pdf>>, on page 18:

    “Below are the reserved pins on the device which will indicate the status of the main PLL lock, DDR3 PLL lock and PA PLL lock.

    • RSV20 - COREPLLLOCK

    • RSV21 - DDR3PLLLOCK

    • RSV22 - PAPLLLOCK

    If those pins are high then respective PLL is locked and if those pins are low then the respective PLL is not locked.”

     

    Suspicion

    1. Above silicon describes the bug for Ti’s V1.0 DSP, and My DSP TMS320C6678ACYPA should not encountered the error condition. But what make me puzzled is the pin of RSV20 is low while the RSV21 and RSV22 pins are both high on my own board. Further, the phenomenon is for the (noboot,emif16boot,SGMII boot,IIC boot) mode, while in other boot mode(SRIO boot, PCIe boot, hyperlink boot), the three pins are all high. May be this information is useful for you, but I can’t understand if it is wrong or not.
    2. Is it possible that the DSP was damaged?
    3. I use TI’s PTH08T220W for the power supply of the DVDD15 and DVDD18, whose output ripple is 15mvpp. Is the PTH08T220W’s ripple can’t satisfy the DSP?

     

    Then, what possible reason may cause the wrong, could you please give me some suggestions or test methods further, thanks for your good ideas! I did check the status like clock, power, and configuration pin, and still have no idea about the RBL staying at 0x20B01154.

    Solicitous of your help! Best Regards!

  • Hi Gang,

    Have you tried the EMIF16 boot on the EVM already just to double check that it works as expected?
    On your custom board a what logical level is the BOOTMODE4 pin?

    Thanks,

    Anthony

  • Gang,

    gang said:
    the value of the DEVSTAT register is 0x00001B01

    Please explain your settings for DEVSTAT for EMIF16 boot. Also, please tell us your settings for DEVSTAT for No Boot mode.

    Regards,
    RandyP

  • HI Gang,

    Please read the below post:
    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/252903/885688.aspx#885688

    This is a documentation error and BOOTMODE04 signal does have an influence for EMIF boot.

    Anthony

  • As Anthony pointed out there is an error in the documentation for the bootmode settings required by EMIF16 boot.  The sub-mode bits are actually in BOOTMODE[5:4] instead of BOOTMODE[9:8]. Try setting your BOOTMODE[12:0] value to 011xx1x01x000.

    Regards, Bill

  • Hi Randy, Anthony and Bil
    Good job!
            Maybe Ti really had make a mistake in the documentation for the boot mode settings required by EMIF16 boot. I had set my BOOTMODE[12:0] value to 011xx1x01x000,and the RBL indeed set the BOOTCOMPLETE register to 1 now!
            But my custom board can’t boot in EMIF16 mode all the same, maybe I should check the NOR flash operation and the project for booting. When set to EMIF16 boot mode, after my board powered up, and connect the emulator, I find the pc register stays at 0x70xxxxxx now。Of course, the pc register stays at the map address for NOR flash on CE0. There are many possibilities that can be wrong, and what’s your opinion of this?
            Thanks very much for your reply and your effort! Every day I also get closer to the target with your help! Surely, I need to work hard remorselessly.
    Regards, Gang.

  • Gang,

    This is where you need to use CCS and watch what the DSP is executing at whatever 0x70xxxxxx is. This is your code, so it should be reasonable for you to follow the code.

    You may want to set a hardware breakpoint at 0x70000000, which is the entry point to the NOR Flash. You could then set the PC back to 0x20b00000 (start of ROM) and let it run to 0x700000 and then start watching what it does there.

    Just a suggestion.

    Regards,
    RandyP

  • Hi, TI Engineers

    Thanks for your reply! Sorry to trouble you again! Yes,I understand your mean and will debug the NOR flash following your good advice.

    Then, I still have question about the ROM Boot Loader (RBL) with TMS320C6678ACYP.on my custom board.

    I set my BOOTMODE[12:0] value to 011xx1x01x000,and the RBL indeed set the BOOTCOMPLETE register to 1 which is for the EMIF16 boot mode. However, in the same experimental conditions, I find that in other boot modes, the RBL still not completed and the BOOTCOMPLETE register is always 0.

    1, When my board powered up and connecting the emulator, I view that the BOOTCOMPLETE register is still 0 besides the emif16 boot mode using your new device configuration;

    2, If you test that the RBL had initial the emif16 correctly using your new device configuration?

    The following table will list the test results of the pc register staying address and the value of DEVSTAT register after connecting the emulator.

     

    Boot mode

    PC counter after JATG

    DEVSTAT

    (addr:0x02620020)

    BOOTCOPLETE

    (addr:0x0262013C)

    0

    No boot

    0x20B0 1154

    0x0000 0001

    0x0000 0000

    0

    Emif16 boot

    0x7006 F778

    0x0000 1921

    0x0000 0001

    1

    SRIO

    0x20B0 C3E4

    0x0000 1A83

    0x0000 0000

    2

    SGMII

    0x20B0 1C90

    0x0000 1C85

    0x0000 0000

    4

    PCIe

    0x20B0 CCD0      

    0x0000 1809

    0x0000 0000

    5

    IIC

    0x20B0 CCD4

    0x0000 080B

    0x0000 0000

    6

    SPI

    0x20B0 A350

    0x0000 040d

    0x0000 0000

    7

    hyperlink

    0x20B0 1290

    0x0000 1A8F

    0x0000 0000

    What reason may cause the RBL not done, or the BOOTCOMPLETE register not be set to 1 in all the others boot mode?

    Regards, Gang.

     

  • Gang,

    You will understand the boot procedure better by reading the Bootloader User Guide and the boot portions of the Data Manual.

    BOOTCOMPLETE will only be set to 1 when the boot process is completed, not when it begins.

    How can the SGMII boot mode complete on your custom board? What external device is connected to the SGMII port?

    The same questions are true for every boot mode.

    Regards,
    RandyP

  • RandyP

    Thanks! Maybe I do have misunderstood the meaning of the manual.

    But what make me puzzled is that on TI 6678 EVM board, the hyperlink boot mode indeed completed and BOOTCOMPLETE was set to 1 with the DEVSTAT value 0x00001A8F. In your word, what external device is connected to the hyperlink port, or other reason I have ignored? I guess that the boot process completed refers to  refers tthe RBL boot process completed, not the whole boot process, am I correct?

    Regards! Gang

  • Gang,

    May I assume your board does not implement the IBL in I2C EEPROM as is done on the EVM? This makes a difference in the use of these bits because a different boot flow is taking place.

    Regards,
    RandyP

  • RandyP

         Yes,that's right. I see now ,and thanks  for your patient guidance. Then, I clearly understand the RBL boot process and the difference between EVM and my board.

    So, I'll check  the code for nor flash operations carefully and  perhaps could find the problem. Another qusention is that in no boot mode ,I can operate the nor flash (erase,program and so on)correctly,but in emif16 boot mode ,nothing could i do wtih the nor flash. How do you think about this, any suggestion is welcome.

    Best Wishes!

    Gang.

  • Gang,

    In No Boot mode, you are using Code Composer Studio with emulation to control your board. CCS uses a GEL file that will automatically perform some device initialization.

    You must perform all device initialization in your own NOR Flash code, unless the Bootloader User Guide specifically mentions an initialization that is done;

    Regards,
    RandyP

  • RandyP

        Thanks for your help and your colleague’s effort. I have solved the problem and  the dsp could boot in emif16 mode sucessfully  now. Then, the conclusion may be that  dsp was not correctly initialized of my own NOR Flash code,of course  the device configuration  is not right.

      I study a lot from the discussion with you, thanks!

    Best wishes!

    Gang

  • Bill-

    > ...there is an error in the documentation for the bootmode settings
    >  required by EMIF16 boot.  The sub-mode bits are actually in
    >  BOOTMODE[5:4] instead of BOOTMODE[9:8].

    I have the latest 6678 data sheet (Rev D, April 2013) which is still showing the sub-mode bits as BOOTMODE[9:8].  To clarify:

      -these are actually BOOTMODE[5:4]; please confirm

      -what happens to BOOTMODE[9:8] ?  They are now reserved?

    On our 6678 board, we need to change some resistors to account for this, so I want to be sure.

    Also, SPRUGY5C makes no mention of sub-mode.  What is the onchip bootloader (RBL) state if I2C boot fails; for example, a new board after assembly?  Will it try additional modes and/or go quiet and assume no-boot?  In this situation, using CCS + JTAG, can we run the standard .out program to write I2C EEPROM?

    Thanks.

    -Jeff
    Signalogic

  • Hi Jeff,

    My original comments are still valid. I'll check with the documentation team to see why this wasn't fixed in the latest release. The sub-mode bits are still BOOTMODE[5:4] and BOOTMODE[9:8] are reserved.

    Note that the bootrom does not include any kind of fall back mode. If you choose I2C boot and the memory has not been programmed, the device may boot into some unknown state. Most of the time you can still connect CCS in this condition but it is possible that the device may try to execute an illegal instruction and end up in an illegal state.

    If you're concerned you can include the option of setting the bootmode to either I2C or noboot.

    Regards, Bill

  • Bill-

    Thanks.  So far we're able to connect repeatedly without the I2C boot EEPROM programmed.  That's a good thing for lab / development stage.

    What would you advise for production boards?  Maybe the test jig could control the boot mode pins, and initially select no-boot, program the I2C EEPROM, then select I2C boot and reset the 6678 ?

    As a side note, I haven't looked over RBL source yet, but I would have thought the RBL would look for a magic word pattern in the initial bit stream and if not found assume the I2C EEPROM is either not programmed or not programmed correctly.

    -Jeff

  • Hi Jeff,

    The method you've described has been used by other customers. Since the difference between no boot and I2C bit is a single bit, it is pretty easy to have the tester drive the part into no boot mode. Once you've programmed you I2C you can drive the I2C bootmode bits and toggle RESETFULLz to reboot the part into I2C mode.

    I'm not an expert on the rbl. The information is available in the KSI bootloader users guide. If you have specific question I can direct them to the rbl experts. 

    Regards, Bill

  • Bill-

    Thanks.  I did start another thread to confirm that BOOMODE[8] is used to determine I2C boot output clock rate:

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/324279.aspx

    Currently we're measuring about 360 kHz, so we want to determine precisely how it's derived.

    -Jeff