API Layer

message. In such a way, interruptions in the CAN transmission line are signaled to the application software.

This data structure contains the variables that shall be received by the MCU from the external test bench through CAN bus with the message 03. This data structure is updated by the software component CanCom when a message 03 is received (nominal transmission rate is 0.01s) and read by the application software every 0.001s. The fields of the data structure are represented by real32_T (float) variables and are not reported for NDA policies. They are opportunely converted from uint16_T to real32_T or uint32_T data types before to be stored in the data structure.

• CanRxDataMsg04

CanTxDataMsg04_T CanTxDataMsg04

This data structure contains the variables that shall be received by the MCU from the external test bench through CAN bus with the message 04. This data structure is updated by the software component CanCom when a message 04 is received (nominal transmission rate is 0.05s) and read by the application software every 0.001s. The fields of the data structure are represented by real32_T (float) variables and are not reported for NDA policies. They are opportunely converted from uint16_T to real32_T or uint32_T data types before to be stored in the data structure.

Functions

CanCom_Init()

status_T CanCom_Init(void)

This function initializes the FlexCan-FD peripheral to allow CAN communi-cation with the external test bench using the in-board CAN transceiver.

Parameters None.

Returns

status_T - Status return code.

status_success The FlexCAN-FD and PIT peripherals are set correctly.

status_canInitError An error occurs in initializing the FlexCAN-FD or PIT peripherals.

Notes

The operations performed during the initialization are the following:

1. Initialize the pins related to CAN Management.

2. Configure the TX buffers for the CAN messages 01 and 02.

3. Configure the RX buffers for the CAN messages 03 and 04.

4. Install the callbacks for the reception of the RX messages.

5. Configure the channels of the PIT1 to periodically send TX messages.

After the initialization, the function CanCom_SendEnable() shall be called to start to send periodically TX messages according to the CAN database.

CanCom_SendEnable() void CanCom_SendEnable(void)

This function starts the channels of PIT1 to send periodically TX messages according to the CAN database.

Parameters None.

Returns None.

Notes

This function shall be called after the initialization of the software component CAN Management to start sending messages.

CanCom_SendDisable() void CanCom_SendDisable(void)

This function stops the channels of PIT1 which are used to send periodically TX messages according to the CAN database.

Parameters None.

Returns None.

Notes

This function is called at the end of initialization of the software component CAN Management to prevent sending messages before that the application software is started.

Firmware Verification and Testing

In software project management, software testing, and software engineering, verifi-cation and validation (V&V) is the process of checking that a software system meets specifications and that it fulfills its intended purpose. It may also be referred to as software quality control [6]. As already discussed, the firmware can be considered as a specific kind of software that provides the low-level control for a device’s specific hardware. Verification and validation are independent procedures that are used together for checking that a product, service, or system meets requirements and specifications and that it fulfills its intended purpose. More precisely, verification is the process to evaluate of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. Differently, validation is the process to guarantee that a product, service, or system meets the needs of the customer and other identified stakeholders.

It often involves acceptance and suitability with external customers [6].

In the context of this thesis, the firmware testing aimed mainly to verification procedures rather than validation ones. As already said, the final goal of the project of this thesis is to develop a proof of concept for an electric powertrain which, as the name suggests, doesn’t need to be validate as product. In fact, the project goal is to proof that the realization of the system that has been designed is achievable. Therefore, the purposes of the tests discussed in this chapter are to verify that the firmware configures the embedded hardware to interact correctly to the other subsystems connected to the MCU, and provides the necessary features required by the application software. In this chapter, the tests, performed in the verification phase, are discussed in the following sections. Section 4.2 is dedicated to the description of the laboratory instrumentation used to perform the MCU debug and trace and the measurements of the involved electrical quantities. The

other ones provide the description of correlated tests performed on the specific software components or hardware peripherals. Each of these sections is structured to describe the test purposes and the requirements to be checked, the developed test programs to execute, the specific test procedure to be performed, the expected results, and the analysis of the results obtained by the test. It is important to underline that no specific tests were developed for the software component Pin Management because its functions are tested one at a time during the testing of other software components.

The structure of the procedure performed for each test is described by the sequence diagram of Fig. 4.1. As can be seen in the figure, the laboratory instrumentation is set up before to interact with the MCU. Then, the test program is downloaded from a version control system (VCS), also know as revision control or source control system A VCS is a software utility that tracks and manages changes to firmware source code, and provides a secure backup in case of data loss or corruption.

The test program is written in the MCU flash memory by means of the specific Lauterbach hardware and software tools (described in detail in section 4.2.1). After that, the test program is started, the electrical signals are measured with the laboratory instrumentation such as oscilloscopes, multimeters, or logic analyzers and the MCU state checked by means of JTAG or ETM interfaces. The acquired results are compared with the expected ones - if they are consistent with each

Figure 4.1: Sequence diagram of the structure of test procedures.

other, the test is passed, otherwise it is failed meaning that one or more bugs are present in the source code.