Table of Contents

Description

The logging service is essential to help us keep track of everything that is going on within the satellite’s flight software. Logging is like printing debug messages to the console. However, instead of just printing messages, logging will also save the debug message to a text file along with a timestamp for when that message was reported. By saving debug messages to text files, we can later review these text files to get a deeper understanding as to what was going on inside the system at a particular time.

The role and design of the logging service is pretty straightforward. The logging service is a Zephyr thread that will read messages that are stored in a queue (Queue A), apply a timestamp to those messages and log level to those messages, and then append the newly formed log messages to another queue (Queue B). The messages stored in Queue A come from other software components that want to log events to a text file. After the logging service adds messages to Queue B, another software component known as the Storage Service will take the messages and write them to a text file stored in NOR flash memory.

Your task is to create the Logging Service, and use test threads to write to Queue A and read from Queue B to simulate the Logging Service’s environment. If successful, your Logging Service will be able to quickly read messages from Queue A, create the log message, and then append it to Queue B. You will need a set of functions that use string manipulation techniques to format the log message the way we want it to be (see Tasks for the format).

Your main points of contacts are:

• Firmware Design Lead
• CDH Design Lead

While creating and testing your code, please use the STM32G431RB MCU. This is the MCU that will be used for our on-board computer (OBC).

Tasks

The log message will follow this particular format:

If you have suggestions for anything to change within the log message, bring it up with @Eesa Aamer and we can get your changes implemented.

[DATE] [TIME] [LOG LEVEL] [COMPONENT] [message]

• [x] Develop a test plan to validate the functionality of each function that you will be creating
• [x] Create two queues, the first queue will consist of structs that contain member variables that require all the information listed above in the log message format. The second queue will simply consist of strings of a certain size (You will have to decide on a string size based on what is reasonable to fit concise, informative log messages)
• [x] Create a thread that when awakened, will read the first struct and create a log message string in the format listed above
  • [x] The thread must then append the newly-created string to the second queue
• [x] Use concurrency control (mutexes, semaphores, etc.) to protect the two queues for multi-threaded applications
• [x] Write unit tests using the test plan developed earlier to verify everything is working correctly
  • [x] You will likely need to create “dummy threads” that will populate the first queue with test messages and then read the second queue to verify if the log message is accurate and correctly formatted
• [ ] Verify that the Jenkins build passes without any errors