NXP Model-Based Design Tools Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

NXP Model-Based Design Tools Knowledge Base

Discussions

Sort by:
Introduction The aim of this article is to help any user of Model-Based Design to enjoy his/her own custom C libraries or to call any C drivers or components that are not yet supported by NXP's toolbox. This uses the Matlab Coder and requires to include only a MATLAB function block in which the model will call a C function. For more details, you can have a look on the Mathworks Help Center at Integrate C Code Using the MATLAB Function Block- MATLAB & Simulink.   BMS System In my opinion, the greatest way to learn something is "learning-by-doing". So in this tutorial, we will add support for the BMS System in Model-Based Design for S32K. You are already familiar with our toolbox supported boards so let's talk a bit about this BMS system. NXP has a great cell controller IC designed for automotive and industrial applications, more details can be found here MC33772B | 6-Channel Li-ion Battery Cell Controller IC | NXP. For this tutorial, we will use the FRDM33772BSPIEVB | MC33772 SPI EVB | NXP  board, which handles up to 6 battery cells and connects to many NXP controllers via SPI. This is also compatible with the S32K family with some minor jumpers adjustments, but all the instructions can be found on the product page.  So the goal of this project is to be able to read the cell voltages from an MBDT Simulink model. Main Steps In order to include custom code, the user should follow these steps: 1. Add the directory path from which the Simulink will include the directories under Settings > Code Generation > Custom code > Include directories. 2. Insert a Matlab Function block in the Simulink model. This will be used for initialization. The goal here is to include the c headers in the generated code files. This requires to declare coder constant using the coder.const function. That has to be updated in the Build info using coder.updateBuildInfo . Here, the headers and the sources has to be included following this template: %% Adding  header information to the generated code coder.cinclude('driver.h'); %% Adding source files to MakeFile coder.updateBuildInfo( 'addSourceFiles', 'driver.c' ); This operation has to be performed only once. 3. When the user needs to call a custom function from the Simulink, the user must add a Matlab Function block, declare the inputs and outputs as required. Inside the Matlab Function code, the coder.ceval function must be called using the parameters provided as inputs. For example, if the user needs to call a C function called BMS_Init with no parameters, the following line of code will perform that: %% Initializing the BMS driver coder.ceval('BMS_Init'); If the user needs to provide an input parameter, then it will be provided either directly, either using coder.ref  as an argument or using coder.rref if the reference to that value has to be passed. function BMS_Init(parameter)    if( coder.target( 'Rtw' ) )          coder.ceval('BCC_Init', parameter);          coder.ceval('BCC_Init', coder.ref(parameter));     end end This will generate the following code: BCC_Init(true); BCC_Init(&parameter); But if the code is more complex, the easiest way is to declare a wrapper function and to call the wrapper using the coder.ceval. BMS Support This scenario fits on most of our users requirements: to use a piece of code unsupported yet on MBDT. For this IC, NXP already provides the KIT3377x_DRV driver together with an example in S32DS which measures cell voltages and displays it using FreeMaster.   We created an S32K project for the S32K144 board, added the FreeMaster block and an LPSPI Instance according to the settings and the pin requirements by the MC33772 board. The Initialize variable will only be used to call the initialization sequence for the BMS. Now, as we described in the previous chapter, we declared a folder "bcc" that contains the required drivers and some wrappers, also inserted in the Configuration parameters. The initialize function contains a Matlab Call Function. This one includes all the steps described at the second point. What should be noticed here is the check from line 7. All that cinclude code will be called only when the coder.target is Rtw. If the user adds an else condition, that code will be called only when simulate. Now, MBD_MCC_Init is wrapper designed to perform all the initialization steps from the driver. It was easier like this. The MC33772 has been initialized so whenever the user needs the values, he/she must add a Matlab Function block that will provide the values to the model.   The code behind this block has been attached in the next image. The output values from the getCellMeasurements are provided as outputs and inside the get_cellVoltages, it will call the C updateMeasurements function using the coder.wref function. Running BMS Now, after we solved some bugs during code generation   and had successfully built the code, we can run the generated code on the board. The following screenshot represents the Voltages and a variable Current measurement converted by the MC33772.   Conclusions In this article, we presented a method of getting the needed C libraries/drivers/code in the Simulink model using custom code and Matlab Coder. We provided a short step list and a more detailed tutorial for an actual application, a Battery Management System, using NXP hardware. This approach can be successfully achieved either if we use the S32K or MPC Toolboxes. Later edit (1): As requested, I attached the model and the FreeMaster project for achieving the measurements from the MC3377xB (FRDM3377xBSPIEVB) with the S32K144 board using Model-Based Design and custom code. In order to run it, you must follow the steps: 1. Download and unzip the archive there is a bcc folder inside, next to the s32k_mc3377x.mdl. 2. Download the SDK (Embedded SW: MC33771/MC33772 SW Driver | NXP )  BCC SW Driver package for MC33771B/MC33772B (Lite version) and from the SDK folder bcc copy all the files to the bcc folder of the model.  I can not add the SDK driver in the archive since for the BCC SDK there is an agreement that you must read before download. 3. Open the s32k_mc3377x model, go to the BMS_Init function and replace the line 4 string with the full path of the model bcc location folder. 4. After this, the code should be generated and run successfully. Later edit (2): If you are interested to get the solution alongside the instruction on how to connect the MC3377xB and the MPC5744P via Model-Based Design Toolbox, please have a look at this question here: MPC5744P &MC33771B Configuration Later edit (3): As many of you requested, we've added the example code for the S32K144 & FRDMDUALMC33664 to communicate with the MC33771C. See the attached archive. bms_s32k_frdm2_771c_tpl_cc. The bcc driver for the MC33771C is different than the one for the MC33771B and you have to download the missing files from here.   Happy hacking! Marius
View full article
1. Introduction In this series of articles, we demonstrate how to program the MR-CANHUBK344 board using the Model-Based Design Toolbox. The goal of this first article is to briefly present the hardware setup (the board and the connections that have to be made) and offer step-by-step instructions on how to create, configure and upload a simple program on the MR-CANHUBK344 development board. This article’s application consists of toggling onboard LEDs using the push button by configuring the Dio peripheral and the respective pins. The next articles in the series will showcase how to use different peripherals of the MR-CANHUBK344 board. 1.1. The MR-CANHUBK344 board The MR-CANHUBK344 evaluation board provides a T1 ethernet interface alongside 6 CAN (Controller Area Network) interfaces, two for each of the three different types, CAN-FD (Flexible Data-Rate), CAN-SIC (Signal Improvement Capability) and CAN-SCT (Secure CAN Transceiver). The board is designed for mobile applications, and it is based on the NXP ® S32K344, an Arm ® Cortex ® -M7 general-purpose automotive microcontroller, which features advanced safety, security and software support. Below you can find the block diagram for the MR-CANHUBK344 board. For more details about the MR-CANHUBK344 board, please follow the link:  https://www.nxp.com/design/development-boards/automotive-development-platforms/s32k-mcu-platforms/s32k344-evaluation-board-for-mobile-robotics-with-100base-t1-and-six-canfd:MR-CANHUBK344 1.2. Prerequisite Software To be able to follow the steps in this article, the following software is necessary: MATLAB ®  and Simulink ® (2021a or newer), including Stateflow ® , MATLAB ® Coder TM , Simulink ® Coder TM , Embedded Coder ® Model-Based Design Toolbox for S32K3xx 1.4.0 or 1.5.0 1.3. Prerequisite Hardware During this example, the following hardware is used: MR-CANHUBK344 evaluation board J-Link Debug Probe 12V power supply and adapters to allow powering up the board through the P27 port 1.4. Powering up the MR-CANHUBK344 First, the CANHUBK344 board accepts a wide range of input voltages, from 5V to 40V, which can be delivered through 2 different ports. P27 is the main power delivery port and it is used with a 5-pin JST-GH connector. This connector has 2 lines for power, 1 is not connected and the last 2 are ground lines. P28 is an alternate way of powering up the board and it consists of a 2-pin header. Regardless of the port chosen for powering up the board, precautions should be taken to make sure that the polarity is correct and that the pins align properly with the ports. Note: By default, the FS26 PMIC (Power Management IC) implements a challenger window watchdog that will reset the board’s MCU continuously if the challenge is not handled in software. To avoid this behavior, the FS26 must be put into debug mode. This is done by removing the JP1 jumper, then supplying 12V to the board and then inserting the JP1 jumper again. An example of how to connect both the power supply and the J-Link Debug probe will be discussed in the next chapter. 1.5. Connecting the J-Link Debug Probe When connecting the J-Link Debug Probe, pay attention to the connector, to make sure that you are aligning the red stripe of the connector with the pin number 1 on both sides. The associated J-Link software is not included in the Model-Based Design Toolbox and has to be installed separately. Installing the J-Link's software in the default location will allow it to work without having to select the location of the installation every time a new model is created.   2. Digital Inputs/Outputs Configuration So far, we have covered details about the board, how to power it up and how to connect the J-Link Debug Probe to it. This chapter will focus on designing the application that will run on the MR-CANHUBK344 board using the Model-Based Design Toolbox. 2.1. Creating and configuring the Simulink model Create a new model: Next, open the newly created model and head to the MODELING tab. To configure the hardware, click on the Model Settings option. If you have a tough time finding the button, you can use the Ctrl+E shortcut to open the Model Settings window. Moving forward, the correct Hardware board must be chosen from the Hardware Implementation tab. In this case, it is NXP S32K3xx. On the Solver tab, make sure to configure the Type to Fixed-step and set the Fixed-step size according to the needs of the application. This parameter controls how often the code in the model runs by setting the period time. For example, a Step Size of 0.1s would make the code run 10 times in a second, once every 0.1 seconds. In the current project, this value ends up affecting the frequency of the LED that is being toggled by itself, so setting it to a very small value might make it hard to see that the LED is indeed blinking. Setting it to a higher value would make the buttons feel unresponsive because the code would check for button presses rarely. A good value for this example is 0.1s, because the toggling LED will be ON, and respectively OFF 5 times in a second, since it changes every 0.1 seconds. This way, the LED’s change is visible, and the buttons feel responsive because their interaction is checked every 0.1 seconds. A few more options must be configured in Hardware Implementation. First, to access the submenu needed for the next changes, you have to click on the Target hardware resources option. From there, select Hardware and change the Hardware Part to S32K344-Q172. This will load the default configuration for the S32K344-Q172 hardware part. Later we will modify this configuration to work on the MR-CANHUBK344. Afterwards, head to the Download tab, still under the Target hardware resources submenu. Make sure that the Type is set to J-Link – JTAG and that the Target Memory is set to FLASH. If your J-Link software has been installed in a location that is different from the default location, you have to select the path to the JLink.exe executable by pressing the Browse button next to the J-Link location label and selecting the executable from the location where it was installed. The last step in the Target hardware resources submenu is to navigate to the Tools Paths and select S32 Config Tool in the Configuration Tool field. This setting changes the external configuration tool that will be used to configure the MCU’s pins, clocks and peripherals. This will allow the MCU to properly control all the components of the board. The Model-Based Design Toolbox for S32K3 uses integration with dedicated configuration tools to allow the configuration of the board's pins, clocks and peripherals, providing options for both Elektrobit Tresos (EB Tresos) and S32 Configuration Tools. More details on this configuration will be provided in the following sections. After all the changes have been made, do not forget to click Apply and Ok. Now, we are going to start designing the application model. To access the Model Based Design Toolbox provided blocks that control the hardware, click on the Library Browser button, which is going to open the Simulink Library Browser. From this window, navigate to the S32K3xx Core, System, Peripherals and Utilities menu under the NXP Model-Based Design Toolbox for S32K3xx MCUs and then select the IO Blocks from the right side of the window. In this example we will only use Dio blocks, so to start things off, we can drag-and-drop the Dio block into the Simulink Workspace. For the blocks to control the right pins, we must use the external configuration tool chosen to map the pins to the correct values. When creating an application for a supported Hardware Part, the Model-Based Design Toolbox comes with a default configuration project, enabling an initial set of peripherals, pins and clock settings for all the components it offers support for. The toolbox can be used with this default configuration project to design applications, without requiring any additional steps inside external configuration tools.   However, if the hardware or the application requires a different configuration than the default one, the external configuration tools allow you to open and modify the default configuration project to suit your needs. To quickly open the S32 Config Tool, you can double-click on the Dio block that has just been added and then click on the Configure… option. This opens the project’s configuration in the selected configuration tool. The configuration can also be done in EB Tresos in a similar manner, if it is the designated configuration software. 2.2. Pins Configuration The next step is to take note of the pins used for the project you intend on creating. In this example, we will be using 2 LEDs and one of the 2 push buttons available on the board, which are part of the Dio component. By studying the schematic, we can obtain all the information we need about the pins used. To be able to easily find a pin, search for its name and then look for the correspondence. In this example, by looking for the USER_SW1 pin, we can see that it is assigned to the PTD15 pin, also identified as GPIO111. After doing this for every pin, we can proceed with the configuration. While using the S32CT program, the pins’ MSCR (third column) will not be needed, but they will be required for the EB Tresos configuration. First, we will have to configure the pins to work as we expect them to, as inputs, outputs or even both. To do that, navigate to the Pins Tool by clicking on the Pins button.   Note: If you are using the Model-Based Design Toolbox for  S32K3xx version 1.5.0, the pins’ configuration will require following these steps first: Before being able to see the configured pins, we must first select the pin’s functional group: In the default configuration projects delivered by the Model-Based Design Toolbox, the pins are organized in Functional Groups based on the peripheral they are routed to, e.g. Adc_Pins_MBDT. If there are no such groups already defined, you can create them by clicking on the icon highlighted by the arrow. This will open a menu from which you can create and delete functional groups. For now, we will select the Dio_Pins_MBDT functional group, to configure the available DIO pins.   In this step, we will focus our attention on the top-left window, the Pins tab. First, we must check if there is any pin with the same name in the configuration. To do that for the button named USER_SW1 we can type its name value in the type filter text field. Here we can see that a pin with the same name already exists, and it is configured on the pin PTB19. To avoid further configuration issues, we must disable this pin. We can do that by clicking on the green Checkbox from the left side of the row. Then, we deselect the already selected item and click done, making sure nothing else is selected. To start the configuration process for the first pin, the button named USER_SW1, we can type its pin value in the type filter text field. As we can see, the pin is not configured for our intended behavior. To change that, we must update the identifier, the label, and click on the checkbox on the left. By doing that, the following menu will pop up: Here we will select the SIUL2:gpio,111 option since it matches our requirement. Afterwards, another window will pop up asking about the direction of the pin. In this case, we are configuring a button, so we only expect it to act as an Input. This process of removing the old configuration and adding the new one has to be repeated for every pin that will need to be configured. Keep in mind that when configuring the LEDs, you will have to set the direction as Input/Output since one of the LEDs will be toggled from one state to another, which requires the LED to be read before the output can be inverted. By taking a look at the bottom window, Routing Details, we can see more configuration options for the pins. You can use the type filter text field to limit the results to only the pins you are interested in seeing. The MR-CANHUBK344 board has its LED logic inverted, so, by default, the board's LEDs would turn on when powering the board. To avoid that, we assign an Initial Value to the LED. By setting the Blue LED's Initial Value to High, it is going to turn off as soon as the board starts.   Note: If you are using the Model-Based Design Toolbox for S32K3xx version 1.5.0, the pins’ configuration will require following these steps as well: The configuration we are about to perform has to be identical to the configuration done in the Pins component. When we return to the Peripherals tool, the Port component will be highlighted in red due to inconsistencies in the pins configured. This is caused by the fact that we just updated the pins in the Pins tool, and now we have to update them in the Port component as well. In the default configuration projects delivered by the Model-Based Design Toolbox, the PortPins are organized in PortContainers based on their respective peripheral, eg. Adc_Pins, Dio_Pins, Can_Pins, etc. As we can see, when clicking on the Port component we are being shown which PortContainer has errors. In this case, it is the PortContainer identified by the number 2, which corresponds to Dio_Pins. The best course of action here would be to start modifying the PortPin entries in such a way that they reflect the newly configured values in the Pins tool. We can begin configuring the pins with the right PortPin Mscr and Name. The Mscr value can also be found in the schematic for the board. For this article, these values have been shown in the table from this chapter’s beginning. They are noted as “GPIO111” or “GPI25” where the numeric part represents the Mscr: 111 and 25. When filling in the PortPin Mscr, the other fields will retrieve their values from the Pins configuration. Important note: The PortContainers in Port and the Functional Groups in Pins must respect the following naming convention: Pins’ Functional group = PortContainer Name + ‘_MBDT’. For example, the Pins’ Functional Group for the PortContainer called Dio_Pins is Dio_Pins_MBDT. This process has to be repeated for each of the 5 added pins. The PortPin Id is a unique indentifier for each item in the PortPin section. This identifier is also unique across all the PortContainers, so in case your PortPin Id is reporting an error about the value not being unique, it means that there’s another PortPin item with the same PortPin Id value. This field can have values from 0 to the number of configured pins. For example, if your configuration has 40 pins, the PortPin Id can hold values between 0 and 40. In this specific scenario, we are replacing 5 Dio pins with another set of 5 Dio pins, so as along as we keep the PortPin Id unchanged for each item, there should be no issues. 2.3. Component Configuration Head back to the Peripherals Tool by clicking on the Peripherals button. Finally, after configuring the pins’ directions, we have to configure the Dio component so that the pins can be used during the execution of the program. This will be done in the DioConfig tab under the Dio Configuration tab. If it is not showing by default, you can press on the Dio component on the left side of the screen and it should bring it up. Understanding how the DioPort and DioChannel are organized might prove useful later. The number present under the DioPort label represents the corresponding value of the Dio port that you want to access. Below you can find a table with the correspondence between the values and the registers. AL=0 AH=1 BL=2 BH=3 CL=4 CH=5 DL=6 DH=7 EL=8 EH=9 Each of those is half of a register and together every line forms a 32-bit register. For example, AL and AH contain all the pin values that are assigned to PTA. AL contains the first 16 pins and AH contains the next 16 pins. For example, the RGBLED0_GREEN pin is assigned to PTA27. From that we can conclude that, since 27 is higher than 15 (the 16 th value of AL, since the first value is 0), the PTA27 pin must be assigned to the AH register. To reiterate, the PTA0-PTA15 pins belong to the AL register while the PTA16-PTA31 (the value must be offset by -16 when computing the Id) pins belong to the AH register, and this is true for the rest of the registers too, PTB, PTC, PTD, PTE. Given that the previous configuration did not match our setup, we should first prepare the registers by removing the components that we have already disabled in the section 2.2. For example, in the DioPort 0 we can see the old (disabled) LEDs, which can be removed by clicking the X button shown. This should be done for each DioPort Id to make sure there aren’t any incorrectly configured items. In the current case, we only have to remove the RGBLED0_BLUE, RGLED0_GREEN and USER_SW_1 items, which we will later replace with our own. After removing the LEDs’ configuration from the previous ports, since now the LEDs are routed to different pins, we can start adding the pins that we have configured in the prior step. Figuring out where each pin should go relies on the explanations from the beginning of this chapter. As an example, adding the ping RGBLED0_BLUE, which corresponds to PTE12, means going to the DioPort 4 because the value 12 is found in the first interval, 0-15, which points us to the EL register. To add a DioChannel, click on the + Button next to DioChannel. A new channel will be created and you have to fill in the details regarding the port. This has to be done for every of the 3 configured pins, in their respective registers. The last step is to save the configuration project and press the Update Code button. Afterwards, press Ok on the dialog window that popped up. Afterwards, feel free to close the configuration software. To update the configuration in the Simulink model, press the Refresh button inside the menu that pops up when double-clicking a block.   3. DIO Model Overview This article’s goal is to explain the workflow of creating a model that toggles the LEDs based on the push buttons available on the board. The logic will be the following: - The blue LED is toggled using the Push button 1; - The green LED is automatically toggled every simulation step. This means we will need blocks to read an input value, write an output value and flip an output value. These operations can be achieved using Dio blocks. A Dio block has multiple possible functions, which you can select from the Function dropdown. Once a new function is selected, the functionality and the block’s inputs and outputs will change accordingly. The pin that is going to be the target of the function can be chosen by selecting it from the dropdown list of the Channel option. The items that appear in the dropdown list correspond to the Dio channels that have been configured in chapter 2.3. The Input Simulation Enable option will not be used in this example, so it should be unchecked. Enabling this option will create an additional input for the block, which can be used to simulate the model’s behavior. For the functions Dio_ReadChannel, Dio_ReadChannelGroup and Dio_ReadPort, the block outputs the simulation input. For the Dio_FlipChannel function, the block will output the inverted simulation input The way the Dio Block is currently configured, it will read the input value from the button USER_SW1 which we can later use to control the LEDs. Since we want to toggle an LED when a button is pressed, it means we have to look for the rising edge of that input. To do that, a Trigger subsystem block will be used, that takes as input the value read from the button USER_SW1. The block’s Trigger type is configured to rising by clicking on the Trigger icon and when it detects that rising edge in its input, the subsystem will be executed. In this situation, we use the Dio block to invert the output of the LED. The contents of the newly added Trigger subsystem are seen below: Automatically toggling the green LED is a much simpler task due to the function FlipChannel available in the Dio block. The FlipChannel Dio block also has an output, which outputs the current state of the LED. Since that information is not going to be used anywhere else, a Simulink Terminator can be attached to that output, to avoid having errors. To upload and run the code on the MR-CANHUBK344 board, select the HARDWARE tab at the top of the window, and then click on the Build, Deploy & Start button. This will start the process of generating code from the Simulink model and uploading it to the board using the J-Link programmer. Note: If the J-Link’s path was not configured in the earlier steps, a dialog box will pop up requiring the path to the executable. If the software was installed in the default location, pressing on the Default option will be enough. Initially, after uploading the program or resetting the board, you will notice that the RGB LED is green and blinking. Keep in mind that the MR-CANHUBK344 board has its LED logic inverted, so writing a value of 1 to an LED output will turn it off, and writing a value of 0 to an LED output will turn it on. Pressing the SW1 toggles the blue LED, while the green one keeps blinking.   4. Conclusion After following the steps shown in this tutorial, you should now be able to create applications that use the MR-CANHUBK344 board’s LEDs and push buttons along with the Model-Based Design Toolbox. To continue learning about the MR-CANHUBK344 development board and how it can be used with the Model-Based Design Toolbox, check out the next articles in this series: Beginner's Guide for Model-Based Design Toolbox: Sending data via UART and monitoring signals with FreeMASTER Beginner's Guide for Model-Based Design Toolbox: Controlling LED intensity with ADC and PWM Beginner's Guide for Model-Based Design Toolbox: Communicating over the CAN Bus     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. 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.
View full article
      Product Release Announcement Automotive Microcontrollers and Processors NXP Model-Based Design Toolbox for MPC57xx – version 3.0.0     Austin, Texas, USA February 18, 2019 The Automotive Microcontrollers and Processors’ Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for MPC57xx version 3.0.0. This release supports automatic code generation for peripherals and applications prototyping from MATLAB/Simulink for NXP’s MPC574xB/C/G/P series.   FlexNet Location https://nxp.flexnetoperations.com/control/frse/download?element=10769197   Activation link https://nxp.flexnetoperations.com/control/frse/download?element=10769197   Technical Support NXP Model-Based Design Toolbox for MPC57xx issues are tracked through NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt   Release Content Automatic C code generation based on PA SDK 2.0.0 RTM drivers from MATLAB®/Simulink® for NXP MPC574xB/C/G/P derivatives: MPC5744B, MPC5745B, MPC5746B                                                (*new) MPC5744C, MPC5745C, MPC5746C, MPC5747C, MPC5748C      (*new) MPC5746G, MPC5747G, MPC5748G                                               (*new) MPC5741P, MPC5742P, MPC5743P, MPC5744P                             (*upd) Multiple options for MCU packages, Build Toolchains and embedded Target Connections are available via Model-Based Design Toolbox MPC574x Simulink main configuration block Enhanced user experience with a complete redesign of all Simulink Library blocks compared with v.2.0.0 to support: Similar look & feel with Model-Based Design Toolbox for S32K14x Series Basic and Advanced configurations modes based on PA SDK 2.0.0 RTM standard API Integration with MathWorks SW environment: Installer, Help and online Add-on Manager for distribution and installation MPC574xP Ultra-Reliable MCU for Automotive & Industrial Safety Applications and MPC574xB/C/G Ultra-Reliable MCUs for Automotive & Industrial Control and summary of the peripherals coverage by Model-Based Design version 3.0.0 is highlighted in red:   Redesigned the main Simulink Embedded Target library for supporting future additions for other MPC57xx derivatives, Automotive Math and Motor Control Libraries and MPC57xx Examples:   Implement communication port auto discovery to allow easy configuration for downloading the generated code to NXP targets and new Diagnostic options to helps with model creation or migration. 100% MPC574x supported peripheral coverage with examples. Currently there are 102 examples available as part of the toolbox that exercise all the functionalities supported. The examples are grouped into two categories: MPC574x Generic examples that can be run on any of the MPC574x Evaluation Boards MPC574x Targeted examples that are configured for a single target (e.g.: might contains peripherals that are available only on a specific target) Motor Control examples for PMSM and BLDC based on FOC and 6-step commutation with Closed and Open loop control Enable MATLAB code profiler for NXP targets for measuring the function execution time using Software -in-the-Loop or Processor-in-the-Loop modes For more details, features and how to use the new functionalities, please refer to the Release Notes and Quick Start Guide documents attached.   MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s MPC57xx MCUs and evaluation boards solutions out-of-the-box with: NXP Support Package for MPC57xx Online Installer Guide Add-on allows users to install NXP solution directly from the Mathwork’s website or directly from MATLAB IDE. The Support Package provide a step-by-step guide for installation and verification. NXP’s Model-Based Design Toolbox for MPC57xx version 3.0.0 is fully integrated with MATLAB® environment in terms of installation, documentation, help and examples;   Target Audience This release (v.3.0.0) is intended for technology demonstration, evaluation purposes and prototyping for MPC574xB/C/G/P MCUs and their corresponding Evaluation Boards: DEVKIT-MPC5744P PCB RevX1 SCH RevB DEVKIT-MPC5748G PCB RevA SCH RevB Daughter Card MPC574XG-256DS RevB Daughter Card X-MPC574XG-324DS RevA Daughter Card MPC5744P-257DS RevB1 Daughter Card SPC5746CSK1MKU6 Motherboard X-MPC574XG-MB RevD Motherboard MPC57XX RevC        
