Network Debug Error - Connection Refused

[dacoast]

I am currently unable to get the debugger to launch successfully for my application.
I am using a 5272, Rel22_rc2.
I have had the debugger working with this application previously, but it seems to stop working for unexplained reasons.

The current problem occurs when trying to launch the debugger:
"Error creating session: 10.0.2.6:2159: No connection could be made because the
target machine actively refused it.

The application is calling InitializeNetworkGDB_and_Wait() and the monitor
window shows that the application reported: "Initialized GDP tcp" and
waits there.

A wireshark capture (filtered for the target ipaddr) shows the following exchange...
From To
4667 21.213012 10.0.1.17 10.0.2.6 TCP 1369 > 2159 [SYN] Seq=0 Len=0
MSS=1460
4668 21.214100 10.0.2.6 10.0.1.17 TCP 2159 > 1369 [RST, ACK] Seq=0 Ack=1
Win=0 Len=0
4669 21.214114 10.0.2.6 10.0.1.17 TCP 2159 > 1369 [RST, ACK] Seq=0 Ack=1
Win=0 Len=0
4670 21.214119 10.0.2.6 10.0.1.17 TCP 2159 > 1369 [RST, ACK] Seq=0 Ack=1
Win=0 Len=0
4740 21.661993 10.0.1.17 10.0.2.6 TCP 1369 > 2159 [SYN] Seq=0 Len=0
MSS=1460
4741 21.663058 10.0.2.6 10.0.1.17 TCP 2159 > 1369 [RST, ACK] Seq=0 Ack=1
Win=0 Len=0
4857 22.163589 10.0.1.17 10.0.2.6 TCP 1369 > 2159 [SYN] Seq=0 Len=0
MSS=1460
4858 22.164649 10.0.2.6 10.0.1.17 TCP 2159 > 1369 [RST, ACK] Seq=0 Ack=1
Win=0 Len=0

Thanks for any help...
-Doug

[rnixon]

I think that "actively refused" means the debugger could not get a response from the device, but there is some device at the IP address you specified. Do you have a way to verify the IP address of the netburner is the address specified in the debugger? In other words, could you be using dhcp, and this time around the netburner received a different address than before?

[dacoast]

Yes, I am using DHCP to assign the Netburner address. But it is setup to always assign the same IP address based on
MAC Address.

I did make some progress in getting the debugger to connect!
It appears that it was taking too long for the DHCP server to assign the IP address, and the debugger wasn't waiting
long enough before trying to connect. I was able to bypass the problem by switching back to the "standard" DHCP call or
by assigning a fixed IP address to the Netburner module.

So... , further questions.
1) Can I change a setting somewhere to control when the debugger attempts to connect, or how long it will try?

2) If I load the debug code via autoUpdate and want to connect at a later time with the debugger, can this be done?
The debug command from the menu seems to always try and reprogram the Netburner before connecting.

Thanks,
-Doug

[Forrest]

1) Can I change a setting somewhere to control when the debugger attempts to connect, or how long it will try?

2) If I load the debug code via autoUpdate and want to connect at a later time with the debugger, can this be done?

1) This is possible. To change the wait time before attempting to connect to a board, go to your run configuration that is being used to load the code on the board. Go to the debug tab, and in the debug tab window, you will see an option to go to the Extra tab. In this tab, you can change the Reboot Wait Time. The default is 4 seconds, but you can extend this to any number. I would not recommend shortening it.

2) This will be possible in Rel23_rc1, which is being uploaded to the server today. Once you update to the new version, this option is under right click on project and select properties. Under NetBurner Options, there is a check box that says 'Bypass Application Load during Debug Builds'. You can toggle this on and off when you need it.

[ellisonsoftware]

I am also having some problems getting an NBEclipse (Rel23_RC7a) Debug session up and running with a MOD5234 and the 'tictactoe' example application.

I've manipulated the settings under the ~Debug_Configurations-->Debugger-->Connection tab:

- TCP:2159 indicates the connection is refused
- Serial or Speed Serial (with the FastSerialDebug app running) indicates "Malformed response to offset query, qOffsets"

I can successfully use the scantask utility on the TCP address
I can successfully use the MTTY utility to connect to the board via USB. Note I did disconnect the MTTTY when trying the Serial Debug.

Toggling the Properties-->NetBurner Options-->Bypass application load during debug builds and using AutoUpdate to load the DBtictactoe_APP.s19 file makes no difference...and I have the reboot wait parameter set at '30'

Any helpful suggestions appreciated!