"Failed to retrieve the Wait in Reset Mode" error message from ccs 3.3

I will look around, but I think the "Wait in Reset" mode is for the C28x family so this may be improperly selected somewhere in either your CCSetup configuration for the BH or your CCS default settings. Which BlackHawk model do you have: USB560bp (bus powered), USB560m (one LED), USB560m (two LEDS)?

An easy thing to try is to bring everything up like this:

1. Close CCS.
2. Power off the board, disconnect the BH USB cable, and remove the power from the BH (if you have that).
3. Reapply power to the BH, connect the USB cable, then power on the board.
4. Run the BHreset_USB560*.bat in a folder like C:\CCStudio_v3.3\blackhawk\Utility\BHProbe.2 . If it reports errors, we will need to dig further there, but it will probably just do a good reset and report no errors.
5. Open CCS, Debug->Reset emulator, then Debug->Connect (or Alt-C).

This should be past the point where you were getting the error before. If you get the error, post back with where in this process the error comes up.

In Tools->Customize / Debug Properties, you would want to have "Connect to the target at startup" unchecked while debugging a problem like this; re-check it later if you want after everything is working again. If there are connection problems, it could also be helpful to change the name of OnTargetConnect() to xOnTargetConnect() in your default GEL file just to prevent anything extra from running until you know what the problem is.

Please let us know if this gets you any farther, or where the problem hits and where the message is displayed.

I performed steps 1 through 5 and had  no reported errors.  See the message below.  My attempt to connect failed again with the same failure message.  I changed the name of the OnTargetConnect() and I even commented it out and still no change. 

In my system I have 4 DSPs in a chain and the last two DSPs are failing to connect.  I have no issues with the first two.  I have attached a pdf of my ccs screen and the error message I am getting. .I first get the "Failed to retrieve the Wait in Reset Mode"  and then the message in the pdf file.

================================================================

C:\CCStudio_v3.3\Blackhawk\Utility\BHProbe.2>call BHprobe_USB560m.bat
Results in file: log\BHprobe_USB560m.log
bin\XDSProbe.exe -v -F BH560USBm.out -p0x0 -r -o log\BHprobe_USB560m.log...

SUCCESS: Command reported no errors.
Results in file: log\BHprobe_USB560m.log
bin\XDSProbe.exe -v -F BH560USBm.out -p0x0 -i -o log\BHprobe_USB560m.log...

SUCCESS: Command reported no errors.
Results in file: log\BHprobe_USB560m.log
bin\XDSProbe.exe -v -f bin\bh-noscantest.cfg -F BH560USBm.out -p0x0 -i -o log\BHprobe_USB560m.log...

SUCCESS: Command reported no errors.
Results in file: log\BHprobe_USB560m.log
bin\XDSProbe.exe -v -F BH560USBm.out -p0x0 -g -o log\BHprobe_USB560m.log...

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

=====================================================================================

I forgot to mention that I am using the USB560M with two LEDs.

Quince Jackson said:

when trying to connect to a TMS320C6455

Connecting to four C6455s is different that the first posting. Please post your .ccs file or email it to me privately. If you have not exported your configuration file yet, in CCSetup go to File->Export and give it a nice name like BH560m_C6455x4.ccs.

Quince Jackson said:

I performed steps 1 through 5 and had  no reported errors.  See the message below.  My attempt to connect failed again with the same failure message.  I changed the name of the OnTargetConnect() and I even commented it out and still no change. 

In step 4, the batch file was BHreset_USB560m.bat, but BHprobe_USB560m.bat does that plus more. Please post your log file from that BHprobe run.

Step 5 included connecting which seems to be where you are getting your errors but that is still not totally isolated. In PDM, please make sure Options->Connect System on Startup is unchecked so things do not happen before you intend for them to. And in your GEL file, make sure the Startup function is also commented out or renamed along with OnTargetConnect(). Now, let's expand the steps to go through to

