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.

C667x: How to assert the BOOTCOMPLETE pin from an intermediate bootloader?

Hello,

I am designing a custom board that uses an intermediate bootloader (it's not the IBL provided for the C6678 EVM, but the concept is the same). The board is booting properly. The boot process is summarized as follows:

  1. At power-on, the ROM bootloader is configured to load the intermediate bootloader from SPI flash memory to MSM. The intermediate bootloader is then executed on CorePac0.
  2. The intermediate bootloader initializes a bunch of DSP peripherals for our application. Then, it loads the application firmware for the CorePacs from SPI flash memory, and sets each CorePac running by writing the firmware entry point to the CorePac's "boot magic address" (L2 SRAM offset 0x87FFFC) and generating an IPC interrupt to wake the core.

That's all working fine, but here is what I am trying to do now. I have the BOOTCOMPLETE pin connected to some external buffers. I want the BOOTCOMPLETE pin to be asserted during the intermediate bootloader -- specifically, I need it be asserted after the GPIO peripheral has been initialized, but before the other CorePacs are loaded.

At the point where I want the BOOTCOMPLETE pin to be asserted, the value of the BOOTCOMPLETE register is 0x1, because only CorePac0 was booted by the ROM bootloader. I've been able to break in at this point with Code Composer and change the BOOTCOMPLETE register from 0x1 to 0xF (I'm using a C6674), but this still isn't causing the BOOTCOMPLETE pin to be asserted. I really thought that would do the trick.

I'm hoping that someone familiar with the internal workings of the BOOTCOMPLETE register and pin can guide me on how I can cause the pin to be asserted during my intermediate bootloader. I know this isn't exactly the intended use of the BOOTCOMPLETE pin (it's normally controlled entirely by the ROM bootloader), but I think what I'm trying to do should be possible with a little guidance.

As always, thanks in advance!

Best regards,
Dave

  • Hi Dave,

    BOOTCOMPLETE register is set after all Core's have been released from reset to run.  This is HW implemented and doesn't matter what SW / OS you're running on top.

    At the point where I want the BOOTCOMPLETE pin to be asserted, the value of the BOOTCOMPLETE register is 0x1, because only CorePac0 was booted by the ROM bootloader. I've been able to break in at this point with Code Composer and change the BOOTCOMPLETE register from 0x1 to 0xF (I'm using a C6674), but this still isn't causing the BOOTCOMPLETE pin to be asserted. I really thought that would do the trick.

    Please ensure to unlocked the kick registers before writing 0xF to BOOTCOMPLETE register. Please read back and verify.

    I was going through RBL source from below link but i could not find information about BOOTCOMPLETE pin assert.

    http://processors.wiki.ti.com/index.php/Keystone_Device_Architecture#Keystone_ROM_Boot_Examples_and_Reference_code

    Thank you.

  • Hi Raja, thanks for getting back to me.

    Raja said:
    Please ensure to unlocked the kick registers before writing 0xF to BOOTCOMPLETE register. Please read back and verify.

    I did run into this previously; my GEL file had locked the KICK registers and so when I wrote to BOOTCOMPLETE from Code Composer the value was not changing. So I had already corrected this before creating my forum post. I am able to read back the value 0xF through Code Composer.

    Raja said:
    I was going through RBL source from below link but i could not find information about BOOTCOMPLETE pin assert.

    I was also looking through the source, and I didn't see anything interesting except that it sets the bits in the BOOTCOMPLETE register in the chipStartCore and nysh_sec_core_boot functions shortly before branching out of the bootloader to the user code. This is why I thought setting the register to 0xF myself would cause the pin to become active. I think we need to try to find out how the BOOTCOMPLETE pin is implemented in silicon -- if it's more than just an AND of the BOOTCOMPLETE register bits, then I'd like to know what the other conditions are so I can try to replicate them in my intermediate bootloader.

    I know this isn't a typical use case for the BOOTCOMPLETE register. I appreciate your help!

    Thanks,
    Dave

  • Hi Dave,

    I did run into this previously; my GEL file had locked the KICK registers and so when I wrote to BOOTCOMPLETE from Code Composer the value was not changing. So I had already corrected this before creating my forum post. I am able to read back the value 0xF through Code Composer.

    One more suggestion, please try this in SPI boot mode not in "no boot" mode. After IBL init, connect to core0 using emulator without gel file and try.

    Thank you.
  • Hi Raja, I have done as you asked, but with the same result:

    1. Turn on board, allow ROM bootloader and my IBL to run as normal (SPI boot mode).
    2. After IBL has initialized things, connect to CorePac0 via emulator without any GEL file loaded.
      1. At this time, I observed the value 0x1 in memory location 0x0262013C (the BOOTCOMPLETE register).
      2. I observed that the BOOTCOMPLETE pin is low (as expected).
    3. Change the value in memory location 0x0262013C from 0x1 to 0xF via emulator.
      1. I read back the value from the memory location and confirmed that it changed to 0xF.
      2. I observed that the BOOTCOMPLETE pin is still low.

    Thanks,
    Dave

  • Hi Dave,

    I think, this is not possible. I am checking with team and will get back to you if they have any suggestions. Thank you.
  • Thanks, Raja. Hopefully they can identify the missing piece of the puzzle. I look forward to their feedback.