Other Parts Discussed in Thread: UNIFLASH, TLV757P
We have designed a custom circuit board that uses the Delfino TMS320F28379D dual core Microcontroller. For expediency, our original Alpha prototypes used TI’s control card (as a plug in module) which uses the ZWT (ball grid package). Our Pre-Beta design now uses the PTP (quad flat pack version). To date, we have built nine of these Pre-Beta units of which (3) would not program CPU2’s FLASH until we slowed the clock down to less than 25MHz. The 6 other cards would reliably flash both CPU’s at 190MHz. We have been using an XDS200 USB programmer and Code Composer Version 6.1.1.00022
Here are some additional details:
- We initially program CPU1’s and CPU2’s flash with a custom boot loader program using flash algorithms in TI’s F021_API_F2837xD_FPU32.lib that subsequently gets application code from an onboard OMAP processor via a UART. This bootloader was developed and tested on our Alpha design which utilized TI’s control card and worked without issue.
- This initial bootloader program is flashed onto the parts via the JTAG port.
- Using our nine Pre-Beta cards (using the 28379D PTP Package),
-
- Code composer’s JTAG test routine works without issue, verifying the JTAG connection for all nine cards
- 100% of all cards had CPU1 reliably flashed at full rate (190MHz). Never any issue with CPU1.
- For six of the cards, CPU2 also programmed at full clock rate.
- But, three of the cards refused to program until the clock rate was slowed down to 25MHz (using 10MHz internal oscillator and PLL settings of IMULT=15, FMULT=0, IDIV=3 (/6))
FYI: The Delfino has its boot pins setup for GET MODE. We have also tried WAIT MODE. No difference.
The errors indicated (for the three failing cards) from code composer were of two different varieties:
- The device flash maybe locked, or
- A break point was unable to be removed at some address.
After much hardware debug and many attempts to get the devices to work (whether changing boot mode, attempts at unlocking flash that was really not locked, etc), we slowed the clock down via code composer properties dialog for PLL settings. With the integer multiplier set to 15 (multiply by 15) and integer divisor set to 3 (a divide by 6), the remaining three boards flashed. Ie: No error messages, no locked flash, no problems with break point removal, just a clean flash load.
Also of note, once any of our delfino’s CPU’s were flashed, they all reliably can be upgraded (re-flashed) via the UART with our bootloader as well as reliably via JTAG at over 100MHz. Over and Over, no further issues.
We are concerned about moving onto beta and/or production without understanding this issue. If this is a known problem that slowing the clock down fixes: OK. If not known or understood, then we are concerned about experiencing this again at larger volumes. Also, why did the control card work without issue? Do they get tested at the factory (ie flashed) so that maybe we would not experience what appears to be an initial programming issue? Or is there enough of a difference in the boot rom between the two different packages??
Thanks in advance for your help.