1. Close PDM.
2. Power off the board, disconnect the BH USB cable, and remove the power from the BH.
3. Reapply power to the BH, connect the USB cable, then power on the board.
4. Run the BHreset_USB560m.bat in the folder C:\CCStudio_v3.3\blackhawk\Utility\BHProbe.2 .
5. Open PDM.
6. Double-click C6400PLUS_0 to open a CCS window.
7. In that CCS window, click Debug->Reset emulator.
8. Now do the Debug->Connect (or Alt-C). Note any results in output windows at the bottom, or any error messages.
9. Close that CCS window.
10. Repeat steps 6-9 for each C6455 one-at-a-time, closing CCS (not PDM) after each has connected.

Steps 2-4 are sometimes necessary when things start going really bad. Once we get it working, they may not be necessary everytime you want to start emulating.

Here is the ccs file.

Everything looks fine in the .ccs file, at least viewing it in CCSetup.

Do you have the BHprobe log and result of the one-at-a-time steps from above?

Here is the log file.  I am working on the steps outlined above.

DSP0 and DSP1 connected and DSP2 and DSP3 failed to connect.  The messages received are shown below

.============================================================================================================

DSP0 Log Window Results - GEL StartUp Complete.

DSP1 Log Window Results - GEL StartUp Complete.

DSP2 Log Window Results - Failed to retrieve the Wait in Reset Mode
A fatal error occured while attempting to remove the remaining debug state that could not be removed at disconnect.  This might have occured because a breakpoint was set at an address that is no longer valid.  This behaviour may be turned off in the "Debug Properties" tab in the Customize dialog under the Option menu.

DSP3 Log Window Results - Failed to retrieve the Wait in Reset Mode
A fatal error occured while attempting to remove the remaining debug state that could not be removed at disconnect.  This might have occured because a breakpoint was set at an address that is no longer valid.  This behaviour may be turned off in the "Debug Properties" tab in the Customize dialog under the Option menu.

Okay, this is getting tough, now. At least we know the scan chain is good, or your would not be able to connect to anything, and the configuration should be good since DSP0/1 work and they are duplicates of DSP2/3. Here are new comments or things to try:

1. Sort of a desperation test would be to replace DSP2 with a BYPASS=6 and see if you can get to DSP3. Then try the other way around. I doubt that either of these would give any worthwhile results, but they are not too hard to try and could point to something new.
2. There is nothing I can find in the C6455 datasheet that indicates we have a wait-in-reset mode. Some of our DSPs do, but the C6455 has the 'no boot' option which would really benefit from the wait-in-reset, but it does not appear to be there.
3. Before trying to connect, see what you have set in the "Debug Properties" tab in the Customize dialog under the Option menu. Under "Target connection actions" you should already have "connect to the target at startup" unchecked. If "Remove remaining debug state at connect" is checked, try unchecking it, OK, then try to connect. This might only postpone the problem rather than solve it, but even then we would know more about the problem.
4. Check the state of the EMU0 and EMU1 pins on DSP2 and DSP3. They should both be high. On some devices, either 10 or 01 implemented a wait-in-reset state. I cannot imagine this exists but is not documented anywhere, but it is definitely something to check. Also, check the reset pins, PORn and RESETn, plus clocks in and out, just to make sure where the problem is not. And look at all the emulation pins, too, for noise of bad levels.
5. The next thing will be to play with the TCK speed and polarity in CCSetup. Right-click/Properties on the Blackhawk... line in CCSetup's left-hand pane. Then on one of the tabs you will have some choices to make for the clock. I have not run into this issue with the C6455 needing to run slower, plus the BH is very good about adapting to the clock speed that can be handled.
6. Do you have multiple boards with this same problem? In other words, could it have to do with the board fabrication rather than the emulation?

After these, we may know more for the next road to take.

Hi :

 I encounter the same problem, what the solution of the problem at last?

xiaoyan bian