PCIe boot: C6678 reset problem

Our application is initially loaded via PCIe. That means we have a working primary i2c boot, followed by a secondary PCIe boot. The host can then upload the software to the DSP and run it. That works fine.

However, the host initiated reset is a problem. The host has GPIO connected pins to the reset inputs (soft, hard (RESETFULL) and local resets but we cannot use POR because that is shared between different components on our board!) of the DSP.

After reset is given, the DSP is expected to rerun the bootloader and follow the exact same sequence as on a POR except for polling the DEVSTAT register pins. After the host has restored the PCIe configuration of the DSP, I can again upload software (and write/read registers across PCIe) to the DSP, but this newly uploaded software never runs.

In another thread, I read that someone was able to reset the DSP via PCIe commands (although not recommended or supported because of PLL issues). I also succeeded in doing just that: resetting (soft reset or hard reset) the DSP by just writing registers across PCIe but the outcome is the same. After reset, I can upload new software, but it does not run.

What is missing here?

Or has the DSP not come out of reset correctly?

Is the POR required for this feature?

16 Replies

  • Hi Gert, I think that old thread was started by me.

    We are able to reset over PCIe by writing to the PLL Reset register, and we do this all the time.

    You must do this:

    Enable MST_PRIV bit in PCIE_PRIORITY_REG from the host (otherwise key below wont be accepted and nothing will happen).

    Write the proper key value (0x5A69 i think) to the PLL_RSTCNTL register. Check that the key was accepted, by reading back, I think it should be 0x000C. This step can easily go wrong.

    Request the reset via PL_RSTCNTL register.

    After the reset, I suggest connecting to the C6678 using CCS, and check that Core 0 has re-entered the IBL (probably addresses 0x00800000 to 0x0081FFFF) and is polling the Boot Magic Address.

    Best wishes, Jonathan


  • In reply to Jonathan White:

    Hi Jonathan,

    yes, I read your great tip about PCIe host driven reset.

    To clarify my question:

    Reset is working.

    In short the local DSP procedure is...

    volatile unsigned int* pE8 = (volatile unsigned int*) (0x023100E8);

    volatile unsigned int* pEC = (volatile unsigned int*) (0x023100EC);

    volatile unsigned int nE8 = *pE8;

    volatile unsigned int Key = 0x5A69;

    *pE8 = Key;

    *pEC |= ((1 << 12) | (1 << 13)); // set as soft reset, standard would be hard reset

    *pE8 = Key;

    *pE8 = 0; // reset

    To summarize, in order to enable MST, via PCIe...

    • unsigned int* p_mapped points to the TI DSP 4K config section.

    • and #define TI_PCIE_PRIORITY 0x3C //3Ch Section 3.1.14

    • volatile unsigned int* pRegister;

    if (do_enableprivilege)

    { // this enables privileged writes initiated by PCIe

    unsigned int bit = (0x1<<16);

    pRegister = (unsigned int *) ( ((unsigned int) p_mapped) + TI_PCIE_PRIORITY);

    *pRegister = SWAP(bit); // Big endian host to Little endian DSP


    After, that the 0x02310000 registers can be mapped via PCIe and the same procedure as the local running reset function can be performed.

    I checked and IBL is restarted at PC 0x20B00000, both for local running reset, or PCIe remotely triggered reset.

    The same thing happens when the (not POR) reset pins are toggled. However, in both cases the software upload procedure has not the desired outcome.

    PCIe seems to be OK after the reset: I can peek and poke memory in the DSP from the host. Upload is working; I need to verify whether it starts (as triggered by Host) or not. So, I will need to debug that further and check whether it leaves the IBL and attempts to run the uploaded software.

    I was just wondering what could prevent the software from running again, especially taking into account that the upload procedure works the first time.

  • In reply to Gert Boddaert68965:

    following experiment done:

    • host stores PCIe BAR config in file
    • host resets C6678 via reset pin
    • host restores PCIe BAR config from file
    • host uploads software to DSP
    • a check program on host reveals software is not running on the DSP.
    • Debugger connected, it shows DSP still running IBL; I manually set the PC to 0x00800000 -> then run -> the software runs correctly as checked by host.

    Note: The programmed magic boot address for core 0 was correct and was thus 0x10800000.

    The code snippet to get the DSP out of reset is as follows:

        /* Now poke the legacy interrupt on the EP to have it break out of boot.
        Do it twice just to be sure */
        if (do_prints) printf("set registers... trigger INT\n");
        pRegister = (unsigned int *) ( ((unsigned int) p_mapped) + TI_MSI_IRQ);
        *pRegister = SWAP(0xff00); /*    This register is written to by the remote device. Writes initiated by an EP over PCIe link that target
                                        BAR0 of the RC land to this register if the offset matches. To generate MSI Interrupt 0, the EP should
                                        write 0x0000_0000 to this register. It will result in a pulse on bit zero triggering the MSI interrupt
                                        from PCIESS to the external processor. */
        if (do_prints) printf("set registers... trigger INT..DONE1\n");
        *pRegister = SWAP(0xff00);
        if (do_prints) printf("set registers... trigger INT..DONE2\n");

    My current work hypothesis is that the IBL is not triggered correctly to start the program at the magic_boot_address.

  • In reply to Gert Boddaert68965:

    Are you using RESETFULL or RESETZ. You need either RESETFULL or POR to trigger the complete boot loader process.



    If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

  • In reply to ArunMani:

    RESETFULL is used.

    Best regards,


  • In reply to Gert Boddaert68965:

    Are you still poking the boot magic address and sending the MSI interrupts after you load the program right?



    If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

  • In reply to ArunMani:

    Yes, exact same procedure as on a first-time upload.

  • In reply to Gert Boddaert68965:

    This is strange. Where is the PC after you loaded the program through PCIe? Also see if there is the devstat register value is different between the two cases.



    If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

  • In reply to ArunMani:


    One more thing to mention is the that only the sticky bits in the PCIe memory-mapped registers (MMRs) will be retained (most of them will be reset to default values) after the soft reset (RESETFULL). The description in the data manuals will be revised in the next release.

    That means you need to re-program the applications registers (e.g. address translation, interrupt setup) and configuration registers (e.g. BARs) after the reset.

    So you should check if the host could indeed trigger the MSI interrupt in PCIe and wake up the Core0 for boot_magic_address.






    Please click the Verify Answer button on this post if it answers your question.

  • In reply to Steven Ji:

    There is indeed a difference between the interrupt registers on a first and second software upload. Considering the order in the boot process: first I2C, then PCIe, then the IBL waits for the interrupt + magic boot address. Should the IBL not have set the interrupt registers in the correct state?

    I will now try to manually set the registers in the same state as on a first upload, then check whether the interrupt can be triggered and whether the IBL transfers the PC to the magic boot address.