NetBurner Community Forum

I've had a situation for a while on my MOD5270 where one of my threads would lock up.

I have multiple OSTasks running that send iprintf and writestring to the same UART for debug logging. I think one of them hitting at the same time maybe what is causing the thread to lock up. Has anyone else run into this before? If so, what's the best way for handling it with debug logging statements?

Thanks.
Scott

I would suppose from my experience using them (a tad better than a guess) that they are re-entrant but not thread safe. That is, you can call them from multiple tasks without issue but if you're using shared data YOU must guarantee the thread safety. (For the sake of this discussion Thread is synonymous with Task).

Yep thread = task for me here

So what I've been seeing is that I occasionally am getting what appears to be a lockup of a thread. In fact it just seems to be access to UART0 from a particular thread.

I understand data can change underneath between threads, since it is read-only for iprintf and writestring statements does that really matter?

Here's a bit more detail in what I've got going on. I receive UDP data in 1 thread. I have a 2nd thread that parses that data and puts it a queue. I then have a 3rd thread that pulls the data from the queue and spits it out the serial port. UART0 is the serial output port. UART1 is my debug port.

I do iprintf() debug statements in the 2nd thread and then 2 writestring() in the 3rd thread that is sent to both UART0 and UART1 back to back with the same data. What I'm seeing is that the writestring() in thread 3 to UART1 stops happening. The other iprintf statements from thread 2 are still coming out though. I plug my monitor into UART0 and see it is still working there and doesn't ever fail, then the weirdest thing... When I plug back into UART1 without doing anything different it will start working again for a few minutes before stopping again. 100% repeatable.

Bit of a headscratcher trying to understand what is occuring, especially with that last bit...

Thanks.
Scott

I wonder if the data is binary and something is getting flowed off? Are you positive you are only sending ascii data? Is the buffer you are sending thread safe? Could some other task change it? Are you declaring too much on the task stack and data is corrupted?

One test you could do is to create a constant array of ascii data, and use that in your writestring(), that would eliminate the variable of changing buffer data

Everything I write out is ASCII data. Obviously my iprintf statements often look like: iprintf("ME Layer[%d]:ScalerPipShadowPropertiesBlueScalerA_High= %d\n", ME_Layer, pDmxConstructsLayer->ScalerPipShadowPropertiesBlueScalerA_High);
where I include vars to write out.

The writestring() statements are definitely 100% ASCII data.

Data shouldn't be changing by other tasks. The data I write out is local to that thread. Stack size was a consideration also, Ive thought before that I really need to write something to monitor stack sizes.

The part that puzzles me most is moving the serial cable between the ports temporarily fixes it. I just can't explain that one at all. I've tested different combinations and timing of doing that to know it's 100% repeatable and not just a coincidence.

I really can't tell from what you posted but the example would cause problems if pDmxConstructsLayer is not made thread safe (and it can be changed). I would think if the value in ScalerPipShadowPropertiesBlueScalerA_High is not thread safe you might get bogus output but I wouldn't expect it to hang your thread. On the other hand if you had a pointer to underlying string data and the string got changed, then you could end up trying to iprintf invalid data. To narrow things down, I would iprintf out some basic strings (maybe with a counter) and see if that ever hangs. If it doesn't then you can start adding back your class/member refs and narrow down the problem. In general though if pDmxConstructsLayer is a global accessible from multiple tasks then you need to be careful. I also like to blink a led inside a task to tell if it's really dead, rather than rely on I/O.

Tod

The part that puzzles me most is moving the serial cable between the ports temporarily fixes it. I just can't explain that one at all. I've tested different combinations and timing of doing that to know it's 100% repeatable and not just a coincidence.

So this was the clue I needed to follow. I just couldn't figure out the relationship at all though. As I was thinking about it over the last couple days while working on other things it occurred to me that I do have HW Flow Control enabled on the other port that I didn't have anything connected to. When I turned off HW Flow Control then it stopped hanging.

This explains why when I would temporarily plug my terminal monitor into that port and then plug back into the other port it would start working again for a short period of time. Since it had Flow Control enabled it basically would get to a point where some buffer was full and that would cause the thread to hang then until it could finally empty the queue backlog out.