TMS320F28069M: InstaSpin Trouble Reading Register PC: (Error -1142 @ 0x0)

Hi Everybody,

I'd like to add one more thing.

While single-stepping through the code (the "main()" function of InstaSpin lab_03a, as follows:

 gTorque_Flux_Iq_pu_to_Nm_sf = USER_computeTorque_Flux_Iq_pu_to_Nm_sf();


  for(;;)
  {
    // Waiting for enable system flag to be set
    while(!(gMotorVars.Flag_enableSys));

    // loop while the enable system flag is true
    while(gMotorVars.Flag_enableSys)
      {
        CTRL_Obj *obj = (CTRL_Obj *)ctrlHandle;

it gets as far as the line "while(!(gMotorVars.Flag_enableSys));"

Then jumps back to " gTorque_Flux_Iq_pu_to_Nm_sf = USER_computeTorque_Flux_Iq_pu_to_Nm_sf();"

It leaves the continuous for loop and goes back to the line just before it!

I didn't think that was even possible!

Best Regards,

Dave

By the way, if I just leave it alone, and let it run, it takes 26 - 27 seconds to get hung up, every time.

If I single-step through the code, it takes considerably longer.

Dave

For emulator connection, you may take a look at the link below. Delete all setting break points during program the code, and don't set any break points in ISR to debug the code.

http://software-dl.ti.com/ccs/esd/documents/ccsv7_debugging_jtag_connectivity_issues.html

Don't change the definition of the gMotorVars  without volatile keyword.

volatile MOTOR_Vars_t gMotorVars = MOTOR_Vars_INIT;

Hi Yanming,

I hope you are doing well in these crazy times.

I'll definitely check out the debugging JTAG webpage. I've already been through the document "C2000 MCU JTAG Connectivity Debug".

Here is a summary of the steps in the above mentioned guide:

Section 4.1

    1.  Yes

    2.  Got it.

    3.  Sort of - isolation was implemented on the board that uses XDS100 emulation.

         JTAG Isolation was removed, though, as per TI suggestion (see TMS320F28069M: Can't connect through XDS100 emulator

    4.  Yes - components are correct.

    5.  Yes - Power is present, at the correct voltages, and power lines are quiet.

    6.  See #3, above...

    7. FTDI chip is programmed (template applied, etc...)

Section 4.2

    1.  Yes for one of the boards.

    2.  LED is not used on the custom boards, but PWRGD is High.

    3.  Replaced cable. Problem persists.

    4.  Already running on external power supply.

    5.  Yes. The USB / JTAG emulator is present in Device Manager. Drivers installed correctly.

    6.  XDS100v2

    7. Best driver already installed (according to Windows 10).

    8.  TRSTn is High at the MCU, but I haven't seen it change from Low to High - always High.

    9.  Target Configuration is correct (different for each board, but correct in both cases).

   10.  This one is weird. It says to "right click on the CPU core", but I can't find anything in this window that looks like a CPU core.

          In any case, this step is useful only if a connection cannot be made; and I'm definitely getting a connection.

   11.  XRSn always High.

   12.  Not sure about this one. Datasheet does not say which pins are BootMode pins.

   13. This one says to put the device in Wait Boot Mode. How?

         Also, I think I read somewhere that if you're having JTAG problems, it could be because you're in Wait Boot Mode, and you should get           the micro out of that mode.

   14.  Checked ALL voltages. They're all ok.

   15.  The Oscillator for the micro is at 20MHz. The Oscillator for the FTD2232 is at 12MHz.

   16. Tried a second device for both board embodiments - they're the same.

   17.  I'm not sure what this means (???).

   Best Regards,

Dave

Hi Yanming,

I went through the debugging JTAG webpage. Here is a portion of that (My comments are in italics.):

By doing this step-by-step operation it is possible to precisely know where the issues are happening:

        If the issue happens during the Debugger Launch phase, check sections 4 and 5 of the Troubleshooting CCS     
        page at the References above.
        It does not happen during the launch phase. I launched the debugger without a project & it did not freeze up.

        If the issue happens during connect phase, check the Troubleshooting the connect phase section below.

       It does not happen during the connect phase. It connects fine. Test Connection passes.

        If the issue happens loading code to the target, check the Troubleshooting CCS - Data Verification Errors   page. It's fine here too.

        If the issue happens after the code loaded successfully but never reaches main(), the problem resides on the
        application code (bad initialization of the device, watchdog timers not being refreshed, invalid memory access,
        etc.) - in this case the application needs to be fixed. It does reach main(), but does strange things after it gets there (e.g. jumping out of the loop when single-stepping). If I don't single-step, it just quits after 27 seconds.

The applications I'm using, however, are examples provided by TI. They work on the EVM, but do not work on the custom board. Could there be some fundamental difference in the micro on the EVM vs. my boards? Is there some firmware that's loaded on the micro in the DRV8301-HC-EVM-Rev D that is not present in the microcontrollers purchased from DigiKey?

The model numbers printed on the outside of the micros match nearly exactly.

The printing on the micros I ordered is:

        TMS320    980

        F28069MPZT

        CB  93CGQ0W

                     G4

The printing on the micro present in the EVM is:

        TMS320    980

        F28069MPZT

        CB  46A764W

                     G4

I'm assuming the 93CGQ0W & the 46A764W are just lot numbers.

Thanks,

Dave

Yes, it's lot numbers, no any other differences between these two devices you mentioned above. You have to check the customer's board to make sure that 1. the power supply of the F28069M and emulator are right; 2. the connection between them are correct as well; 3. The target configuration file (.ccxml) is set properly for the using emulator.

Only modify the ADC, GPIO and PWM configuration and hardware parameters in user.h, hal.c and hal.h according to the customer's board, don't change the other code example lab in the first step.

Hi Yanming,

Thank you for your attention to this matter.

In a previous post, I listed step-by-step the items in the document "C2000 MCU JTAG Connectivity Debug".

Note that I stated that power supplies were correct (3.3V, 24V). The connections between them are correct as well.

In addition, there are pull-up resistors on *TRST, TMS & TDI. There are pull down resistors on TCK & TDO. All of them are 3.3 k ohm.

The target configuration file is set up correctly. When using the USB oriented PCB, the target is XDS100; when using the other PCB, the target is the XDS110.

There were some sections of the above-mentioned document that I either did not understand, or could not complete, summarized as follows:

Section 4.1

    3.  Sort of - isolation was implemented on the board that uses XDS100 emulation.

         JTAG Isolation was removed, though, as per TI suggestion (see TMS320F28069M: Can't connect through XDS100 emulator

          Could the lack of isolation be the issue? If so, then I'm completely stuck, because the isolation itself causes another issue (see the link above). There is no isolation on the board that uses the XDS110, nor has there ever been.

    6.  See #3, above...

Section 4.2

   10.  This one is weird. It says to "right click on the CPU core", but I can't find anything in this window that looks like a CPU core.

          In any case, this step is useful only if a connection cannot be made; and I'm definitely getting a connection.

   12.  Not sure about this one. Datasheet does not say which pins are BootMode pins.

   13. This one says to put the device in Wait Boot Mode. How?

         Also, I think I read somewhere that if you're having JTAG problems, it could be because you're in Wait Boot Mode, and you should get the micro out of that mode.

   17.  I'm not sure what this means (???).

In reply to your last statement "Only modify the...": I have not modified anything beyond what you suggest. This problem occurs even in the simple example program - Example_2806xScia_FFDLB.c for SCI Digital Loopback. So it is not related to changing parameters in InstaSpin.

Another scenario that may be of help:

Usually I just click the debug button while the focus is on the main program. But if I launch from the Target Configuration Tab, the following occurs -

When launching with no particular project selected, everything is static. There are no errors, or anomalies.

When I connect, though, the following message appears on a new Tab:

    Break at address 0x3ff75b, no debug information available, or outside of program code.

It then allows me to load the program and run it. After about 30seconds, another new tab pops up with the following message:

    No source available for "_system_post_cinit() at C:\Users\dreagan\workspace_v10p3\Example_2806xScia_FFDLB\Debug\Example_2806xScia_FFDLB.out{3}0x3ff4fa{4}

The address 0x3ff4fa is where the program has usually headed under these conditions. It's a STOP command, and is located in the Boot section of code, according to the Memory Map.

Another thing worth noting is that I get the same message when I attempt a "CPU Reset" from Code Composer.

I would not normally expect a Reset to go to this section of code. In addition, a Reset (after it's completed) should normally allow you to run the program.

The address listed as 0x3ff75b is a new one. I have NO breakpoints set, so I'm not sure what the message "Break at address 0x3ff75b..." means.

I've tried lowering the frequency of the JTAG clock with no success, but so far I've only tried 1MHz & 500kHz.

Next - I'm going to try lowering the JTAG frequency even further. Then I'm going to try loading and running a very simple program that uses no interrupts, and see if the same things happen.

After that, I'm not sure. We've been focusing on the JTAG, but could this have another cause?

Thanks,

Dave

Hi Yanming,

By the way, I finally found a mention of _system_post_cinit. It's in the compiler reference document. It says:

        _system_post_cinit(): This function is invoked during C/C++ environment setup, after C/C++ global data
        is initialized but before any C++ constructors are called. This function should not return a value.
        The _c_int00( ) initialization routine also provides a mechanism for an application to perform the setup (set
        I/O registers, enable/disable timers, etc.) before the C/C++ environment is initialized.

Very little info about _system_post_cinit(). This doesn't say what it does, and then goes on to discuss some other function, presumably related, but doesn't say how...

Even so, allthis is happening long after the environment setup, so I don't understand why it should be looking for this routine.

Best Regards,

Dave

Did you enable the watchdog in your project? If not, this function doesn't have any impact on the connection of the JTAG and the code execution.

Dave Reagan said:

    No source available for "_system_post_cinit() at C:\Users\dreagan\workspace_v10p3\Example_2806xScia_FFDLB\Debug\Example_2806xScia_FFDLB.out{3}0x3ff4fa{4}

1. Which example are you using for test? Any message reported when you click "Test Connection" button in ".ccxml" file?

2. Do you set up the clock and PLL correctly according to your hardware board?

Hi Yanming,

The watchdog is disabled in all the examples I've been using.

1. I started off using lab03a from the instaspin labs, but in a quest to simplify the code, I later switched to Example_2806xScia_FFDLB.c. Then to simplify even further, I started using Example_2806xGpioSetup.c, which I think has no interrupts.

Test Connection works - here's the output:

[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\dreagan\AppData\Local\TEXASI~1\
CCS\ccs1031\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 'jioserdesusb.dll'.
The library build date was 'Apr 29 2021'.
The library build time was '17:49:40'.
The library package version is '9.3.0.00058'.
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
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 XDS100v2 USB Debug Probe_0]

2. I haven't changed anything in the InstaSpin lab03a, where they are set up in hal.c. So I'm assuming it's correct.

Sorry - I've been throwing a lot of material at you in these posts. It's usually 24 hours before I can see your replies, so I'm trying to get as much information as I can in each post.

In that spirit, I would like to reiterate a couple of questions I asked previously:

There were some sections of the "C2000 MCU JTAG Connectivity Debug" document that I either did not understand, or could not complete, summarized as follows:

Section 4.1

    3.  Sort of - isolation was implemented on the board that uses XDS100 emulation.

         JTAG Isolation was removed, though, as per TI suggestion (see TMS320F28069M: Can't connect through XDS100 emulator

          Could the lack of isolation be the issue? If so, then I'm completely stuck, because the isolation itself causes another issue (see the link above). There is no isolation on the board that uses the XDS110, nor has there ever been.

    6.  See #3, above...

Section 4.2

   10.  This one is weird. It says to "right click on the CPU core", but I can't find anything in this window that looks like a CPU core.

          In any case, this step is useful only if a connection cannot be made; and I'm definitely getting a connection.

   12.  Not sure about this one. Datasheet does not say which pins are BootMode pins.

   13. This one says to put the device in Wait Boot Mode. How?

         Also, I think I read somewhere that if you're having JTAG problems, it could be because you're in Wait Boot Mode, and you should get the micro out of that mode.

   17.  I'm not sure what this means (???).

If you feel they are relevant to the topic at hand, could you please address the above questions?

Thank You,

Dave

Hi Yanming,

I monitored 3.3V while launching, connecting, loading and running Example_2806xGpioSetup.c. There are no problems until actually running the program. After about 27 seconds, at nearly the same moment the program gets hung up (I can't tell whether before or after), the 3.3V drops to practically nothing for about 700 uS, as shown in the attached scope screenshot.

Any idea what might be causing this?

Please also see the previous post; i have a few other questions / comments.

Thanks,

Dave

Also - here's the current being drawn from the 3.3V regulator (voltage across a 1 ohm resistor).

Please post the schematic of your own board, and what power supply is on the board when you run the program?

Is it possible to change the lab01 according to your own board? And then run the lab01 to see what happens when only power supply for controller, no power supply to inverter?

Or you might try to run a timer example without any GPIOs output on your board to see what happens. Obviously, the issue could be from your hardware board, it's not related to the emulator and software code.

Hi Yanming,

I've attached the schematic.

I cut power to the inverter and bridge, but still get the same results.

I'm using a benchtop power supply for 5V, since I suspected the 7805 was shutting down.

But I still see the same thing at the program level.

Anyway, take a look, and let me know what you think.

Thank You,

DaveSchematic Electric Handpiece MCB PP 1-6.pdf

Cut the power to the gate driver also, and only keep the power to MCU and JTAG emulator. And then run an example in C2000Ware or lab01 to see what happens.

Use a benchtop power supply, and limit the output current to 0.5A.

Hi Yanming,

I did as you suggested, and the firmware runs without incident.

The problem could be something in the driver circuitry, either the DRV8301 itself or the surrounding circuit.

I'll go through that with a fine-tooth comb.

I also plan to check the setup of ports & pins on the micro that interact with the driver and make sure they are appropriately set to input or output as required. Something intended to be an input, but actually defined as an output could potentially sink a lot of current.

Do you have any further suggestions?

Thank you,

Dave