View full article
  Product Release Announcement Automotive Embedded Systems NXP Model-Based Design Toolbox for BMS – version 1.1.0     The Automotive Embedded Systems, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for BMS version 1.1.0 RTM. This release is an Add-On for the NXP Model-Based Design Toolbox for S32K3xx 1.4.0, which supports automatic code generation for battery cell controllers and applications prototyping from MATLAB/Simulink. This product adds support for MC33775A, MC33774A, MC33772C, MC33664, and MC33665A and part of their peripherals, based on BMS SDK components (Bcc_772c, Bcc_772c_SL, Bcc_775a, Bcc_774a, Bms_TPL3_SL_E2E, Bms_common, Phy_664, Phy_665a). In this release, we have enhanced the integration with the Model-Based Design Toolbox for S32K3xx version 1.4.0, added support for the BMS SDK 1.0.2 and BMS SDK 1.0.2 SL, and MATLAB support for the latest versions. This product comes with battery cell controller examples, targeting the NXP HVBMS Reference Design Bundle Using ETPL (RD-HVBMSCTBUN) and 800 V Battery Management System (BMS) Reference Designs Using ETPL (RD-HVBMSCT800BUN).   Target audience: This product is part of the Automotive SW – Model-Based Design Toolbox.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=3983088   Technical Support: NXP Model-Based Design Toolbox for BMS 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 Battery Cell Controllers derivatives: MC33775A MC33774A MC33772C MC33665A MC33664   Support for the following peripherals (BMS SDK components): Bcc_775a Bcc_774a Bcc_772c Bms_Common Bms_TD_handler Bcc_772c_SL Bcc_TPL3_SL_E2E   Support for MC33775A, MC33774A and MC33772C Battery Cell Controllers & MC33664PHY and MC33665PHY The toolbox provides support for the MC33775A, MC33774A, MC33772C, MC33664 and MC33665A. The MC33775A, MC3774A, and MC33772C are lithium-ion battery cell controller ICs designed for automotive applications performing ADC conversions of the differential cell voltages and battery temperatures, while the MC3366 and MC33665A are transceiver physical layer transformer drivers, 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 BMS show how to communicate between the S32K344/S32K358 and the MC33775A, MC33774A, and MC33772C via the MC33664/MC33665 transceivers.  For the MC33775A and MC33774A, the examples show how to configure the battery cell controllers to perform Primary and Secondary chain conversions and read the cell voltage conversion results from the MC33775A/MC33774A, while for the MC33772C the examples show how to configure the Battery cell controller to read the pack current. All the converted values are displayed to the user over the FreeMASTER application.               BMS SDK version supported: SW32K3_BMS_SDK_4.4_R21-11_1.0.2 SW32K3_BMS_SL_SDK_4.4_R21-11_1.0.2_DEMO Support for MATLAB versions: R2021a R2021b R2022a R2022b R2023a More than 15 examples showcasing the supported functionalities: MC33775A Configuration and data acquisition example MC33774A Configuration and data acquisition example MC33772C Configuration and data acquisition example RD-HVBMSCTBUN Configuration and data acquisition example alongside additional peripherals on the BMU board (communication, sensors, auxiliary circuits) RD-HVBMSCT800BUN Configuration and data acquisition example alongside additional peripherals on the BMU board (communication, sensors, auxiliary circuits)   For more details, features, and how to use the new functionalities, please refer to the Release Notes and Quick Start Guides documents attached.   MATLAB® Integration: The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s Battery Cell Controllers together with S32K3xx MCUs and evaluation board solutions out-of-the-box. NXP Model-Based Design Toolbox for BMS version 1.1.0 is fully integrated with MATLAB® environment.     Target Audience: This release (1.1.0) is intended for technology demonstration, evaluation purposes, and battery management systems prototyping using NXP Battery Cell Controllers and S32K3xx MCUs and Evaluation Boards.   Useful Resources: Examples, Trainings, and Support: https://community.nxp.com/community/mbdt   DEMO High Voltage Battery Management System with Model-Based Design: The HVBMS with MBDT demo, running on the NXP HVBMS Reference Design and NXP GoldBox, combines the MathWorks Simulink application example Design and Test Lithium Ion Battery Management Algorithms  together with the NXP’s Model-Based Design Toolbox for BMS  Blocks to automatically generate, build, and deploy standalone BMS applications on the NXP targets. Here are the main highlights of this demo: Develop a High-Voltage Battery Management System application to run on the NXP's HVBMS Reference Bundle using the Model-Based Design paradigm Model, Develop, and Validate BMS Applications in MATLAB and Simulink Automatically Generate code, Build, and Deploy hardware-aware applications on NXP microcontrollers and processors Monitor and Tune the application using FreeMASTER and Vehicle Network Toolbox at runtime Create a Cloud Digital twin with NXP GoldBox and AWS with data processing in MATLAB Cloud          
