Disbaling Debug Prints

[isonthomas]

Hi,

Is there a method by which we can complete remove the debug prints. In my application the UART interface used for debug prints is used for BT module communication as well. We need to check if we complete disable the debug prints so that no other data other than the one expected by the BT module is reaching it. Kindly let us know if you have a procedure.

-Ison

[Panu]

Is there a method by which we can complete remove the debug prints.

Yes. Make vo_stdout and vo_stderr point to some other file than the UART console. For example, simply construct a null file ptr and point vo_stdout (interrupt enabled UART output) and vo_stderr (direct port UART output) to that. Or you can redirect vo_stdout and vo_stderr to a disk file or to another device, such as LCD screen. Sometimes I put the console output to go to an SPI port or to a soft serial port so I can see the VSOS output and still use the UART for a hardware purpose.

Here's the (two) program(s) that you need. Load driver QUIETCON to remove all console output. It also publishes uartOut so you can still fprintf to the uart from your own programs. The second program UARTOUT uses this feature to print its parameter string to the uart.

Source code of QUIETCON:

Code: Select all

// This program removes all console output and publishes uartOut so you can print to the UART yourself.
/* 
	To use this program, include this line in the beginning of your program:
	
		DLLIMPORT(uartOut) extern VO_FILE *uartOut;
	
	Then you can print to the uart with e.g. 
		
		fprintf(uartOut,"Hello, Uart!\n");

*/

#include <vo_stdio.h>
#include <volink.h>     // Linker directives like DLLENTRY
#include <apploader.h>  // RunLibraryFunction etc
#include <kernel.h>		// Kernel symbols

const FILEOPS nullFileOperations = {
	(void*)CommonOkResultFunction,
	(void*)CommonOkResultFunction,
	(void*)CommonOkResultFunction,
	(void*)CommonOkResultFunction,
	(void*)CommonOkResultFunction,
};
char* NullFileIdentify(register __i0 void *self, char *buf, u_int16 bufsize) {return "FNUL";}
const SIMPLE_FILE nullFile = {__MASK_PRESENT | __MASK_OPEN | __MASK_READABLE | __MASK_WRITABLE | __MASK_FILE, 
	NullFileIdentify, &nullFileOperations};

VO_FILE *stdout_save;
VO_FILE *stderr_save;

//Redirect all output to null and publish uartOut
void init(void) {
	stdout_save = vo_stdout;
	stderr_save = vo_stderr;
	AddSymbol("_uartOut", NULL, (u_int16)(&stderr_save)); //publish original stderr as uartOut
	vo_stdout = &nullFile; //point stdout to nullfile
	vo_stderr = &nullFile; //point stderr to nullfile
}

void fini(void) {
	vo_stdout = stdout_save;
	vo_stderr = stderr_save;
}

Source code of UARTOUT:

Code: Select all

// This program prints to the uart after QUIETCON driver has been loaded.
// If QUIETCON is not loaded, loading of this program will fail with a missing symbol error.

#include <vo_stdio.h>
#include <volink.h>     // Linker directives like DLLENTRY
#include <apploader.h>  // RunLibraryFunction etc
#include <kernel.h>		// Kernel symbols

DLLIMPORT(uartOut) extern VO_FILE *uartOut;

ioresult main(char *parameters) {
	fprintf(uartOut,parameters);
	return S_OK;
}

[isonthomas]

Hi Panu,

Thanks for the input. One quick clarification, will this disable the kernel outputs that we observe before the application gets loaded.

Hello.<LF>
VSOS 3.33 build Sep 28 2016 14:40:21<LF>
VLSI Solution Oy 2012-2016 - www.vlsi.fi<LF>
<LF>
Starting the kernel..<LF>
Starting Devices... <LF>
Internal Flash<LF>
<LF>
Installed system devices:<LF>
S: SPI Flash c213, handled by FAT.<LF>
Load drivers, config 0...<LF>
Driver: INTTRACE... <LF>
Driver: AUOI2SMA... <LF>
Driver: S:MainApplication.ap3...

From what I understood, the quietcon.dl3 will be loaded only after the initial prints and the console prints will be disabled after this particular step.

-Ison

[Panu]

Hi!

You are correct, it will not remove the early kernel prints. Is that really necessary?

If it is, then you must modify the kernel. In the beginning of kernel main(), there is a line

Code: Select all

	vo_stdout = vo_stdin = vo_stderr = &consoleFile;

which you can remove and in place of it write something like

Code: Select all

	{
		extern SIMPLE_FILE *nullFile;
		static FILE *uartOut = &consoleFile;
		vo_stdout = vo_stdin = vo_stderr = &nullFile;
		SymbolAdd("_uartOut",NULL,(u_int16)(&uartOut));
	}

and then remove the QUIETCON driver.

I haven't tested it but it could work. Anyway, it could be one of the last steps that you do with the project... personally I'd like to be able to read the kernel printouts somehow. And we need to still debug and probably modify the kernel a little together, so it could be too much work for you to modify the kernel yourself right now(?)

-Panu

[Panu]

Another possibility is take a look at console.c in the kernel - that is what implements the UART console output. You can easily see how to make it work differently than how it works now; there's just one function, ConsoleWrite, which puts a character to the UART. In the kernel it is like this:

Code: Select all

u_int16 ConsoleWrite(register __i0 VO_FILE *self, void *buf, u_int16 sourceIndex, u_int16 bytes) {
	u_int16 oldRxInt;
	
	// Save RX interrupt state - needed for compatibility with legacy routines
	Disable();
	oldRxInt = PERIP(INT_ENABLE0_LP) & INTF_UART_RX;
	PERIP(INT_ENABLE0_LP) &= ~INTF_UART_RX;
	Enable();
	
	//since console is a console, only characters are written to it. Hence bytes is always 1.	
	putch(((char*)buf)[0]); //Send character to raw UART port
	
	// Restore RX interrupt state
	Disable();
	PERIP(INT_ENABLE0_LP) |= oldRxInt;
	Enable();
};

Instead of putch() which puts a character into the UART, you could send the character to any other hardware.

[isonthomas]

Hi Panu,

Thanks for the update. I will try the modifications.

This debug print disabling is just for a testing purpose. As I have mentioned, the console UART is multiplexed with our Bluetooth module. We are observing some unexpected behavior on the BT module. So the print disabling is just to test whether the debug prints are causing the issues.

-Ison

[Panu]

Ok, that's great! Hope you get both problems resolved!

-Panu