TMS320F28379D: Failing to Program Flash or Ram

Hi Matt,

Do you have the ability to put the device in wait boot mode? What boot mode are you using now? 

Could you also try testing connection in CCS? Here are some old instructions, but the process is very similar in new versions of CCS: https://www.youtube.com/watch?v=o_2iMqZ1EbU

 Best Regards,

Ben Collier

Hi Ben

Thank you for replying to me.

The same issue occurs when in wait boot mode, or Get mode (which i have historically set for "boot from flash"). Interestingly under the Get mode the rest line pulses low at ~15ms rate, i did some further experimenting with this and found a script which disbaled the watchdog, running this seemed to stop this pulsing low.

I have tested the JTAG connection using my target configuration file and that passes all tests

Thanks

Matt

Matt,

What debug probe are you using? 

Best Regards,

Ben Collier

The XDS110, i have been told by me colleague that it isn't actually 5 that program, it is actually 3 program, 3 don't

Matthew,

Do you encounter this problem when connecting to the device or when flashing it?

You can determine this by doing the following:

1. In CCS, Select view > target configurations

2. Right-click on your target configuration and launch the selected target configuration

3. Right click on the each CPU core and select the option to connect

Does the problem occur at this step? 

4. After the core is connected, left-click on the target core for download and click the load button at the top of the screen

5. Browse project to find the .out file that you wish to load to the core

When following these steps, where in this process do you see the problem?

If the problem is with loading the code and not with connecting, could you please look at watch VDD, VDDIO and XRSn with an oscilloscope when you are trying to load the code onto the device? 

Best Regards,

Ben Collier

Ben,

I have launched the Target config file, and connected each core in turn:

This looks good to me.

The next stages i will use code destined to be loaded into flash

The progress bar in the pop up does not move and in the console i get the following

and the debug screen implies the target gas been disconnected

Monitoring VDDIO no change is seen on the 3V3, VDD no change on 1.2V

XRSn, has different output depending on the boot mode switches from power on.

Boot From flash: the line is at 3V3, put pulses low for 50us at a rate of 15ms. Connect the target it remains high, the pulsing then returns as soon as you start programming

All other boot modes: The line is held high, there is a single 50uS low pulse when you initially start programming, then it returns high and stays in that position

Thanks

Matt

Hi Matt,

All of the signals that you measured sound like they look correct.

When you see the message asking you to reset your debug probe, could you try unplugging your debug probe from your PC then reconnecting it? 

Best Regards,

Ben Collier

HI Ben

I have tried that with a variety of ways, connecting to different ports, the point at which i unpug the de0bugger but get the same issue

Mat

Hi Matt,

Could you please share some screenshots of your target configuration file? Specifically, could you please go to the advanced tab and click on the C28xx_CPU1 core so I can see the initialization script like this? 

Also, once you are connected to the cores on your device, could you try using the on-chip flash tool (found in tools) to erase your flash? 

Best Regards,

Ben Collier 

HI Ben

PLease see below

And the test connection seems to pass 

[Start: Texas Instruments XDS110 USB Debug Probe_0]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

[Result]

-----[Print the board config pathname(s)]------------------------------------

C:\Users\morford\AppData\Local\TEXASI~1\
CCS\ccs1020\0\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 100- or 510-class product.
This utility will load the adapter 'jioxds110.dll'.
The library build date was 'Jan 1 2021'.
The library build time was '11:25:57'.
The library package version is '9.3.0.00032'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '5' (0x00000005).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.

-----[Print the reset-command hardware log-file]-----------------------------

The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the XDS110 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for XDS110 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).

-----[Perform the Integrity scan-test on the JTAG IR]------------------------

This test will use blocks of 64 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.

The JTAG IR Integrity scan-test has succeeded.

-----[Perform the Integrity scan-test on the JTAG DR]------------------------

This test will use blocks of 64 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.

The JTAG DR Integrity scan-test has succeeded.

[End: Texas Instruments XDS110 USB Debug Probe_0]

When i try and erase the sectors i get the same message 

 C28xx_CPU1: GEL Output:
Memory Map Initialization Complete
C28xx_CPU1: If erase/program (E/P) operation is being done on one core, the other core should not execute from shared-RAM (SR) as they are used for the E/P code. Also, CPU1 will be halted to determine SR ownership for the CPU which will run the Flash Plugin code, after which CPU1 will be set to run its application. User code execution from SR could commence after both flash banks are programmed.
C28xx_CPU1: Erasing Flash memory...
C28xx_CPU1: Error: (Error -1135 @ 0xC095) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 9.3.0.00032)
C28xx_CPU1: Trouble Halting Target CPU: (Error -1044 @ 0x0) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 9.3.0.00032)
C28xx_CPU1: Error: (Error -1135 @ 0xC095) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 9.3.0.00032)
C28xx_CPU1: Unable to determine target status after 20 attempts
C28xx_CPU1: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

This also seems to be crashing code composer studio

Could this be related to the soldering temperature? I am trying to find out exactly what they did during manufactire

Matt

Matt, 

Just to confirm, you are able to follow the above steps and flash your device as expected with a different identical board? 

Best Regards,

Ben Collier

Yes that is the case

I have had the solder temperature profile back and seem to have hit an maximum of 240degC when they seem to be rated at 250 degC. So i do not think that they have been exposed to too much heat

Matthew,

Thanks for working with us to help debug this.  In order to isolate this fully to a device issue, would it be possible to swap the C2000 MCUs on a non-working board and a known good board?  I'm making an assumption that these are TQFP and not BGA, let me know if these are BGA where this might be impractical.

1)If the issue follows the C2000 MCU then we can begin a return/failure analysis process back to TI.  If it stays with the board, then we have some more debug we can help with, etc.

2)If you'd like to share your PCB schematic in advance, I can take a look, or we can wait for the above results.  We can use an off-forum chat function to share files that you don't want on a public forum.  Let me know and I can get that setup.

3)Can you also share the top side marking of the units both working and non-working?  This will give me some advance info on the manufacture dates, etc of the devices.

Best,

Matthew

Thanks Matthew, i had started the process of getting the DSPs replaced, i have 4 remaining spares which i will get replaced. It is not something that we can do in-house.

Would you be able to setup a way to transfer the schematic for you to review? 

I will get the marking for you in the morning

Matt

Matt,

I'll send you a chat/friend invite and we can use that to attach the files.

Best,

Matthew

Matthew,

Sorry for the long time between posts, was out last week for Thanksgiving here in the US.  I'm still looking into this, can you comment what version of CCS you are using to connect/program to these devices? 

Best,

Matthew

I am using v10. Devices shoudl be changed next week

Thanks Matthew, will see what the swap tells us.  

Best,

Matt

HI Matt, had the boards back today with the new devices (out of the same original pack) and all 3 have programmed without issue. 

Matthew, Thanks for the update and glad to see the new devices are passing.

For the older devices, do you still have those, just not populated on a PCB?  There are two paths we can take with those;

1)Populate on known good board and see if failure persists(if not then perhaps there was simple soldering issue originally)

2)Submit these devices back to TI for re-test, there is procedure for that I can fwd if we want to go that route.

Given the relatively high fail rate originally and that the new units are from the same batch I would tend to think there was some PCB build issue in play, but we can only know for certain with more debug.

I was able to review the schematics you sent, and I didn't see any issues there as well.

Let me know what you would like to do.

Best,

Matt