View full article
      Product Release Announcement Automotive Microcontrollers and Processors NXP Model-Based Design Toolbox for S32K1xx - 2018.R1     Austin, Texas, USA July 23, 2018 The Automotive Microcontrollers and Processors’ Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K1xx 2018.R1. This release supports automatic code generation for S32K1xx peripherals and applications prototyping from MATLAB/Simulink for NXP’s S32K1xx Automotive Microprocessors.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=10221477   Activation link https://nxp.flexnetoperations.com/control/frse/download?element=10221477     Technical Support NXP Model-Based Design Toolbox for S32K1xx issues are tracked through NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt   Release Content Automatic C code generation based on S32K SDK 2.0.0 RTM drivers from MATLAB® for NXP all S32K14x derivatives: S32K142 MCU Packages with 16/32KB SRAM (*updated) S32K144 MCU Packages with 48/64KB SRAM (*updated) S32K146 MCU Packages with 128KB SRAM (*new) S32K148 MCU Packages with 192/256KB SRAM (*new) Multiple options for packages and clock frequencies are available via Model-Based Design Toolbox S32K Simulink main configuration block New S32K peripheral support added for DMA, RTC, Registers were added to extend the existing toolbox capabilities. The 2018.R1 peripheral coverage for each of the S32K14x derivatives is shown below: Redesigned the FlexTimer configuration block to support additional features for PWM generation and triggering events Added support for System Basis Chip (SBC) UJA116x configuration Redesigned the main Simulink Embedded Target library for supporting future additions of other S32K derivatives and External Devices for S32K products Implement communication port auto discovery to allow easy configuration for downloading the generated code to NXP targets and new Diagnostic options to helps with model creation or migration. 100% S32K supported peripheral coverage with examples. Currently there 115 examples available as part of the toolbox that exercise all the functionalities supported Add support for External Mode that enables Simulink on the host computer to communicate with the deployed model on NXP hardware board during runtime Enable MATLAB code profiler for NXP targets for measuring the function execution time using Processor-in-the-Loop 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 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 NXP solution directly from the Mathwork’s website or directly from MATLAB IDE. The Support Package provide a step-by-step guide for installation and verification. NXP Model-Based Design Toolbox for S32K1xx 2018.R1 is fully integrated with MATLAB® environment in terms of installation, documentation, help and examples;   Target Audience This release (2018.R1) is intended for technology demonstration, evaluation purposes and prototyping for S32K142, S32K144, S32K146 and S32K148 MCUs and Evaluation Boards  
