NetBurner Community Forum

I have no idea what has happened but I am no longer seeing any debug output from the other tasks.

I see debug output from the main task and all the initialisation that I have, but the other tasks do not show any debug output anymore.

What have I missed? Is there a compiler option I am missing? I did have to rebuild the complete installation a few weeks ago but it was working after that.

Cheers,
Dave...

did you close/reopen the serial port somewhere after your main routine?

Is your main task ever blocking to allow the other tasks to run?

The UART0 was not closed or opened in my application.

The main task is blocking and the other tasks are being executed as I can step into them. I can step over the iprintf code too and it shows nothing on STDIO.

I will add code to the main task today to see if it outputing debug during running. At present it does not send out anything.

Dave...

I'd suspect a Tx/Rx wiring-swap issue, or a jumper setting on the serial driver ICs, or a loose serial or USB connector. First try to load a simple AppWiz "Hello World" type of example. If that fails, and if you are listening to STDIO on a PC consider this: On rare occasions I've seen the PC serial ports lock up hard enough to require resetting the PC. I like MTTTY for the most part as a no-frills, basic terminal program, but I've unfortunately seen it do this kind of confounding, hair-tearing kind of thing more than once. If I use other serial programs I don't seem to see these issues. At first I thought it might be related to the particular PCs I use, or the serial/USB converters I use, but I've also seen it happen to other MTTTY users too.

Thanks RG,

I am seeing the debug output during bootup and as the application runs. Before I enter the while loop in the main task I output to the debug and it appears on MTTY. It is just the debug from the other tasks, which are running that are not showing any output yet I know the code is running because I can see on the LCD that it is working. The code is functioning as expected, just no debug output.

This is my own hardware that the MOD5234 is running on and has been for the last 2 months of development. It just started doing this recently. The debug output is RS232 on a 10 pin header. I may shutdown some tasks to see if I can find which one has started to cause this issue.

I'll try a different TTY ap on th PC and see if this is working.

As the code is in source control, I may roll back to 2 weeks ago and see if this fixes the issue. Then I can compare and see what is different.

Dave...

Dave,

After your application reaches the point where stdio is not working in other tasks, can you still output stdio in the main task while loop? Keep in mind that syslog can be used for outputting debug messages until you figure out what is wrong with stdio, it will also be a good indication you are hitting the sections of code where stdio is being attempted. Did you close any reopen the debug serial port? This would switch it from its polling mode boot default to the standard interrupt serial driver. If you did then I would see what happens if you don't and vice versa. Also you should see what happens if you call a write() to the FD of the serial port instead of calling the stdio functions. Then try using the very low level polling functions from bsp.h for interfacing with the UART:
char LocalInByte()
void LocalOutByte( char c )
int LocalCharAvail()
After you see which of these things are working and failing you should have a better indication of what level in the code for stdio is failing.

Larry mentioning that the default stdio is polled reminded me of an issue he steered me clear of a few years back. I seem to remember the following: If you use the OpenSerial() call to get an fd you start interrupt driven code for the specified port. If you do this, I believe it is important to call SerialClose() prior to making the OpenSerial() call. Otherwise, stdio routines will still be linked to the polled driver while read() or write() calls to the interrupt driven fd conflict with the polling-driven stdio calls.

Here's what I typically do, although this may no longer be required for the current update of serial drivers. Seems to me it cna't hurt to call SerialClose 1st:

SerialClose(0);
int Debug_fd = SimpleOpenSerial( 0, 115200 );
ReplaceStdio( 0, Debug_fd ); // stdin
ReplaceStdio( 1, Debug_fd ); // stdout
ReplaceStdio( 2, Debug_fd ); // stderr


In th epast, if you skipped the SerialClose(), things worked for a while, but not for long....
Larry, does this ring a bell?

You must call the SerialClose before you call the SimpleOpenSerial function. If you do not then the open call will return the error: SERIAL_ERR_PORT_ALREADYOPEN. The ReplaceStdio functions used to be required if you close and reopen the default stdio port. There were changes made to the serial driver recently, 2.4RC1, which will automatically call ReplaceStdio if you close and reopen the default boot port. You now only need to use ReplaceStdio if you want to point stdio at a different file descriptor.
So for versions of the NNDK older then 2.4RC1 you must call these ReplaceStdio functions, otherwise the stdio functions will still be pointing at the polling UART driver. Since OpenSerial function will have just enabled interrupts for that UART, unpredictable things can happen when you call stdio that is still connected to the polling UART functions.

This is interesting.

I added an iprintf to the main loop and nothing is being shown on the debug output. The call to iprintf before the while loop is being shown. All the tasks are already started and running prior to this call before the while loop as there is a delay of about 5 seconds as it checks the FLASH drive size.

This is the while loop in the main task.

iprintf("Starting Main Loop\r\n");
while (1)
{
if(ActivePage != ActivePageLast)
{
ActivePageLast = ActivePage;
Mimic_DrawScreen(ActivePage);

if(ActivePage != PAGE_MAIN)
{
PageTimer = Secs + PAGETIMEOUT; // Return to main page time
}
}
Mimic_Update();
Mimic_Process();
System_Process();
OSTimeDly(TICKS_PER_SECOND / 8); // Update every 1/4 second
iprintf("Main Loop Running\r\n");
}

In the above code, the debug output at the end of the while loop never appears.

I then tried the close and opening of the serial port and still the same. Everything up to the while loop.

Dave...