• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 82 subscribers
  • Views 2486 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28069M: Device held in Reset

Manu Abraham
Genius 3510 points
Part Number: TMS320F28069M

Hi,

As part of a project, wanted to have only the Piccolo alone on a standalone board to simplify the project; the FT2232 Programmer/debugger had to be broken out to program the controller. This resulted in two small PCB's of which the controller board alone is of interest while the programmer/debugger board came out due to absolute necessity of programming the controller. Attached pictures of both PCB's.

I've tried to copy the EEPROM contents from the LAUNCHXL_F28069M to the programmer board to make it as identical to the launchpad to avoid any hassles in programming/debugging the controller during production phase of the final project. Attached schematics of both boards.

After copying the VID, PID and the rest of the EEPROM contents, the programmer identifies itself as a XDS100 V2 debugger, as in the case with the launchpad. Attached screenshots.

Trying to do a test connection, attached log:

4520.test_connection.txt
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
[Start: Texas Instruments XDS100v2 USB Debug Probe_0]
Execute the command:
%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity
[Result]
-----[Print the board config pathname(s)]------------------------------------
C:\Users\Manu\AppData\Local\TEXASI~1\CCS\
ti\4\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 'jioserdesusb.dll'.
The library build date was 'Feb 8 2018'.
The library build time was '18:36:28'.
The library package version is '7.0.188.0'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '4' (0x00000004).
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 FTDI FT2232 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for FTDI FT2232 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).
-----[The log-file for the JTAG TCLK output generated from the PLL]----------
There is no hardware for programming the JTAG TCLK frequency.
-----[Measure the source and frequency of the final JTAG TCLKR input]--------
There is no hardware for measuring the JTAG TCLK frequency.
-----[Perform the standard path-length test on the JTAG IR and DR]-----------
This path-length test uses blocks of 64 32-bit words.
The test for the JTAG IR instruction path-length succeeded.
The JTAG IR instruction path-length is 38 bits.
The test for the JTAG DR bypass path-length succeeded.
The JTAG DR bypass path-length is 1 bits.
-----[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
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Trying to debug the default test application, Code Composer Studio states that the device is held in Reset, attached log:

debug_error.txt
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
C28xx: Failed CPU Reset: (Error -1137 @ 0x6) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 7.0.188.0)
C28xx: Trouble Reading Register PC: (Error -1137 @ 0x0) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 7.0.188.0)
C28xx: Trouble Reading Register ST1: (Error -1137 @ 0x6) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 7.0.188.0)
C28xx: GEL: Error while executing OnReset(1): Target failed to read register ST1
at (ST1&~(0x0100)) [f28069.gel:312]
at C28x_Mode() [f28069.gel:32]
at OnReset(1)
C28xx: Flash Programmer: Warning: The configured device (TMS320F28069), does not match the detected device (). Flash Programming operations could be affected. Please consider modifying your target configuration file.
C28xx: Failed CPU Reset: (Error -1137 @ 0x0) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 7.0.188.0)
C28xx: Trouble Reading Register PC: (Error -1137 @ 0x0) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 7.0.188.0)
C28xx: Trouble Reading Register ST1: (Error -1137 @ 0x6) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 7.0.188.0)
C28xx: GEL: Error while executing OnReset(1): Target failed to read register ST1
at (ST1&~(0x0100)) [f28069.gel:312]
at C28x_Mode() [f28069.gel:32]
at OnReset(1)
C28xx: Trouble Writing Memory Block at 0xae0 on Page 1 of Length 0x1: (Error -1137 @ 0xAE1) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 7.0.188.0)
C28xx: Error occurred during flash operation: Target failed to write 0x00000AE0@Data
C28xx: Trouble Writing Memory Block at 0xae1 on Page 1 of Length 0x1: (Error -1137 @ 0xAE2) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 7.0.188.0)
C28xx: Error occurred during flash operation: Target failed to write 0x00000AE1@Data
C28xx: Trouble Writing Memory Block at 0xae2 on Page 1 of Length 0x1: (Error -1137 @ 0xAE3) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 7.0.188.0)
C28xx: Error occurred during flash operation: Target failed to write 0x00000AE2@Data
C28xx: Trouble Writing Memory Block at 0xae3 on Page 1 of Length 0x1: (Error -1137 @ 0xAE4) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 7.0.188.0)
C28xx: Error occurred during flash operation: Target failed to write 0x00000AE3@Data
C28xx: Trouble Writing Memory Block at 0xae4 on Page 1 of Length 0x1: (Error -1137 @ 0xAE5) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 7.0.188.0)
C28xx: Error occurred during flash operation: Target failed to write 0x00000AE4@Data
C28xx: Trouble Writing Memory Block at 0xae5 on Page 1 of Length 0x1: (Error -1137 @ 0xAE6) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 7.0.188.0)
C28xx: Error occurred during flash operation: Target failed to write 0x00000AE5@Data
C28xx: Trouble Writing Memory Block at 0xae6 on Page 1 of Length 0x1: (Error -1137 @ 0xAE7) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 7.0.188.0)
C28xx: Error occurred during flash operation: Target failed to write 0x00000AE6@Data
C28xx: Trouble Writing Memory Block at 0xae7 on Page 1 of Length 0x1: (Error -1137 @ 0xAE8) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 7.0.188.0)
C28xx: Error occurred during flash operation: Target failed to write 0x00000AE7@Data
C28xx: Flash Programmer: Device is locked or not connected. Operation cancelled.
C28xx: File Loader: Memory write failed: Unknown error
C28xx: GEL: File: C:\Users\Manu\workspace_v8\Example_2806xLaunchPad\Debug\Example_2806xLaunchPad.out: Load failed.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Measuring the voltage on Pin #11/XRS_N (RESET#) shows that the controller is held at 0V, which would explain the logs. I wonder why how I can take the device out of Reset. Maybe I've missed out something. Can someone be kind enough to pint out the issue at hand ?