View full article
      Product Release Announcement Automotive Microcontrollers and Processors NXP Model-Based Design Toolbox for MPC57xx – version 3.1.0     Austin, Texas, USA December 16 th , 2019 The Automotive Microcontrollers and Processors Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for MPC57xx version 3.1.0. This release supports automatic code generation for peripherals and applications prototyping from MATLAB/Simulink for NXP’s MPC574xB/C/G/P and MPC5777C series.   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   Release Content Automatic C code generation based on PA SDK 3.0.2RTM drivers from MATLAB®/Simulink® for NXP MPC574xB/C/G/P and MPC5777C derivatives: MPC5744B, MPC5745B, MPC5746B                                                   (*upd) MPC5744C, MPC5745C, MPC5746C, MPC5747C, MPC5748C         (*upd) MPC5746G, MPC5747G, MPC5748G                                                  (*upd) MPC5741P, MPC5742P, MPC5743P, MPC5744P                                (*upd) MPC5777C                                                                                            (*new) Added support for SIL, PIL and AUTOSAR Blockset code generation and simulation for the MPC5777C Ultra-Reliable MCU for Automotive and Industrial Engine Management. Currently only the basic enablement is available for this microcontroller as shown in the picture below: Enhance MATLAB/Simulink support to all versions starting with 2016a to 2019b Enable MATLAB AUTOSAR Blockset on all MPC574xB/C/G/P and MPC5777C to allow users to configure, simulate, generate and profile AUTOSAR Applications with NXP Hardware; For more details, features and how to use the new functionalities, please refer to the Release Notes and Quick Start Guide documents.   MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB® and Simulink® experience by allowing customers to evaluate and use NXP’s MPC57xx MCUs and evaluation boards solutions out-of-the-box with: NXP Support Package for MPC57xx Online Installer Guide Add-on allows users to install NXP solution directly from the Mathwork’s website or directly from MATLAB IDE. The Support Package provide a step-by-step guide for installation and verification. NXP’s Model-Based Design Toolbox for MPC57xx version 3.1.0 is fully integrated with MATLAB® environment in terms of installation, documentation, help and examples;     Target Audience This release (v.3.1.0) is intended for technology demonstration, evaluation purposes and prototyping for MPC574xB/C/G/P and MPC5777C MCUs and their corresponding Evaluation Boards: DEVKIT-MPC5744P PCB RevX1 SCH RevB DEVKIT-MPC5748G PCB RevA SCH RevB DEVKIT-MPC5777C-DEVB                                                                     (*new) Daughter Card MPC574XG-256DS RevB Daughter Card X-MPC574XG-324DS RevA Daughter Card MPC5744P-257DS RevB1 Daughter Card SPC5746CSK1MKU6 Daughter Card MPC5777C-516DS                                                        (*new) Daughter Card MPC5777C-416DS                                                        (*new) Motherboard X-MPC574XG-MB RevD Motherboard MPC57XX RevC      
View full article
  Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for S32M2xx – version 1.0.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 S32M2xx version 1.0.0. This release supports automatic code generation for S32M2xx peripherals and applications prototyping from MATLAB/Simulink for NXP S32M2xx Automotive Microprocessors. This new product adds support for S32M41, S32M242, S32M43,  S32M244, S32M274, S32M276 MCUs and part of their peripherals, based on RTD MCAL components (ADC, AE, DIO, CAN, DPGA, GDU, GPT, MCL, PWM, MCU, PORT, QDEC, UART). In this release, we have also added support for FreeMASTER, AMMCLib, and MATLAB support for the latest versions. The product comes with over 60 examples, covering all supported peripherals, and Simulink simulation modes Software-in-the-Loop, Processor-in-the-Loop, and External Mode.   Target audience: This product is part of the Automotive SW – S32M2 Standard Software Package.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=3785898   Technical Support: NXP Model-Based Design Toolbox for S32M2xx 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 S32M2xx derivatives: S32M241 S32M242 S32M243 S32M244 S32M274 S32M276   Support for the following peripherals (MCAL components): ADC AE DIO CAN DPGA GDU GPT MCL PWM MCU PORT QDEC UART   Provides 2 modes of operation: Basic – using pre-configured configurations for peripherals; useful for quick hardware evaluation and testing Advanced – using S32 Configuration Tool or EB Tresos to configure peripherals/pins/clocks   Integrates the Automotive Math and Motor Control Library version 1.1.34: All functions in the Automotive Math and Motor Control Functions Library v1.1.34 are supported as blocks for simulation and embedded target code generation.   Integration with FreeMASTER 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 R2021a R2021b R2022a R2022b R2023a R2023b   Support for custom board initialization Toolbox generates the components’ peripherals initialization function calls as configured in the Board Initialization window, which can be customized to each Simulink model. This feature allows users to set a custom order for the components initialization, the insertion of the Custom code sequences, or share the custom initialization with multiple Simulink models via the Export and Import functionality.       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 hardware configuration once. After it is saved as a custom default project, it can be used for every model that is being developed.     Integration with S32 Config Tools version v1.7:       Integration with S32 Design Studio The toolbox automatically generates the <model_name>_Config folder, next to the Simulink model location, providing the user the opportunity to easily import the generated code from Simulink into S32 Design Studio. Each time the code is generated, the <model_name>_Config folder is updated with the new changes. The toolbox also provides a mechanism to launch an S32 Design Studio instance, with the imported generated code project in the Project Explorer tab from S32DS.   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   Support for profiling in PIL mode:   Examples for every peripheral/function supported: We have added over 60 examples, including: CDD Blocks (Ae, Dpga, Gdu, Mcl, Qdec) Communication (Can, Uart) AMMCLib IO Blocks (Adc, Dio, Pwm) ISR Blocks (Hardware Interrupt Handler) MCAL Blocks (Gpt) Utility Blocks (FreeMASTER) Software-in-the-Loop / Processor-in-the-Loop / 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 S32M2xx MCUs and evaluation board solutions out-of-the-box with: Model-Based Design Toolbox for S32M2xx version 1.0.0 is fully integrated with MATLAB® environment in terms of installation:     Target Audience This release (1.0.0) is intended for technology demonstration, evaluation purposes, and prototyping of S32M2xx MCUs and Evaluation Boards.   Useful Resources Examples, Training, and Support: https://community.nxp.com/community/mbdt      
