TMS320F280039C: TMS320F280039C

Hi William,

Are you trying to connect to a TI board like a launchpad or controlCARD or is this a custom board? If you have access to an oscilloscope, could you please probe your TDO (yellow), TMS (purple), TCK (blue), and TRST(green) like I did below? My oscilloscope capture was triggered on the falling edge of TMS.

Best Regards,

Ben Collier

Hi Ben,

I am connecting to our custom target board.  I have successfully connected to the board, as mentioned, but then it stops connecting for some reason. 

Here are the signals you requested; it is obviously not responding properly but I don't know why?  The signals are mapped the same way you had yours.

Please let me know your thoughts.

Thank you,

William

Hi William,

So are you no longer able to connect to the device at all, or do you get disconnected while your program is running? Are you using any of the JTAG pins for anything else? For example, TDO can also be used as a GPIO. Also, how long are your traces for TMS, TCK, TDI, and TDO? It looks like noise might be affecting your TDO signal, although noise problems usually result in a different error message when testing connection.

Best Regards,

Ben Collier

Hi Ben,

Once this happens I am no longer able to connect to the device at all.  The JTAG pins are not used for anything else.  However, I may have loaded an example program which accidentally configured the JTAG pins as something else.  Would that cause this problem?  I would think that upon a device reset the JTAG lines defaulted to JTAG to prevent this issue from happening but I am not sure. All JTAG traces on the target board are less than 1.0 inch in total routed length. I don't think it is noise because I was able to repeatedly connect and emulate for sometime without any issues.  I think this may have something to do with the JTAG pins being accidentally configured as GPIO pins and then no longer being able to connect.  Is that possible?

Thank you,

William

Hi Ben,

This is the code that was executed and configured the TDI and TDO pins as other than JTAG by accident when loading an example program from the Universal MotorControl Lab F28003x. GPIO_35 is the TDI pin and GPIO_37 is the TDO pin. 

// GPIO35->EPWM5B->M2_WL
GPIO_setPinConfig(GPIO_35_EPWM5_B);
GPIO_setDirectionMode(35, GPIO_DIR_MODE_OUT);
GPIO_setPadConfig(35, GPIO_PIN_TYPE_STD);

// GPIO37->Reserve
GPIO_setPinConfig(GPIO_37_GPIO37);
GPIO_setDirectionMode(37, GPIO_DIR_MODE_IN);
GPIO_setPadConfig(37, GPIO_PIN_TYPE_STD);

Would loading this to the target prevent all future JTAG connections once this program was loaded? How would I resolve this? 

Regards,

William

Hi William,

Could you try putting the device in Wait Boot mode by power cycling the device with the GPIO pins set like below? 

Best Regards,

Ben Collier

Hi Ben,

Sure, I can try this but I am curious as to why?  Do you think this will allow the device to boot correctly when the JTAG XDS200 Debug Probe is connected, thus solving the problem I am having?

Thanks,

William

Hi Ben,

After changing the boot pins to Wait Boot mode, I can now successfully connect to the target device. 

Please help me understand how that resolved the problem?  I am under the impression that I needed the device to boot from Flash.

Is this a workaround fix? 

Thank you,

William

Hi Ben,

However, once the example program in the hal.c file changes the pin functionality of GPIO_35 and GPIO_37 (TDI and TDO JTAG pins) the connection for emulation is lost.  Why is this application changing the JTAG pin functionality if the example program in the Universal MotorControl Lab is meant to be run with a JTAG emulator?  Please advise.

Also, I am assuming I will need to comment out this section of code to debug without any issues?

Thank you,

William

Hi William,

Putting the device into wait-boot mode stops the device from running any user code until it is taken over by the JTAG debug probe. Every time the device is booted, these pins are assigned to TDI and TDO until your program changes the functionality to GPIO_35 and GPIO_37. In wait-boot mode, this never happens, so you are able to connect to the device.

I am not very familiar with the Universal Motor Control Lab, is it possible to use different GPIO pins instead of GPIO_35 and GPIO_37? 

Best Regards,

Ben Collier