Blackhawk problems after updating CCS4

Matthew,

Have you tried updating your Blackhawk drivers?  I have found that a number of 510 class emulators have required driver updates after updating to 4.1.3.  I believe Blackhawk has new drivers available that fix this problem.

Regards,

John

John,

Blackhawk driver version is 4.1.3.5.

Software update feature of CCS does not come up with newer driver. Everything is up to date.

However... Going to "Help -> Software Updates -> Manage Configuration" shows that besides 4.1.3.5 also driver version 4.1.3.1 is installed. Can this cause any conflicts and how do I make sure the newest version is used?

Matthew,

The manage configuration dialog will show all the versions that have been installed but in reality you only have one version of the BH drivers as they get overwritten.

4.1.3.5 is the latest version

I have an install that still has the 4.1.3.1 BH drivers.  I will try my BH510L (similar emulator) before and after the update to 4.1.3.5 to see if I can get the same error.

John

My BH510L is working fine with F28035 before and after the BH driver update.  I don't have access to a USB2000.  I will see if I can pull in someone from BH to help out.

One thing to try:

• unplug the USB2000 and plug it back in
• go to \ccsv4\emulation\Blackhawk\Utility\BHProbe.2 and run BHreset_USB2000.bat

John

BHreset_USB2000 shows :

Results in file: log\BHreset_USB2000.log
bin\XDSProbe.exe -v -F bhemutbcl.dll -p0x0 -r -o log\BHreset_USB2000.log...

SUCCESS: Command reported no errors.
Press any key to continue . . .

and BHprobe_USB2000 utilities shows :

Results in file: log\BHprobe_USB2000.log
bin\XDSProbe.exe -v -F bhemutbcl.dll -p0x0 -r -o log\BHprobe_USB2000.log...

SUCCESS: Command reported no errors.
Results in file: log\BHprobe_USB2000.log
bin\XDSProbe.exe -v -F bhemutbcl.dll -p0x0 -i -o log\BHprobe_USB2000.log...

SUCCESS: Command reported no errors.
Results in file: log\BHprobe_USB2000.log
bin\XDSProbe.exe -v -f bin\bh-noscantest.cfg -F bhemutbcl.dll -p0x0 -i -o log\BH
probe_USB2000.log...

SUCCESS: Command reported no errors.
Results in file: log\BHprobe_USB2000.log
bin\XDSProbe.exe -v -F bhemutbcl.dll -p0x0 -g -o log\BHprobe_USB2000.log...

SUCCESS: Command reported no errors.
Press any key to continue . . .

Hi Mathew,

We would have expeted the USB510L to generate the same error; it uses the same 28x files.   We are looking into this.  

What version of CCS did you upgrade from?  (I am assuming that you had v4.1.2 or something previoulsy installed and updated to 4.1.3.00038...and did not install v4.1.3.00038 from scatch on a clean system).

Andrew

Hi Andrew,

I upgraded from 4.1.2.00027 to 4.1.3.00038.

I think I have nailed the issue.

"Enable silicon real-time mode" was enabled in "Generic Debugger Options -> Real-time Options". If this is enabled while Blackhawk connects to ControlCARD it fails. When not enabled while connecting, all is going well. When programmed and ready to debug, I can enable silicon real-time mode again and it works. I just have to make sure I disable it before loading new software.

Although I can continue working on my project now, I think it is a good idea to fix this "feature" in a future CCS release.

Thanks for all the help.

Regards,

Matthew

Mattew,

That must be it, and why we could not duplicate the error.  There are other posts with the same resolution to disable real-time mode. http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/51390/182664.aspx 

I agree that this should be corrected because the error does not indicate the problem.  Hopefully, at a minimum, an error message could be generated for the modes that are not supported when real-time is enabled.  For example, when you do a Program Load it would check that real-time flag first, or when you set the flag, it warns you about loading the next time.

Thanks for following through on this to find the cause.  I'm sure this thread will be beneficial to other users.

Andrew

I agree that this seems to be something that needs to be cleaned up.  Andrew thanks for following up on this.

I am having trouble reproducing the same scenario.  I want to nail it so we can work with the team to make it work smoother.  

If I put my device in real-time mode I don't get an error on connect but I do get one when I try to flash my program.

Here is what I am doing:

• I launch a debug session.  Put the 28x into real-time mode in the Generic Debugger Options.  I click the button at the button so that it will remember my settings and put the device in real-time the next time I launch a debug session.  (I have also done this by right clicking on a project, selecting Debug Properties and accessing the options that way to see if it made a difference).
• Terminate my debug session.
• Launch the debug session again.  I can see that the real-time buttons are enabled.
• Click on the connect button and it connects fine.
• However if I try to flash my device now I get an error about not being able to write to the target.  If I take it out of real-time mode I can flash ok

I would like to reproduce the error you get on connect.  Can you let me know what GEL file your target config is using?  I am wondering if it has some code in the OnTargetConnect() function that is triggering the error.  You can see the list of loaded GEL files by going to Tools->GEL Files when you are in a debug session.  One solution would be to have the GEL check for real-time mode, disable it if needed and then enable it again after the accesses.  I can update the GEL file to do that if that is the case.

John

John,

Maybe I incorrectly stated that the error occurs while connecting. "Connecting to target....." was the last message seen by me before the error popped up, but it might have connected just fine and failed on the start of writing to the target. I always just click the "Debug launch" button and do not individually connect and program the device.

I don't which .gel file I use, and I don't know where to look (still learning my way around CCS), but I'm pretty sure it's the default file for the 28035.

Regards,

Matthew

I just realized the error message says "Error connecting to target" so it must be a connection error.

I can confirm that I use the TI delivered "f28035.gel".

Matthew,

Based on the error message I think for you it really is failing on connect.  My error message is quite a bit different.  

To see which GEL file is being loaded do the following:

• Start the debugger
• Go to the Tools menu and select "GEL Files".  This will open the same view that shows the debugger options but will have GEL files selected on the left
• All loaded GEL files will now be listed.  For me I just see f28035.gel listed.  That file doesn't seem to do anything special on connect other than a Reset and it checks real-time mode before doing that.

If it is a different file it would be great if you could attach it to the thread.

I have a GEL file now that disables realtime before the load/flash and enables again afterwards that seems to work.

Thanks,

John

Never mind.  I missed your last message.  I am going to attach my GEL file

6646.f28035.gel

Earlier I mentioned I could continue working again with the "Enable Real-time mode" disabled but now I experience the same errors again. I checked and this time real time mode is disabled for sure. I also never get the "Rude Retry" option which, in the previous case, always solved the problem.

- Tried the GEL files posted by John: Same issues.

- Tried TI's example program "Example_28035_Flash": Same Issues.

- Tried moving the ControlCARD from my custom PCB to the TI docking station with the Blackhawk USB2000: Same issues.

- Tried ControlCARD on TI docking station connected via onboard USB (XDS100) to a different computer: Same issues.

I now suspect that my ControlCARD is causing this. Is it possible that the ControlCARD's FLASH memory is corrupted somehow, so that no debugger can connect to it?

The first error I get is :

Error connecting to the target:
Error 0x80000200/-1041
Fatal Error during: OCS,
Device driver: Problem with the Emulation Controller.
It is recommended to RESET EMULATOR.  This will disconnect each
target from the emulator.  The targets should then be power cycled
or hard reset followed by an emureset and reconnect to each target.

And then after pressing Retry :

Error connecting to the target:
Error 0x80000240/-233
Fatal Error during: Initialization, OCS,

loops forever.

Regards,

Matthew