smit12345 wrote on Wednesday, June 17, 2009:
I am facing the problem of FreeRTOS freezing up. My windows application sends a random stream of data using USB HID interface. After a count of 3096 transactions the RTOS freezes and stops responding. Can anyone help me out in debugging the problem.
1. Embedded Processor: AT91SAM7X256 with GCC
2. Host : Windows Host
3. Interface : USB
rtel wrote on Wednesday, June 17, 2009:
If you are using the USB HID that comes with the (very old) FreeRTOS demo then I’m afraid its not a fully tested or fully compliant driver, but just an example. You will have to debug the application to determine the cause. Alternatively WITTENSTEIN provide tested and supported USB drivers, but these are commercially licensed.
Regards.
smit12345 wrote on Wednesday, June 17, 2009:
Thanks for your positive response.I have not used USB HID comes with FreeRTOS demo. I have develop my Own USB HID device on FreeRTOS.In fact Device can send and receive data up to 3099 transjecation after then Device Stops the responding. I can not Debug the code .
smit12345 wrote on Thursday, June 18, 2009:
Hi Richard ,
Waiting for your replay. I have purahsed both the e-book also but I didnot find any kernal internal detail and debugging method of FreeRTOS kernal. SO Pl. Guide me how to solve above mentioned problem.
rtel wrote on Thursday, June 18, 2009:
Well the first thing to determine is where the program ends up when it freezes. In a data abort? If its in an exception handler then you can work out what the program was executing when the exception occurred - but this is ARM7 specific debugging, rather than FreeRTOS debugging.
Regards.
smit12345 wrote on Friday, June 19, 2009:
As told by you I have tested all the exceptions and data abort but no exceptions were generated and the OS freezed, as a result I was not able to ascertain where the application the freezing was happening… Is there any other method or tool to get to the root of the problem.
davedoors wrote on Friday, June 19, 2009:
If its not executing an exception, what is it doing? What is being executed when you stop the debugger?
smit12345 wrote on Saturday, June 20, 2009:
Most of the time its not possible to use a debugger to debug an USB application. I used RS232 and hyperterminal to debug most of the application. Is there any way to know what the O/S or application was doing before freezing up?
smit12345 wrote on Saturday, June 20, 2009:
Hi Richard,
By disabling configUSE_TRACE_FACILITY by setting the value to 0 in FreeRTOSConfig.h my application executed for 3186 times as against the previous count 3096. Is there any relationship between this macro or any other macro which freezes my application?
Rgds.
smit12345 wrote on Wednesday, June 24, 2009:
Hi Richard,
Waiting for your replay…
Regards
smit thakkar
rtel wrote on Wednesday, June 24, 2009:
I sent a reply to the email you sent to services at freertos.org.
smit12345 wrote on Wednesday, June 24, 2009:
Hi Richard,
Actually my mail server was down from last two days so can you mail me on xxxx@xxxx.com
helarsen wrote on Thursday, June 25, 2009:
Yes debugging usb can be difficult but as mentioned on www.osronline.com/ (article:"USB Analyzer Shoot-Out" you need to be registered to read) usb protocol analysers are now available at prices down to $600. Such a device will at least allow you to tell what transactions went on to the bus. This can potentially save you a lot of debugging time.
regards henning
incrediball wrote on Thursday, June 25, 2009:
Just one question: why do you want other people to do your work for you? Chances are that it is your own program that is freezing up and not FreeRTOS. FreeRTOS is not running in a protected kernel so if your program does something invalid, it will bring down everything.
Reasons for a program to freeze up include but are not limited to:
1. interrupt not being cleared
2. interrupt calling an invalid FreeRTOS instruction such as one that internally uses critical sections.
3. memory corruption, includes stack overflows, invalid pointers, buffer overflows, race condition, etc.
4. idle thread is blocked, e.g. because of a delay.
5. deadlock
There’s more: search the forum and faq.
arpitmehta wrote on Wednesday, July 01, 2009:
Hi incrediball,
Thanks for Your Reply. I donot want my work is soveld by other person. but it’s not my issue. So Pl. Refer my earllier post. Try to understand I have all ready worked on your suggested steps.
So Pl. guide me. What Can I do for solving the problem?
FYI: I need help . I donot like anybody is working on my behalf.
incrediball wrote on Wednesday, July 01, 2009:
Why is it not your issue? Of course it is, or do you presume that your program is 100% error free?
It is easy to blame the tools that one has to work with. However experience has taught me that it is almost always the way how the tools are used, that determines the outcome. In other words, don’t blame FreeRTOS for your hanging program unless you can prove that FreeRTOS is hanging. Since you do not know where and why it is hanging, you can hardly claim that it is not your problem.
We can only hint at what the problem might be, especially with the vague information that you have provided (which I have read). The things that I have listed are only some possibilities but there are many others. Start with finding out where the program is hanging. Since it hangs after only 3096 transactions then that is very easy to reproduce (worse is something that happens randomly once a day or so). You may find a debugger helpful but personally I never bother as I have found them to be more trouble than they’re worth on embedded systems. I prefer to provide feedback through logging, displays, LEDs, etc.