Working from a guess here as I don't have traceX installed BUT.... I've got 2 threads working on 3 devices on the same I2C bus. One thread (Audio) is set at priority 1. The other thread is at a much lower priority. I've got a situation where there appears to be a deadlock with inversion of thread priorities or some such thing (again, I have no trace that tells me what the exact order of events here was, but I'm pretty sure it's the way I'm thinking. The state of the threads in question: The audio thread is set up as: The pressure thread is set up as: The audio thread is calling the write with a TX_WAIT_FOREVER while the pressure thread is calling the read with a wait of 2. But it looks like a deadlock to me. Nothing on the I2C bus in question at all; dead quiet out there. So any hints as to how to get around this? I was assuming that if this happened, that it would break the deadlock by the pressure thread timing out or ThreadX boosting priority on something to break it. Apparently that isn't a great assumption. Second, I can't follow the stack walkback very far without it running out of code to look at. If I include the source for ThreadX can do I that without it being set up differently than the default values the binary one is set for? Thanx rjl
↧