View full article
Here you can find a short&focused presentation with main capabilities for the FreeMASTER tool. It is a very useful tools for real-time data visualization and MCU real-time control. You can create some very interesting Web interfaces for your applications - have a look at this video to find out more. Video Link : 7933 In case you have comments and questions - please leave a reply bellow. 
View full article
1. Introduction  The purpose of this article is to illustrate how to configure and use the ADC and PWM peripherals of the MR-CANHUBK3 Evaluation board.  We will demonstrate how to develop an application which uses the on-board potentiometer to control the PWM duty cycle for the RED LED on the target. For more details on MR-CANHUBK344 and how to do the initial setup (Simulink ®  environment, J-Link debugger, etc.) please refer to Interacting with Digital Inputs/Outputs on MR-CANHUBK344 article. 2. ADC Configuration  2.1 Hardware Connections  The MR-CANHUBK344 evaluation board has multiple ADC channels that can be routed on various pins in complex applications. Our focus will be on the ADC channel corresponding to the potentiometer.  The potentiometer present on the board (R84) is a 10K trimmer potentiometer connected between 3V3 and GND and is connected to the net named ADC_POT0. This is further routed via pin 11 – PTE13/ADC1_S19.    Potentiometer  and LED1 placement on the EVB:     Potentiometer schematic:   ADC_POT0 pin and its different routing options, with the correct one highlighted can be seen below:  The configuration of Adc component will be done in S32 Configuration Tools, but the same behavior can be achieved using EB Tresos.  2.2 Pins Configuration Firstly, we need to specify the configuration options for the pin itself. This is done in the Pins menu of the S32 Configuration Tools, as follows:   1.We search for the PTE13 pin and check if it is already configured.  In this case it is not routed to any functionality, but, if it was routed to anything but ADC, we need to perform the same steps:   1.Click on the checkbox near the pin name:   2. Select ADC1:adc1_s19 from the pop-up window:   3.Provide a label and identifier for the newly mapped pin  In this example, the Label and Identifier are set to ADC_POT0  After the pin is configured, we move to the Routing Details menu:   We search in the Routing Details menu for our pin, using the label set at the previous step. Once we find our pin, we check for the following options to be configured as follows:   Direction to be configured as Input  Input Buffer Enable to be configured as Enabled and update them accordingly if they aren’t.  2.3 Component Configuration  With the pins properly configured, we can move on to configure the Adc peripheral. We open the Adc component and begin by navigating to the AdcConfigSet tab where several steps need to be performed. In the AdcHwUnit menu, we first need to define a HW Unit for the ADC.  If no HW unit is defined, a new one can be created by clicking the "+" button. We can modify the default configuration delivered with the toolbox and automatically assigned by MBDT in the new Simulink model or we can configure a new one. With the ADC peripheral instance defined, the first steps are to:  Name our HW unit. In this example it is named AdcHwUnit_0.   Select the ADC hardware of our unit. As we already know from the schematics, the potentiometer uses channel S19 of the ADC1, so we choose ADC1 for this configuration option.  The logical Unit ID is used to enumerate multiple HW units if present. Since for this example we only have one, we put the value 0 here.  For the transfer type we can choose between either Interrupt or DMA. For this example, we choose to use interrupts.  From the options presented below, most of them are not relevant for this example and can be kept with their defaults value.  An important setting is the conversion resolution. For this example, we chose the maximum resolution of 14, which corresponds to a maximum value of 2^14 (16384). We can now move to the Channel definition inside the HW unit. If no channels are present, we can add a new one the same as before, by clicking the "+" button.  With a channel defined, the following configuration options need to be performed:  We need to specify the name of the ADC channel. For this example, we use ADC_POT_0. Note: This will be relevant when defining ADC groups. An ADC group is composed of multiple ADC channels.   Logical channel ID is 0 for this example since this is the only channel configured.  For the Physical Channel Name, we choose S19_ChanNum43 because we know we are on the S19 channel of the ADC. By looking in the S32Kxx Reference Manual we see that channel number 43 is mapped to ADC1_S19.  Physical Channel Id is just a mirror of the channel number from point 3.  With both HW Unit and Channel in place, we need to define an Adc Group. Adc Groups are used to oversee conversion for the channels assigned to them. For this example, our group will only have one channel assigned, the ADC_POT_0.  In the Group configurations array menu, we click the "+" button to add our group.   We name our group. For this example, our group will be named Adc1Group_0.   Group access mode should be SINGLE.  Conversion Mode should be ONESHOT. When Conversion Mode is set to Oneshot, the ADC unit performs a single conversion and then waits to be triggered again.  Conversion Type should be NORMAL. Here we can choose between NORMAL and INJECTED conversion types; an injected conversion can be performed on top of a regular conversion, based on some external trigger(sensor, timer etc.). For this application we don’t need this feature.  Group ID is 0 since it is the only group configured.  Group Trigger source is SW  Group Notification function is Adc_Adc1Group0Notification . This is the callback function of the ADC group. The function pointer is called each time the group conversion is finished.   Note: underlined values at steps 1 and 7 are highlighted because they will be visible in Simulink blocks when we create our model.  We can configure several options for conversion as well. In this example we have HW average enabled, using 4 samples. This is done in order to mitigate noise that may occur on the readings without delaying too much the final results.  In the AdcGroupDefinition menu, we have to add our channel, as configured in the previous steps.   2.4 Clocks Configuration (MCU)  For the ADC to work properly, it needs to have its peripheral clock enabled. This is done inside the Mcu Peripheral, under McuModuleConfiguration tab -> McuModeSettingConf:   Important note here:  Since ADC_POT0(PTE13) is configured by default as VRC_CTRL,  which is a PMC voltage regulator output that uses a BJT (Bipolar Junction Transistor) to generate a 1.5V supply, we need to disable this feature from Mcu configuration, otherwise we will not get accurate readings on the ADC pin.  This is done in the Mcu component, McuModuleConfiguration tab, McuPowerControlUnit menu, by disabling Last Mile Regulator Base Control Enable option:  2.5 Interrupts Configuration (Platform)  Since we opted to use the ADC in Interrupt Mode, we need to perform the correct configuration options inside Platform MCAL component.  The corresponding Interrupt Vector needs to be enabled, a priority must be given to it, and the correct handler function has to be specified from the RTD implementation.  All these options are configured inside Platform peripheral -> Interrupt Controller tab:     As it can be observed, the Interrupt Vector for ADC1 is enabled, has a priority of 5 and its handler function is Adc_Sar_1_Isr.  Finally, we save our configuration, we use the Update Code button and move to the model creation part of our example.     3. ADC Model Overview   With the configuration in place, the usage of S32 Configuration Tools (S32CT) is finished and we can implement our application in Simulink. In the following sections, we will go through the steps of creating a model that reads the potentiometer voltage and displays its value, converted into digital values, in FreeMASTER. More details FreeMASTER setup can be found in article 2.  Model overview:      Going from top to bottom we have:  3 data store variables: the ADC VersionInfo, Adc1Group0_ResultBuffer, and Channel0.  The initialize block  The FreeMASTER config block  The Start Group Conversion block  The HW Interrupt Callback block, which triggers:  The ADC Read Group block  All the ADC blocks can be found inside the MBDT:  The functionality is further detailed below:  In the initialization block we prepare the SW for the ADC conversion by assigning the result buffer variable for our ADC group and by enabling the Group Notification.  Note: To be observed that the ADC Group used in both ADC blocks is exactly the same as the one underlined in 2.3 configuration chapter.  With the initialization done, the ADC group conversion can be started. This is performed periodically in the model’s step() function.  When the group conversion is finished, the group notification callback signals back to us that we can read the ADC value, and this is done into the subsystem triggered by the Hardware Interrupt block:  The freshly converted value is stored inside Channel0 variable and it is ready to be used further.   As it was observed in Sending data via UART and monitoring signals with FreeMASTER, FreeMASTER can be used to observe the evolution of a certain variable over time. We can use this feature to display the ADC readings stored on Channel0 on an oscilloscope.   We check if the values shown match our expectations when the Potentiometer is rotated. As it can be observed in the picture below, the values go from 0, up to 16384, and then back down to 0, as the potentiometer is rotated clockwise and then counterclockwise. This fully matches our expectations and validates that both the configuration and the Simulink application are implemented correctly.    4. PWM Configuration  4.1 Hardware Connections  The MR-CANHUBK344 is suited for various Pulse Width Modulation applications. The main PWM output port of the board is P8A, which in conjunction with P8B can be used to control and read feedback from common servomotors.  In this example , we are controlling the intensity of the RGB LED via PWM, based on the ADC readings from the potentiometer.  Note: The PWM control of the RGB LED is possible because each one of the 3 colored LEDs can also be routed via an eMIOS channel:  It is important to mention that we chose to generate our PWM signals using the Enhanced Modular IO Subsystem (eMIOS). eMIOS provides us independent channels, UCs (unified channels) that we can configure to generate or measure time events for different functions in different chip applications.   eMIOS distributes these channels across a number of global and local counter buses. Each local bus is dedicated to a group of eight contiguous channels. Each channel can generate its own timebase, and each counter bus has its timebase provided by a dedicated channel.  For the S32K344 MCU, we have 3 eMIOS instances available, each with the following configuration:  There are 4 different eMIOS channel types: X, Y, G and H. Each channel type supports a different subset of operation modes. More information can be found in “eMIOS channel types section of the S32K3xx MCU Family - Reference Manual :  It is important to be acquainted with the types of channels and their supported operation modes in order to be able to configure UCs properly, as some permutations may not be possible and configuration errors may occur.  The eMIOS is clocked by CORE_CLK, which has a frequency of 160 MHz. This is worth mentioning now, as it will become relevant when calculating the frequency of our PWM.  Important note: For this example, we choose to control the intensity of the Red LED ONLY, as the configuration steps for the other 2 LEDs would be similar.   Since we know that the Red LED is routed via CH19 of eMIOS_0, which is a type Y channel, we can choose to operate it via OPWMB Mode (Output Pulse Width Modulation Buffered). This mode comes with a fixed period for the PWM signal, variable(controllable) duty cycle and uses an external counter bus.   4.2 Pins Configuration Firstly, we need to route the pin:  We look for the port and pin number of the red LED, and we observe it is part of Port E and has pin number 14:  As we did for the ADC pin, we look for PTE14 inside Pins tool , and we route it to eMIOS_0: emios_0_ch_19_y  When prompted, we select Output as direction for our pin. We provide a label and an identifier(RGBLED0_RED) for the pin.  In the Routing Details menu, we should have the following options configured:  Direction: Output; Output Inversion Select: Invert and OutputBuffer Enable: Enabled.   Note: If the configuration is done in EB Tresos and we add a new routing for the pin as PWM in the Port component, an error message will most likely appear. This can occur if the pin is already configured as a GPIO pin (DIO) inside Port component. To avoid this, the routing of the pin as a GPIO should be deleted.    4.3 Clocks Configuration (MCU)  As a prerequisite, we need to make sure that CORE_CLK is configured . This can be observed inside Mcu component -> McuModuleConfiguration tab -> McuClockSettingConfig menu -> McuClockReferencePoint submenu  Moreover, we need to make sure that the clock is enabled for the eMIOS instance we will be using:  This can be done in Mcu -> McuModuleConfiguraion ->McuModeSettingConf - >McuPeripheral  4.4 MCL  As stated before, eMIOS can work using global or local buses. Different channels need to be assigned as timebase channels for the buses depending on the desired configuration:  Global bus A: serves all UCs, uses CH23 as timebase  Local bus B: serves UC0..UC7, uses CH0 as timebase  Local bus C: serves UC8..UC15, uses CH8 as timebase  Local bus 😧 serves UC16..UC23, uses CH16 as timebase  Global bus F: serves all UCs, uses CH22 as timebase  For example, we will use the global bus A and CH23 as master timer channel. This is configured inside Mcl component, as follows:  In the Mcl Specific Configuration tab, in EmiosCommon menu, we can add a new common eMIOS configuration, or we can modify an existing one to suit our needs.  We name our configuration   We select the eMIOS instance (eMIOS_0 in our case, since Red LED is routed via CH19 of eMIOS_0)  Clock Divider Value is used in frequency calculation and will be addressed separately. It has a range from 1 up to 256.  We need to define the time base channel for our master bus in its dedicated tab, as follows:  We name our time base channel  We select CH23, since we use Global Bus A  Default period and Master Bus Prescaler are used in frequency calculation. Default period can be any value from 0 up to 65534 and Master Bus Prescaler can be 1, 2, 3... up to 16.   PWM frequency calculation:  The PWM frequency needs to be decided upon based on the type of peripheral we want to actuate. For example, most servomotors operate at 50Hz, most BLDC motors support frequencies ranging from 5kHz up to 50kHz etc. This information needs to be known beforehand and configured according to the following formula:  A different way to think about this is by visualizing this formula having in mind the period of our PWM signal instead of its frequency:    Default Period is given in ticks, and the value of a tick is determined by the CORE_CLK frequency, divided by the 2 prescalers(Clock Divider Value and Master Bus Prescaler) and then inverted.  An undivided(both prescalers are 1) CORE_CLK tick has a value of 6.25 ns (1/160000000Hz).   Knowing the desired frequency for our application, we can determine its period. In order to have the same period, hence frequency, for the generated PWM signal, we need to adjust(or not, depending on the application) the values of the 2 prescalers in order to increase the CORE_CLK tick duration. The maximum value we can set for the Default Period is 65534; this value is then multiplied with the CORE_CLK tick duration after it is prescaled and the final result is the period of the PWM signal our application will generate.   Note: Without any prescaling, the maximum PWM period duration is roughly equal to 410 microseconds (6.25 ns * 65534), which corresponds to a frequency of ~2.4kHz. For applications that need slower frequencies, the CORE_CLK has to be prescaled. Ideally, the values for the prescalers and for the number of ticks should output an integer number for the period duration.  If we know our operating frequency f, we can adjust the 2 prescaler values and the default number of ticks to achieve it:  Example 1: If we know we need to actuate a servomotor with operating frequency of 50 Hz, we substitute in the formula the values we know (PWM_Frequency, CORE_CLK) and look for values of the prescalers and default number of ticks that do not exceed the configurable range. Note that multiple solutions are likely to be found and a suitable one needs to be chosen.  A possible solution for this specific frequency is Clock Divider Value = 256, Master Bus Prescaler = 1, Default Period = 12500.  Another one is {128,4,6250}.  Example 2: If we know we need to actuate a BLDC with an operating frequency of 20kHz, a possible solution is {1,1,8000}. Another one is {2,2,2000}.    4.5 Component Configuration  Inside the Pwm component, we need to perform 2 sets of configurations, one for the eMIOS channel and one for the PWM channel. Both can be performed in PwmChannelConfigSet tab.  4.5.1 eMIOS    First of all, we need to add our eMIOS instance. This is done by clicking the "+" button at the top of the window. We need to make sure the proper hardware instance is selected, in our case, eMIOS_0.  With that in place, we can move to the configuration of the channels. If no channels are configured, a new one can be added using the "+" button. In our example, several channels are already configured, but our focus is on the 8th channel. With it selected, we set its name, we select the Channel ID to address  19th eMIOSchannel, select the desired operating mode(OPWMB), choose Bus A as a counter bus. For the PwmEmiosBusRef, we use the one previously configured at step 4.4.  We keep the prescalers at DIV_1 and we choose not to phase shift our signal, since it is not needed for our application.  4.5.2 Pwm Channel  With the eMIOS channel configured, we can move to the PWM channel configuration.  We add our channel, we give it a relevant name and assign it a channel ID. The Channel ID identifies the position of the channel in the configured list of channels.  For the PwmHwChannel option, we select the eMIOS channel configured at the previous step.  Default Period should have the same value as the one we defined for the Master Bus inside Mcl component, otherwise we will receive an error message.  Default Duty cycle represents the duty cycle forwarded to the LED at initialization. We keep it at 0 for our example.  At the PwmMcuClockReferencePoint option, we select CORE_CLK, as defined in the Mcu component.  Note: For this example, the use of interrupts was not needed. However, if interrupts have to be used, proper configuration settings must be done inside Platform component:  As it can be observed, we have 6 Interrupt vectors, numbered from 0 to 5, for each EMIOS instance. Each vector handles 4 channels. The channels are assigned in descending order, starting with vector 0: For each instance, the _0 vector will serve the channels # 23, 22, 21 and 20, the _1 vector will serve the channels # 19, 18, 17 and 16 and so forth until the _5 vector which will serve the channels # 3, 2, 1 and 0.  This concludes the configuration part of the PWM channel needed for our example and we can move on with the Simulink model.   5. PWM Model Overview    In order to implement this application, we will extend the ADC model created at step 3. Since we want to control the intensity of the LED based on the readings from the potentiometer, we will use the ADC converted potentiometer value as an input for the PWM channel.   Our application is structured into 4 parts:  Initialization part  Input Handling  Algorithm  Output Setting  The Initialization and Input handling sections of our application are similar to the ones present in the model created at step 3 of this article, the only exception being that the ADC reading is not only stored inside Channel0 variable, but it is also fed into the algorithm.  Our application’s algorithm’s goal is to convert the raw values provided by the ADC into values that are accepted by the PWM block. Since our input values need to be scaled up with a factor of 2, we need to apply the Gain block from Simulink.    We need to consider that the Pwm Block expects an argument of uint16 data type, so we need to make sure that the gain applied is of that type:  The output of our application is represented by the LED intensity (i.e. the duty cycle). One important mention here is that the duty cycle is not expressed as a percentage, but as a value from 0 to 32768 (0 -> 0% duty; 16384 -> 50% duty; 32768 -> 100% duty).   For the output control, we need to use a Pwm block from the MBDT:    We drag and drop the Pwm block into our canvas, we select the desired function (Pwm_SetDutyCycle) in our case, and also the Pwm channel we want to control(we choose the PWM channel configured at 4.5.2 step, in our case PwmChannel_8; all the channels selectable from the drop-down list are the ones previously configured in S32CT) :  We apply the algorithm to the input value and feed the result into the PWM block:   Below, a video showcasing the functionality can be found In the first part of the video, the potentiometer is rotated clockwise and the duty cycle of the LED gradually reaches 100%, then, in the second half of the video, the potentiometer is rotated in the opposite direction and the LED can be observed dimming down until it turns back off completely. Note: The status LEDs were covered with black tape so that the Red LED's intensity can be seen more clearly   6. Conclusion  ADC and PWM are 2 peripherals with a large applicability domain and they are frequently used in embedded applications. The goal of the article was to extend the general knowledge about those 2 peripherals and apply it on a hands-on example using MR-CANHUBK344 Evaluation board. The LED intensity dimming example illustrated in this article covers the configuration part of both peripherals, the development of an algorithm that handles input values and feeds them to the output and, together with the previous articles, helps us understand better the integration process of embedded applications using Model-Based Design Toolbox.      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.   Simulink is a registered trademark of The MathWorks, Inc. See mathworks.com/trademarks for a list of additional trademarks.  
View full article
This video shows how: Install the Support Package Add-On Use of Installer Wizard Toolbox package download & install License generation and setup
View full article
MODEL BASED DESIGN TOOLBOX FOR PANTHER (MPC574xP) Family of Processors 2.0   Model Based Design Toolbox for MATLAB/Simulink supporting Panther (MPC57xP) version 2.0 is now available.   The product is FREE OF CHARGE and it is available for public.   DOWNLOAD Model Based Design Toolbox MBDT      Release Highlights – Model Based Design Toolbox for Panther (MPC574xP) Support for new Panther XDEVKIT-MPC5744P board (ARDUINO style) which works with the new chassis XDEVKIT-MOTORGD for motor control applications. Incorporation of latest Automotive Math and Motor Control Library release 1.1.7. Support for latest MATLAB versions including 64 bits (2015/2016 a/b) New DMA blocks, allowing ADC sampled data to be transferred to memory without CPU intervention through DMA module. New LINFlexD blocks for serial communication support now allowing data send/receive operations through UART. New Memory Read/Write blocks are added and they can now be used to read/write any memory zone. New Custom Initialization block is added and it can be used to extend the configuration of any module outside the default setup prior to the model first step. Support for S32 Design Studio for Power Compiler v1.1 in addition to new compilers versions Wind River DIAB v5.9.4.8 and Green Hills MULTI for PowerPC v2015.1 New Advanced Motor Control blocks, were added and now new functions like Track Observer or Back EMF Observer are provided as Simulink Blocks. Aligned ADC clock frequency from 20MHz to 80MHz (max speed). New ADC channel configuration block is redesigned to be allow configuration without sampling for the ADC channel, making now DMA scenario for transfers possible. New Diagnostics panel can be used to enable/disable multiple consistency checks. New Bootloader build to support UART1 communication. Support in sync with FreeMASTER release 2.0.2.   new!!! HOT-FIX:  Add support for the latest e200 compiler that is released with S32 Design Studio for Power v1.2 . Refer to HotFix_3 setup to have the MBD Toolbox working with latest e200 compiler.   Community Support Available   Support available via the NXP community at: https://community.nxp.com/community/mbdt
View full article
This video shows: - motor control typical setup with S32K144 rev2.0 Evaluation Board; - Simulink model for a BLDC motor control; - how to setup Simulink to generate ANSI C code for S32K144 rev2.0 MCU; - quick tour of the Model Based Design Toolbox; - quick tour of the FreeMASTER data visualizer; - Motor Control example running with DevKit S32K144EVB and MotorGD shield;
View full article
In this video we talk about  how hall sensors works, how the commutation sectors are defined based on hall transitions and how can we identify the hall patterns when no datasheet is available.   We discuss about: - Hall sensors - Commutation sectors  - Hall sensors alignment procedure - Hall sensors electronic circuit used on MotorGD and MPC5744P devkits NOTE: Chinese viewers can watch the video on YOUKU using this link 注意:中国观众可以使用此链接观看YOUKU上的视频
View full article
This video shows how to program the ADC with Model Based Design Toolbox to obtain the speed reference for the BLDC speed closed loop control system. We discuss about: - How the ADC works - How to simulate the ADC operations - How to implement a simple program to read data from the ADC - How to use BAM to load the application into microprocessor memory - How to test in real time with FreeMaster - How to scale the Potentiometer voltage into a speed reference data that represents the rpm. - How to implement from scratch a Simulink model to cover the ADC functionality NOTE: Chinese viewers can watch the video on YOUKU using this link. 注意:中国观众可以使用此链接观看YOUKU上的视频
View full article
This video shows: - how to download the Model Based Design Toolbox; - how to generate a license from your account; - how to setup the environment; - quick tour of the toolbox, supported functionalities and available examples;
View full article
 MODEL BASED DESIGN TOOLBOX for S32K14x Automotive MCU rev2.0  Download the product from Model Based Design Toolbox official webpage   Model Based Design Toolbox: Assists Automotive customers with rapid prototyping and accelerates code development on NXP Automotive MCUs Provides an integrated development environment and tool chain for configuring and generating all the necessary software (including initialization routines, device drivers and a real-time scheduler) Automatic ANSI C code generation from MATLAB/Simulink™ Seamless integration with embedded coder including SIL and PIL models      S32K Automotive MCU rev2.0 Enablement Support for the new S32K144 MCU, S32K144EVB evaluation board and new chasses XDEVKIT-MOTORGD for motor control and XDEVKIT-COMM Integrate the latest Automotive Math and Motor Control Library release 1.1.8 for ARM M4 cores Integrate the latest SDK release version 1.0.0 for S32K Automotive MCU; Integrates FreeMASTER version 2.0.2 Support for latest MATLAB versions including 64 bits (2015b, 2016a/b and 2017a); Example Library for S32K peripherals and Motor Control scenarios; S32K supported peripherals are highlighted on block diagram Multiple enhancements and fixes over the previous version of the Toolbox version 1.0    Help and Support  Please join our Model Based Design Toolbox community for updates and support. Click here to watch a quick install guide video   Click here to watch motor control demo with S32K rev2.0  
