You are here

Debugging a ThreadX stack fault on FX3 | Cypress Semiconductor

Debugging a ThreadX stack fault on FX3

Summary: 3 Replies, Latest post by svintech on 09 Nov 2016 07:31 AM PST
Verified Answers: 0
Last post
Log in to post new comments.
svintech's picture
User
3 posts

I'm getting a "5 _tx_thread_stack_error_handler()  0x40030f44" in my application, under load (while doing something).  I can't find anything on how to debug these.  I have 3 threads in my app and I checked to the stack on each of them, looking for the constant that the system stack checking places in each one so I'm pretty sure it's not a simple stack overrun.  

According to the documentation I could find from ThreadX online, the stack checks are for top/bottom of the stack area and making sure my stack pointer is "in" range so I'm guessing that my stack pointer itself is corrupted (not pointing into the stack space).  I explored the possibility of adding a "CyU3PThreadStackErrorNotify" handler to my threads but this doesn't seem to be supported in the version of ThreadX being used here in the Cypress environment.

Is there any more information I can get from the debug tracing on this?  (added a screen shot of the fault).  It would be handy to mail it down to a specific thread.  The call stack in GDB simply shows me function calls that are not available to me at the source level (I have no access to source.

I'm not asking for someone to debug my code for me, just some clues.  If someone could point me in the right direction I can do my own leg work.

Thanks, 

John Svinicki

Firmware engineer

 

 

 

nisa's picture
Cypress Employee
85 posts

Please try by starting afresh. Please terminate all the active debug configuration  and then  Please use the attached link to debug step by step using Zylin http://www.cypress.com/file/134361/download

 

svintech's picture
User
3 posts

Nishant - Thank you for the quick response.  I will review the document you referenced carefully but it is marked as "obsolete",  Am I supposed to be doing exactly what it says or are you trying to point out that I have not setup something correctly or are using old tools?

I didn't get much background on this:  I'm currently running on a Cypress FX3 Super Speed Explorer board which is married to a prototype daughter card but the identical problem exists in our final design which is a single board.  I have used this debugger quit a bit over the last 2 years and it has been very useful in finding and fixing a number of problems.  Prior to the testing the scenario that generates the bug, I can set breakpoints, single step the program, inspect memory, etc and the debugger works great.  After the bug happens, I have little to go on for a post mortem.  The debugger will pause the program and I can inspect memory and check some things but execution is essentially halted in this "stack check" fault code.

What I really need to know is which "stack" is the offender?  There are 3 threads I create in the application.  If I knew which one was at fault, that would be helpful.  

Perhaps the answer is in the document that you references, I will review it and get back to you.

Again, thank you for your quick reply.

John Svinicki

Firmware engineer, 

Xitron, LLC, 

Cubic Labs, 

 

svintech's picture
User
3 posts

Nishant - 

I'm sorry, the referenced document was not helpful.  It describes setting up the debugging environment for a "EZ-USB® FX3™ Development Kit (CYUSB3KIT-001)" using the Olimex or Seeger JTAG interfaces.

I am using the "CYUSB3KIT-003 EZ-USB® FX3™ SuperSpeed Explorer Kit" with onboard JTAG and already appear to have the debugger correctly configured and running.

Would it be possible to get source code or documentation for the following library functions:

 _tx_thread_shell_entry(),  _tx_timer_thread_entry(), _tx_thread_system_suspend(), and _tx_thread_stack_error_handler()?

I might be able to build these into my system (in lieu of the library object code so I could source level step through these?  There may be a reference somewhere to the CyU3PThread structure (as a passed pointer) so I can tell which thread is causing the error.

Regards, 

John Svinicki

 

 

 

 

Log in to post new comments.