Unable to program F28M35H52C1 with blinky

Florian,

Xmls that Lori posted work with CCSv5 only.

Could you upgrade your CCS version to CCSV5.3 and then try to program the Flash with the xmls that Lori provided?  Example projects in controlsuite are also going to be updated soon to work with CCSV5.

Thanks and regards,

Vamsi

Thanks for that hint. With CCSv5.3 things running fine. I suggest that you update the QSG shipped with the EVMs or add a notice to them pointing out that you have to use v5 instead of recommending v4.

Sorry to be back again, but the fix Vamsi provided lasted only till lunchbrake. After programming successfully for two or three times, I suddenly stuck with a SC_ERR_FTDI_FAIL error numbered -150.

I then reconnected the EVM several times, restarted CCS and the whole PC, checked for updates and even reinstalled ccs5.3 completely from scratch (including all available updates and the files from Lori). Nothing worked. This is the output of ccs' connection test feature:

[Start]

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\FLORIA~1.WIL\AppData\Local\.TI\
    693494126\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 'Mar  6 2013'.
The library build time was '21:55:17'.
The library package version is '5.1.45.0'.
The library component version is '35.34.40.0'.
The controller does not use a programmable FPGA.

An error occurred while hard 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 '-150' (0xffffff6a).
The title is 'SC_ERR_FTDI_FAIL'.

The explanation is:
One of the FTDI driver functions used during
configuration returned a invalid status or an error.

[End]

Meanwhile I seriously think about choosing another brand if it goes on like this. It should not be such difficult to get a controller programmed and with the controllers I used in the past every issue regarding programming was solved within minutes, so one could concentrate on it's own work with the software and don't be bothered with faulty tools.

Hi Florian,

Could be an issue with the FTDI drivers. Please take a look at the below FAQ for a similar error:

http://processors.wiki.ti.com/index.php/XDS100#Q:_I_got_a_-150_SC_ERR_POD_FAIL_error.2C_what_does_this_mean.3F

ki

Dear Ki-Soo,

of course it's a problem with the drivers. That's why I uninstalled CCS and all the drivers that come with it, restarted the PC and installed CCS again completely from scratch. Windows detects it as XDS100 Channel A and B and also displays the virtual COM port by the way.

I can also not remember of any other FTDI drivers being used on that computer. I've simply no idea of whats going wrong :(

Should I try any other drivers or do you have a clue what to try else?

Florian,

You've done things similar to how I would recommend.  A few extra things to check:

1) A jumper at J8 on the Docking Station will remove any chance of having the two FTDI chips battle against each other.  The jumper disables the FTDI on the Docking Station.

2) I have rarely (but have seen) Windows not play nice with an installed FTDI device.  One resolution (other than what you've already done) is to reprogram the FTDI chip.  This will force Windows to reinitialize the FTDI chip as a 'new' device.  To do this run the "program_ftdi.bat" file in the attachment.

3) A CCS installation should install all the proper drivers, but for reference the applicable FTDI driver package is here: http://www.ftdichip.com/Drivers/D2XX.htm

I would try these items in order.  Let us know if any of this helps.

(removed bad attachment - the proper attachment is a few posts further down in this thread - see xds100v2-FT_Prog_v2.2.zip)


Thank you,
Brett

Dear Brett,

thanks for your ideas, seem to at least move the issue :)

1) As I'm not using the docking station anymore but supplying through the micro USB there is no need for disabling the XDS100v1 at the moment. But thanks for that hint, I'll remember once I use the docking station again.

2) This morning I did a reinstall again, not only from CCS but from ControlSuite, too. So both programs should be completely virgin. After that the -150 error was still there, so I tried the reprogramming. This went fine and looked promising, but after restarting (for which Windows asked for after installing drivers for the "new" devices) the error just changed to -151. The VID/PID are also wrong as shown in http://processors.wiki.ti.com/index.php/XDS100#Q:_How_can_I_check_if_the_VID.2FPID_for_the_EEPROM_are_programmed_correctly.3F . Therefore I assume that I have to reprogram the FT2232H again by using MProg and the specified EPT file. Am I correct in that point or will that just bring the -150 again?

Thanks again for your support,

Florian

Florian,

To program the FTDI, I would recommend running the .bat that I included in my last post.  I can specifically say that it is the correct file for programming.  (as you mention there is a way to program the xds100v2 properly through Mprog as well though).

I've found that the -150 and -151 errors can pop up for multiple reasons, so I wouldn't be as concerned with what these specific error codes mean.

A few other things that I forgot previously:
1) make sure that SW3 on the controlCARD is set to 'ON'.  If this isn't true, the JTAG will not connect to CCS. 
2) both the emulator and the MCU have to be powered seperately.  If both LD1 (MCU powered?) and LD4 (emulator powered?) are not lit up then you won't be able to connect.

I'm hoping that this gets you closer to the solution.


Thank you,
Brett

Dear Brett,

I did try to program the FT2232H using your .bat file, but that just erases the chip and complains about a missing file afterwards. As I've seen in your .bat, it needs some .xml file probably containing the settings to program, but in the zip you provided, there was no such file. I therefore used MProg with the file specifically provided for the FT2232H (in contrast to the apparently formerly used FT2232C) found at this url: http://processors.wiki.ti.com/images/f/f8/XDS100_wUART_FT2232H.zip The programming went fine changing the displayed device name in the Device Manager from some serial bridge (after erasing by your .bat) back to XDS100. But as a consequence the error switched back from -151 to -150 (as I suspected).

I double checked the switch position (and switched it off&on again to ensure good contact) and the supply (both LD1 and LD4 light up after connecting the respective supplies), but they are all correct. I even tried if there is an issue with the sequence of the two supplies being connected, but there isn't.

