 This is Saig from SD Microelectronics. In this video, I'm going to show you how to self-test the SDM32's FT-CAM peripheral using the external loopback mode feature. The agenda for this video is divided into seven sections as shown. We start with a brief CAN FD overview. Then we'll proceed to show example of standard CAN message filtering. Then move to a brief overview of CAN FD test modes. In particular, we will focus our attention on external loopback mode. Moving forward, we will show how we calculate FT-CAM bit timing using online bit timing calculator. And finally, we began the hands-on FT-CAM example. At the end, we will quickly review the expected result from the receipt buffer and oscilloscope. 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 FD protocol overview, frame architecture comparison to older CAN 2.0, FT-CAM main features, RAM management, RAM sections, which include RAM filtering sections, reception sections, and transmission sections. As well, the document goes over the test modes, transceiver delay compensation, clock calibration on FT-CAM, and the last section document goes over the SDM32 FT-CAM improvements over the older SDM32 BX-CAN IP. For this hands-on, we'll test the CAN flexible data rate using the external loopback test mode. We will observe the CAN FD communication using the FT-CAM 2 receipt buffer. And optionally, we can observe a digital signal output directly from the FT-CAM controller using an oscilloscope or a logic analyzer. As a side note, please be aware, you can access all the materials discussed in this video through the links shared in the description. As well, if we need to brush up on the theoretical aspect of CAN FD, please refer to our SDM32 H7 online training video 47. In this hands-on example, we will use the Nucleo H743 Zi2, a micro USB cable, and an oscilloscope for verifying the output signal. Please note that the oscilloscope is not necessary for experimenting with the example. Please also note that although we're using the Nucleo H743 Zi2 for this hands-on, the process is the same for other SDM32 H7 MCUs. To commence the series, we will do a quick CAN FD protocol overview. The CAN protocol is a standard serial differential bus broadcast communication system. The differential signaling on the physical layer helps with mitigating any induced noise on the bus. Thus, it's a suitable communication method in industrial or automotive settings. Since CAN node broadcasts its messages, it does not directly address other nodes on the system. So any message sent on the bus is also received by all other nodes. Messages are received by the intended target using local filters that accept or reject specific message identifiers that it receives. CAN bus is suitable for real-time application because of the bit-wise arbitration process for contention resolution, where the highest priority message takes control of the bus first. CAN with flexible data rate is an extension of classical CAN protocol in that it provides increased bandwidth. CAN FD can transfer data at higher rate up to eight megabits per second for data phase and the data payload capacity is increased to 64 bytes. In this slide, I will briefly brush up on the flexible data rate CAN frame format. The FD CAN frame is divided into three phases, namely first arbitration phase, the data phase, and the second arbitration phase. First arbitration phase contains the starter frame, message ID field, message control, and status field. The transmission phase consists of the data length code, the data to transmit, and the checked cyclic redundancy sequence, CRC, for data integrity check. And finally, second arbitration phase contains the acknowledgement field transmitted by other nodes on the bus. This bit is transmitted as acknowledged if at least one node successfully received the message, the end of frame field, the end of frame space, which is used for separating the current frame from the next. All transmitted and received messages are stored in the CAN message 10 kilobyte RAM space. The message RAM has a width of 32 bits. The FD CAN module can be configured to allocate up to 2,560 words into the message RAM. Now I will briefly touch the topic of the received handler. The RX handler controls the transfer of received messages from the CAN core to the external CAN message RAM. The FD CAN referral offers a possibility to configure two sets of acceptance filter, one for standard identifiers and one for extended identifiers, to store or to reject received messages. Up to 128 filter elements can be configured for the 11 bit standard IDs and up to 64 filters, elements can be configured for 29 bit extended IDs. The user chooses to enable or disable each filter element and can configure each element for acceptance or rejection filtering. Each filter element can be configured as a range filter. The filter matches for all the messages with the identifier and the range defined by the two IDs. Filter for dedicated IDs, the filter can be configured to match for one or two specific identifier. And finally, the classic bit mass filter to match groups of identifiers by masking bits of received identifiers. The first ID configured is used as a message ID filter. The second ID is used as a filter mask. Each zero bit at the filter mask mask out the corresponding bit position of the configured ID filter. You can read more about these application filters in the FD CAN application node or refer to your MCU reference manual. Here, I will go over a brief example. They'll configure four different filters for handling message reception. First is a range filter from hex 16 to hex 20. Second filter accepts only messages with IDs that are either hex 15 or hex 120. And then we store them in 501. Third filter also accepts messages with specific ID. But this time we store it in a specific buffer index. And the last filter is a classic masking filter for accepting messages with specific bit patterns in the identifier. The table shown presents different configurations of the standard 11 bit message ID filter for that example mentioned in previous slide. Each standard filter element contains standard filter type, standard filter element configuration, standard filter ID one, standard filter ID two. The first filter is configured to reject the messages with IDs in the range hex 16 to hex 20. The second filter is configured to accept messages in the RX 501 with ID equal to dual ID hex 15 or hex 120. The third filter is configured to store messages in RX buffer at index four. Only messages with ID equal to hex 130 will be accepted. The fourth filter is configured to accept any message identifier with this specific bit pattern as shown in ID one. While ID two is a bit mask used to ignore certain bits, within the operation mode of FD can, several test modes are available beside the normal operation. We can test our can FD system using one of the test modes that are used for self tests. You can read details of each test mode from the application node or from the MC reference manual. Here, we will only focus on external loopback test mode. In the loopback test mode, we have the freedom to test our can FD controller without external hardware requirement like the can FD transceiver, which would be required to convert digital can FD signal to differential can H and can L signal. Let's review the two loopback modes available to us here. Internal loopback mode. This mode can be used for a hard self test, meaning the FD can can be tested without affecting a running can system connected to the FD can TX and FD can RX pins. In this mode, FD can RX pin is disconnected from the FD can and the FD can TX pin is held in recessive. Next, let's review the external loopback mode. The FD can treat its own transmitted messages as received messages and stores them if they pass the acceptance filtering into the RX buffers or into the FIFOs. To be independent from external stimulation, the FD can acknowledge errors in the loopback mode. In this mode, the FD can performs an internal feedback from its transmit output to its receive input. The actual value of the FD can RX input pin is disregarded by the FD can controller. The transmitted messages can be monitored at the FD can TX transmit pin using an oscilloscope or a logic analyzer. Now let us go over the hands-on example. Our task is to create a 12-byte transmit buffer to have the can FD controller send the 12-byte payload to itself. We need to configure the filter appropriately in order to accept the transmitted message into a reception buffer index zero. We will randomly pick FD can to controller. We will enable external loopback mode for self-testing. Therefore, we won't need any external hardware like the can FD transceiver. We will use Poly method to ensure the message has been transmitted successfully. Therefore, we will not be using interrupts. In addition, we will have both extended frame and dead rate switching enabled. Let's begin our demo by launching STM32Q IDE. Next, we'll create a new STM32 project. Under MCU selector, we'll search for STM32H743ZI. Select the MCU and click Next. For project name, we'll go with FD can underscore external underscore loopback underscore demo. Under connectivity, we'll pick one of the FD can controllers. We can't pick any FD can controller we want, so let's just go with FD can too. Next, let's configure the basic settings for the FD can controller. If you notice a red warning next to the clock configuration tab, like mine shows, then you need to resolve the clock conflict using the automatic clock issue resolver, as shown. We will begin configuring the FD can controller. Select frame format to be flexible data rate mode with bit rate switching enabled. Set mode to external loopback self-test mode. Auto retransmission. The transmitter checks for the presence of acknowledge bit and retransmit the message if no acknowledge was detected. In our case, we're working with external loopback mode where the acknowledge bit is ignored by the FD can controller. We can leave this as disabled. Transmission pause. This enables other can nodes in the network to transmit messages, even if their message has lower priority identifiers. This feature loses up burst transmission coming from single node and it protects against babbling idiot scenarios where the application program erroneously requests too many transmissions. Protocol exception. If the FD can receives a frame with FDF recessive and their reserve bit recessive, it will signal a protocol exception event by setting the protocol exception event bit and the FD can protocol status register. When the protocol exception handling is enabled, this will cause the operation state to change from receive state to integrating state at the next sampling point. In case protocol exception handling is disabled, the FD can will treat a recessive reserve bit as a phone error and will respond with an error frame. A phone error will be detected when a fixed phone bit field contains one or more illegal bits. As well, we'll keep this feature as disabled for now. For the nominal bit and data bit timing, we have to make some calculations beforehand. Let's take a look and see how it's done. For bit time calculations, we will use third party online tools such as the Kavassar Canon FD calculator. For using this tool, all we need are three different parameters, namely the clock tolerance, total node delay and peripheral clock frequency. We can determine the clock tolerance using the data sheet and obtain the parts per million tolerance using the converging factor shown. For node delay, we'll just assume a value of 180 nanosecond. We already know the peripheral clock frequency to be 50 megahertz. Entering the required parameters and the Kavassar Canon FD calculator, we obtain the following table for 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. Now, let's enter the values we recorded in the previous table. Leave message RAM offset as zero since we only have one FD-CAM instance. If we had multiple FD-CAM instances enabled on the same node, then we have to partition the RAM space accordingly. We only have one standard filter configured in this example. So enter one for the standard filter number field. However, for the extended filter number, we enter zero because we have no extended identifier message present in our project. As for the reception and transmission data structures, we will only need one Rx buffer and one Tx buffer, each fitting up to 12 bytes of data. We won't be using any of the five rules in our example. You can read more about the difference between their reception and transmission data structures and the FD-CAM application node or read more about it in the reference manual. Before finishing our Qt-MX configuration, we need to make changes to the default FD-CAM GPIO pen assignment. You only have to change the default pen assignment if you're using the Nucleo H743 with chip revision fee and board ID MB-1364. Else you can skip this step. 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 to move over to. We are now done here. We can now generate our low-level initialization code. Before going further, please note that in this video description, you'll come across a zip folder containing a full working project, PDF slides, along with other text files containing the necessary code to be added here. First, we'll begin by adding the required data structures for our example. Next, we'll configure the standard reception filter. Here we want to filter into a reception buffer index zero for specific message ID, namely filter for message identifier hex 111. Now we configure the transmission message header. We configured a standard CAN FD identifier with message ID of hex 111. We want to send a message with a data payload of 12 bytes and have bit rate switching enabled. We send a message to the transmission buffer in the RAM. Then start the FD-CAM peripheral. Finally, we transmit the message from the transmission buffer and we wait for the transmission to be sent successfully using a while loop. Note, we are not using an interrupt, so it's necessary to pull for the transmission completion before we move on. As a last step, we check for the reception buffer for the expected data. Next, click on the hammer icon for compiling our code. We will now try to upload our project into the microcontroller. Click on the green debug icon. Next, click on the debug tab, where we will select the board we want to upload the code into. Check the ST-Link serial number scan. Then click on the scan to search for ST-Link serial number. In my case, I have two identical boards connected to my PC, so I will just select the first serial number in the list. Click OK. Then the debugger should launch on its own. In the debugger window, we will add the TX array and RX array into the expression window so that we can observe changes in the reception data array. Here, we can see the content of TX array duplicated into the RX array, meaning we successfully transmitted and received Canada message via external loopback self-test mode. Connecting your oscilloscope or logic analyzer to transmit PIN PB6, we can observe a signal similar to what's shown in this figure. Keep in mind that since we're running an external loopback mode, we cannot see any signal on the reception PIN PB5. Relevant application notes, as well as the reference manual and datasheet can be found in the following links. We hope you found this video helpful. Thank you very much for watching.