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

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.

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 .

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.

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.

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.

If its not executing an exception, what is it doing? What is being executed when you stop the debugger?

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?

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.

Any one Can Help me.??????

Hi Richard,
Waiting for your replay...

Regards
smit thakkar

I sent a reply to the email you sent to services at freertos.org.

Hi Richard,

Actually my mail server was down from last two days so can you mail me on smit.thakkr@gmail.com

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

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.

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.

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.