| (Q) - My telemetry stream is being flooded with the same event message. How do I - make it stop? - | |
| - The most direct way to stop an event message from flooding your downlink - stream is to send a command to EVS to filter the offending event (see - \ref cfeevsugmsgcntrl or \link #CFE_EVS_SET_FILTER_CC \EVS_SETBINFLTRMASK \endlink). - In order to stop the event message from being sent, a bit mask of \c '0xFFFF' should - be used. If the event is not currently registered for filtering, the event message - must be added using the command \link #CFE_EVS_ADD_EVENT_FILTER_CC \EVS_ADDEVTFLTR \endlink. - | |
| (Q) - I filtered an event message and would now like to see it again. What do I do in - order to see those events again? - | |
- If the event message that you are interested is registered with EVS for filtering,
- then you have 2 options:
-
-
| |
| (Q) - What is the purpose of DEBUG event messages? - | |
| - Event message of type "DEBUG" are primarily used during flight software development - in order to provide information that is most likely not needed on orbit. Some commands - send debug event messages as verification that a command request was received. When - writing the EVS local event log to a file, for example, an event message of type DEBUG - is issued. On orbit, this event message is probably not needed. Instead, the command - counter is used for command verification. - | |
| (Q) - How do I find out which events are registered for filtering? - | |
| - EVS provides a command (\link #CFE_EVS_WRITE_APP_DATA_FILE_CC \EVS_WRITEAPPDATA2FILE \endlink) - which generates a file containing all of the applications that have registered with EVS and - all of the filters that are registered for each application. Note that EVS merely generates - the file. The file must be transferred to the ground in order to view it. - | |
| (Q) - Why do I see event messages in my console window? - | |
| - By default, the events are configured to transmit out a "port" that shows event messages - in the console - | |
| (Q) - What is the difference between event services and the ES System Log - | |
| - Events are within the context of an App or cFE Service (requires registration with ES). - The system log can be written to outside of the Application or cFE Service context, - for example during application startup to report errors before registration. - | |
| (Q) - How is the memory pool handle (sent in SB housekeeping telemetry) intended to be used? - | |
|
- The memory pool handle is used to analyze the SB memory pool statistics. The cFE ES
- command (#CFE_ES_SEND_MEM_POOL_STATS_CC) to dump the memory pool statistics takes the pool handle
- as a parameter. These statistics tell how the SB memory pool is configured and gives details
- on margin. An improperly configured SB memory pool may inhibit communication. This may occur
- if there is not enough margin to create a block of the size needed for a transfer. Refer to
- the ES memory pool users guide for more details. \ref cfeesugmempoolsrv - | |
| (Q) - When sending a message, what message header - fields are critical for routing the message? - | |
| - To route the message properly, the software bus uses only the Message ID and - packet length fields from the header of the message. If the packet length field - is incorrect, then the buffer allocation for the message will also be incorrect. - This may appear to the receiver as a truncated message or a message with unknown - data added to the end of the message. - | |
| (Q) - How many copies of the message are performed in a typical message delivery? - | |
| - There is a single copy of the message performed when sending a message - (from the callers memory space) using CFE_SB_TransmitMsg. - When transmitting the message, the software bus copies the message from the - callers memory space into a buffer in the software bus memory space. There - is also the option to request a buffer from SB, write directly to the buffer - and send via CFE_SB_TransmitBuffer. This is equivalent to the previous zero - copy implementation. - The #CFE_SB_ReceiveBuffer API gives the user back a pointer to the buffer. When - working with the buffers, the additional complexity to be aware of is the - buffer is only available to the app from the request to send (on the sending side), - or from the receive until the next receive on the same pipe on the receiving side. - If the data is required outside that scope, the app needs a local copy. - | |
| (Q) - When does the software bus free the buffer during a typical message - delivery process? Or how long is the message, and the pointer to the buffer - in the #CFE_SB_ReceiveBuffer valid? - | |
| - After receiving a buffer by calling #CFE_SB_ReceiveBuffer, the buffer received is valid - until the next call to #CFE_SB_ReceiveBuffer with the same Pipe Id. - If the caller needs the message longer than the next call to - #CFE_SB_ReceiveBuffer, the caller must copy the message to its memory space. - | |
| (Q) - The first parameter in the #CFE_SB_ReceiveBuffer API is a pointer to a pointer which - can get confusing. How can I be sure that the correct address is given for this - parameter. - | |
| - Typically a caller declares a ptr of type CFE_SB_Buffer_t (i.e. CFE_SB_Buffer_t *Ptr) - then gives the address of that pointer (&Ptr) as this parameter. After a successful - call to #CFE_SB_ReceiveBuffer, Ptr will point to the first byte of the software bus - buffer. This should be used as a read-only pointer. In systems with an MMU, writes - to this pointer may cause a memory protection fault. - | |
| (Q) - Why am I not seeing expected Message Limit error events or Pipe Overflow events? - | |
|
- It is possible the events are being filtered by cFE Event Services. The filtering
- for this event may be specified in the platform configuration file or it may have
- been commanded after the system initializes. - There is a corresponding counter for each of these conditions. First verify that - the condition is happening by viewing the counter in SB HK telemetry. If the - condition is happening, you can view the SB filter information through the EVS - App Data Main page by clicking the 'go to' button for SB. The event Id for these - events can be learned through a previous event or from the cfe_sb_events.h file. - | |
| (Q) - Why does the SB provide event filtering through the platform configuration file? - | |
| - To give the user the ability to filter events before an EVS command can be sent. - During system initialization, there are many conditions occurring that can cause - a flood of SB events such as No Subscribers, Pipe Overflow and MsgId to Pipe errors. - This gives the user a way to limit these events. - | |
| (Q) - Why does SB have so many debug event messages? - | |
| - The SB debug messages are positive acknowledgments that an action (like receiving a - cmd, creating a pipe or subscribing to a message) has occurred. They are intended to - help isolate system problems. For instance, if an expected response to a command is - not happening, it may be possible to repeat the scenario with the debug event turned - on to verify that the command was successfully received. - | |
| (Q) - How is the QOS parameter in the #CFE_SB_SubscribeEx used by the software bus? - | |
| - The QOS parameter is currently unused by the software bus. It is a placeholder to be - used with the future software bus capability of inter-processor communication. Setting - the QOS as #CFE_SB_DEFAULT_QOS will ensure seamless integration when the software bus - is expanded to support inter-processor communication. - | |
| (Q) - Can I confirm my software bus buffer was delivered? - | |
| - There is no built in mechanism for confirming delivery (it could span systems). - This could be accomplished by generating a response message from the receiver. - | |
| (Q) - Is it an error to load a table image that is smaller than the registered size? - | |
| - Table images that are smaller than the declared size of a table fall into one of two categories. - - If the starting offset of the table image (as specified in the Table Image secondary file header) is - not equal to zero, then the table image is considered to be a "partial" table load. Partial loads - are valid as long as a table has been previously loaded with a non-"partial" table image. - - If the starting offset of the table image is zero and the size is less than the declared size - of the table, the image is considered "short" but valid. This feature allows application developers - to use variable length tables. - | |
| (Q)
- I tried to validate a table and received the following event message that said the event failed: - - What happened? - | |
| - The event message indicates the application who owns the table has discovered a problem with the - contents of the image. The code number following the 'Status' keyword is defined by the Application. - The documentation for the specified Application should be referred to in order to identify the exact - nature of the problem. - | |
| (Q) - What commands do I use to load a table with a new image? - | |
| - There are a number of steps required to load a table. - -# The operator needs to create a cFE Table Services compatible table image file with the - desired data contained in it. This can be accomplished by creating a 'C' source file, compiling - it with the appropriate cross compiler for the onboard platform and then running the elf2cfetbl - utility on the resultant object file. - -# The file needs to be loaded into the onboard processor's filesystem using whichever file transfer - protocol is used for that mission. - -# The \link #CFE_TBL_LOAD_CC Load Command \endlink is sent next to tell Table Services to load the - table image file into the Inactive Table Image Buffer for the table identified in the file. - -# The \link #CFE_TBL_VALIDATE_CC Validate Command \endlink is then sent to validate the contents of - the inactive table image. This will ensure the file was not corrupted or improperly defined. The - results of the validation are reported in Table Services Housekeeping Telemetry. If a table does - not have a validation function associated with it, the operator may wish to compare the computed - CRC to verify the table contents match what was intended. - -# Upon successful validation, the operator then sends the - \link #CFE_TBL_ACTIVATE_CC Activate Command. \endlink The application owning the table should, within - a reasonable amount of time, perform a table update and send an event message. - | |
| (Q) - What causes cFE Table Services to generate the following sys log message: - - CFE_TBL:GetAddressInternal-App(\%d) attempt to access unowned Tbl Handle=\%d - | |
| - When an application sharing its table(s) with one or more applications is reloaded, the reloaded application's - table handle(s) are released. cFE Table Services sees that the table(s) are shared and keeps a 'shadow' version - of the table in the Table Services registry. The registry will show the released, shared tables with no name. - When the applications sharing the table attempt to access the table via the 'old', released handle, Table Services - will return an error code to the applications and generate the sys log message. The applications may then unregister - the 'old' handle(s) in order to remove the released, shared table(s) from the Table Services registry and share the - newly loaded application table(s). - | |
| (Q) - When does the Table Services Abort Table Load command need to be issued? - | |
- The Abort command should be used whenever a table image has been loaded but the application has not yet activated it and
- the operator no longer wants the table to be loaded.
-
- The purpose of the Abort command is to free a previously allocated table buffer. It should be noted, however, that multiple
- table loads to the SAME table without an intervening activation or abort, will simply OVERWRITE the previous table load using
- the SAME buffer.
-
- Therefore, the most likely scenarios that would lead to a needed abort are as follows:
-
-
| |
| (Q) - - | |
| - | |