View full article
      Product Release Announcement Automotive Microcontrollers and Processors NXP Model-Based Design Toolbox for S32K1xx – version 4.1.0     Austin, Texas, USA July 22, 2019 The Automotive Microcontrollers and Processors, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K1xx version 4.1.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 S32K116 and S32K118 microcontrollers, AUTOSAR applications code generation, Local Interconnect Networks (LIN) support and many other various new functionalities to help customers with rapid prototyping with NXP S32K 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     Release Content Automatic C code generation based on S32K SDK 3.0.1RTM drivers from MATLAB® for NXP all S32K1xx derivatives: S32K116 MCU Packages with 32QFN and 48LQFP (*new) S32K118 MCU Packages with 48/64 LQFP (*new) 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 Integrates the Automotive Math and Motor Control Library release 1.1.17 for: S32K11x based on ARM M0+ cores; S32K14x based on ARM M4F cores; Multiple S32K1xx peripheral support. The peripheral coverage for each of the S32K1xx derivatives is shown below: S32K116 S32K118   S32K142   S32K144     S32K146 S32K148 Add support for Local Interconnect Network (LIN) for all S32K1xx devices Add support for Motor and Solenoid Drivers devices MC33GD3000, MC34GD3000, MC33937 and MC34937 Extend support for System Basis Chip (SBC) with UJA113x blocks 100% S32K1xx supported peripheral coverage with examples. More than 230 examples available as part of the toolbox that exercise all the functionalities supported Add support for CLASSIC AUTOSAR Application Layer Simulation and Code Generation for S32K1xx devices. This feature allows customers to build, simulate and test AUTOSAR Application directly on S32K1xx microcontrollers to check for correct functionality and performance using build in profilers. 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 NXP solution directly from the Mathwork’s website or directly from MATLAB IDE. The Support Package provide a step-by-step guide for installation and verification. NXP Model-Based Design Toolbox for S32K1xx version 4.1.0 is fully integrated with MATLAB® environment in terms of installation, documentation, help and examples;    Target Audience This release (4.1.0) is intended for technology demonstration, evaluation purposes and prototyping for S32K116, S32K118, S32K142, S32K144, S32K146 and S32K148 MCUs and Evaluation Boards       
