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.

TMS320F28027F: Unprogrammed brand new F28027F boot mode issue

Part Number: TMS320F28027F
Other Parts Discussed in Thread: UNIFLASH, TIDA-01168

Hi

I have a brand new PCB with a brand new F28027F on it, JTAG header connected to XDS110.

when i power up the board, the f28027f goes into a reset cycling mode.

from what i have read so far the f28027f is going to flash and since there is nothing programmed in it, the watchdog times out and reset...

I used CCS --> XDS110 --> JTAG --> F28027f

issue:

CCS can not reach the F28027f

verified with a scope that the JTAG pins are toggling on the header

When nTRST goes high on the header, should that not pull the F28027F out of the watchdog reset cycle mode and put it in emulation boot mode?

I also used Uniflash --> XDS110 --> JTAG -- F28027F

same issue...

is there a specifig GPIO config that i have to have for the JTAG to work?

I played with GPIO37 and GPIO34 variations and none will talk through JTAG.

This board will go into high production and wanted to know if there is a mass programmer available for the f28027F so we dont have to use JTAG on every board.

appreciate the help.

  • Shahram Montazeri said:
    I have a brand new PCB with a brand new F28027F on it, JTAG header connected to XDS110.

    Shahram,

    To make sure the CCS setup is correct, can you try connecting to a TI board?  

    Has the PCB design worked in the past?

    Shahram Montazeri said:
    When nTRST goes high on the header, should that not pull the F28027F out of the watchdog reset cycle mode and put it in emulation boot mode?

    If TRSTn is high then the boot ROM will go through the "emulation boot" sequence. i.e. the boot ROM detects that a JTAG debug probe is connected and uses the contents of two reserved SARAM locations in the PIE vector table to determine the boot mode. If the content of either location is invalid, then the Wait boot option is used.  This should result in the code looping, with the internal watchdog disabled. 

    Can you try pulling the TRSTn pin high manually and observing if the reset pattern does not occur?

    If it is an internal watchdog reset, then the reset pin will be pulled low for 512 OSCCLK cycles each reset.  This pattern should not be seen if the device detects the JTAG debug probe is connected.

    Does the PCB have an external watchdog connected that could be causing the reset?

    Regards

    Lori

  • Hi Lori

     

    I disabled the external watch dog.

    Correct it is around 512cycles.

     

    The xds110 JTAG is connected, but the nTRST is low. It only goes HIGH when I try to connect with CCS and then it goes low again.

    Default level is not HIGH when JTAG is connected…

     

    I will try the manual pull high on nTRST.

     

    So when it enters emulation mode and it reads the PIE vector locations. Is that enough to allow me read and write registers and program the F28027F?

    Or are there other steps to successfully program a brand new F28027F

     

    Thank you very much.

     

  • I should have mentioned this app note - it can help debug JTAG connection issues.

    https://www.ti.com/lit/spracf0

    Best Regards

    Lori

  • great, i will take a look at this and test later today.

    on the MASS Programing, what options are available? 

    thanks

  • Shahram Montazeri said:
    on the MASS Programing, what options are available? 

    Shahram,

    Check the list of C2000 Flash programming tools on this page: 

    https://www.ti.com/microcontrollers/c2000-real-time-control-mcus/design-development.html#programmers-debuggers

    Regards

    Lori

  • Hi

    I have been playing with the xds110 probe i have and it seems the issue is with this unit...

    here is the report from CCS when i configure it and test it. this is the same on Windows 10 and IOS (CCS installed on both platforms)

    [Start: Texas Instruments XDS110 USB Debug Probe]

    Execute the command:

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

    [Result]


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

    /Users/shahram/.ti/ccs1000/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 'libjioxds110.dylib'.
    The library build date was 'Nov  8 2020'.
    The library build time was '19:06:39'.
    The library package version is '9.2.1.00042'.
    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).

    -----[An error has occurred and this utility has aborted]--------------------

    This error is generated by TI's USCIF driver or utilities.

    The value is '-233' (0xffffff17).
    The title is 'SC_ERR_PATH_BROKEN'.

    The explanation is:
    The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.
    An attempt to scan the JTAG scan-path has failed.
    The target's JTAG scan-path appears to be broken
    with a stuck-at-ones or stuck-at-zero fault.

    [End: Texas Instruments XDS110 USB Debug Probe]

  • Shahram,

    Are you connecting to your new PCB or to a TI board?  Does this same setup connect to a different board?

    Thank you

    Lori

  • hi Lori

    i have a launchpad f28027f, that has its own JTAG xds100 that works.

    I have not tried connecting the xds110 to it yet.

    I have built a TIDA-01168 board and the xds110 is connecting to it.

    in the DOS window i tried >dbgjtag -f @xds110 -S integrity.    and it fails.

    am i correct in assuming the test is doing a SCAN test on the xds110 chip it self and does not go out to the TIDA board? or do i need to setup an external loopback TDO to TDI to get the test to pass?

  • Shahram,

    This is correct, the diagnostics from the xds tools in DOS shouldn't need a connection to the device, these are just checking the XDS110.

    I'd like to make sure we are using the correct tools(since there are different ones for XDS100 and XDS110).

    The below is in the path C:\ti\ccs_base\common\uscif\xds110

    execute "xds110reset"

    then execute "xdsdfu -e"

    This will tell us if the xds110 is recognized as well as the FW version, etc

    Let me know the results, and we can go from there.

    Best,

    Matthew

  • Hi

    xds110 is seen by the tools, please see below...

    i did a test as well, result are showen below, where the scan fails: dbgjtag.exe -f @xds110 -S integrity

    -----------------------------------------------------

    C:\ti\ccs1000\ccs\ccs_base\common\uscif>cd xds110
    C:\ti\ccs1000\ccs\ccs_base\common\uscif\xds110>xds110reset.exe

    C:\ti\ccs1000\ccs\ccs_base\common\uscif\xds110>xdsdfu.exe -e

    USB Device Firmware Upgrade Utility
    Copyright (c) 2008-2019 Texas Instruments Incorporated.  All rights reserved.

    Scanning USB buses for supported XDS110 devices...

    <<<< Device 0 >>>>

    VID: 0x0451    PID: 0xbef3
    Device Name:   XDS110 Probe with CMSIS-DAP
    Version:       3.0.0.14
    Manufacturer:  Texas Instruments
    Serial Num:    00000000
    Mode:          Runtime
    Configuration: Standard

    Found 1 device.

    --------------------------------------------

    --------------------------------------------

    C:\ti\ccs1000\ccs\ccs_base\common\uscif\xds110>cd ..

    C:\ti\ccs1000\ccs\ccs_base\common\uscif>dbgjtag.exe -f @xds110 -S integrity

    -----[An error has occurred and this utility has aborted]--------------------

    This error is generated by TI's USCIF driver or utilities.

    The value is '-233' (0xffffff17).
    The title is 'SC_ERR_PATH_BROKEN'.

    The explanation is:
    The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.
    An attempt to scan the JTAG scan-path has failed.
    The target's JTAG scan-path appears to be broken
    with a stuck-at-ones or stuck-at-zero fault.

    C:\ti\ccs1000\ccs\ccs_base\common\uscif>

  • Shahram,

    Thanks for the additional information.  While it shouldn't be necessary on a fresh device(everything is erased), I'd like to go ahead and put the device in Wait Boot mode to see if this resolves the issue  You will need to drive GPIO37 to 3.3V/high and GPIO34 to 0V/low link to the datasheet here .  You need to use a weak PU on GPIO37 since it is also TDO, so 2k-10k should be OK.

    I see where this was discussed in the above posts, but I don't think we have tried this yet.  Feel free to let me know if this is incorrect.

    Best,
    Matthew

  • Good morning Mathew

    I will give that a try today...

    so you don't think the dbg test is of concern, that seems to be the issue when I try to use CCS10. i get the same error msg when I try testdevice in CCS

  • Matthew

    the issue doesnt seem to be state of the MCU, its the probe that is not being setup properly...

    this is msg from CCS when i do "test Connection", CCS obviously wont pass this point if the test doesnt pass, right?

    i dont mind getting other probes to test if you think the xds100v2 works or recomend a lunch pad with JTAG header so i can test the probe on an approved TI board.before i debug my board.

    thanks

    ----------------

    [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\shahr\AppData\Local\TEXASI~1\CCS\
        ccs1000\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 'Dec 13 2020'.
    The library build time was '08:16:48'.
    The library package version is '9.2.1.00046'.
    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).

    -----[An error has occurred and this utility has aborted]--------------------

    This error is generated by TI's USCIF driver or utilities.

    The value is '-233' (0xffffff17).
    The title is 'SC_ERR_PATH_BROKEN'.

    The explanation is:
    The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.
    An attempt to scan the JTAG scan-path has failed.
    The target's JTAG scan-path appears to be broken
    with a stuck-at-ones or stuck-at-zero fault.

    [End: Texas Instruments XDS110 USB Debug Probe_0]

  • Shahram,

    If it is possible to try an XDS100 class emulator I would try that to see if the results are any different.  I've observed some very isolated incidents where there was a drive strength issue with the XDS110 and the XDS100 didn't have that issue.  

    If you are OK doing so, can you attach a screen shot of your schematic as it relates to the JTAG pins on the C2000?  

    Could you also confirm the voltages you see on the following pins:

    1)VDDIO

    2)VDD(even if using the internal regulator VREGENZ = 0)

    3)XRSn(you may see a toggle, but I want to make sure this isn't held low)

    Best,
    Matthew

  • Good morning

    i actually took the f28027F off of the Launchpad board I have and rewired the JTAG pins to my board.

    it worked great. i can program the f28027f on my board and run it. there are some glitches but I think its due to the length of the wires I used to connect the Luanchpad jtag to the PCB.

    I ordered a xds100v2 from Mouser to use on my board.

    i also tried the xds110 after I got the xds100 working, but same problem...

    1) VSSIO i will check

    2) VDD is 3.3V

    3XRSN is 3.3v and toggles in the beginning but remains high.

    the problem with xds110 is not the connection to the board. it doesn't get passed the TI USCIF  (SP??)

    I even grabbed a brand new laptop with no TI drivers or CCS on it. and started from scratch to make sure there were no xds100 legacy drivers on the computer... thinking maybe the older drivers are causing the xds110 not to function properly. same behaviour.

    at this point, either my xds110 was/is broken out of the box, or there are issues with the drivers, or there is a setting that needs to be set and its not on the forum, manual or anywhere I could find.

    neither CSS will pass the test jtag point nor will the uniflash6.1.0, they both get stuck at that USCF point. which from the looks of it is not leaving the connector boundry.

    regards

  • Shahram,

    If you can get the XDS100v2 from the launchpad to connect, then no need to check the other power rails, they must be OK.

    I believe that earlier you had sent the output of the xdsdfu -s, and I confirmed that your emulator FW was current.

    There is one last thing I'd like to check, can you open the target config file in CCS(screenshot posted below) and cycle to the "advanced tab" and send me what you have in a re-post?  Our newer devices support cJTAG, but the F28027F does not, so I want to make sure that is not the issue.

  • Morning

    i can confirm the screen shot matches my setting for the xds110

    I ordered a new xds100v2 and connected that one... it works

    On another note, not sure if you want to open a new thread... l was programing and had a glitch on the power supply and now the f28027 says its locked.

    do I have to replace the MCU or is there a way to unlock it... are the default keys FFFF?

    thanks

  • Shahram,

    Unfortunately this sounds like the XDS110 is not functioning here.  Depending on when/where you bought it there may be some ability to return it/refund it if it wasn't damaged, etc.  I think TI.com provides a 90 day return policy, but would need to look into that.

    In terms of the MCU, unfortunately if the device is locked(CSM is programmed) and the password is unknown then we consider the device permanently locked. This can happen if there is a power loss during programmation as you mention.  Once this happens you will need to replace the device.

    Best,

    Matthew

  • Hi

    I am not worried about the probe... it was purchased from ti.com last year.

    i am up and running, that is important.

    ok I will replace the F280.

    thank you for your support.

    if you like you can close this.