Home/Support/Support Forum/RCM3400 TX/RX to XT09 is crash with Time out waiting for respond
New and improved user forum site going live on 12/6 (All users will need to reset their password when the new forum is active)
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

RCM3400 TX/RX to XT09 is crash with Time out waiting for respond

0 votes
RCM3400 TX/RX to XT09 is crash with Time out waiting for respond .
I have a RCM3400 runnibg port C at 9,600 bout and port D running at 19,200 bout.
1. The port C connected by wire to the computer running win 7 or 10 and function ok.
2. The port D function ok and TX / RX no problem at 19,200 bout with X-CTU or HyperTerminal and crash when TX or RX is connected to XT09 radio transmitter.
3. The device XT09 is tested as stand alone and in MaxStream devises with each other and are communicating ok
4. What can cause the crash with Time out waiting for respond. No error indication in software to trace it.
5. How to trace it where is the crash if I'm using 3 tasks and transmit or receive are performed in first task.
6. I put a simple test to transmit from Task1 message "Hello Word \r\n" and it is sending the text ok to the receiving XT09 that is monitoring the transmission.
And after transmuting the "Hello World" the RCM3400 is crashing with the massage "crash with Time out waiting for respond .".
asked Jun 28, 2016 in Rabbit Software by kosta45 New to the Community (2 points)

Please log in or register to answer this question.

1 Answer

+1 vote
That error message sounds like the debugger is losing its connection to the RCM3400.

You might want to write a simple test program to run on your hardware to confirm correct wiring. Without multiple tasks, just open the serial port and relay data between STDOUT and the XT09. Once that's working, try to integrate that code back into your main program with the multiple tasks.

Other options: Can you just run Task1, with the other two tasks "on hold"? Can you single-step through Task1 using the debugger to see what's happening?

Based on the crash, you're likely overwriting memory, overflowing your stack, or possibly even reconfiguring serial port A (with a serAxxx call instead of serDxxx).
answered Jun 28, 2016 by TomCollins Veteran of the Digi Community (2,382 points)
Thank You Tom,a systematical eliminating the step by step help.