This is Saig from ST-Microelectronics. In this video, I'm going to show you how to set up two N7 or 3Zi2 boards to communicate using the CAN-FT protocol through the FT-CAN peripheral. The agenda for this video is divided into seven sections, as shown. We start with a brief overview of CAN-FT transceiver, and then we'll do an overview of FT-CAN normal operation mode. Next, we'll reveal the external circuit used for our setup. In section 5, we'll show how we calculate the FT-CAN bit timing using the online bit timing calculator. Then we begin the hands-on FT-CAN example. And finally, at the end of the presentation, we'll quickly review the expected result from the receive data buffer, and then we'll take a look at the snapshot of the expected oscilloscope signal observed at the output pin of the nuclear board. For this hands-on, we will test the CAN-FT data rate using the normal operating mode of the STM32 H7 FT-CAN peripheral. We will observe the CAN-FT communication using the FT-CAN1 receive buffer. And optionally, we can observe the digital signal output directly from the FT-CAN controller using an oscilloscope or a logic analyzer. In normal operating mode, we will be needing to interface the CAN bus using the CAN-FT transceiver, so the digital signal from the CAN-FT controller is converted to differential signal. For this, we will use microchips MCP2562-FT. As a side note, please be aware you can access all the materials discussed in this video through the link shared in the description. Refer to FT-CAN external loopback mode video for a quick overview of CAN-FT protocol. If you need a detailed brush up on the theoretical aspect of CAN-FT, please refer to our STM32 H7 online training video 47. See the link section at the end of the video. This hands-on focuses on the practical aspect, so it assumes you already have some basic knowledge about CAN protocol. Throughout the video series, application note 5348 will be referenced. I will quickly go over its content with you. This document contains information about CAN-FT protocol overview, frame architecture comparison to older CAN 2.0, FT-CAN main features, RAM management, RAM sections, which include RAM filtering sections, reception section, and transmission section. As well, the document goes over the test modes, transceiver delay compensation, clock calibration on the FT-CAN. In the last section, the document goes over the STM32 FT-CAN improvements over the older STM32 VX-CAN IP. As well, for additional reference, take a look at the datasheet for the CAN-FT transceiver or microchip. In here, you will find useful information like the panel table for the transceiver, electrical characteristics such as the CAN-H and CAN-L voltage level for the dominant and recessive logic, timing-related information like the propagation delay, and more. For this project, we will use two NUCLEO H743 Zi2 boards, two micro USB cables, a host computer to connect the NUCLEO boards to, and an oscilloscope for verifying the output signal. Don't worry if you don't have a scope at hand. The oscilloscope is not necessary for experimenting with this example. Note that although we are using the NUCLEO H743 Zi2 for this hands-on, the process is the same for other STM32 H7 MCUs with the FT-CAN peripheral. For our external circuit, we will utilize the following items. Two microchip CAN-FT transceiver. With dual inline package, this will make things easier for us when we're prototyping on the breadboard. Two 120 ohm resistor for the terminal CAN nodes on the bus. This is used to reduce signal reflection on the CAN bus. Keep in mind that any additional CAN nodes added to their bus, for example, node 3, 4, and beyond, we will not require any additional resistors. A single 0.1 microfarad, ceramic capacitor for each node, which is used for filtering any potential noise on the VDD bus to the ground. We will use solderless breadboard to place the CAN transceiver, resistors, and capacitors. And we will use jumper wires to connect the NUCLEO board and provide power and ground to the breadboard. No soldering will be required for this example project. The CAN-FT transceiver provides an interface between the digital domain and the CAN-FT physical layer, which uses differential signaling. As mentioned previously, we intend to use the CAN-FT transceiver to convert the digital signal from the FT-CAN controller to differential signal for the CAN bus. As seen in this scope capture, CAN is a serial two-wire differential bus. The data is sent one bit at a time through two equal and opposite complementary signals on the CAN-HI and on the CAN-LO bus wires. The value of VDIF determines whether the bit transmitted on the bus is a dominant bit or a recessive bit. The voltage difference range defining the recessive and dominant logic is defined in the DC characteristic table of CAN-FT transceiver data sheet. Differential signaling provides the following benefits. Enhanced noise immunity from external sources. Benefit of reduced outgoing noise and crosstalk. Benefit of operating using low voltages within a high noise environment. Because of these features, differential signaling is a preferred protocol in noisy industrial and automotive settings. We will now do a quick overview of normal operation mode of FT-CAN peripheral. Unlike the test mode, normal operation mode is not restricted to any limitation. We will use normal operating mode to have two SDM32-87s to communicate with each other through CAN-FT protocol. As from normal operating mode, we have access to the following features of the FT-CAN peripheral. We can receive and send both the data and remote frames. We can give acknowledgement to valid frames received from other nodes. And we can send both active error frames and overload frames. Refer to application node 5348 or the reference manual for more details. Now let us go over the hands-on example. Our task is to send a 12-byte data buffer from the CAN-FT node 1 through the CAN bus to a second CAN-FT node. For this, we need to configure the filter appropriately in order to accept the received message. We will randomly pick FT-CAN-1 controller for our hands-on project. As a prerequisite for communicating between two nuclear boards, we will enable normal operating mode for the FT-CAN. As discussed previously, for this mode, we will need the external hardware as described in the schematic that will be reviewed next. We will use HolyMethod to ensure the message has been both transmitted and received successfully. In addition, we will have both extended frame and bed-rate switching enabled. As for the reception and transmission storage data structures for the FT-CAN controller, we will configure to use a single buffer for both RX and TX. The schematic shown in the figure illustrates the external circuit comprising of microchips CAN-FT transceiver, each interfacing with FT-CAN-1 controller on two different nuclear boards. Looking at one of the transceivers in the schematic, starting from PEN 1, we can see that PEN PB9 on the nuclear board is connected to the TX PEN of the transceiver. We assess PEN on the transceiver as connected to the ground PEN of the nuclear board. VDD PEN is connected to the 5-fold PEN of the nuclear board. RX PEN is connected to PB8 of the nuclear board. PEN 5 is also connected to VDD. PEN 6 and PEN 7 are connected between the two transceivers to form the CAN bus. And finally, PEN 8, standby PEN, is connected to the ground in order to run the transceiver in normal mode, as discussed in the data sheet of the transceiver. Please note, the full schematic view is located within the zip folder, which is linked in the video description. Before we start the hands-on, please take a look inside the zip folder that is linked in the video description. In there, you'd find a source code that we will add to the hands-on project later on. The zip folder contains source code for node 1, source code for node 2, a PDF of all the slides discussed in the video, hands-on project for node 1 and node 2, completed for your reference. And finally, the zip folder contains a schematic of the external circuit comprising the CAN FD transceivers and other components connected. Now, let's get started by creating our first STM32 project for CAN FD node 1 under MCU selector. We'll search for STM32 H743ZI. For project name, we'll go with ftcan underscore node 1 underscore demo. Let's close the IOC file for node 1. First, let's create another STM32 project for node 2. Again, similar to node 1 project, we'll start off by looking under the MCU selector. Then, we'll search for STM32 H743ZI. For project name, let's use ftcan underscore node 2 underscore demo. Let's close the IOC file for node 2 and go back to configuring node 1 IOC first. For ftcan node 1, we begin the IOC configuration by first enabling the ftcan1 peripheral. If you notice a red warning or an arrow sign next to the clock configuration tab, like mine shows, then you can resolve the clock conflict using the automatic clock issue solver. Go back to pinout and configuration tab. Next, we'll start configuring the ftcan1 peripheral for node 1. For frame format, we select flexible data rate with bitrate switching enabled. For the mode field, leave it as normal mode. Enable automatic retransmission. In case an error is detected in a message on the CAN bus, the transmitter will retransmit the error message. Leave transmit pause and protocol exception as disabled in our case. For detailed explanation of these two fields, you can refer to the ftcan external loopback mode hands-on video. For the normal bit and data bit timing, we have to make some calculations beforehand. Let's take a look and see how it's done. For bedtime calculations, we will use third-party online tools like the Kvasser CAN ft calculator. For using this tool, all that we need are three different parameters, namely the clock tolerance, total node delay, and peripheral clock frequency. We can determine the clock tolerance using a datasheet and obtain the parts per million tolerance using the conversion factor shown. For example, we will use the datasheet for this MCU to find the HSI clock characteristic table. We can find the percentage tolerance for subtracting the max or min from typical frequency and then divide back by the typical frequency, and finally multiply by 100. For node delay, for now, we will just go with a value of 180 nanoseconds. We can determine the node delay using vendor datasheet for the CAN ft transceiver. For example, refer to the AC characteristic table for the CAN ft transceiver mcp256 to fd. And for the frequency parameter, we already know the peripheral clock frequency is 50 MHz from our IOC file configuration. Entering the required parameter in the Kvasser CAN ft calculator, we obtain the following table for the nominal and data bit times. Note that the nominal bit timing is the bit time for the arbitration phase while the data bit timing is for the data phase. Okay, let us now enter the values we recorded in the previous table. Leave the massive RAM offset as 0, since we only have a single ft can instance. On the other hand, if we had multiple ft can instances enabled on the same node, then we would have to partition the RAM space accordingly. We only have one standard filter configured in this example, so enter 1 for the standard filter number field. However, for extended filter number, we enter 0 because we have no extended identifier message present in our project. As for the reception and transmission data structure, we will only need one rx buffer and one tx buffer, with each configured to fit up to 12 bytes of data. We won't be using any of the files in our example. You can read more about all the different reception and transmission data structures in the ft can application node, or read more about it in the microcontroller reference manual. Before finishing our cube MX configuration, we need to make some changes to the default ft can GPIO pen assignment. Keep in mind, you only have to change the default pen assignment if you're using the Nucleo H743 with chip revision V and port ID MB1364, else you can skip this step. Now, let's begin changing the pen assignment. Hold left control key on your keyboard, and hold left mouse button on the green pen GPIO. Then drag the pen to where you want it to move over to. Repeat this for the other pen as well. Finally, we are now done here. We can now generate our low level initialization code. We are done the basic ft can configuration for node one. For now, let's close the generated source file for node one. As well, close the IOC file for node one. Okay, this time we repeat the exact same process for node two. All of the IOC configuration is the same between node one and node two. So I'm going to speak this step up. This concludes our basic ft can configuration for both node one and node two. We are now ready to write our C code for establishing communication between the two can ft nodes. Again, close the generated main.c file for node two and close the IOC file we configured for node two. Let us start with programming our can ft node one. A quick reminder, you have the option to use the zip folder linked in the description to copy and paste the required source code as we go along. With that in mind, we can now start coding. First, we'll begin by adding the required data structures for our example. Here we define five data structures. First is the filter configuration structure required by ft can reception handler. Next are the transmission and reception structures. Then we define two arrays, one for sending the data to node two and the other is for reception array receiving data from node two. Now we configure the transmission message header. We configure the node one with a standard can ft identifier and with an arbitrary message ID of hex one. We want node one to send a message with a data payload of 12 bytes and have bit rate switching enabled. For the ft can event five volt control parameter, we choose do not store tx event in this example. So you can also ignore the message marker parameter here. Next, we'll configure the standard reception filter. Here we want to filter into reception buffer index zero for specific message ID. Namely, we want to filter for message identifier hex two which is node two message identifier. Next, we start the ft can referral here. We transmit the message from the transmission buffer and we wait for the transmission to be sent successfully using a while loop. For the reception of messages from node two, we also use polling method to wait until a message is ready for node one to read. The polling for both the transmission and reception is important here. Else the ft can communication would likely fail if we don't wait. And here is node one checking the reception buffer index zero for the array data from node two. We can now wrap up the coding for node one and save our progress. Great, now we need to replicate the coding process for node two but with minor differences like the message identifier and the filter ID. We will speak through the next step since the coding is essentially the same between node one and node two with the exception of node two message identifier and the filter ID for accepting message from node one. I will highlight the differences as we go along. Pay attention to the transmission message identifier here. For node two, we use an identifier with the value of hex two. This value is also used by node one reception handler filtering system. We also need to pay attention to the filter ID one value. Here, we give it a value of hex one because that's the message identifier for node one. Now let us compile the code for node one and for node two project. Make sure there are no errors or warnings present. Next, click on the main dot C for node two. Then click on the build icon again so we can compile the project for node two. Before uploading a binary into the nuclear board, we have to configure the debugger setting for both nuclear boards. Let's start by configuring node one first. So, click on the main dot C for node one project. Then click on the debug config as shown. Click on the debugger tab. Since we will be simultaneously running multiple debuggers in our SDM32 cube IDE session, we need to configure the two unique port numbers for each debug session. For node one, we will use the default value of 61234. We have two boards connected to the host. Therefore, we have to assign the board serial number for each debug configuration. This completes our debugger configuration for node one. Click apply to save the changes and then we move on to node two. For node two debug configuration, the process is the same, but the port number and the serial number assigned to debug configuration will be different. Finally, we can begin the debug session for node one and node two can FD communication. To observe the data transferring between the nodes, we're going to add the node one and node two transmission and reception arrays into the expression tab of the debugger view. Do the same for node two. Add the arrays into the expression view window. As shown, both the reception arrays are currently populated with zeros. Now, click resume on the green play button for both node one and node two. After pausing, you should observe both reception arrays getting populated with data from their respective nodes. This concludes our hands-on example. For your reference, you should observe a signal like what's shown here. Connecting our oscilloscope probe to pin PB9, we can observe the transmission signal shown. The figure represents only a small snapshot of the signal. The arbitration phase of the signal is running at 500 kilobits per second, while the data phase is transferring data at 1 megabit per second. And for the reception pin, PB8, we observe a similar signal as shown. Again, the figure represents only a small snapshot of the phone can FD signal. Relevant application nodes, as well as the reference manual and the data sheet can be found in the following links. We hope you found this video helpful. Thank you very much for watching.