I'll try the whole stuff on a different PC this afternoon. If it works there, it may be some strange driver issue resulting from some other program installed on this PC. If it's neither working there, could the error result from some hardware defect on the controlCARD? Although I've no idea how it should have been got broken, that question decides whether to spend scads of money on a new controlCARD or not :(

Dear Brett,

unfortunately even another PC doesn't change anything. The -150 still persists.

But meanwhile I've discovered a different potential reason: While reading thru the datasheet, I was suddenly scared by the warning message on page 337, informing the reader about the potential lockout of JTAG by changing the respective GPIO config. As the -150 error is the same with an unpowered target (you also mentioned that the reported driver error is not necessarily correlated with a driver issue), I instantly thought about that being the real problem. Although I did not deliberately change the settings of the JTAG pins, that could accidentally have happened while playing around with the two LEDs which are unfortunately also located on PORTC. :(

I then tried to boot from a different source by altering switch SW7, which successfully stopped the LEDs from blinking - but I still cannot access the controller. Actually that would proof that I didn't locked out the JTAG, because if the malicious code changing the I/O config is not executed, everything should be fine. Or am I wrong in that point?

Is it really possible to destroy a complete device by a single faulty line of code?

Dear Brett,

being on hardware level now, I had a look on the JTAG signals with my DSO just to see what's going on there. While executing the "Test Connection" function of CCS, not a single line of the JTAG port on the controller does at least a single movement. That might being caused by the wrong I/O config, I then had a look on the signals on the´other side of the ISO7220 namely the side where the FT2232H is located. There, TMS at least tries to go down for a few milliseconds, but doesn't make it more than about 200mV below it's quiescent level of 3.3V. As long as there is no back current through the ISO7220 inhibiting the line on the other side to go low, which seems improbable because the behaviour is the same with the micro USB and therefore the power for the controller removed (except for the lines on the controler side being at around 0.7V), we are either back on a software/driver issue or the FT2232H is no longer in the mood to drive the lines correctly. By the way the USB lines do change when using the "Test Connection" function.

EDIT: Besides your .bat is working now ;) But unfortunately didn't change the behaviour neither.

Florian,

My instinct is now telling me that this isn't a driver issue.  The FTDI seems to be programming correctly, Windows seems to notice that its an xds100v2 (and sees the virtual COMport), and you've been through this multiple times  and on two computers.

The issue that you mention which involves locking yourself out of the JTAG GPIOs is a real possibility.  Your FLASH code may be configuring the JTAG signals as GPIO inputs/outputs and may be the root cause.  Your logic in looking into the JTAG signals seems valid to me (and may in fact rule out the JTAG-GPIO idea), but I'm not an expert on this and there may be something that explains what you are seeing.  I'll try to get someone else to look into this post as well.  (there's also a possibility that this caution note does not pertain to this part.  I will look into this)

Thanks for your patience on this :)


Thank you,
Brett

Florian,

Update: The caution note you mentioned is not valid and is being removed from the TRM.  This isn't your issue.

Can you try to connect to the device when the boot mode is in Boot-to-M3-Ethernet mode (change the controlCARD's SW1 to down-down-up-up)?


Thank you,
Brett

Dear Brett,

thanks for the update of the GPIO thing, now I don't have to fear any longer that debugging will become horror because of searching the disassembly for any instruction changing portc settings any time you changed something.

I tried to connect with the boot to ethernet setting, but it didn't worked neither. (and of course the leds don't blink with this setting)

Hence I investigated the JTAG signales further: With U20 (the ISO7220 carrying the TCK signal) removed (and therefore it's 750k internal pull-up removed), the ADBUS0 output (carrying TCK) of the FT2232 is only around 2.5V. After resoldering U20 to check your boot to ethernet solution, I then tested the drive strength of the FT2232H by a simple 10k resistor to ground. Surprisingly I *am* able to bring TCK, EMU0 and EMU1 down to low level that way! (But not the other signals like TMS, TDI, etc.) Initially that looked weird because they should all be CMOS outputs and therefore easily be able to drive a 10k load. But the 74HC03 has open drain outputs, so it's evident why the 10k pull-down wins against the 750k pull-up within the ISO7220 on EMU0 and EMU1. (Concerning gate 4 of U59 isn't it good practice to connect unused CMOS inputs either to VDD or to VSS anyway?) However that is neither a cause for TCK being so weak nor for TMS not making it to less than 3V when using the "Test Connection" feature. By the way the supply of the FT2232H is all correct, so this 2.5V thing at the outputs is not a fault on that point. Additionally it might be worth mentioning that TRSTn, TDI, TCK and TMS are physically able to be driven by the FT2232H to a low level. That happens within the first second after connecting the debugger to a USB port. While this time they all stay low except for three short synchronous pulses and then switch to their already known always high level.

Finally one could imagine of some ESD damage, but it sounds strange considering the fact that the FT2232H is programming well and able to drive the outputs low within the first second after connecting.

Florian,

I took a look at a known good cCARD that I have and TCK seems to be at about 3.05V at U20.pin2. My reading is higher than yours which could be a concern, but it seems well within the specs of the isolator chip.

One more thought is to try to remove C276 (if it isn't already removed); this would be useful if you suspect a large delta between the two supplies. Another may be to again try using the Docking Station baseboard to power the MCU side.

From everything mentioned so far I believe your setup is now correct and I'm starting to run out of ideas on why it isn't working. 

If the above ideas don't work, my inclination is to think that either ESD has caused some sort of weird issue or the EVM was only marginally passing QC when it was released.  If you bought the item from TI eSTORE, the following link may be helpful:
https://estore.ti.com/faq.aspx#q5.1


Thank you,
Brett