Thanks,

Manu

  • 0
    TI__Guru** 113615 points
    Hi Manu,

    When you scope the XRSn pin, do you see it's LOW all the time or toggle. Is it's LOW all the time then you need to check the power supply on the board as well as trace the XRSn pin to make sure there is no active driver on board which is driving this pin LOW all the time.

    Regards,

    Vivek Singh
  • 0 in reply to Vivek Singh
    Genius 3510 points
    Hi Vivek,


    Observable on the scope:

    XRSn pin:
    Whatever happens it is held at ~ 0V. When I press the RESET button the voltage on the pin changes from 200mV to 120mV

    TRST pin:
    3.32V

    X2 pin:
    Shows a sinewave with a frequency of 12MHz with an amplitude of 2.08V.

    AFAICS, as you can see the schematic in the post, the XRSn pin is connected to a RESET button pulled up to VDD with a 2k2 resistor, with a 100n damping resistor. There is no other connection to the XRSn pin.

    Thanks,

    Manu
  • 0 in reply to Manu Abraham
    Genius 3510 points

    Hi Vivek,

    The voltages VDD and VDDIO all seem okay. The measurements on the following pins:

    Vcc=3.2V

    Pin #3  (VDD)   : 3.2V
    Pin #5  (VDDIO) : 3.2V
    Pin #11 (XRSn)  : 98mV
    Pin #12 (TRSTn) : 3.1V
    Pin #13 (VDDIO) : 3.2V
    Pin #14 (VDD)   : 2.2V
    Pin #24 (VREFHI): 1.795V
    Pin #25 (VDDA)  : 3.2V
    Pin #37 (VDD)   : 3.2V
    Pin #38 (VDDIO) : 3.2V
    Pin #43 (SCITXA): 1.75V
    Pin #46 (VDD3FL): 3.2V
    Pin #50 (SCIRXA): 3.2V
    Pin #61 (VDDIO) : 3.2V
    Pin #68 (GPIO34): 2,4V
    Pin #63 (VDD)   : 3.2V
    Pin #70 (TDO)   : 2.4V
    Pin #79 (VDDIO) : 3.2V
    Pin #81 (VDD)   : 3.2V
    Pin #91 (VDD)   : 3.2V
    Pin #93 (VDDIO) : 3.2V

    Thanks,

    Manu

  • 0 in reply to Manu Abraham
    Genius 3510 points
    I can confirm that the resistor shows 2.199k ohms; Checking the tracks, one end is definitely physically tied to 3.2V. Definitely, XRSn pin is pulling it down and not allowing it to rise. Why would that be ?

    Thanks,

    Manu
  • 0 in reply to Manu Abraham
    Genius 3510 points
    One notable difference to the Launchpad, I must say is that there exists a 12MHz crystal on this board and it is running too. The onchip voltage regulator seems to be running; The JTAG connection tests works without failures (log attached in the first post) ? Have been reading the datasheet over and over again, what could cause the XRSn pin not to get pulled back up again.

    Any idea ? Or is it a damaged controller chip ?

    Thanks,

    Manu
  • 0 in reply to Manu Abraham
    TI__Guru 62975 points

    Manu,

    VDD is a 1.8V supply.

    -Tommy

  • 0 in reply to tlee
    Genius 3510 points
    Hi Tommy,

    Thanks for the reply, was at wits end.

    Ugh, I see that in the datasheet now. :-(
    I need to redo the PCB again. :-/

    I guess, that would have damaged the controller as well. :-(

    On the launchpad, the controller is running from the internal VREG, I guess. Since there is no additional regulator. By additionally connecting VDD to 3.2V, the controller got fried possibly, I guess ? Somehow I managed to miss this part.

    Thanks,

    Manu
  • 0 in reply to Manu Abraham
    Genius 3510 points
    Hi Tommy,

    Reworked the PCB. Things do work as expected. VDD connected to 3.2V was indeed the issue at hand.

    Thanks,
    Manu
  • 0 in reply to Manu Abraham
    TI__Guru 62975 points
    Manu,

    Thanks for reporting back your results. I'm glad that you resolved the problem. Let us know if we can help with anything else.

    -Tommy
  • 0 in reply to tlee
    Genius 3510 points
    Hi Tommy,

    No, I should thank you. You probably did not realize the frustration, trying to debug that problem.
    Much appreciated, the help.

    Thanks,
    Manu