• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 55 subscribers
  • Views 721 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Connection-Refused-Error because of incorrect IP address (Debug Test Controller configuration utility)

Niklas Winter
Prodigy 120 points
Other Parts Discussed in Thread: TMS320C6678

Context:

I implemented an Ethernet-based test automation framework for testing my modules on the TMS320C6678 board from remote. The test framework includes a test server, a "Blackhawk XDS560v2 System Trace" and the TMS320C6678 board. The test procedure works as follows:

  • At the beginning, we collect all test binaries.
  • My test server connects to the "Blackhawk XDS560v2 System Trace" via Ethernet
  • Each test binary is uploaded to all cores.
  • After one binary has been uploaded to all cores, we start all cores simultaneously   

Problem:

In general, my test automation framework works smoothly. However, from time to time, I have got one problem regarding the connection. I get the following error:

E_RPCENV_IO_ERROR(-6) No connection: Error on socket connect: Connection refused (ECONNREFUSED): Check the IP address
ERROR: 14 : remote procedure call failed : failed to open the DTC configuration service for url sd560v2e:-1408236848

Apparently, my IP address is screwed up from time to time. So far, I have checked some potential error sources:

  • Checked network parameters
  • Checked power supply of blackhawk emulator 

I have noticed one inconsistency, namely, why I must use "sd560v2e" instead of "bh560v2e" as IO adapter when using the "Debug Test Controller configuration utility". I would assume to use the "bh560v2e" as IO adapter if I use the "Blackhawk XDS560v2 System trace" as an emulator.

Question:

Why is my IP address corrupted from time to time? Is it due to a wrong firmware we used (See the inconsistency I have noticed)