Dynamic C target connection problem on Windows 10 computer

Question

Dynamic C is being used on a Windows 10 machine for a project using the RCM6700. All has been going well until Windows 10 was automatically upgraded. Since then it has not been able to make a connection to the target. A second portable that has been used for years building applications for Rabbit processors now also cannot connect to the target.

The COM port Latency Timer was changed to 2 msec in both computers but this did not help. This connection issue has been around for many years but it was always solved by reducing the latency.

Any ideas as to what could be done to get Dynamic C going again?

Answer 1

Part of the problem was on the adapter board on which the rabbit connector was mounted. After fixing this, 10.72C on the Windows 10 machine did compile and save the program in flash. However, it would not start debug execution. It was hung trying to communicate with the target.

To isolate the problem different programming cables and a number of RCM6700's were tried. Nothing helped.

Finally, 10.72C was uninstalled and reinstalled (using typical install). After setting the project options again, it does now have debug control. It looks like the Windows 10 upgrade caused some problem with the installed 10.72C software.

Answer 2

Hello the Latency issue usually fixes this problem. Did you uninstall the previous version, then reboot the machine after you install and change the latency on the port?

Answer 3

Are you sure that nothing changed with the RCM6700 configuration? Are you testing in your own hardware or a development board?

If a development board, make sure you have the jumper closed on pins 1-2 of JP1 (SMODE->3.3V).

Can you load a compiled binary to the board with RFU?

What release/version/build of Windows 10 (run "winver")?

Comments

The latency was fixed for the port.  Windows 10 Version 2003 (OS build 19041-450).  A windows speed-up was run and now a binary can be loaded including with RFU.  When debug is started, it runs for about a minute then loses connection with the target.  Remember, this was all going well on the same hardware prior to the windows upgrade. Since I don't need the debugger anymore on this project, it is no longer a blocking issue.

---

It was odd that the failure affected the "second portable" used for years cannot connect to the target.  I would check for possible code changes that break the connection to the debugger (disable interrupts, reconfigure serial port A and/or pins used in debugging, etc.)  If you compile your program to the target but do not run it and it's OK but fails after you run it, then something in your code is crashing the debug kernel on the device (and you might be able to single step your code to figure out where it happens).  Or it's something with the programming cable?