1. Introduction This is the fourth article in the Beginner’s Guide series and it aims to showcase how to configure the CAN peripheral to be able to send and receive CAN messages over the CAN Bus using the MR-CANHUBK344 Evaluation Board. For more details about the MR-CANHUBK344 board or step-by-step instructions on how to run a Simulink ® model on it using MBDT, please check out the first article in the series: Interacting with Digital Inputs/Outputs on MR-CANHUBK344. This article’s application consists of reading digital and analog inputs, processing them before they are sent across the CAN Bus from one CAN instance to another, and then controlling digital and analog outputs based on the received message. 1.1. Extra Prerequisite Software On top of the requirements from the first article, the application that we are developing in this article requires the Vehicle Network Toolbox TM from MathWorks. 1.2. Optional Hardware In this article we are going to show the messages that are sent across the CAN Bus using a device that can interact with the CAN Bus. The specific model we are using is the PCAN-USB Pro FD. 2. CAN Configuration This chapter will focus on the changes that have to be made in the configuration project in order for the board’s components to communicate properly with each other. It will focus mainly on the CAN-related settings, as the settings for the DIO, ADC and PWM have been explained in the previous articles. 2.1. Hardware Connections The MR-CANHUBK344 board has 6 CAN instances, with 3 different transceivers among them. CAN0 and CAN1 use TJA1443ATK, CAN2 and CAN3 use TJA1463ATK and CAN4 and CAN5 use TJA1153. Each of the CAN instances has 2 identical connectors, wired to each other, labelled A and B, to allow for daisy chain wiring. In this article we will focus on communicating between the CAN0 and CAN1 instances. Note: A CAN bus usually requires 60 Ohm termination at both ends of a CAN bus. This may be accomplished using one of the included CAN Term boards. For a CAN instance to work properly, the unused connector (if there is one) has to be connected to a CAN Term board, which is included in the MR-CANHUBK344 package. Below you can find a schematic that shows how the CAN0 instance is connected to its transceiver and how the signals are routed between them: 2.2. Pins Configuration The pins for the CAN instances can be found by searching for the component name inside the schematic. For this article’s purpose, I have extracted the necessary pins below. The _RX and _TX pins are linked directly to the CAN instance, while the _ERRN, _STB and _EN pins correspond to the transceiver associated to the CAN instance, like illustrated in the schematic above. To start configuring the pins, we have to open the Pins Tool, inside the S32 Configuration Tools. To quickly open the configuration project for a model, you can click on the Configure button from the window that appears when double-clicking a MBDT Block. Once the software has opened, clicking the Pins button will open the  Pins Tool. Inside the Pins Tool, we will focus on the top-left window, called the Pins tab. First, we check if the pin we are trying to add already exists in the configuration by typing the name in the search bar. Here we can see that no other pin is configured for this purpose (by the lack of green checkmarks in the box to the left). This has to be done for every of the 12 pins that we are configuring. This process has been showcased in detail in the first article, Interacting with Digital Inputs/Outputs on MR-CANHUBK344. Here is a case where the pin already exists. The steps that have to be taken in order to remove the old configuration consist of clicking the green checkmark, and then unchecking the currently selected option in the window that pops up. After checking every pin, we can start adding the ones we want to configure. Note: CAN_RX, CAN_ERRN are inputs, while CAN_TX, CAN_STB and CAN_EN are outputs. The CAN_STB and CAN_EN are outputs because we will set appropriate values to them to initialize the transceiver by switching it into the normal operating mode, while the CAN_ERRN is an input because it is used to inform the MCU about possible problems that can take place when initializing the transceiver. To do that, we type the pin’s value in the search bar. As an example, let’s look at some of the pins that we are configuring: The LED_CAN0 pin is connected to a red LED placed near the CAN connector which is used separately from the CAN, similarly to any other LED on the board. It also shares the same inverted logic as the other LEDs. It has the corresponding value PTC18, which we type in the filter. Afterwards, we populate the Identifier and Label fields with the pin’s name. Then we click the checkmark to the left and select the appropriate option in the window that shows up. Here, the for the LED we select the SIUL2:gpio,82 option. Since we are configuring an LED, which is an output, we also select the Output option in the window that asks for the pin’s direction. The process is similar for the other pins, but keep in mind that when configuring the CAN_RX and CAN_TX pins, you have to choose another signal from the list of available signals. Given the difference between the pins we are configuring, the CAN_ERRN, CAN_EN and CAN_STB are connected to the SIUL2 peripheral as inputs/outputs, while the CAN_RX and CAN_TX are connected to their respective CAN peripheral. Here is how that looks for the CAN0_RX pin: This is how the signals for the CAN0 and CAN1 instances look after being configured: To be able to see the signals in a similar manner, you can type “CAN” in the search bar of the bottom window, called Routing Details. Next, we have to return to the Peripherals Tool by clicking the highlighted button.   2.3. Component Configuration 2.3.1. CanController To start configuring the CAN instances, the first step is to open the Can_43_FlexCAN component and navigate to the CanController tab, inside the CanConfigSet panel. Here we are going to configure the two CAN controllers that correspond to the CAN0 and CAN1 instances. The CanController section provides all the necessary settings to configure a CAN controller instance, as required by the application.  You can expect to interact with some of them more frequently than the rest, so we are focusing on explaining what these do. The Name field controls the name that is associated to the controller and it is used to reference the controller in other menus. Can Hardware Channel controls which physical CAN instance is connected to the current controller. The Can Controller Activation checkbox enables the Can Controller. Without it, the controller does not function. CAN Rx/Tx Processing Type enables/disables read and write operations through Can_MainFunction_Read(), respectively Can_MainFunction_Write(), for handling PDU (Protocol Data Unit) events while set to polling. If the parameter is set to POLLING or MIXED, then the functions mentioned will be polling for RX Indication or TX Confirmation. If the parameter is set to MIXED, then only the hardware objects which have the attribute CanHardwareObjectUsesPolling set to true will be affected. Alternatively, if the parameter is set to INTERRUPT, Can FD ISO controls whether the Flexible Data-Rate feature is enabled on the Controller. In this example, we use the Can FD protocol for communicating between CAN instances so it will be checked. The Can Controller Default Baudrate field is responsible for choosing which Baudrate configuration to assign to the controller. The Baudrate configuration will be presented in the following screen. CanCpuClockRef allows you to select the reference clock. For the CAN peripheral, there are 2 clocks available, FLEXCAN_PE_CLK0_2 and FLEXCAN_PE_CLK3_5, covering the CAN0, CAN1, CAN2 and CAN3, CAN4, CAN5 respectively. These clocks can be configured inside the Mcu component, which will be shown in the following chapters. The Name field is used to select it in the Can Controller Default Baudrate field from the previous screen. Can Automatic Time Segments Calculation can be used to automatically set the Can Propagation Segment, Can Phase Segment 1 and Can Phase Segment 2 according to the Bitrate and the Can Controller Prescaler. Can Controller Prescaler sets the prescaler for the controller, based on the Clock selected. Can Controller BaudRate (Kbps) controls the speed that the data is transferred at. In the following section, containing Can Propagation Segment, Can Phase Segment 1 and Can Phase Segment 2 you can configure the timings of the CAN transfer. And finally, in the bottom section you can configure the timings for the Flexible Data-Rate protocol, by changing the Can FD Controller Baudrate, Can FD Propagation Segment, Can FD Phase Segment 1, Can FD phase Segment 2, Can FD Resynch Jump Width and Can FD Prescaler. These can be seen as FD equivalents for the previous settings. The first section allows you to configure the CanRamBlock associated with the current Can Controller. A CAN controller’s CAN RAM contains CAN hardware objects defined as a PDU buffer. The CAN RAM block can store message buffers in different configurations of sizes. According to the S32K3XX reference manual, the RAM block can store 32 messages of 8 bytes, 21 messages of 16 bytes, 12 messages of 32 bytes or 7 messages of 64 bytes. In the second section, CanRxFifo, the RX Fifo can be added or removed. According to the S32K3XX Reference manual, only the CAN0 allows the use of Enhanced RX FIFO. So if you are using another CAN instance and the FD protocol, the CanRxFifo should be disabled duo to the incompatibility between CanLegacyFifo and the FD protocol. Since this article’s application involves 2 CAN instances communicating with each other, it means that another Can Controller has to be set up besides the one that is already here. To have a solid starting point for the second Can Controller’s configuration, you can copy the current controller’s configuration and paste it into a new one. After completing the steps above, you will end up with 2 identical Can Controllers, which will cause conflicts due to duplicate items. To solve this, fill in the details for the second Can Controller. In this case, that only involves changing the Name, the Can Hardware Channel, the Can Controller ID (which should simply increment) and Can Controller Default Baudrate (the correct one becomes available in the dropdown list after changing the Name field). The last setting that needs to be changed on this newly created Can Controller is deleting the CanRxFifo, since the CAN1 does not have the Enhanced Fifo feature and we are using the FD protocol at the same time. 2.3.2. CanHardwareObject The next step is configuring the Can Hardware Objects inside the CanHardwareObect tab, still under the CanConfigSet menu. Working in a similar manner to the previous subchapter, we will focus on the explaining the options that you can expect to use. First of all, as a general rule, the RX objects should be placed before the TX objects in the list of objects. So there shouldn’t be any RX object with an ID that is higher or equal to the lowest TX object’s ID. The Name field controls the name associated to the hardware object that is displayed inside MBDT blocks. The Can ID Message Type controls whether the can message’s ID type is Extended, Mixed or Standard. Can Object ID acts as an identifier for the hardware objects. It starts with 0 and should continue without any gaps. Can Object Type controls whether the hardware object will be used to receive or transmit CAN messages. Can Controller Reference selects which Can Controller this object is configured for. Can Hw Object Count defines the number of elements in the hardware FIFO. The CanHwFilter is used for filtering messages. The Can Hw Filter Mask determines which part of the filter is active. The decimal number 536870911 converted to binary is 11111111111111111111111111111 (29 digits). This means that the mask enables the entire filter, since the extended ID format has 29 bits. The Can Hw Filter Code is the ID that the message would be compared to, based on the filter mask. Let’s look at the example in the image: Filter Code:  00000000000000000001111110000 (1008 in decimal) Filter Mask:  11111111111111111111111111111 Allowed IDs: 00000000000000000001111110000 (1008 in decimal) This means that the filter only allows messages coming from the extended ID 1008. If you want the filter to allow more than one value, you have to modify the filter mask in such a way that the filter does not check if every bit is equal to the filter code. Another example: Filter Code:  00000000000000000001111110000 (1008 in decimal) Filter Mask:  11111111111111111111111111110 Allowed IDs: 00000000000000000001111110000,                      00000000000000000001111110001 (1008 and 1009 in decimal) In this case, the filter mask allows the last bit to be different from the filter code. Since the Can Hardware Objects that already exist are properly configured for the CanController_0, we do not have to perform any changes. But, for the CAN1 to be able to communicate with the CAN0 instance, we have to add a TX (Transmit) hardware object for it. To do that, click on the highlighted + Button and then configure the object accordingly. As an alternative, you could copy the configuration from CanHardwareObject_Can0_Tx_Interrupt and simply change the fields that are relevant to the CAN1. This means changing the Name to reflect the correct controller, updating the Can Object ID, making sure that the Can Object Type is set to TRANSMIT, and changing the Can Controller Reference to point towards the CanController1. After finishing these configuration steps, the CAN0 would be set up to both receive and send messages, while the CAN1 is configured to only send messages. 2.4. CanIf Configuration The CAN Interface is found between the low-level CAN drivers and the upper communication service layers from the AUTOSAR stack. It provides a way to interact with different CAN Hardware device types like CAN Transceivers and CAN Controllers. Next, the newly created Can Controller (for the CAN1) has to be added to the CanInterface, in the CanIfCtrlCfg section, inside the CanIfCtrlDrvCfg menu. To add a new CanIfCtrlCfg element, press the + button, and then you have to update the CanIfCtrlId field and choose the right Can Controller for the CanIfCtrlCanCtrlRef.   2.5. Clocks Configuration (MCU) In order for the CAN instances to work properly, their clock has to be enabled in the McuModeSettingsConf tab, under McuModuleConfiguration, in the Mcu component. Once on this page, you have to scroll down and verify that the Clocks corresponding to your FlexCAN instances are enabled. By default, they are enabled in this current configuration, but it is important to remember that the CAN peripherals require to have their clocks. To change the reference clock, CanCpuClockRef, for a set of Can Controllers, you can find them in the McuClockSettingsConfig > McuClockReferencePoint.   2.6. Interrupts Configuration (Platform) The last step in the Configuration Tool is to set up the Interrupts for the CAN instances that we are using in this model so that we can use Interrupt-based blocks. To do that, head to the Platform component, by clicking the Platform button on the left of the Peripherals Tool. Afterwards, we have to navigate to the Interrupt Controller tab, where we can see all the interrupts that are currently configured. To configure the CAN instances, scroll down until you see the FlexCAN instances that you are configuring. In this article we use the CAN0 and CAN1 instances, so we are configuring these two instances. When it comes to FlexCAN interrupts, the FlexCAN0_0 contains 9 general interrupt requests, while the FlexCAN0_1 – FlexCAN0_3 instances contain 96 message buffer interrupts. More details about the interrupt mappings can be found inside the reference manual, S32K3XXRM, by consulting the attached file called S32K3xx_interrupt_map.xlsx. As you can see, one of them is already configured, so we only have to configure the FlexCAN1 instance as follows:   2.7. Dio Configuration The Input/Output pins configured previously also have to be configured in the Dio component, similarly to chapter 2.3. from the first article, Interacting with Digital Inputs/Outputs on MR-CANHUBK344. Now, inside the Dio component, we are configuring the input/output pins that will be used later in the model to enable the transceivers. Briefly going over the process, we have to remove the default pins that do not match the configuration we are working on. In this situation, it means removing the CanController_0_EN, CanController_0_STB and CanController_0_ERRN channels from the DioPort PTC_H. Afterwards, we add the Input/Output pins configured previously.   2.8. Uart, FreeMASTER, Adc and Pwm Configuration This article’s application involves using the Adc and Pwm components, as well as the FreeMASTER functionality, the way they were configured in the previous articles. For details on how to configure Uart and FreeMASTER, please refer to the second article, Sending data via UART and monitoring signals with FreeMASTER. As for the Adc and Pwm configurations, you can find step-by-step instructions in the third article of this series, Controlling LED intensity with ADC and PWM. For these components, there is no difference from the setups described in the referenced articles.   3. CAN Model Overview This article’s application aims to incorporate the previous components into a single example. This application consists of gathering data from two inputs, the ADC potentiometer and the USER_SW2 button, processing it, packaging it and sending it across the CAN Bus, so that it can be received by the other CAN instance and then control two outputs. The two outputs are a Blue LED that turns on according to the USER_SW2 button presses, and a Red LED whose intensity varies based on the rotation from the potentiometer. The following diagram aims to provide a better understanding for the flow of this application: Now, let’s break down the model into smaller pieces. Starting from the top left, the model uses a few variables. These have been grouped based on their purpose. For example, the Channel1 variable from the ADC is responsible for holding the value read from the ADC. Similarly, in the case of the CAN instances, the variables Data and Length represent the message that has been received across the CAN Bus. The last panel is the most important one, representing the values of the Dio and Aio peripherals right after the CAN message has been unpacked. Moving on to the Initializations section, this is where we perform the operations needed to prepare the components. In this specific case, we initialize the 2 CAN transceivers by setting 2 of their inputs to HIGH. In the initialization subsystem, a result buffer is set for the ADC conversion and the group notifications are enabled, so the configured ADC callback would be executed when the conversion on the group finishes. Finally, we turn the LEDs of the board off since this board uses inverted logic for the LEDs, which means they would normally turn on along with the board. The FreeMASTER Config block is used for enabling FreeMASTER functionality for this project. Moving on, there’s one more block to talk about before explaining the active parts of the model, which executes each step and which starts the group conversion for the ADC. Once the conversion is done, the hardware interrupt for the ADC will be triggered and the subsystem linked to the hardware interrupt callback block will output the ADC signal. The conversion to single data type takes place because the CAN Pack block is configured to accept a floating-point number which represents a voltage between 0V and 3.3V, corresponding to how much the potentiometer is turned. As specified, we start by collecting data from the inputs, the Aio and Dio. In the case of the Aio, we scale the value to represent the voltage read by the ADC. To be able to package the data and interpret it after the transfer, we are using a DBC file. DBC is a CAN Database file, which describes what kind of signals will be stored and sent through the CAN message. Afterwards, the data is then sent to a VNT packing block (VNT stands for Vehicle Network Toolbox TM ). By opening the CAN PACK block, we can see that the signals configured in the DBC file have been parsed properly and the block now expects them as an input. The ADC value will be a 32-bit variable, representing a voltage between 0V-3.3V, while the Dio variable will only have 1 bit, representing whether or not the button is pressed. In total, the variables take up 5 bytes, which becomes the length of the message. The next block, CAN Unpack, is used to extract the raw data from the CAN Frame, since that’s what will be sent by the CAN Transmission block. Can_Write is one of the available functions for the Can block and as the name suggests, it’s responsible for sending the CAN Message across the CAN Bus. The second dropdown item allows the user to select which CanHardwareObject will be sending the data. The items that appear here are the items configured as TRANSMIT in the menu seen in section 2.3.2. In this application, the data is being sent using an interrupt-based hardware object. The CAN FD Message checkbox selects whether the message being sent is using the CAN FD protocol and the Extended ID CAN Message selects the format for the ID. These should reflect the settings done in the configuration software. The second half of the application start with the CAN0 receiving the message sent by the CAN1. One important thing to note about how this works is that receiving the message is based on the CanIf_RxIndication, which triggers the Hardware Interrupt Callback. Afterwards, we can access the data. In the Hardware_Interrupt_Handler block, after selecting Can as the Interrupt Group, the following list of Can-related callbacks is made available. This application requires the ability to read incoming CAN Messages, so the CanIf_RxIndication is used for that purpose. CanIf_RxIndication is a callback which has an interrupt-based execution, being called whenever a CAN frame is received. Before obtaining the actual values from inside the CAN Message, we have to, once again, use the CAN Pack and Unpack blocks to extract the data and decode it according to the DBC file. Now that we have the values, we use the ADC value to proportionally change the brightness of the Red LED, and we use the value of the DIO to turn on or off the Blue LED. To validate the model, we can use the FreeMASTER tool to read and graph the values. As we can see, the received message is made up of 5 bytes of data, which represent the Adc Value and the Dio Value. Below you can see the variables' representaton on a graph made in real time in the FreeMASTER software. The red signal represents the value read from the potentiometer, situated between 0V and 3.3V. The blue signal corresponds to the state of the button: if the button is pressed, the blue signal will be equal to 1; otherwise the signal will be 0. On the bottom of the window, you can see the values of the signals at the time the screen capture happened. Apart from the ADC_Received and Dio_Received variables, which correspond to the red and blue signals from the graph, the other variables provide details about the last CAN message received.  By connecting the device capable of reading CAN messages, we can also see  them being transmitted through the CAN Bus. Here we use the PCAN-View software application to show the messages captured by the PCAN-USB Pro FD.     4. Conclusion After following the steps in the tutorial, you should now be able to include the MR-CANHUBK344 board into applications that require CAN Communications, either between the MR-CANHUBK344 board and a third party, or even between different CAN instances  from the same board. This article’s application also serves as an example on how to manage the workflow of adding multiple MBDT components into a single model.     Instructions on how to run the attached model: Download and extract the archive’s contents; Copy both the .mdl and .mex file to the location where you wish to set up the project; Note: for the model to work properly, please place the .mex and .dbc files next to the model. Open the .mdl file and make sure that MATLAB’s Current Folder points to the folder that contains the model; Click on the Hardware tab and then press the “Build, Deploy & Start” button.   Simulink is a registered trademark and Vehicle Network Toolbox is a trademark of The MathWorks, Inc. See mathworks.com/trademarks for a list of additional trademarks.

