I receive the following errors when trying to connect to the Peripheral Explorer Kit:
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.
I receive the following errors when trying to connect to the Peripheral Explorer Kit:
Hello,
There is details on these wiki pages on debugging such connection issues:
http://processors.wiki.ti.com/index.php/XDS100
http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems
Let me know if that helps!
Best Regards,
Chris
Hi,
Check the positioning of switches on controlCard. Refer the attached doc.
F28335 controlCARD-InfoSheet.pdf
Regards,
Gautam
Gautam,
I tried connecting with SW1 in the ON position initially and then I was instructed by online help to try it in the OFF position. In either position, when I try to "Test Connection" I receive "an error occurred while hard opening the controller".
Please help
Gautam,
After searching through as much information as I can find, it appears that the error I receive in Code Composer:
An error occurred while soft opening the controller.
-----[An error has occurred and this utility has aborted]--------------------
This error is generated by TI's USCIF driver or utilities.
The value is '-151' (0xffffff69).
The title is 'SC_ERR_FTDI_OPEN'.
The explanation is:
One of the FTDI driver functions used during
the connect returned bad status or an error.
The cause may be one or more of: invalid XDS100 serial number,
blank XDS100 EEPROM, missing FTDI drivers, faulty USB cable.
Use the xds100serial command-line utility in the 'common/uscif'
folder to verify the XDS100 can be located.
[End: Texas Instruments XDS100v2 USB Debug Probe_0]
Is very similar to this one that I found on the wiki.ti XDS100 page (the DOS window did not show up):
It says to check with my XDS100 manufacturer. Since I've only dealt with ti, I don't know if there is a third party I should contact. I'm a bit of a novice when it comes to this stuff, but it seems like the EEPROM may not have been programmed properly. If you believe that I need to program the EEPROM, let me know if there are any potential pitfalls that may trip up the non-expert.
Tom
Hi Tom,
The Peripheral Explorer kit's on-board emulator is based on the xds100v1. So first of all, you should have that chosen as the emulator in your target configuration.
Based on your error, it looks like the FTDI chip is not programmed or is corrupt, could you try to reprogram it via the procedure in the below forum post:
https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/21086
Let us know how things go.
Thank you,
Brett
Brett,
I tried reprogramming the FTDI chip using the suggested procedure and I received a no devices found.
Everything seemed to be going correctly; I downloaded MProg, launched it, and opened XDS100wUART.ept. The text box indicated "The number of Blank devices = 0 , The number of programmed devices = 1". The pictures that indicate what the parameters should be set to did not open, so I could not verify that everything was setup correctly. So I went to Device then Program and received a "No Devices Found" error.
This is getting pretty frustrating. Can I get a phone call from an expert to walk me through this, it is getting more than a little frustrating?
Tom
Hi Tom,
I am a bit confused when you say that "the parameter should be set to did not open". Can you attach a screenshot?
After opening the XDS100_wUART.ept file, I get something like the below:
At this point, you should be able to 'Erase All Existing Devices', and then afterward, 'Program All Existing Devices'.
Thank you,
Brett
Tom,
To answer a question you asked previously, the board definitely has an xds100v1 on the board. (I designed it)
Based on what you've written up, the FTDI driver has now been programmed correctly and the xds100v1 worked well enough to get programmed in the first place.
The next step is to see if Windows is happy. In Device Manager, do you see the highlighted entries below?
If so, I think CCS isn't playing well. I would recommend trying the 'Test Connection' button in your target configuration (within CCS) and let us know what the output is.
If not, I think Windows is having some kind of driver issue with xds100v1 (a hardware issue isn't completely out of the question though). Based on previous experience, a reinstall of CCS may help this - a fresh install will reinstall the drivers. If you want to try something before resorting to that, I have attached the drivers here:
/cfs-file/__key/communityserver-discussions-components-files/171/XDS100-Drivers-v1.0.zip
Let us know which bucket you fall into. Hopefully this gets us closer to the resolution.
Thank you,
Brett
Tom,
Welcome to the world of digital control then!
Trust me, you're not so far behind. Different vendors and different chipsets have different IDEs and nuances to getting started. Ideally, our documentation helps keep you guys out of pitfalls, but our documentation isn't always ideal and there's always the chance of user error. The key thing is that we can eventually get over these issues and once resolved focus on the chip and engineering.
So to roughly answer the questions:
1) In CCS, when you choose xds100v1 or xds100v2 or xds110, you are choosing how CCS will try to talk to your emulator (which driver to use). Your emulator then talks to your F28335 (it knew how to talk to the C2K because of the programming you did via MProg). The XDS100v1 and XDS100v2 are both based on a family of FTDI chips and the driver between the two (I have come to assume) is very similar. I think this is why you could use the xds100v2 driver without issue (I've noticed that I could do this as well while running experiments previously). [Speculation] The XDS100v2 is a faster emulator so perhaps the xds100v2 driver has a few extra lines of code to utilize a higher speed operation [end Speculation]. The XDS110 is a different animal and because that driver didn't match with your hardware, you ran into problems.
2) Test Connection issue with xds100v2 - I'm not 100% sure what's going on here. Do you get the same kind of thing if you choose xds100v1+F28335 as your target configuration? Are you trying to run 'Test Connection' while the device is already connected to CCS?
Thank you,
Brett
Brett,
I appreciate your help. I'm taking a course at a local university that focuses on the TMDSPREX28335. It was a little overwhelming at first learning the architecture of the F28335, relearning C and all of the z-transforms and complex math I haven't used in many years. It is all starting to come together now though.
I see that ti does have a significant amount of software available for free. I was wondering if you could give me some advice on the best way to get a three phase PFC control board together. We have one with analog circuitry, but it is cumbersome and not really worthy of going to production. I'm not sure if I should graduate to the Sensorless FOC and PFC Developer's Kit (TMD2MTRPFCKIT) when I'm comfortable with the peripheral Explorer Board, or are there three phase PFC algorithms available from ti that I should explore.
I would greatly appreciate your feedback on the subject.
Tom
Tom,
The kit closest to what you are doing that we offer is the TMDSILPFCKIT. The kit is available on the TI eSTORE and all the software/SCH can be downloaded freely from controlSUITE. In case you haven't come across them, the below is a link to all our application kits:
http://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/c2000_performance/real-time_control/f2802x_f2803x_f2806x/tools_software.page#application
What kind of control are you hoping to use in your application?
P.S. If you're thinking motor, the TMDSHVMTRPFCKIT would be my recommendation. There's lots of pretty useful software built around it.
Thank you,
Brett
Brett,
My company typically designs and manufactures high power (50kW and up) applications, so we are looking at three phase PFC solution. I've only taken a cursory look at what software is available, but I have not yet seen any three phase PFC software. If I don't find anything available, hopefully I can adapt what is available to my requirements.
Thanks,
Tom
Brett,
I finished up my old school analog battery charger project so I can finally devote time to the digital control project that I had communicated with you about a while back. Anyway, I have a single phase AC current source operating fine in open loop. There are three interleaved dual IGBTs switching at 10KHz each with an effective 30 KHz of ripple on the output. Like I said, everything looks fine in open loop.
When I close the loop using the difference equation that was calculated with the Bilinear transform, it operates like a conditionally stable loop. As I increase the DC bus over 150 volts, resulting in a modulator gain of over 34dB (150 Vdc / 3 volt tri wave) it becomes very unstable.
As any analog engineer would do, I revisited my compensation. I modified it to a type II configuration with 90 degrees of phase margin. That sounded good until I plotted phase and gain using MatLab and noticed how my compensation phase bump decreased significantly at 1/2 the sample rate. Until now, Nyquist was something I brought up when I wanted to sound smart.
So I sample my current feedback at 10 KHz. Right after I sample, I compare the sample to my sine wave reference. The error generated is compensated with my difference equation. The compensated error is loaded into my compare register to generate the PWM duty cycle.
Looking at the Bode plot, it seems like I need to sample at a faster rate, but changing the PWM duty cycle more than once a period seems like a jittery, high frequency, unstructured technique to me. So what do I do with all of the extra samples?
I sure hope I'm on the right track.
Tom
Hi Tom,
Could you start a new thread on this topic now that we're continuing to run toward a new subject? A new thread will help you to get the best feedback on the new subject.
I have some opinions, but there are definitely others looking at the forum who are more experienced in control theory than I.
Moderator Edit: The thread was continued here: https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/439023
Thank you,
Brett