Colway Solutions
Modbus Member Logo

Configure Diagnostics

 

MSPL-C has embedded debugging code to printout out useful information to enable users to analyse, debug and diagnose the function of the library. Such code can be enabled only during initial development and disabled later to save code space as well as to decrease the CPU utilisation of the library.

The type of debugging statements output by the library also controlled at four levels as discussed in section 2.6.1

All diagnostics settings are done using 'C' macros making them configurable only at compile time and not at run time. So configuring diagnostics can be done with the following steps:


Step-1: Select debugger level 14


Step-2: Include or exclude Formatted I/O support. 14


Step-3: Implement the debug "sink". 15


 

2.6.1       Step-1: Select debugger level

Enabling the debugger and setting the debug level is done by defining a value for the DEBUG_LEVEL macro. This macro is defined in MSPL_UserIf.h

e.g.

#define DEBUG_LEVEL DEBUG_ERROR

 

This macro can be assigned one of the following values:

Macro Value

Description

DEBUG_NONE

This value disables the debugger. No debugging statements are output from the library. This is the value you will use once your application has been fully tested and ready to be released.

DEBUG_ERROR

This value causes the debugger to output statements when any error occurs in the library. In a well tested application there should be very few occurrences of "error debugger statements". In a way, it's a good idea to set the debugger to this level during the initial period after a release is done in order to capture errors that might occur post-release. An example of an error condition is when the library finds that the Modbus packet that has arrived is larger than the buffer size configured. In this case the library outputs this message:

"Error: MSPL_ReadMbPdu: Buffer too small to read PDU"

DEBUG_WARNING

This value causes the debugger to output relevant messages when errors occur or when conditions occur that could potentially lead to errors. An example of a warning is when the library receives a Modbus request with the function code set to an unsupported value. In this case the library outputs this message:

"Warning: Unsupported function code, sending exception response"

DEBUG_INFORMATION

This value causes the debugger to output routine information that indicates the overall status of the library and also shows the flow of execution, in addition to error and warning messages. This is the setting you will use in diagnosing any errors reported in the application. For instance when the library receives a Modbus read request for Coils, it outputs the following informational message:

"==> FC=0x01 (Read Coils) "

DEBUG_VERBOSE

This value causes the debugger to output messages that can be used for deep debugging. An example of such a message is when the library outputs the value of each byte of the Modbus packet received by it as well as that of the response. This setting is useful in diagnosing difficult problems but at the same time generates an overwhelming amount of messages that can get you lost.

 

Back to the top

 

2.6.2       Step-2: Include or exclude Formatted I/O support

If a function like sprintf that implements formatted I/O is supported on the platform, the library can make use of it to create more meaningful debugging messages. For instance if a Modbus request with an unsupported function code is received, the debug message will be formatted to contain the unsupported function code to make it easier to debug the problem.

Support for formatted I/O can be configured by setting the macro STDIO_SUPPORTED to a value of '1' and providing the name of the function to be used in the macro FORMATTED_STRING_PRINT. Both these macros are defined in MSPL_UserIf.h.

 

#define STDIO_SUPPORTED 1 // Enable formatted I/O support

#define FORMATTED_STRING_PRINT sprintf


Back to the top

 

2.6.3       Step-3: Implement the debug "sink"

The debugging messages output by the library have to be finally output to a physical device like a display, a printer or a serial terminal etc. This output device is referred to as the debug sink. To provide the flexibility of choosing the debug sink to the user, the library outputs its messages to a function called MSPL_DebugPrint. This function is defined in MSPL_UserIf.c but is left unimplemented (i.e. an empty function). Users should implement this function and sink the debug message passed as an argument to an appropriate device.

The format of this function is as below:

void MSPL_DebugPrint( CSPL_U8 networkNo, CSPL_U8 eventType,

char * debugMessage)

Parameters:

      i.      networkNo (IN): The network who Modbus instance generated this debug print. This paramter enables redirecting of debug prints from different networks to different sinks so that they do not all get jumbled.

    ii.      eventType (IN): Indicates the debug level at which this debug print was made. Possible values are one of: DEBUG_VERBOSE, DEBUG_INFORMATION, DEBUG_WARNING and DEBUG_ERROR. A possible use of this information is to print debug messages of different levels in different colours.

   iii.      debugMessage (IN): A null-terminated 'C' string containing the debug message.

Shown below is a very simple implementation of this hook function that adds a time stamp to the debugger message and prints it to the standard output device.

 

void MSPL_DebugPrint(CSPL_U8 networkNo, CSPL_U8 eventType, char* debugMessage)

{

/* Add a time stamp to the debugger message & print it to the

standard output */

SYSTEMTIME st;

GetLocalTime(&st);

printf("%d:%d:%d.%03d - %s", st.wHour, st.wMinute, st.wSecond,

st.wMilliseconds, debugMessage);

}

 

Back to the top

 

Back to Index

Privacy Policy Site Map FAQ Contact Us