1. Introduction This is the second article in the beginner’s guide series and it showcases an example application developed in MATLAB ® Simulink ® for the MR-CANHUBK344 evaluation board. The application illustrates the ease of utilizing UART capability through NXP ® 's Model-Based Design Toolbox. For more details on MR-CANHUBK344 and how to do the initial setup (Simulink environment, J-Link debugger, etc.) please refer to article 1. 2. UART Configuration The focus in this chapter will be to provide a detailed guide on how to configure the UART (Universal Asynchronous Receiver-Transmitter) peripheral, by covering all the necessary steps such as configuring an UART instance and its corresponding pins for data transmission and enabling the peripheral clock and interrupts. Configuration of the MCU peripherals, the clock and pins direction, can be performed using S32 Configuration Tool (S32CT) which is proprietary to NXP. Please be advised that exactly the same microcontroller configuration can be achieved using Elektrobit Tresos Studio (EB Tresos). 2.1. Hardware Connections Looking at the Schematic of the evaluation board (MR-CANHUBK344-SCHematic), we can see that the LPUART2 peripheral can be routed through the debug interface: This is very convenient since the kit includes a DCD-LZ Programming Adapter, a small board that combines the SWD (Serial Wire Debug) and the Console UART into a single connector. 2.2. Pins Configuration For configuring the LPUART2 peripheral pins, we must open the configuration project (please check article 1 for more information on this process) and access the Pins Tool (top right chip icon).   While in this screen, from the Peripherals Signals tab, we can route the lpuat2_rx to the PTA8 pin and lpuart2_tx to the PTA9 pin: 2.3. Component Configuration In this subchapter, we dive into configuring the UART peripheral, component that allows the serial communication. We will also explore the various settings and parameters that enable efficient data transmission and reception. First, the LPUART_2 instance must be assigned to UartChannel_0 of MCAL AUTOSAR module by doing the following settings in the UARTGlobalConfig tab, which can be opened also from the Components tab: UART asynchronous method is set to work using interrupts as opposed to DMA. This method dictates how the mechanism for the functions AsyncSend and AsyncReceive works. More will be discussed in chapter 3. Other settings here include: Desire Baudrate (115200 bps), Uart Parity Type, Uart Stop Bit Number, etc. . These are important as they will have to be mirrored later in the PC terminal application. Afterwards, go to GeneralConfiguration and please note that the interrupt callback has the name MBDT_Uart_Callback, this is already configured in the default S32K344-Q172 project: MBDT_Uart_Callback is the name of the user defined callback which will have its implementation designed in the Simulink application. It will be called whenever there is an UART event: RX_FULL, TX_EMPTY, END_TRANSFER or ERROR. We can give any name to this callback, but since it will also be later used in the Simulink model implementation, it would be easier to keep the same nomenclature, at least for the purpose of this example. 2.4. Clocks Configuration (Mcu) In this subchapter we enable the clock of the LPUART2 instance, in the Mcu component: In the newly opened Mcu tab, go to McuModuleConfiguration then McuModeSettingConf and then to McuPeripheral: Then enable the clock for the LPUART_2 peripheral: UART is an asynchronous data transmission method, meaning that the sender and receiver don't share a common clock signal. Instead, they rely on predefined data rates (baud rates) to time the transmission and reception of bits. The clock, in this context, is used to establish the bit rate and ensure that both the sender and receiver are operating at the same speed. This synchronization enables successful data transmission and reception, preventing data loss or corruption. In UART, the transmitting device sends data bits at regular intervals based on the clock rate, and the receiving device uses its own clock to sample and interpret these bits accurately. This asynchronous nature makes UART suitable for various applications, allowing data to be transmitted reliably even when devices have slightly different clock frequencies. 2.5. Interrupts Configuration (Platform) In this subchapter, we will illustrate how to enable the UART interrupts. To find the corresponding settings we need to access the Platform component, afterwards we go to Interrupt Controller and then enable the UART interrupts: The interrupt controller from the Platform component configures the microcontroller interrupts vector and the handler there is the one declared inside RTD (Real-Time Drivers), implemented also inside RTD. It means that the LPUART_UART_IP_2_IRQHandler is already defined and it is not recommended to change its name. We are just pointing the interrupts vector to use it. 3. UART Model Overview In this chapter we will do the implementation for a simple Simulink model that uses the above configuration of the microcontroller to send a message via UART when the processor initially starts, and then echo back the characters that we type in a serial terminal. For implementing our application we are going to create a Simulink model, where we can drag and drop the UART block from the Simulink library to implement the logic of our application. The UART block can be found in the Simulink Library under the NXP Model-Based Design Toolbox for S32K3xx MCUs. The UART block can be found under S32K3xx Core, System, Peripherals and Utilities in CDD Blocks: After adding it to the Simulink canvas we can double click on it to access the block settings: Here the desired function can be selected: GetVersionInfo, SyncSend, AsyncSend, GetStatus etc.   Some useful information can be found below, regarding the functions that will be later used in this example, as an addition to what the Help button already provides. Uart_SyncSend is used for synchronous communications between the target and the UART terminal as it is checking the status of the previous transfers before proceeding with a new one (not to be confused with a synchronous serial communication, there is no separate clock line involved). This method of transferring data bytes ensures that the transmission buffers are free while it is blocking the main thread of execution until the corresponding transmit register empty flag is cleared. Uart_AsyncSend function, as a method of transferring data, is called asynchronous because data can be transmitted at any time without blocking the main thread of execution. It is recommended to be used in conjunction with transfer interrupts handlers to avoid errors. Uart_AsyncReceive is the function used to get the input data. Its output, Data Rx, is used to specify the location where the received characters will be stored. By placing this block in the initialize subsystem and in the interrupt callback, as we are about to see in the following chapter, we make sure that each character received will be stored and also that the receive interrupt is ready for the next event. Also, for UART, the Hardware Interrupt Callback block can be added from ISR Blocks: Here, the previously configured Interrupt handler (MBDT_Uart_Callback, see chapter 2) must be selected: The Hardware Interrupt Handler Block is used to display all the user defined callbacks that can be configured in S32CT, allowing their implementation in the Simulink model. In case of UART, the MBDT_Uart_Callback will be present in this block, to allow the implementation of specific actions when an interrupt occurs on the configured LPUART instance. If we would have modified the name of the receive callback in S32CT, after updating the generated code, we would be able to see the change in the Simulink block by pressing the Refresh button. Here’s how the overall picture of the implementation looks like on the Simulink canvas: In the Variables section we can see a list of DataStoreMemory blocks which act as memory containers similar with the global variables in C code. The Initialize block is a special Simulink function in which the implementation that we only want to be executed once, at startup, can be added. Inside this function block the variable transfer_flag is initialized with value 1, marking that the next event will be to receive a byte. Uart_AsyncReceive block sets a new buffer to be used in the interrupt routine where the character sent from the keyboard is stored. This function doesn’t actually read the character but only points to the memory location where the characters will be stored after reading it. Uart_SyncSend function will output the string of characters: “Hello, MR-CANHUBK3 here! Please write a message and I will echo back the characters as you type them”, framed by NL and CR characters. In UART Actions we have the Hardware Interrupt Handler Block that calls UartCallback at each transfer event, but we use the Event line to filter out all events except for END_TRANSFER. Now let’s see what’s inside the If Action Subsystem block: When a character is sent from the PC terminal and received in our application, an End Transfer event occurs (with receive direction) and the Send block is the executed path (because transfer_flag is equal to 1). This, in turn, will call the function Uart_AsyncSend to load the transmit buffer with that same byte that was received. Also the variable transfer_flag is changed from 1 to 2. When the transmit buffer was successfully emptied, meaning that a character was sent to the PC terminal, an End Transfer event occurs (with transmit direction) and the Receive block is the executed path (because transfer_flag is now equal to 2). This, in turn, will call the function Uart_AsyncReceive to reset the receive buffer making it ready for the next receive event. Also the variable transfer_flag is changed from 2 to 1. The Uart_GetStatus function block can be used to store the number of remaining bytes and the transfer status if further development of this example is desired. The complete  application together with the executable files can be found in the first attachment of this article (Article 2 - mrcanhubk344_uart_s32ct). 4. Test using the PC Terminal Emulator In this chapter we discuss the details of building, deploying, and testing the UART-based application. Our focus will be on the testing phase, creating an effective testing setup and ensuring that each element of the application performs correctly. First of all please make sure that the hardware setup with all the wires connected looks like this: Beside the hardware connections that are already mentioned in setup chapter from article 1, a USB to Serial converter device needs to be connected between the USB port of the PC and the DCD-LZ adapter that comes with the evaluation board. The DCD-LZ adapter is then connected to the evaluation board via the P6 debug port. The J-Link debugger can be connected directly to the evaluation board or to the DCD-LZ adapter via the P26 JTAG port. Once the hardware setup is complete, we can continue with the project build step. Pressing the Build button in the Embedded Coder ® app in Simulink, will generate the corresponding C code from the model. The code is then compiled and the executable file is created and deployed on the target (MR-CANHUBK3 evaluation board) using J-Link JTAG. As previously mentioned, a Terminal emulator program needs to be installed and configured on your computer and an USB to Serial converter needs to be connected between the computer and the target, as illustrated in the above picture. Probably the simplest choice for the Terminal would be PuTTY, which needs to be installed and then configured as follows: We can see now that the UART settings from chapter 2.3 are mirrored here. What port the USB-Serial converter uses can be found by looking it up in Device Manager, under the Ports tab. Here’s what will appear in the terminal once the application is deployed and running on the board: As a first part of the application’s functionality, after deployment, when the processor initially starts, a welcome message is sent: Hello, MR-CANHUBK3 here! Please write a message and I will echo back the characters as you type them. In the second part of the functionality, after the initialization phase, the UART terminal automatically transmits ASCII bytes corresponding to whatever is typed in the terminal window. If everything works correctly you will be able to see, being sent back like an echo, the characters that were just typed. In this case: 13780 -> Each typed in character is echoed back! 5. FreeMASTER Model Overview In this chapter we will discuss about the NXP proprietary FreeMASTER tool and how it can be integrated with Model Based Design Toolbox applications. We will build a second Simulink model to demonstrate its capabilities. FreeMASTER is a user-friendly real-time debug monitor and data visualization tool that enables runtime configuration and tuning of embedded software applications. It supports non-intrusive monitoring of variables on a running system and can display multiple variables on oscilloscope-like form or as data in text form. You can download and find out more about it on the NXP website. The FreeMaster blocks can be found under S32K3xx Core, System, Peripherals and Utilities in Utility Blocks: FreeMASTER Config block allows the user to configure the FreeMASTER embedded-side software driver, which implements the serial interface between the application and the host PC. It actually inserts the service in the application, and it is the only one mandatory to be added to the Simulink canvas in order to have the FreeMASTER functionality available. FreeMASTER Recorder block is optional and allows the user to call the Recorder function periodically, in places where the data recording should occur, in our case in the main step function. For this example the only configuration that is needed, is to select the appropriate UART instance, in our case LPUART2, and set the Baudrate to 115200 bps: It is important to mention that the UART instance that is used by the FreeMASTER toolbox cannot be properly used for other communication purposes. The reason for this is that, during initialization, the configuration for the transfer interrupt callbacks as well as the Tx and Rx buffers are changed definitively to be controlled by FreeMASTER. If the above-mentioned blocks would be added in the previously described Simulink model, then only the welcome message would appear in the terminal at initialization phase (after powerup or MCU reset). On the other hand, echoing back the characters that are typed in the terminal window would no longer work. This is not an issue since the terminal can no longer be used anyway. That is because the COM port of the PC is used by the FreeMASTER application, which would prevent any other app from accessing it. For these reasons a new project needs to be created in Simulink for the FreeMASTER example application, but the UART configuration created in chapter 2 can definitely be reused. Similar to the first part of the functionality that was described in chapter 4, FreeMASTER communication protocol is synchronous, using an implementation that resembles the one for the SyncSend function. The execution is blocking the Step Function (I.e., the main execution thread) for as long as it takes to free the transfer buffer, which normally happens instantly unless there is an error (like a broken physical wire). The flags that signal whether the transmission or reception registers are empty or full, respectively, are checked in a do-while loop in interrupts, in case of Long Interrupt Mode (See Mode setting in the FreeMaster configuration tab). To better understand how FreeMASTER works and how it can help development, a dummy variable called counter was created which does nothing more than just store the incrementing value coming from the Counter Limited Simulink block. For the purpose of this example the limit of the block was set to 200, meaning that the counter will reset when the value is reached. It is important to make sure that the compiler will not optimize the code in such a way that this variable could be renamed. If the variable is renamed it is difficult to be found in the associated FreeMaster project which will be described in the following section. Compiler optimizations on certain variables can be avoided by setting their Storage Class to Volatile or Exported Global as shown below: As previously mentioned, what we need to add to the Simulink model are the two FreeMaster blocks Config and Recorder. Here’s a picture with the overall view of the working canvas: Once the FreeMASTER blocks are added in the Simulink model, we can proceed with similar actions to the ones from chapter 4: press the Build button in the Embedded Coder app to generate the corresponding C code from the model, this code is then compiled, the s32k3xx_uart_fm_s32ct.elf file is created  and deployed on the target (MR-CANHUBK3 evaluation board) using J-Link JTAG. The complete application together with the executable files can be found in the second attachment of this article (Article 2 - mrcanhubk344_fm_s32ct). 6. FreeMASTER PC application Up until now, all that we discussed about FreeMASTER was related to the board side of the whole project: UART configuration, implementation of the Simulink model, hardware connections. In what follows we will do the setup for the FreeMASTER application on a Windows PC. For this, we need to install and launch FreeMASTER 3.2 or a later version (as mentioned in chapter 5 , you can download it from the NXP website) We now need to configure the hardware connection that is used for communicating with the board. Under Project – Options… go to Comm tab and choose the corresponding port (as mentioned in chapter 4, you can find out what port your USB-Serial converter uses by looking it up inside Device Manager, under the Ports tab or leave the Port value as COM_ALL for automatic port finding): In order to identify the variables that we want to watch, we need to point to the location where the .elf file is stored. Go to MAP Files tab and choose …\mrcanhubk344_fm_s32ct\mrcanhubk344_fm_s32ct.elf as Default symbol file: We need to create a Variable watch for the counter. For this, simply expand the drop-down list and begin typing the initial letters of the variable’s name: If the update rate of the value is not fast enough, the Sampling period can be decreased: OK, now we have the variable but we need to track its value evolution over time. We could use an oscilloscope for this. Create New Oscilloscope by right clicking on counter in the Watch window: At this point you can press Start communication (the green GO! button). Let it run for a few seconds in order to have it looking like this: FreeMASTER Recorder can be added to the window similarly to the method previously described. Press Start communication (the green GO! Button). The Run/Stop buttons can be pressed at the desired moment for starting or respectively stopping the recording of the specified variable. Time triggers can also be used to replace the button presses. The Simulink implementation can be updated at any point in time as needed. If the two FreeMASTER blocks are active then you should be able to add: multiple variables with the keyword volatile in front (in C code, if you wish to continue working with the generated code) or multiple DataStoreMemory blocks with Volatile Storage Class in Simulink. Then Build the model as usual to be able to monitor the newly added variables in the PC app. After build and deploy are completed, when the FreeMASTER window regains focus on the screen, please make sure to click Yes. This means that the newly created .elf file was automatically detected and the list of symbols needs to be resynchronized: This streamlined approach guarantees efficient variable tracking and management, elevating the debugging experience  and the quality of model-based design. 7. Conclusion The integration of Simulink UART and FreeMASTER blocks in model-based design offers an effective solution for developing and testing embedded systems. The Simulink UART block facilitates communication with external devices using UART protocols, enabling seamless data exchange. Meanwhile, the FreeMASTER tool enhances monitoring and control by providing real-time visualization of variables and parameters. Together, these tools streamline the development process, allowing for efficient testing, debugging, and optimization of embedded systems, ultimately leading to more reliable and robust products.   Instructions on how to run the attached model: Download and extract the archive’s contents; Copy both the .mdl and .mex file to the location where you wish to set up the project; Note: for the model to work properly, please place the .mex file next to the model. Open the .mdl file and make sure that MATLAB’s Current Folder points to the folder that contains the model; Click on the Hardware tab and then press the “Build, Deploy & Start” button.   NXP is a trademark of NXP B.V. All other product or service names are the property of their respective owners. © 2023 NXP B.V. MATLAB, Simulink, and Embedded Coder are registered trademarks of The MathWorks, Inc. See mathworks.com/trademarks for a list of additional trademarks.

  Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for S32K3xx – version 1.4.0 RFP   The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K3xx version 1.4.0. This release supports automatic code generation for S32K3xx peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3xx Automotive Microprocessors. This new product adds support for S32K310, S32K311, S32K312, S32K314, S32K322, S32K324, S32K328, S32K338, S32K341, S32K342, S32K344, S32K348, S32K358 and S32K396 MCUs and part of their peripherals, based on RTD MCAL components (ADC, PWM, MCL, DIO, CAN, SPI, UART, LIN, GPT). To enable BMS applications development, the toolbox offers support for MC33775A and MC33772C battery cell controllers (& MC33665PHY). In this release, we have also updated RTD, AMMCLib, and MATLAB support for the latest versions. The product comes with over 120 examples, covering everything that is supported, including demos for battery cell controllers (BCC) and motor control.   Target audience: This product is part of the Automotive SW – S32K3 Standard Software Package.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=14146527   Technical Support: NXP Model-Based Design Toolbox for S32K3xx issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt   Release Content Automatic C code generation from MATLAB® for NXP S32K3xx derivatives: S32K310 S32K311 S32K312 S32K314 S32K322 S32K324 S32K328 S32K338 S32K341 S32K342 S32K344 S32K348 S32K358 S32K396   Support for the following peripherals (MCAL components): ADC PWM MCL LIN CAN SPI UART GPT DIO   Board initialization: The Model-Based Design Toolbox for S32K3xx generates the component’s peripherals initialization function calls as configured in the Board Initialization window. The toolbox provides a default configuration including function calls for initializing the clocks, followed by pins and a custom order for the rest of the peripherals which have been configured in the project associated to the model. Moreover, the toolbox provides the option to save and export the initialization sequence to a file which can be later used for other models as well – in this way, the customization of the board initialization sequence can be done only once, even if applicable for other models as well. Such a file can be then imported as an external Board Initialization Template.   Custom Linker Files and Startup Code: The toolbox allows the selection of custom linker files and startup code to be used during the build process. By enabling the Use Custom Linker or/and Use Custom Startup Code checkboxes, this feature is activated, allowing the users to Browse for specific files.   Support for Referenced Configurations The Model-Based Design Toolbox for S32K3xx enables the usage of Referenced Configurations, a Simulink feature which allows users to share the configuration of an application with multiple models.   Support for MC33775A and MC33772C battery cell controllers & MC33665PHY The toolbox provides support for the MC33775A, MC33772C, and MC33665. The MC33775A and MC33772C are lithium-ion battery cell controller ICs designed for automotive applications which perform ADC conversions of the differential cell voltages and battery temperatures, while the MC33665 is a transceiver physical layer transformer driver, designed to interface the microcontroller with the battery cell controllers through a high-speed isolated communication network. The ready-to-run examples provided with the MBDT for S32K3 show how to communicate between the S32K344 and the MC33775A and MC33772C via the MC33665 transceiver. For the MC33775A, the examples show how to configure the battery cell controller to perform Primary and Secondary chains conversion, and read the cell voltages conversion results from the MC33775A, while for the MC33772C the examples show how to configure the Battery cell controller to read current. All the converted values are displayed to the user over the FreeMaster application.       Support for AUTOSAR blockset (SW-C deployment) New RTD version supported  (3.0.0) Provides 2 modes of operation: Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32 Configuration Tools or EB Tresos to configure peripherals/pins/clocks Integrates the Automotive Math and Motor Control Library release 1.1.32: All functions in the Automotive Math and Motor Control Functions Library v1.1.32 are supported as blocks for simulation and embedded target code generation.   FreeMASTER Integration We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications.   Support for MATLAB versions We added support for the following MATLAB versions: R2021a R2021b R2022a R2022b R2023a   S32Design Studio Integration We provide a simple mechanism for the users to export the code generated from Simulink and import it directly into S32Design Studio. This functionality can be useful if the model needs to be integrated into an already existing project or for debugging purposes.   Support for custom default project configuration The toolbox provides support for users to create their custom default project configurations. This could be very useful when having a custom board design – only needing to create the configuration for it once. After it is saved as a custom default project, it can be used for every model that is being developed.   Support for component restore to default settings The toolbox allows users to restore the configuration of a component (for models which use the EB Tresos configuration tool) to the settings corresponding to the Default Configuration Template the model uses. This allows reverting changes (if made) to the default values.   Simulation modes: We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL) External mode     Examples for every peripheral/function supported: We have added over 120 examples, including: Battery Management Systems examples Motor control applications (including eTPU example on S32K396) Communication (LIN, SPI, CAN, UART) AMMCLib Timer control (GPT) DIO FreeMASTER SIL / PIL / External mode For more details, features, and how to use the new functionalities, please refer to the Release Notes document attached. MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K3xx MCUs and evaluation board solutions out-of-the-box with: NXP Model-Based Design Toolbox for S32K3xx version 1.4.0 is fully integrated with MATLAB® environment in terms of installation:       Target Audience This release (1.4.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3xx MCUs and Evaluation Boards.   Useful Resources Examples, Trainings, and Support: https://community.nxp.com/community/mbdt          

1. Introduction This article shows how to develop an application for the UCANS32K1SIC evaluation board in MATLAB ® and Simulink ® and NXP ® ’s Model-Based Design Toolbox.  1.1. General purpose The UCANS32K1SIC is a CAN signal improvement capability (SIC) evaluation board designed for both automotive (ADAS, Body Control Units etc.) and industrial applications (Building Control, Servos, Mobile Robotic, etc.) In total, there are three UCANS32K1 evaluation boards: UCANS32K146-01 UCANS32K1SCT UCANS32K1SIC In this article, we choose to focus only on one of them, the UCANS32K1SIC evaluation board. The UCANS32K1SIC provides two CAN SIC interfaces and is based on the S32K146 (32-bit Arm ®  Cortex ® -M4) from the S32K microcontroller family. Also, the UCANS32K1SIC features EdgeLock ®  SE050 secure element for authentication and encryption development. For complete details, please access the following link 1.2. Block Diagram     2. The UCANS32K1SIC application example model The UCANS32K1SIC application example proposed in this article (ucans32k1sic_mbd_4_3_0) implements the following actions: Controls the RGB LED (GPO) Reads the Switch state  (GPI) Displays  messages on the LCD screen (“Red Led On”, “Green Led On”, “Blue Led On”) using the I 2 C communication protocol Adds FreeMASTER communication via UART protocol Configures  both instances of the CAN communication protocol (CAN0 and CAN1) and sends/receives messages 2.1. Prerequisite Software For the development of this application, the following software is required: MATLAB ® and Simulink ® (minimum 2020a) Stateflow ® MATLAB Coder ™ Simulink Coder™ Embedded Coder ® Support Package for ARM Cortex-M Processors Model-Based Design Toolbox for S32K1xx 4.3.0 FreeMASTER Run-Time Debugging Tool 3.2 2.2. Prerequisite Hardware For the development of this application, the following hardware is required: UCANS32K1SIC evaluation board DCD-LZ-ADAPT debug adapter with cable, which provides breakout connectors for SWD/JTAG Debugger and FTDI USB-UART CAN Bus Terminator (DRONE-CAN-TERM) with MicroUSB cable CAN cable terminated on both ends OLED Display 128x64 pixels JLink Debug Probe (or any other compatible SWD probe) IXXAT USB-to-CAN V2 (or any other canAnalyser )   3. Simulink model implementation and blocks configuration After the NXP Model-Based Design Toolbox for S32K1xx is installed, the next step is to open the library and drag and drop the necessary blocks. The MCU configuration with MBD_S32K1xx_Config_Implementation block   The first step is to add the MBD_S32K1xx_Config_Information into our Simulink model. This action makes the model aware that it will generate code for the S32K1 microcontroller. Once opening the block, the user needs to choose the processor family inside the MCU tab. For this particular board, the processor is S32K146. Then the system clock frequency (MHz) must also be specified: Clock Frequency Value (80 MHz) External Crystal clock - 8 MHz (check the schematics or other materials)     In the Target Connection tab, the following settings are required: The download interface JTAG and SEGGER JLink software. In our case, the kit comes with the SEGGER JLink so we are selecting this one. In case the JLink software is installed at a different location than the default one, the correct path shall be indicated in the “SEGGER JLink installation path” field.       3.1. Reads the Switch state (GPI) In this application, each push of the button selects which color of the RGB LED is lighten up. So, to be able to control that, the state of the button needs to be read. A variable named “counter” stores the values corresponding to each state (0-RED, 1-GREEN, 2-BLUE). The pin corresponding to the SW button reading must be configured (using the schematic for the UCANS32K1SIC evaluation board).                   With each execution of the main step in the model, the GPI Read block triggers the subsystem where the states of the LED are changed.   3.2. Controls the RGB LED (GPO) When the counter is incremented, the LED changes its state (RED-GREEN-BLUE). This is implemented using the GPO Write blocks. The pins corresponding to each LED color must be configured according to the schematic.   After identifying each pin, they must be set in GPO write blocks as follows: To turn on one of the LEDs colors, set the pin to 0 and to turn it off set it to 1. This is because the LED anode is routed to 3V3 and the cathode is connected to the pin. When the application requires to turn on only one color, the others must be turned off, as might be seen in the screenshots below.                            3.3. Displays messages on the LCD screen (“Red Led On”, Green Led On”, “Blue Led On”) using the I 2 C communication protocol For this example, the OLED display used is 128 x 64 pixels. The LCD communicates with MCU via LPI2C0 (P4). So, in order to communicate with the OLED display, the LPI2C instance must be first configured. LPI2C0 block configuration: The pins corresponding to LPI2C0 instance must be configured according to the schematic.                   Next, the OLED block  needs to be configured as follows:   After the LPI2C0 and OLED blocks are configured, messages can be displayed on the LCD screen using the LCD Write String block. LCD Write String block configuration:           To display the other messages (GREEN LED ON and BLUE LED ON), the steps are the same. To clear the LCD screen and  display another message, the LCD Clear Screen must be used.       3.4. FreeMASTER project via UART protocol FreeMASTER is a user-friendly real-time debug monitor and data visualization tool that enables runtime configuration and tuning of embedded software applications. The FreeMASTER block configuration from NXP MBDT for the S32K1xx library uses the following communication interfaces: UART CAN In this example, we used the LPUART1 interface to send/receive messages from the FreeMASTER application. The pins corresponding to LPUART1 (they are routed to the P6 connector) instance must be configured according to the schematic.                              The RxD and TxD pins required routed in the schematics are PTC6 and PTC7. Another parameter that must be configured is the Baud Rate (maximum number of bits per second to be transferred). For this application, the Baud Rate is 115200 kbps.     3.5. Configures of both instances of the CAN communication protocol (CAN0 and CAN1) and sends/receives messages In this subchapter, the goal is to show how to receive/send messages on both CAN instances (CAN0 and CAN1). CAN0 instance First, CAN0 instance needs to be configured. For this action, the CAN configuration block is required. In the General tab, the following settings are: Module: 0 (for the CAN0 instance) Operational Mode: Normal mode Max number of MBs (1-32): 16 The RxD and TxD pins required are: PTE4 and PTE5 (according to the schematic)           In the Bit rate tab, the default Bitrate is 1000Kbit/s, but it depends on the case.     The next step is to choose the operating mode for the CAN transceiver (for UCANS32K1SIC, the CAN transceiver is TJA1463). The TJA1463 is a member of the TJA146x family of transceivers that provide an interface between a Controller Area Network (CAN) or CAN FD (Flexible Data rate) protocol controller and the physical two-wire CAN bus. Control pins STB_N and EN are used to select the operating mode. To simplify the application, the Normal mode has been selected to be set for the entire execution of the application. HIGH-level state on pin STB_N and pin EN selects Normal mode. According to the schematic, for the instance of CAN0, the corresponding pins for STB_N and EN are PTE11 and PTA10. For checking the correctness of the configuration of the settings and application, the transceiver outputs CAN_H and CAN_L are connected to CAN Analyzer, while messages are sent from the PC.           A numeric sequence with the ID 0x3FF is sent continuously while a  message received with ID 0x3FE toggles the PTD15 (Red LED) on each receive. To receive a CAN message asynchronous with the application, the CAN receive interrupt must be used. When a message is received, it triggers the subsystem Rx_0x3FE.     The fcan_s32l_receive block configuration is: Module: 0 Mode: Non-blocking Message Buffer: 14 ID: 3FF ID mask: FFFFFFFF         To send a message with the ID 0x3FF on CAN0, in the fcan_s32l_send block, the following settings are required: Module: 0 Mode: Blocking Timeout (ms): 50 Message Buffer: 15 ID: 3FF       CAN1 instance For the instance of CAN1, the steps are the same as above (the configuration of CAN0), but this time a numeric sequence with ID 0x2FF is sent continuously and a received message with ID 0x3FF will toggle the PTD16 (Green LED) on each receive. A CAN Analyzer is needed to analyze and collect data from the CAN bus and display them on the PC. To use both CAN instances on the same  CAN Analyzer, a hardware connection is needed between CAN0A and CAN1A (or any CAN0 with CAN1). This can be seen in the following diagram:     In this application, the  CAN Analyzer used is IXXAT USB-to-CAN V2 and the software interface is IXXAT canAnalyser3 Mini, but of course, any other CAN Analyzer can be used.       4. Model overview The application is structured in 3 categories as follows: Input (green area): Hardware-dependent blocks that read/receive values from peripherals Algorithm (blue area): Hardware-independent blocks that process the values received from Input blocks, runs the algorithm and controls the outputs. Output (pink area): Hardware-dependent blocks which receive the processed values from the Algorithm blocks.     After all the steps have been followed, the code can be generated, compiled, and deployed on the target. To do so, Go to Simulink -> Apps -> Embedded Coder then click on the Build button.     In the Diagnostic Viewer, the process can be analyzed if there is any error and if the download was successfully completed on the target as in the image below:       The following figure shows the setup:     Conclusion In this article we explained how to use the NXP Model-Based Design Toolbox for S32K1xx to handle the UCANS32K1SIC evaluation board. Access to all the board's peripherals was possible in Simulink by using the Model-Based Design Toolbox, an addon which connects the MATLAB and Simulink high level world with the NXP Tools and Hardware. In this application, we have shown how to control the RGB LED and read the state of the switch; how to display messages on the LCD screen and configure both instances of the CAN communication protocol for sending and receiving messages. We have also added the FreeMASTER communication to monitor or fine-tune the algorithms running on the UCANS32K1SIC board, while the model is available down below.   EdgeLock and NXP are trademarks of NXP B.V. All other product or service names are the property of their respective owners. © 2023 NXP B.V. Arm, Cortex are trademarks and/or registered trademarks of Arm Limited (or its subsidiaries or affiliates) in the US and/or elsewhere. The related technology may be protected by any or all of patents, copyrights, designs and trade secrets. All rights reserved. MATLAB, Simulink, Stateflow and Embedded Coder are registered trademarks and MATLAB Coder, Simulink Coder are trademarks of The MathWorks, Inc. See mathworks.com/trademarks for a list of additional trademarks.

Introduction With the latest advances in microcontrollers, they are getting faster and more efficient, being able to successfully run complex algorithms in a reasonable time. One important category are Artificial Intelligence algorithms. Using both NXP ® and MathWorks ® ecosystem, the steps to deploy an AI algorithm to NXP hardware are simplified and straight forward. The article provides guidance on how to implement a State-of-Charge (SoC) estimation algorithm based on a feedforward deep learning network developed by Mathworks' experts (Battery State of Charge Estimation in Simulink Using Deep Learning Network). The algorithm is then deployed on i.MX RT1060 Evaluation Kit using NXP Model Based Design Toolbox for I.MX RT. As the main objective of the article is to demonstrate how to run an AI algorithm on NXP evaluation board, the example is ran in Processor-in-the-Loop (PIL) simulation mode. This type of simulation represents an important step in the validation process of an algorithm, corner cases can be easily replicated as the input data can be directly loaded from MATLAB's workspace. The execution of the algorithm is done on the microcontroller. For a more detailed overview of the execution of the algorithm, code profiling options can be enabled to generate a report which details execution times.   What BMS is Battery Management System (BMS) is a critical component in battery-driven devices, such as electric vehicles. Their main objective is to ensure that the battery pack remains in an optimal and safe operating mode. At the core of the most tasks, the BMS must compute the State-of-Charge (SoC) estimation. To make a precise estimation, the algorithm requires an accurate model of the actual cells, which are difficult to characterize. An alternative to this approach is to create data driven models of the cell using AI methods such as neural networks.   Deep Learning Toolbox The Deep Learning Toolbox™ developed by Mathworks provides a framework for deep neural networks to be used in algorithms. It enables the user to use convolutional neural networks (ConvNets, CNNs) and long short-term memory (LSTM) networks to perform classification and regression on image, time-series and text data. The network and layer graphs are not mandatory to be created in MathWorks ecosystem, as other frameworks can be used, such as TensorFlow™ 2, TensorFlow-Keras, PyTorch ® .   Prerequisite Software To create, build and deploy a Simulink Model onto the i.MX RT RT1060 EVK, the following software is required: MATLAB R2022a Deep Learning Toolbox Simulink ® MATLAB ® Coder™ Simulink ® Coder™ Embedded Coder ®  Support Package for ARM Cortex-M Processors i.MX RT MBD Toolbox (version 1.3.0)   Prerequisite hardware The hardware required for this example is i.MX RT1060 Evaluation Kit. The i.MX RT1060 crossover MCUs are part of the EdgeVerse™ edge computing platform. The core of the MCU is a Arm ® Cortex ® -M7 core at 600 MHz. The device is fully supported by NXP’s MCUXpresso Software and Tools, a comprehensive and cohesive set of free software development tools.   Model - Overview The BatterySOCSimulinkEstimation model included in the Deep Learning Toolbox computes the SoC estimation using two methods: first method uses a neural network and the second one uses the extended Kalman filter algorithm. By plotting data generated by these two estimations and comparing it to the true values, it is possible to validate that the FNN predicts the SoC with an accuracy of 3 within a temperature range between -10 C and 25 C.   Note! Before making any modification to the model included in the toolbox, it is recommended to create a backup of the example in order to be able to revert to the original state. For this example, the predictions are done on the i.MX RT1060 evaluation board in PIL mode while the Kalman filter is locally computed on the computer. Referenced Model From the original model, the FNN block must be added in a new blank model. As the newly created model is used in a Referenced model, an input port must be added to received data (make sure the Port dimensions is set to 5), and one output port to return the data computed. The other settings for all these 3 blocks can be left default. Next, in the Model Settings the following changes must be made: Hardware Implementation Hardware Board: NXP MIMXRT1062xxxxA Target Hardware Resources Download Type: OpenSDA OpenSDA drive: Click on browse and select the partition assigned to the IMXRT1060 PIL Communication interface: Serial Interface Hardware UART: LPUART1 Serial port: The COM port assigned to the board (it can be found by using Device Manager or by running serialportlist command in MATLAB Command Window) Baudrate: 115200 Code generation Verification Check Enable portable word sizes   Top model Based on the BatterySOCSimulinkEstimation model included in the Deep Learning Toolbox, the FNN block must be removed (either deleted or commented). A ModelReference subsystem must be added to the model. In the Block Parameters of the ModelReference subsystem, select the model created and configured above. Simulation Mode must be set to Processor-in-the-Loop (PIL). Another modification that must be done is the sample time of the nnInput Data Read Memory block which must be changed from 0 (continuous) to -1 (inherited).   Next, in the Model Settings the following changes must be made: Hardware Implementation Hardware Board: NXP MIMXRT1062xxxxA Target Hardware Resources Download Type: OpenSDA OpenSDA drive: Click on browse and select the partition assigned to the IMXRT1060 PIL Communication interface: Serial Interface Hardware UART: LPUART1 Serial port: The COM port assigned to the board (it can be found by using Device Manager or by running serialportlist command in MATLAB Command Window) Baudrate: 115200 Code generation Verification Check Enable portable word sizes   Deployment and validation Now that both models (top model and referenced model) are configured, SIL/PIL manager can be opened from the APPS tab in Simulink. In the SIL/PIL tab, the simulation must be selected to SIL/PIL only (red rectangle) and the System Under Test to Model Blocks in SIL/PIL mode (blue rectangle). Before the simulation is started, the BatterySOCSimulinkEstimation_ini.m script must be executed to load the necessary data into MATLAB's workspace. The script can be found next to the Simulink Model included in the Deep Learning Toolbox. From the top model, the SOC scope can be opened to display the generated data. The simulation can be started from the RUN button within the scope. Note! Diagnostic Viewer can provide important information if there are any errors within the models. If the simulation is successfully deployed on the target, the data plotted into the scope should look like this:   Code profiling Code profiling is an important tool to validate an algorithm as it provides important information about the execution time. The time is measured by the timer configured in Model Settings -> Hardware Implementation -> Hardware board settings -> Target hardware resources -> Profiling Timers. By default, the PIT timer, channel 0, is used. The Code generation can be enabled from Model Settings -> Code Generation -> Verification -> Code execution time profiling -> Measure task execution time. The generated report can either be Coarse (referenced models and subsystems only) or Detailed (all function call sites). When the simulation is completed, a small window is opened. The Profiling report can be opened by clicking on the view the full code execution profiling report.   Conclusion The NXP and Mathworks ecosystems enable the users to deploy an Artificial Intelligence algorithm onto the NXP hardware. In the end, I strongly recommend the users interested in BMS and Artificial Intelligence to watch the Deploying a Deep Learning-Based State-Of-Charge (SOC) Estimation Algorithm to NXP S32K3 Microcontrollers webinar hosted by Javier Gazzarri (MathWorks) and Marius Andrei (NXP).   EdgeVerse and NXP are trademarks of NXP B.V. All other product or service names are the property of their respective owners. © 2023 NXP B.V. Arm, Cortex are trademarks and/or registered trademarks of Arm Limited (or its subsidiaries or affiliates) in the US and/or elsewhere. The related technology may be protected by any or all of patents, copyrights, designs and trade secrets. All rights reserved. PyTorch, the PyTorch logo and any related marks are trademarks of The Linux Foundation. MATLAB, Simulink, Stateflow and Embedded Coder are registered trademarks and MATLAB Coder, Simulink Coder, Deep Learning Toolbox are trademarks of The MathWorks, Inc. See mathworks.com/trademarks for a list of additional trademarks. TensorFlow, the TensorFlow logo and any related marks are trademarks of Google Inc.

The content of this article is identical to the AN13902: 3-Phase Sensorless PMSM Motor Control Kit with S32K344 using MBDT Blocks

    Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for S32K3xx – version 1.3.0 EAR   The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K3xx version 1.3.0. This release supports automatic code generation for S32K3xx peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3xx Automotive Microprocessors. This new product adds support for S32K311, S32K312, S32K314, S32K322, S32K324, S32K341, S32K342, S32K344, S32K358 and S32K396 MCUs and part of their peripherals, based on RTD MCAL components (ADC, PWM, MCL, DIO, CAN, SPI, UART, GPT). To enable BMS applications development, we have added support for MC33775A and MC33772C battery cell controllers (& MC33665PHY). In this release, we have also updated S32 Configuration Tools, RTD, AMMCLib, and MATLAB support for the latest versions. The product comes with over 115 examples, covering everything that is supported, including demos for battery cell controllers (BCC) and motor control.   Target audience: This product is part of the Automotive SW – S32K3 Standard Software Package.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=13957417   Technical Support: NXP Model-Based Design Toolbox for S32K3xx issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt     Release Content Automatic C code generation from MATLAB® for NXP S32K3xx derivatives: S32K311 S32K312 S32K314 S32K322 S32K324 S32K341 S32K342 S32K344 S32K358 S32K396   Support for the following peripherals (MCAL components): ADC PWM MCL CAN SPI UART GPT DIO   Support for MC33775A and MC33772C battery cell controllers & MC33665PHY The toolbox provides support for the MC33775A, MC33772C, and MC33665. The MC33775A and MC33772C are lithium-ion battery cell controller ICs designed for automotive applications which perform ADC conversions of the differential cell voltages and battery temperatures, while the MC33665 is a transceiver physical layer transformer driver, designed to interface the microcontroller with the battery cell controllers through a high-speed isolated communication network. The ready-to-run examples provided with the MBDT for S32K3 show how to communicate between the S32K344 and the MC33775A and MC33772C via the MC33665 transceiver. For the MC33775A, the examples show how to configure the battery cell controller to perform Primary and Secondary chains conversion, and read the cell voltages conversion results from the MC33775A, while for the MC33772C the examples show how to configure the Battery cell controller to read current. All the converted values are displayed to the user over the FreeMaster application.       Support for custom default project configuration The toolbox provides support for users to create their custom default project configurations. This could be very useful when having a custom board design – only needing to create the configuration for it once. After it is saved as a custom default project, it can be used for every model that is being developed.       Support for component restore to default settings The toolbox allows users to restore the configuration of a component (for models which use the EB Tresos configuration tool) to the settings corresponding to the Default Configuration Template the model uses. This allows reverting changes (if made) to the default values.   Support for AUTOSAR blockset (SW-C deployment) New RTD version supported  (v3.0.0 CD04) – only for S32K311, S32K358 and S32K396 New S32 Configuration Tools version supported (v1.6) Provides 2 modes of operation: Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32 Configuration Tools or EB Tresos to configure peripherals/pins/clocks Integrates the Automotive Math and Motor Control Library release 1.1.31: All functions in the Automotive Math and Motor Control Functions Library v1.1.31 are supported as blocks for simulation and embedded target code generation.   FreeMASTER Integration We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications.   Support for MATLAB versions We added support for the following MATLAB versions: R2021a R2021b R2022a R2022b   S32Design Studio Integration We provide a simple mechanism for the users to export the code generated from Simulink and import it directly into S32Design Studio. This functionality can be useful if the model needs to be integrated into an already existing project or for debugging purposes.     Board initialization: The Model-Based Design Toolbox for S32K3xx generates the component’s peripherals initialization function calls as configured in the Board Initialization window. The toolbox provides a default configuration including function calls for initializing the clocks, followed by pins and a custom order for the rest of the peripherals which have been configured in the project associated to the model.     Simulation modes: We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL) External mode     Examples for every peripheral/function supported: We have added over 115 examples, including: Battery Management Systems examples Motor control applications (including eTPU example on S32K396) Communication (SPI, CAN, UART) AMMCLib Timer control (GPT) DIO FreeMASTER SIL / PIL / External mode For more details, features, and how to use the new functionalities, please refer to the Release Notes document attached.   MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K3xx MCUs and evaluation board solutions out-of-the-box with: NXP Model-Based Design Toolbox for S32K3xx version 1.3.0 is fully integrated with MATLAB® environment in terms of installation:         Target Audience This release (1.3.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3xx MCUs and Evaluation Boards.   Useful Resources Examples, Trainings, and Support: https://community.nxp.com/community/mbdt                

    Product Release Announcement EDGE PROCESSING   NXP Model-Based Design Toolbox for i.MX RT Crossover MCUs – version 1.3.0     The Edge Processing Tools Team at NXP Semiconductors is pleased to announce the release of the Model-Based Design Toolbox for i.MX RT 1xxx Series version 1.3.0. This release supports automatic code generation for peripherals and applications prototyping from MATLAB/Simulink for NXP’s i.MX RT 117x, 106x, 102x & 101x Series of crossover MCUs.   NXP Download Location https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=MCTB-EX   MATHWORKS Download Location https://www.mathworks.com/matlabcentral/fileexchange/81051-nxp-support-package-imxrt1xxx   Version 1.3.0 Release Content Automatic C code generation based on MCUXpresso SDK 2.11.0 drivers and MCUXpresso Configuration Tools 11.0 initializations from MATLAB®/Simulink® for: i.MX RT 1076: MIMXRT1176DVMAA,MIMXRT1176AVM8A,MIMXRT1176CVM8A i.MX RT 1075: MIMXRT1175DVMAA,MIMXRT1175AVM8A,MIMXRT1175CVM8A i.MX RT 1073: MIMXRT1173CVM8A i.MX RT 1072: MIMXRT1172DVMAA,MIMXRT1172AVM8A,MIMXRT1172CVM8A i.MX RT 1071: MIMXRT1171DVMAA,MIMXRT1171AVM8A,MIMXRT1171CVM8A i.MX RT 1061: MIMXRT1061CVJ5A,MIMXRT1061CVL5A,MIMXRT1061DVJ6A,MIMXRT1061DVL6A i.MX RT 1062: MIMXRT1062CVJ5A,MIMXRT1062CVL5A,MIMXRT1062DVJ6A,MIMXRT1062DVL6A i.MX RT 1064: MIMXRT1064CVJ5A,MIMXRT1064CVL5A,MIMXRT1064DVJ6A,MIMXRT1064DVL6A i.MX RT 1011: MIMXRT1011CAE4A,MIMXRT1011DAE5A i.MX RT 1024: EVKMIMXRT1024     Multiple options for configuration of MCU packages, Build Toolchain and embedded Target Connections are available via Simulink Model Configuration UI       Multiple MCU peripherals and Drivers are supported. The following subsystems highlighted in red as supported in Simulink environments in various forms: blocks, files, options                           i.MX RT 117x derivatives     i.MX RT 106x derivatives i.MX RT 101x derivatives     Basic and Advanced Simulink Block configuration modes via MCUXpresso Configuration Tools 11.0 UIs for Pins, Clocks, and Peripherals       MATLAB/Simulink versions 2019a – 2021b are supported for Design, Simulation, Code Generation, and Deployment of applications on i.MX RT 117x,106x, 102x & 101x Series. Other i.MX RT devices will be supported in future versions of the toolbox. Support for Software-in-Loop (SiL), Processor-in-Loop (PiL), and External Mode (classic serial, XCP Over Serial, and XCP over Ethernet). RTCESL – Real-Time Control Embedded Software Motor Control and Power Conversion Libraries (limited support designed for Motor Control applications). A future update will enhance the number of functionalities supported by Simulink.     Simulink Example library with more than 200 models to showcase various functionalities:   Integrated PMSM Motor Control Sensor/Sensor-less application for both IMXRT1060-EVK and IMXRT1170-EVK:     Target Applications with MATLAB/Simulink This release of the Model-Based Design Toolbox can be used to design, build, and test applications from multiple domains: INDUSTRIAL AC Meters Motion Control Robotics HMI SMART CITY/HOME Video Surveillance Identification Appliances Speakers   AUTOMOTIVE HVAC ECU     Target Audience This release is intended for technology demonstration, evaluation purposes, and prototyping for i.MX RT 1xxx MCUs and their corresponding Evaluation Boards: EVK-MIMXRT1170 EVK-MIMXRT1060 EVK-MIMXRT1064 EVK-MIMXRT1010 EVK-MIMXRT1024       Useful Resources Examples, Training, and Support: https://community.nxp.com/community/mbdt Technical by System Tools: https://web.microsoftstream.com/channel/618ab630-c8da-4fa8-ade8-5aa70a353124      

  Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for S32K1xx – version 4.3.0 Austin, Texas, USA - September 13, 2022   The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K1xx version 4.3.0. This release supports automatic code generation for S32K1xx peripherals and applications prototyping from MATLAB/Simulink for NXP S32K1xx Automotive Microprocessors. This new release adds support for RDDRONE-772B  Battery Management Systems (support for MC3377xC), Code deployment directly from Simulink via JTAG/SWD (OpenSDA, PeMicro Probe, or SEGGER JLink), SIL/PIL support for the latest MATLAB versions, new community and customer requested features (Enhanced support for SBC, FCAN Blocks, UART Blocks, I2C Blocks) and many other various new functionalities to help customers with rapid prototyping with NXP S32K1xx microcontrollers.   FlexNet Location: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=MCTB-EX   Activation link: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=MCTB-EX   Technical Support: NXP Model-Based Design Toolbox for S32K1xx issues are tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt   Release Content Automatic C code generation based on S32K SDK 4.0.0 RTM drivers from MATLAB® for NXP all S32K1xx derivatives: S32K142W MCU Packages with 48/64 LQFP (*updated) S32K144W MCU Packages with 48/64 LQFP (*updated) S32K116 MCU Packages with 32QFN and 48LQFP (*updated) S32K118 MCU Packages with 48/64 LQFP (*updated) S32K142 MCU Packages with 48/64/100LQFP (*updated) S32K144 MCU Packages with 48/64/100LQFP and 100BGA (*updated) S32K146 MCU Packages with 64/100/144LQFP and 100BGA (*updated) S32K148 MCU Packages with 144/176LQFP and 100BGA/QFP (*updated) Multiple options for packages and clock frequencies are available via Model-Based Design Toolbox S32K Simulink Main Configuration Block       Added Support for RDDRONE-BMS772         We added examples for the RDDRONE-BMS772. This is a standalone BMS reference design suitable for mobile robotics such as drones and rovers, supporting 3 to 6-cell batteries. MBDT examples cover applications like BMS, LCD, CAN and SBC.       Battery Management System (BMS) support for MC3377xC – examples, documentation and FreeMASTER UI are available Special Simulink Blocks have been added to simplify the way a user can initialize such a controller, read vital parameters (like cell voltage, stack voltage, temperature, current), and manage the whole system. The entire suite of blocks is easily integrated within the new Battery Management Toolbox from Mathworks, so users can leverage these algorithms on top of our blocks.       Enhanced FCAN Support We improved the FCAN communication support by addressing the following: FCAN communication is now fully functional when external SBC is configured (for both UJA113x and UJA1169) The user is able to retrieve the ‘Error Status’ of an ongoing transfer and abort it in case something is wrong. The ‘Receive’ and ‘Send’ blocks for FCAN now allow the user to specify when the initialization for the message buffers should be executed (during Model Initialization, at each execution of the block, or none). If the ‘NONE’ option is selected, a newly added block ‘FCAN_MBConfig’ can be used to configure the message buffer. The FCAN messages ID can also be provided via an input port for both ‘Send’ and ‘Receive’ operations.   Multiple S32K1xx peripheral support. The peripheral coverage for each of the S32K1xx derivatives is shown below:   S32K116 S32K118       S32K142   S32K144         S32K146 S32K148       Added support for JTAG deployment directly from Simulink We added support for deployment over JTAG directly from Simulink. In the main Config block, under Target Connection, the JTAG option must be selected. Following this action, the JTAG Interface selection becomes active. Here is the following selection: OpenSDA Embedded Debug – the EVB Embedded Debugger is used. USB Multilink PEmicro – an external PEmicro probe is used. SEGGER JLink – this action requires the external selection of the SEGGER JLink     Extended support for MATLAB versions We extended support for our toolbox to cover a wider range of MATLAB releases – starting from R2016a and going up to R2022a. This way we want to avoid locking out users that have constraints regarding MATLAB versions.   New community-requested features In our efforts to make  NXP’s Model-Based Design Toolbox for S32K1xx version 4.3.0 fit the needs of the users, we have added the following requested features/updates: Added OSIF Time Delay Block Added Code Size Report Added NONE option for the SPI SIN/SOUT pins Enabled support for more than one ADC Interleave Block Updated Profiler functionality Updated FCAN Blocks Updated I2C Blocks Updated LPUART Blocks Fixed Registers dropdowns not displaying options on some machines   100% S32K1xx supported peripheral coverage with examples. Approximately 300 examples are available as part of the toolbox that exercises all the functionalities supported.     For more details, features, and how to use the new functionalities, please refer to the Release Notes document attached.   MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K1xx MCUs and evaluation boards solutions out-of-the-box with: NXP Support Package for S32K1xx Online Installer Guide Add-on allows users to install the NXP solution directly from the MathWorks website or directly from MATLAB IDE. The Support Package provides a step-by-step guide for installation and verification. NXP Model-Based Design Toolbox for S32K1xx version 4.3.0 is fully integrated with MATLAB® environment in terms of installation, documentation, help and examples:       Target Audience This release (4.3.0) is intended for technology demonstration, evaluation purposes, and prototyping for S32K116, S32K118, S32K142, S32K144, S32K146, S32K148, S32K142W, and S32K144W MCUs and Evaluation Boards.   Useful Resources Examples, Trainings, and Support: https://community.nxp.com/community/mbdt      

  Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for S32K3xx – version 1.2.0 RTM   The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K3xx version 1.2.0. This release supports automatic code generation for S32K3xx peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3xx Automotive Microprocessors. This new product adds support for S32K312, S32K314, S32K322, S32K324, S32K341, S32K342, and S32K344 MCUs and part of their peripherals, based on RTD MCAL components (ADC, PWM, MCL, DIO, CAN, SPI, UART, GPT). To enable BMS applications development, we have added support for MC33775A and MC33772C battery cell controllers (& MC33665PHY). In this release, we have also updated FreeMASTER, AMMCLib, and MATLAB support for the latest versions. The product comes with over 130 examples, covering everything that is supported, including demos for battery cell controllers (BCC) and motor control.   Target audience: This product is part of the Automotive SW – S32K3 Standard Software Package.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=13593437   Technical Support: NXP Model-Based Design Toolbox for S32K3xx issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt     Release Content Automatic C code generation from MATLAB® for NXP S32K3xx derivatives: S32K312 S32K314 S32K322 S32K324 S32K341 S32K342 S32K344     Support for the following peripherals (MCAL components): ADC PWM MCL CAN SPI UART GPT DIO   Support for MC33775A and MC33772C battery cell controllers & MC33665PHY The toolbox provides support for the MC33775A, MC33772C, and MC33665. The MC33775A and MC33772C are lithium-ion battery cell controller ICs designed for automotive applications which perform ADC conversions of the differential cell voltages and battery temperatures, while the MC33665 is a transceiver physical layer transformer driver, designed to interface the microcontroller with the battery cell controllers through a high-speed isolated communication network. The ready-to-run examples provided with the MBDT for S32K3 show how to communicate between the S32K344 and the MC33775A and MC33772C via the MC33665 transceiver. For the MC33775A, the examples show how to configure the battery cell controller to perform Primary and Secondary chains conversion, and read the cell voltages conversion results from the MC33775A, while for the MC33772C the examples show how to configure the Battery cell controller to read current. All the converted values are displayed to the user over the FreeMaster application.           Support for custom default project configuration The toolbox provides support for users to create their custom default project configurations. This could be very useful when having a custom board design – only needing to create the configuration for it once. After it is saved as a custom default project, it can be used for every model that is being developed.         Support for component restore to default settings The toolbox allows users to restore the configuration of a component (for models which use the EB Tresos configuration tool) to the settings corresponding to the Default Configuration Template the model uses. This allows reverting changes (if made) to the default values.   Support for AUTOSAR blockset (SW-C deployment) New RTD version supported  (v2.0.0) New S32Config Tools version supported (v1.5) Provides 2 modes of operation: Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32Configuration Tool or EB Tresos to configure peripherals/pins/clocks Integrates the Automotive Math and Motor Control Library release 1.1.29: All functions in the Automotive Math and Motor Control Functions Library v1.1.29 are supported as blocks for simulation and embedded target code generation.   FreeMASTER Integration We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications.     Support for MATLAB versions We added support for the following MATLAB versions: R2020a R2020b R2021a R2021b R2022a   S32Design Studio Integration We provide a simple mechanism to let users the opportunity to export the code generated from Simulink and import it directly into S32Design Studio. This functionality can be useful if the model needs to be integrated into an already existing project or for debugging purposes.          Simulation modes: We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL) External mode     Examples for every peripheral/function supported: We have added over 130 examples, including: Battery Management Systems examples Motor control applications Communication (SPI, CAN, UART) AMMCLib Timer control (GPT) DIO FreeMASTER SIL / PIL / External mode   For more details, features, and how to use the new functionalities, please refer to the Release Notes document attached.   MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K3xx MCUs and evaluation board solutions out-of-the-box with: NXP Model-Based Design Toolbox for S32K3xx version 1.2.0 is fully integrated with MATLAB® environment in terms of installation:         Target Audience This release (1.2.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3xx MCUs and Evaluation Boards.   Useful Resources Examples, Trainings, and Support: https://community.nxp.com/community/mbdt            

Get to know NXP Model-Based Design Toolbox™—a connection between MathWorks and NXP ecosystems that allows rapid prototyping of complex embedded designs on NXP microcontrollers. In this presentation, @Irina_Costachescu and @mariuslucianand  will highlight the main features of the NXP Model-Based Design Toolbox. They will demonstrate how to design a BMS application, covering the main development phases from an idea to a running on target prototype. Register here: https://www.matlabexpo.com/online/2022.html 

This page summarizes all Model-Based Design Toolbox topics related to the DSC Product Family. Model-Based Design Toolbox for DSC- Release Notes: Rev 1.0.0 - NXP Model-Based Design Toolbox for DSC MC56F8x MCUs - version 1.0.0 

    Product Release Announcement EDGE PROCESSING NXP Model-Based Design Toolbox for DSC MC56F8x MCUs - version 1.0.0 Bucharest, Romania  December 15th , 2021   The Edge Processing Tools Team at NXP Semiconductors is pleased to announce the release of the Model-Based Design Toolbox for DSC MC56F8x Series version 1.0.0. This release supports automatic code generation for peripherals and applications prototyping from MATLAB/Simulink for NXP’s DSC MC56F81xxx and MC56F83xxx Series of MCUs based on DSP568000E core. NXP Download Location https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=MCTB-EX MATHWORKS Download Location https://www.mathworks.com/matlabcentral/fileexchange/103600-nxp-support-package-dsc  Version 1.0.0 Release Content Automatic C code generation based on MCUXpresso SDK 2.7.3 drivers and MCUXpresso Configuration Tools 10.0 initializations from MATLAB®/Simulink® for:   MC56F81xxx        MC56F81868VLH, MC56F81646VLF, MC56F81648VLH, MC56F81663VLC,      MC56F81666VLF, MC56F81668VLH, MC56F81743VLC, MC56F81746VLF,      MC56F81748VLH, MC56F81763VLC, MC56F81766VLF, MC56F81768VLH,             MC56F81866VLF, MC56F81643VLC                                     MC56F83xxx     MC56F83789VLL, MC56F83683VLH, MC56F83686VLL, MC56F83689VLL,     MC56F83763VLH, MC56F83766VLK, MC56F83769VLL, MC56F83783VLH,     MC56F83786VLK, MC56F83663VLH   Multiple options for configuration of MCU packages, Build Toolchain and embedded Target Connections are available via Simulink Model Configuration UI     Multiple MCU peripherals and Drivers supported. The following subsystems highlighted in red as supported in Simulink environments in various forms: blocks, files, options MC56F81xxx derivatives MC56F83xxx derivatives   Basic and Advanced Simulink Block configuration modes via MCUXpresso Configuration Tools 10.0 UIs for Pins, Clocks, and Peripherals   MATLAB/Simulink versions 2020a – 2021b are supported for Design, Simulation, Code Generation, and Deployment of applications on MC56F81xxx and MC56F83xxx Series. Other MC56F8x devices will be supported in future versions of the toolbox. Support for Software-in-Loop (SiL), Processor-in-Loop (PiL); RTCESL – Real-Time Control Embedded Software Motor Control and Power Conversion Libraries for DSP568000E core.     Simulink Example library with more than 100 models to showcase various functionalities:   Integrated PMSM Motor Control Sensor/Sensor-less application for MC56F83000-EVK: Integrated application that uses the on board FXOS8700CQ accelerometer and magnetometer sensor for both MC56F81000-EVK and MC56F83000-EVK.    Target Applications with MATLAB/Simulink This release of the Model-Based Design Toolbox can be used to design, build, and test applications from multiple domains: INDUSTRIAL AC Meters Motion Control Robotics HMI       Target Audience This release is intended for technology demonstration, evaluation purposes, and prototyping for DSC MC56F8x MCUs and their corresponding Evaluation Boards: EVK-MC56F81000 EVK-MC56F83000 Useful Resources Examples, Training, and Support: https://community.nxp.com/community/mbdt    

This page summarizes all Model-Based Design Toolbox tutorials and articles related to DSC MCUs Product Family.

This page summarizes all Model-Based Design Toolbox videos related to DSC MCUs Product Family.

General Tip of the day Tip of the day  Model Reference Model referencing in i.MX RT Toolbox  Peripherals FLEXCAN How to set i.MX RT FlexCAN receive message buffer Mask for range of IDs ?   LPI2C How to use LPI2C in transfer mode in i.MX RT  LPUART Questions about i.MX RT LPUART driver  Apps

General Installer and Setup  External mode External mode example wouldn't compile after update  Others MPC57xx MBD Toolbox not appears in Simulink Library Browser  Peripherals Apps Motor Control BMS Request for HSD/LSD/MSDI Communication Examples for MPC5775B BMS and VCU Reference Design 

        Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for HCP – version 1.1.0 RFP       The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for HCP version 1.1.0. This release supports automatic code generation from MATLAB/Simulink for S32G2xx, S32S2xx, and S32R41 MPUs. This new product adds support for running Processor-in-Loop and Software-in-Loop simulation on S32R41 (ARM Cortex-A53).   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/product?child_plneID=683951   Technical Support: NXP Model-Based Design Toolbox for HCP issues will be tracked through NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt     Release Content Automatic C code generation from MATLAB® for NXP S32G2xx derivatives: S32G274A Automatic C code generation from MATLAB® for NXP S32S2xx derivatives: S32S247TV Automatic C code generation from MATLAB® for NXP S32R4x derivatives: S32R41 Supported Evaluation Boards GoldBox Development Platform (S32G-VNP-RDB2 Reference Design Board) GreenBox II Development Platform X-S32R41-EVB Development Board Support for MATLAB versions: R2020a R2020b R2021a R2021b Simulation mode: We provide support for Software-in-Loop (SIL) and Processor-in-Loop (PIL) simulation mode with code execution profiling:   Includes the HEV demo (S32G2xx, S32S2xx):   Includes the RADAR demo - MFSK Radar Range and Speed Estimation on Multiple Targets (S32R41), in collaboration with Gamax Laboratory Solutions Kft.:   Includes an Example library with 16 examples that cover: Software-in-Loop (SIL), Processor-in-Loop (PIL)   GUI to help you setup the toolbox and the evaluation board :     For more details, features and how to use the new functionalities, please refer to the Release Notes document attached.   MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32G2xx, S32S2xx, and S32R41  processors and evaluation board solutions out-of-the-box with: NXP Model-Based Design Toolbox for HCP version 1.1.0 (RFP) is fully integrated with MATLAB® environment in terms of installation:       Target Audience This release (1.1.0 RFP) is intended for technology demonstration, evaluation purposes and prototyping S32G2xx, S32S2xx, and S32R41 and Evaluation Boards.   Useful Resources Examples, Trainings and Support: https://community.nxp.com/community/mbdt    

          Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for S32K3xx – version 1.1.0 RTM     Austin, Texas, USA December 20, 2021 The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K3xx version 1.1.0. This release supports automatic code generation for S32K3xx peripherals and applications prototyping from MATLAB/Simulink for NXP S32K3xx Automotive Microprocessors. This new product adds support for S32K344 and S32K312 MCUs and part of their peripherals, based on RTD MCAL components (ADC, PWM, MCL, DIO, CAN, SPI, UART, GPT). To enable BMS applications development, we have added support for MC33775A battery cell controller (& MC33664PHY). In this release, we have also added 2 new motor control applications (for both PMSM and BLDC), as well as updated FreeMASTER, AMMCLib, and GCC compiler to the latest versions. The product comes with over 100 examples, covering everything that is supported, including demos for battery cell controllers (BCC) and motor control.   Target audience: This product is part of the Automotive SW – S32K3 Standard Software Package.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=12920897   Technical Support: NXP Model-Based Design Toolbox for S32K3xx issues will be tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt     Release Content Automatic C code generation from MATLAB® for NXP S32K3xx derivatives: S32K344 S32K312   Support for the following peripherals (MCAL components): ADC PWM MCL CAN SPI UART GPT DIO   Support for MC33775A battery cell controller & MC33664PHY The toolbox provides support for the MC33775A and MC33664. The MC33775A is a lithium-ion battery cell controller IC designed for automotive applications which perform ADC conversions of the differential cell voltages and battery temperatures, while the MC33664 is a transceiver physical layer transformer driver, designed to interface the microcontroller with the battery cell controllers through a high speed isolated communication network. The ready-to-run example provided with the MBDT for S32K3 shows how to communicate between the S32K344 and the MC33775A via the MC33664 transceiver. The MCU configures the battery cell controller to perform Primary and Secondary chains conversion, reads the cell voltages conversion results from the MC33775A, and displays the values to the user over the FreeMaster.     Added new motor control examples The toolbox provides examples for both 3-shunt PMSM and BLDC motor control applications. Each of them has a detailed description of the hardware setup and an associated FreeMASTER project which can be used for control and data visualization.     Support for custom default project configuration The toolbox provides support for users to create their custom default project configurations. This could be very useful when having a custom board design – only needing to create the configuration for it once. After it is saved as a custom default project, it can be used for every model that is being developed.     Support for AUTOSAR blockset (SW-C deployment) Updated to the latest version of RTD (v1.0.0) and GCC(v10.2) Provides 2 modes of operation: Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32Configuration Tool or EB Tresos to configure peripherals/pins/clocks Integrates the Automotive Math and Motor Control Library release 1.1.26: All functions in the Automotive Math and Motor Control Functions Library v1.1.26 are supported as blocks for simulation and embedded target code generation.   FreeMASTER Integration We provide several Simulink example models and associated FreeMASTER projects to demonstrate how our toolbox interacts with the real-time data visualization tool and how it can be used for tuning embedded software applications.   Support for MATLAB versions We added support for the following MATLAB versions: R2020a R2020b R2021a R2021b   S32Design Studio Integration We provide a simple mechanism to let users the opportunity to export the code generated from Simulink and import it directly into S32Design Studio. This functionality can be useful if the model needs to be integrated into an already existing project or for debugging purposes.     Simulation modes: We provide support for the following simulation modes (each of them being useful for validation and verification): Software-in-Loop (SIL) Processor-in-Loop (PIL) External mode     Examples for every peripheral/function supported: We have added over 100 examples, including: Motor control applications (PMSM and BLDC) Communication (SPI, CAN, UART) AMMCLib Timer control (GPT) DIO FreeMASTER SIL / PIL / External mode   For more details, features, and how to use the new functionalities, please refer to the Release Notes document attached.   MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s S32K3xx MCUs and evaluation board solutions out-of-the-box with: NXP Model-Based Design Toolbox for S32K3xx version 1.1.0 is fully integrated with MATLAB® environment in terms of installation:       Target Audience This release (1.1.0) is intended for technology demonstration, evaluation purposes, and prototyping S32K3xx MCUs and Evaluation Boards.   Useful Resources Examples, Trainings, and Support: https://community.nxp.com/community/mbdt    

This page summarizes all Model-Based Design Toolbox videos related to HCP Product Family. Deploying Radar Applications to NXP´s S32R41 Processor Using Simulink® Link to the recording here This webinar shows how to use Radar Toolbox, Simulink ®  , and Embedded Coder ®  to generate C code for radar signal processing algorithms for range and speed estimation and deploy them to NXP ® ´s S32R41 high-performance processor for high-resolution radar. Based on MathWorks´ radar example models, we use Embedded Coder to generate optimized C code and run it in Processor-in-the-Loop (PIL) mode on the S32R41 processor. The code generation workflow will feature the use of NXP´s Model-Based Design Toolbox (MBDT), which provides an integrated development environment and toolchain for configuring and generating all the necessary software to execute complex applications on NXP MCUs and processors.