While Sending User Program: Timeout while waiting for response from target.

Rabbit
1

I am using an RCM3309 with the Rabbit 3000A CPU and Dynamic C 9.62.

I have the above error reported when I “Compile using compiler preferences (F5)” my code, when the project is configured for debugging (Compile to flash run in RAM, RST28 instructions enabled, Kernel debug enabled, debugger settings set as per attached JPEG screenshot). The error is displayed immediately after what appears to be successful completion of the upload to the Rabbit (i.e. byte count uploaded matches total byte count) and before the debugger can get control to stop at the first line of main() (the normal point at which the Dynamic C environment returns control to the user after a compile with debugging enabled).

During the upload of the compiled code, the status bar at bottom of the Dynamic C window reports “Sending Write Packet”, then at the end of the upload, this changes to “Communication error” and a pop-up dialog appears with the above error message. When I dismiss the error dialog, I can not proceed with my debug session, since the debugger has lost communication with the target (yet the debugger connection seems to have remained open, as the “Run” menu has the “Close connection” entry available).

When I make one of the following changes to the project/code, the problem is no longer present:

  1. Temporarily remove any one of my .LIB modules (i.e. to reduce the size of the code).
  2. Change the compiler settings to optimise for size rather than for speed.
  3. Change the debugger options to disable Execution Tracing.

The symptoms and workaround seem to suggest that I am tripping over some segment/region/stack size boundary, but I’ve checked the region sizes and stacks and I cannot see that there is any likelyhood of such a boundary overflow.

I’ve seen postings around web suggesting that I should try adjusting serial connection related settings in the Dynamic C Default.dcp file, which I have tried (increased the serial connection timeout value), but this produced an odd effect of reporting a different error, equally confusing and unrevealing).

I’m thinking the answer to this issue lies in understanding exactly what the Dynamic C environment is doing when it switches from uploading the code to beginning the debug session.

Can anyone provide any insight into the above problem?

TIA

Dave