• State Not Answered
  • Locked Locked
  • Replies 43 replies
  • Subscribers 22 subscribers
  • Views 7015 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Are you using RTX? Can you help me?

Tamir Michael

Hello,

I have a major problem with RTX and Keil don't seem to be able to help (as they want a simple scenario to cause the problem, but I cannot give them the hardware of course. Maybe I can make it go wrong using an evaluation board).
I'm using RTX as the backbone of a product that needs to run for extended periods of time without reboot (weeks...).
The problem is that RTX stops executing arbitrary tasks at arbitrary moments - they remain 'ready' but not get services. Today I discovered a task entering 'WAIT_MUT' while not using ANY mutex. My question: Are there any tips using RTX correctly? I am growing totally frustrated and tired of this, what am I supposed to tell the client?! I'm using latest and so expensive RL-ARM without any results whatsoever.
Can you share your experience with me?

Thanks you for your attention,

Tamir

Parents
  • 0

    I am using RTX also. I was running a test over the weekend and came in to find the system had died for no apparent reason. I ran it overnight again and again and sometimes it would be running and other times it had died (basically running just a single task and ISR in this case). To make a long story short it was the ULINK debugger I left connected to the board. The damn thing cannot remain connected to the PC via USB when running overnight tests, even though it was not being used and my PC was off. The USB was unplugged from the ULINK and the 'problem' disappeared. (BTW: ULINK2 must be completely removed from the board).

Reply
  • 0

    I am using RTX also. I was running a test over the weekend and came in to find the system had died for no apparent reason. I ran it overnight again and again and sometimes it would be running and other times it had died (basically running just a single task and ISR in this case). To make a long story short it was the ULINK debugger I left connected to the board. The damn thing cannot remain connected to the PC via USB when running overnight tests, even though it was not being used and my PC was off. The USB was unplugged from the ULINK and the 'problem' disappeared. (BTW: ULINK2 must be completely removed from the board).

Children
  • 0 in reply to grz bzz

    hmm, I don't think this phenomenon has anything to do with RTX itself - we do keep a ULINK2 connected without a problem. are you absolutely SURE that problem has disappeared? some system's here ran for a week without a problem, others died after 1 or 2 days.

  • 0 in reply to Tamiryan Michael

    Well, the only test I was running was with a SSP as SPI Master interfacing to a single slave and exchanging an identical command/request sequence using Modbus ASCII protocol. No changes were made to the code when I removed the USB connection from the ULINK. It hasnt died since I did this. The frames exhanged were upwards of 2.7 million after a successful weekend run. Before the ULINK was removed I was consistently failing at a fraction of the frames reported. I cannot say that this is your problem but it is another angle you need to consider...

  • 0 in reply to grz bzz

    As I noted above, my issue is resolved already. It was all about addressing FlashFS's SD card driven card from exception mode, as well as a path that locked a mutex from exception mode. Once removed, no hangup were experienced anymore.