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.

How did we 'brick' our F28069?

Other Parts Discussed in Thread: CONTROLSUITE

We have been using our "Rev 1" control board for some months, making good use of the F28069's ADCs, PWMs, trip zones, SPI, SCI, etc..  We never bothered to use our external 20 MHz crystal on X1 and X2 as the internal 10 MHz crystal was working just fine.  We updated our linker file so that we could flash the DSP, and that worked as well.

We recently did a respin and now have a "Rev 2" board.  While it has a variety of small improvements, the area around X1 and X2 is the same.  Our previous functionality was there, but we determined that we needed the more precise external clock, so we finally had to address the issue.  We have relied on the controlSUITE code; therefore, our initialization code has been as such:

// Select Internal Oscillator 1 as Clock Source (default), and turn off all unused clocks to conserve power.
IntOsc1Sel();

// Initialize the PLL control: PLLCR and CLKINDIV
InitPll(DSP28_PLLCR,DSP28_DIVSEL); // 10 MHz (int. osc.) * 16 (multiplier) / 2 (divsel) = 80 MHz

// Initialize the peripheral clocks
InitPeripheralClocks();

We were unable to find the appropriate TI documentation (the links provided in the forums were broken), but after reading the forums, we changed the code as such:

// Select external crystal oscillator as Clock Source (default), and turn off all unused clocks to conserve power.
XtalOscSel();

// Initialize the PLL control: PLLCR and CLKINDIV
InitPll(DSP28_PLLCR,1); // 20 MHz (ext. xtal) * 16 (PLLCR multiplier) / 4 (divsel) = 80 MHz

// Initialize the peripheral clocks
InitPeripheralClocks();

We put the code in the board, and it worked, but our new Rev 2 board would no longer communicate via JTAG.  Our new board had become a "brick."

We went back to our Rev 1 board, and put in the new code into it, and while it first worked, it too lost JTAG communications, and it is now also a "brick."

There didn't appear to be any warnings in the DSP's Reference Manual's "OSC and PLL Block" regarding such a problem (as there was regarding the programming of the FLASH).  What could we have done wrong that has caused both our old board to become a brick, and how can we avoid this problem in the future?  This problem is obviously a show-stopper for our product.

  • Mark,

    If you go back to using the internal oscillator as opposed to the crystal, does the card work again?   Based on the above, I think the answer is, "I think so, but I can no longer connect to them".

    If this is the case, can you try changing the boot mode of the F28069?  Ideally you'd change it to wait mode.  If in this state the chip should wait for an emulator connection once powered.  (as opposed to directly running the code in flash and being locked out by the speed of the clock, incorrect settings, etc)

    If you're using a controlCARD, changing the boot mode can be done via switches on the card itself.

    Hopefully this helps.


    Thank you,
    Brett