View full article
  Product Release Announcement Automotive Embedded Systems NXP Model-Based Design Toolbox for S32K3xx – version 1.5.0     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.5.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, S32K374, S32K376, S32K388, S32K394 and S32K396 MCUs and part of their peripherals, based on RTD MCAL components (ADC, CAN, DIO, GPT, I2C, ICU, LIN, MEM, MCL, PWM, SPI, UART). In this release, we have also updated RTD, S32 Configuration Tools, AMMCLib, FreeMASTER, and MATLAB support for the latest versions. The product comes with over 140 examples, covering all the features and functionalities of the toolbox, including demos for motor control applications.   Target audience: This product is part of the Automotive SW – Model-Based Design Toolbox.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=3983098   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 S32K374    S32K376    S32K388    S32K394  S32K396   Support for the following peripherals (MCAL components): ADC CAN DIO GPT I2C ICU LIN MEM MCL PWM SPI UART   New RTD version supported  (4.0.0 P19) New S32 Configuration Tools version supported (2024.R1.7) 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.35        All functions in the Automotive Math and Motor Control Library v1.1.35 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.   S32 Design Studio Integration We provide the feature of importing the code generated from a Simulink model inside the S32 Design Studio IDE. This functionality can be useful if the model needs to be integrated into an already existing project or for debug purposes.   Support for custom default project configuration The toolbox provides support to use and create custom default project configurations. This could be very useful when having a custom board design – offering the possibility to create the configuration for it only once. After it is saved as a custom default project, it can be used for every model that is being developed.         Such custom projects, addressing specific hardware designs are offered inside the current version of the toolbox to integrate the following EVBs: S32K396-BGA-DC1 MR-CANHUBK344, alongside a set of examples specifically created to target this hardware design and a series of articles (available on NXP Community) demonstrating how to use the toolbox features and functionalities for creating applications for custom boards.   For a complete list of the hardware on which the toolbox was tested and developed, please consult the attached Release Notes document.   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) including AUTOSAR SW-C deployment External mode     Motor Control Applications The toolbox provides examples for 1-shunt and 2-shunt PMSM and BLDC motor control applications, supporting both S32 Configuration Tools and EB  Tresos. Each of the examples provides a detailed description of the hardware setup and an associated FreeMASTER project which can be used for control and data visualization. The toolbox also demonstrates the integration of the Motor Control Blockset in developing such applications.   Support for MATLAB versions We added support for the following MATLAB versions: R2021a R2021b R2022a R2022b R2023a R2023b R2024a   Examples for every peripheral/function supported More than 140 examples showcasing: I/O Control Timers and scheduling Communication (CAN, I2C, LIN, SPI, UART) Motor Control applications AMMCLib FreeMASTER SIL / PIL / External mode For more details, features, and how to use the new functionalities, please refer to the Release Notes and Quick Start Guides documents 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. NXP Model-Based Design Toolbox for S32K3xx version 1.5.0  is fully integrated with MATLAB® environment.   Target Audience: This release (1.5.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      
View full article
        Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for HCP – version 1.2.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.2.0. This release supports automatic code generation from MATLAB/Simulink for S32G2xx, S32S2xx, and S32R41 MPUs. This new product adds support for new MATLAB versions R2022a and R2022b for running in Processor-in-the-Loop mode.   FlexNet Location: https://nxp.flexnetoperations.com/control/frse/download?element=13897177   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 R2022a R2022b Tools update for S32R41: S32 Flash Tool v2.1 S32 Debugger v3.5 Simulation mode: We provide support for Software-in-Loop (SIL) and Processor-in-Loop (PIL) simulation mode with code execution profiling: 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.2.0 (RFP) is fully integrated with MATLAB® environment in terms of installation:       Target Audience This release (1.2.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    
View full article
Introduction   The RDDRONE-BMS772 is a standalone BMS reference design suitable for mobile robotics such as drones and rovers, supporting 3 to 6 cell batteries. The main components mounted on the board are: MCU: S32K144 (S32K1 Microcontroller for General-Purpose); BCC: MC33772B (6 Channel Li-Ion Battery Cell Controller IC); SBC: UJA1169TK (Mini High-Speed CAN System Basis Chip); RFID: NTAG5-Boost (NTAG 5 Boost: NFC Forum Compliant I2C Bridge for Tiny Devices) An overview of the pins available on the board and the connections between ICs can be consulted below. For further details, please check the datasheet and schematic available on the product's page.       Prerequisite software   To create, build and deploy a Simulink model onto the RDDrone BMS772, the following software is required: MATLAB ®  R2016a or later Simulink ® MATLAB ® Coder™ Simulink ® Coder™ Embedded Coder ® Support Package for ARM ® Cortex ® -M Processors S32K1xx MBDT Toolbox Version 4.3.0 JLink Debug Probe Segger FreeMASTER Run-Time Debugging Tool   Prerequisite hardware   The hardware required for this example is: RDDrone BMS772 CAN Bus Terminator resistor (DRONE-CAN-TERM) OLED Display 128x32 pixels 12V DC Power Supply (it's not included in the RDDRONE kit) External Thermistor with cable CAN interface for USB 6-Cell Battery Emulator (it requires a separate 12V DC power supply, consult User Manual) JLink Debug Probe Soldering iron: By default, the BCC is configured to work with a 3S configuration. To configure for 4S, 5S or 6S, multiple modification must be performed on the board. (Consult SPF-45742 for further details)   Create the model and configure the components Initialize the model To configure a model to work with blocks from S32K1xx toolbox, the MBD_S32K1xx_Config_Information block must be added. The RDDRONE is part of S32K144 family, with an External 32 MHz external crystal. The download interface is JTAG, using the Segger Link. Note! Segger JLink Software is not included in the toolbox and must be installed separately.     Initialize System Basis Chip   The System Basis Chip (SBC) mounted on the board is UJA1169TK, which is a mini high speed CAN transceiver. Moreover, it also features a watchdog and it can be configured via LPSPI0 (Low Power Serial Peripheral Interface). Out of the box, the SBC is running in Forced Normal Mode, which means that the watchdog is disabled, but CAN transceiver continues to work. If the SBC is initialized and configured, it exits the Forced Normal mode and enters Normal Mode operation. Now, the watchdog must be reset accordingly to the configuration made, otherwise it will trigger a reset.  A special operation mode is Software Development Mode Control and it allows the SBC to be configured (CAN, power regulator) while the watchdog is kept disabled. To enable the SDMC, the SBC must be in Forced Normal Mode (Further details can be found here: 7.11.2 Restoring factory preset values). Note! MCU configures the SBC via the SPI. Therefore, the LPSPI0 must be initialized before the SBC config block. A basic configuration for SBC can be found below.     Initialize FreeMASTER   FreeMASTER is a user-friendly real-time debug monitor and data visualization tool that enables runtime configuration and tuning of embedded software applications. The connection between MCU and FreeMASTER application can be done via the following: UART CAN Debugger Probe/On-board debugger interface In this example, the CAN0 interface is used to send/receive messages from FreeMASTER application. The RxD and TxD pins required are PTE4, respectively PTE5 (both are routed to J3 connector). The default bitrate is 1000 Kbit/s but depending on the use case, it can be lowered.   Note! FreeMASTER can add a lot of overhead if the user interface monitors multiples variables at a very fast refresh rate, and it can cause the step function to overrun.    Initialize BCC   Battery Cell Controller (BCC) MC33772B can be configured and used by the MCU via SPI/TPL. Similar to SBC, the communication interface (LPSPI1) must be initialized before initializing the BCC. As a feature, the BCC block can assist you to configure the LPSPI interface to properly work.  First of all, add the LPSPI config block and select the instance to 1 (as this instance is routed on the RDDRONE board from the MCU to the MC33772B). Go to Pins tab and select the pins used by LPSPI1 and BCC. The role, baud rate and other advanced settings are going to configured later from the BCC config block.  As there are no TPL transceiver added, the MC33772B communicates with the MCU via LPSPI instance 1 (previously configured). In the General tab, Instance refers to the instance of the BCC (not to be confused with the LPSPI instance). In the area "SPI Mode", the type of the BCC must be selected. In this case, the BCC mounted on the RDDRONE is MC33772B. The number of cells is 6. Going next to the SPI tab, the SPI Instance needs to be set to 1 and the SPI CS Selection to LPSPI_PCS0.  Lastly, in the Pack Settings, it is a must to set Shut Resistance to 500 uOhm (as this is the value of the shunt resistor R1 mounted on the board). In the MC33772B config block, the following settings must be modified: Configuration Tab General Settings Instance: 0 Mode: SPI SPI Mode Device: MC33772B Cell number: 6 SPI tab SPI instance: 1 SPI CS Selection: LPSPI_PCS0 Pack Settings Shut resistance: 500 uOhm (shut resistor R1 is mounted directly on the RDDRONE)     After the MC33772B is properly configured (especially the SPI instance is selected), you can click on the Config SPI for BCC as Master button from SPI tab (highlighted by the orange rectangle in the image above).   Note! MCU configures the BCC via the SPI. Therefore, the LPSPI1 must be initialized before the MC33772B config block.   Initialize SSD1306 OLED   The OLED display used in this example is a 128 x 32 pixels display that communicates with the MCU via LPI2C0 (J23).  The configuration for LPI2C is presented below: After the LPI2C is configured, the block to configure the OLED can be added and configured as below: LPI2C Instance: 0 SSD1306 Address: 60 (represented in decimal format, hex: 0x3C) Width: 128 Height: 32 Font: 11 x 18 Background color: Black Note! MCU configures the LCD via the I2C. Therefore, the LPI2C0 must be initialized before the LCD config block.   Initialize Gate Driver   The gate driver is controlled by a D-type flip flop and it allows the MCU to disconnect the electrical load (motors, servos) attached to Power OUT pads from the Power IN, when the battery is discharged or various faults occurs. GPIO PTC2 is connected to the 'Data input' pin of the D-type flip flop (U10) and it is active low (set pin to 0 to enable the gate driver and to 1 to disable it). GPIO PTC1 is connected to the 'CLK' pin of the flip flop which is a rising edge triggered clock signal input pin. So, to control the gate driver, the PTC2 must be set to the desired state, then the PTC1 is toggled 2 times. To assure that the sequence is kept in order, set the priority of each GPIO Write block.   Structure of the application One of the most recommended design style for an application in Simulink with NXP MBD Toolbox is to break down the application into three categories as: Input: Hardware dependent blocks that read/receive the values of interest from peripherals Algorithm: Hardware independent blocks that process the values received from the Input blocks. Output: Hardware dependent blocks which receive the processed values from the Algorithm blocks   One advantage of this approach is that a fully tested application can be converted to new hardware without any modification to the ALGORITHM part. Only the INPUT and OUTPUT blocks must be updated to the new hardware. Moreover, while developing an application, you can validate the ALGORITHM section in Software-in-the-Loop (SIL) or Processor-in-the-Loop (PIL). These two methods of simulation are useful to test cases that are not easy to replicate, as specific data can be fed as input. Taking these into account, this example can be structured like this: Input (green area): The blocks in this area read data from the MC3377xB BCC and store them in multiple data stores. In case there are any faults detected, MC3377xB_Fault_Get_Status reads the error and store it in FaultStatus data store memory. To make sure the MCU is not halted, an onboard LED (PTB13) is toggled at each step. Algorithm (blue area): As this example is more of a dummy one, the algorithm part only processes the PackVoltage and PackCurrent to be properly displayed on the OLED display. toggleLED variable is negated at every step to toggle the onboard LED. OUTPUT (pink area) Reset the SBC UJA116x's watchdog to avoid the forced restart of the board PackVoltage and PackCurrent received in INPUT area and processed in ALGORITHM area is then shown on the OLED display. Toggle the LED and save the new value in toggleLED data store memory.   Deployment Now that the application is completed (make sure the steps at Create the model and configure the components -> Initialize the model are correctly followed), it can be deployed on the target. First of all, the JLink probe must be correctly connected to the RDDRONE board to the J2 header. Then, power the board using a 12V power supply by using the J4 pads. Important! When soldering the header on J4 pads, make sure the polarity is properly respect, otherwise, you might risk to permanently damage the board. The CAN analyzer must be connected to J3 and the CAN terminator to J20 (located on the back of the board, right below J3 header). OLED display must be inserted into J23 header.  Important! Make sure to properly respect the polarity of the display, otherwise you might risk to permanently damage the display. The 6 Cell Battery Emulator must be connected to the JP1 header. Depending on the configuration made on the back of the RDDrone, connect the cells to its respective pin on the board (consult the overview pinout presented at the beginning of the article). Pin JP1[7] must be connected to the CTREF[33] pin of the battery emulator. Finally, the code can be generated based on the Simulink model, compiled and deployed on the target. To do this, go to Simulink -> Apps -> Embedder Coder then click on the Build button. Now, in the Diagnostic Viewer, the deployment process can be analyzed to see if there are any errors with the application and if the download was successfully completed on the target like in the image below, where we can see: The .elf file is successfully generated and its size The download is completed Important! In order to be able to download code on the target, the reset line from the SBC to S32K144 must be disconnected, remove the header on J5 during the deployment process.   FreeMASTER Now that the application is deployed on the target, FreeMASTER can be configured to connect to the target via CAN. Go to the TOOLS -> Connection Wizard and select the Connect over CAN BUS with CAN card or USB-to-CAN module. In the prompted window, configure the CAN Interface accordingly to your hardware and configuration made in the Simulink model.   Now that the FreeMASTER connection with target is completed, the .ELF file must be selected to access variables and monitor them in real-time. Finally, start the communication between FreeMASTER and the target and the data shown should be similar to this:   Conclusion In this article, we described how to use NXP Model Based Design Toolbox for S32K1xx to handle a custom hardware design (such as RDDRONE BMS772), from the configuration of the peripherals to the download on the target and validating the application. The example covers all the peripherals that the S32K1xx toolbox 4.3.0 supports for the RDDRONE. Feel free to comment below if you have questions.   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. 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.  
View full article