NXP Model-Based Design Tools Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

NXP Model-Based Design Tools Knowledge Base

Discussions

Four-Part How-To Series Model-Based Design Toolbox (MBDT) is an integrated development environment and toolchain for configuring and generating all the necessary software automatically to execute complex applications. The MBDT includes integrated Simulink® embedded target for NXP processors, peripheral device blocks and drivers, the Math and Motor Control library set, and bit-accurate simulation results. Watch on-demand each of our Model-Based Design Toolbox four-part How-To series and learn the basics of MBDT, also its SPI and CAN communication and its PWM control blocks.   Session 1/4 =  Get to Know the User-Friendly NXP MBDT for Application Development in MATLAB/Simulink dumitru-daniel.popa‌ will show  you how to configure and use the MBDT, engineered to help you speed up application development in MATLAB/Simulink Environment for NXP hardware. Get to know its main features and capabilities  through  the creation, simulation, built, deployment, and validation of a basic "hello world" type of application on the S32K144EVB .   Session 2/4 =   Introducing the SPI Communication Blocks from NXP MBDT nxf46081‌  will highlight the key aspects of communication in the automotive industry while showing you how to configure and use designated blocks that implement the SPI communication inside the MATLAB/Simulink Environment for creating a quick and easy data transfer application using MBDT and the S32K144EVB. Session 3/4 =  Introducing the CAN Communication Blocks from NXP MBDT constantinrazvan.chivu‌  will highlight the key aspects of communication in the automotive industry while showing you how to use MBDT and the S32K144EVB to simplify CAN applications with only a few blocks: configuration, transmit, and receive. Session 4/4 =  Introducing the PWM Control Blocks from NXP MBDT mariuslucianandrei‌  will showcase how to start using PWM, its features and functionalities while showing you how to build a first application able to generate different types of PWM signals using MBDT and the S32K144EVB; also, learn to sample the external signals to determine the key values: duty-cycle, period, among others.   Your software development processes can speed up by using the free-of-charge NXP Model-Based Design Toolboxes for MATLAB and Simulink development environments, providing full integration, an out-of-the-box configuration, and action blocks for basic/advanced features for designing complex automotive solutions.
View full article
      Product Release Announcement Automotive Processing   NXP Model-Based Design Toolbox   for S12ZVMx – version 1.4.0     Austin, Texas, USA September 9, 2020 The Automotive Processing, Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S12ZVMx version 1.4.0. This release supports automatic code generation for S12ZVM peripherals and applications prototyping from MATLAB/Simulink for NXP S12ZVMx Automotive Microprocessors. This new release adds extended MATLAB version support (R2015a-R2020a), integrates with AMMCLib v1.1.21, is compatible with MathWorks Automotive Advisory Board checks, adds over 50 new examples and more.   FlexNet Location: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=MCTB-EX   Activation link: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=MCTB-EX   Technical Support: NXP Model-Based Design Toolbox for S12ZVMx issues are 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 S12ZVMx derivatives: S12ZVM 32/L31/16: MC9S12ZVM16 MC9S12ZVML31 MC9S12ZVM32 S12ZVML/C 128/64/32: MC9S12ZVML32 MC9S12ZVML64 MC9S12ZVMC64 MC9S12ZVML128 MC9S12ZVMC128 S12ZVMC256: MC9S12ZVMC256   Integrates the Automotive Math and Motor Control Library release 1.1.21: All functions in the Automotive Math and Motor Control Functions Library v1.1.21 are supported as blocks for simulation and embedded target code generation for: Bit Accurate Model for 16-bit fixed-point implementation Bit Accurate Model for 32-bit fixed-point implementation Bit Accurate Model for floating-point single precision implementation             Extended support for MATLAB versions We extended support for our toolbox to cover a wider range of MATLAB releases – starting from R2015a and going up to R2020a. This way we want to avoid locking out users that have constraints regarding MATLAB versions. Motor control examples We have added new motor control examples – BLDC (closed loop) and PMSM (closed loop, sensorless):   MAAB Checks (MathWorks Automotive Advisory Board) The toolbox is compatible with MathWorks Automotive Advisory Board checks – reports can be generated from Model Advisor:   Updated examples: We have added over 50 new examples, including: Motor control (both BLDC and PMSM) AMMCLib GDU (Gate Drive Unit) Profiler 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 S12ZVMx MCUs and evaluation boards solutions out-of-the-box with: NXP Support Package for S12ZVMx  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 S12ZVM version 1.4.0 is fully integrated with MATLAB® environment in terms of installation: Target Audience This release (1.4.0) is intended for technology demonstration, evaluation purposes and prototyping S12ZVMx MCUs and Evaluation Boards.   Useful Resources Examples, Trainings and Support: https://community.nxp.com/community/mbdt                                                    
View full article
In the following articles, we are going to detail the capabilities of our BMS blocks and how to use them on the NXP battery cell controller DevKits.
View full article
This article details the TPL communication setup between S32K1xx boards and MC3377xBTPL Battery Cell Controllers.  It covers both hardware and software setup for the Battery Management System models designed using Model-Based Design Toolbox for battery packs of more than 14 cells in series.  At the end of this article, the user will be able to setup the Battery Cell Controller hardware and to design a Simulink model that reads the cell and pack voltages, current, temperatures and faults status. The measured values will be displayed on the host PC using FreeMaster. 
View full article
This article details the SPI communication setup between S32K1xx boards and MC3377xBSPI Battery Cell Controllers. It covers both hardware and software setup for the Battery Management System models designed using Model-Based Design Toolbox for battery packs up to 14 cells in series.  At the end of this article, the user will be able to setup the Battery Cell Controller hardware and to design a Simulink model that reads the cell and pack voltages, current, temperatures and faults status. The measured values will be displayed on the host PC using FreeMaster. 
View full article
Introduction The application is based on an example of basic GPIO for S32K144 (gpio_s32k14_mbd_rtw). The application is extended to fit the needs of motor control application running a sensorless PMSM Field Oriented Control algorithm. Therefore, certain modes (states) and transitions (events) are implemented. NOTE: Theory of Finite state machines defines states and events (transitions). Following design uses approach which may seem to mix states and transitions at some point. Some states are run just once, thus they may be considered as transitions only. However, the design is considered as an example and may be extended in terms of additional checks for external events, making these "one-shot" states the actual states. The design has been well known from NXP Automotive Motor Control Development Kits and it has been well accepted by majority of customers. Therefore, the same concept is presented for MATLAB Simulink. Finite State Machine Design The application structure should introduce a systematic tool to handle all the tasks of motor control as well as hardware protection in case of failure. Therefore, a finite state machine is designed to control the application states using MATLAB Simulink Stateflow Chart (Stateflow library/Chart). The motor control application requires at least two states - "stop" represented by "ready" state and "run" represented by "run" state. However, some additional states need to be implemented to cover e.g. power-on situation, where the program waits for various auxiliary systems (system basis chip, DC-bus to be fully charged, memory checks, etc.). In addition, the motor control application and specifically the sensorless field oriented control requires additional states to calibrate the sensors and to start the motor with known position. Therefore, transition from READY state to RUN state is done through an initialization sequence of CALIB (sensors calibration) and ALIGN (initial rotor position alignment or detection) states. To stop the motor, the application goes back to the READY state via INIT (state variables initialization). While the INIT state is designed to clear all the internal accumulators and other variables (but the parameters can be changed in the run time and not reset to the default settings), the RESET state is introduced to enable power-on or "default configuration" or "soft reset" initialization in the case of the motor control parameters are changed using FreeMASTER or other user interface. All the states are linked with an output event which is traced out of the state machine chart block. These events can be used as trigger points for calling the handlers (state functions). The transitions are driven by the input value of the state machine, treated as an event using a simple comparison (e.g. [u==e_start]). To change the state, the event/input value should be changed. If the event has changed, the state machine changes the state only in case of there is an existing action linked with the current state and the event. The state machine is designed to be used in the application using Event input (to signal the event), State output (to indicate the current state) and Event triggers outputs (to call the state functions / handlers). Following application has been built to show an example of the state machine usage. Following tables show the nomenclature of the states and events: State Purpose Value Reset Power-on / Default settings / Soft-reset state. May include some HW checking sequence or fault detection. 1 Init Initialization of control state variables (integrators, ramps, accumulators, variables, etc.). May include fault detection 2 Ready Stand-by state, ready to be switched-on. Includes fault detection, e.g. DC-bus overvoltage or high temperature 3 Calib Calibration state to calibrate ADC channels (remove offsets). Includes fault detection 4 Align Alignment state to find the rotor position and to prepare to start. Includes fault detection 5 Run Motor is running either in open-loop or sensorless mode. Includes fault detection 6 Fault Fault state to switch off the power converter and all the peripherals to a safe state. 7 Input events are the triggers which initiate a change of current state. Input Event Purpose Value e_init_done Asserted when the Init state has finished the task with success 1 e_start Asserted when a user sends the switch-on command 2 e_calib_done Asserted when all the required ADC channels are calibrated 3 e_align_done Asserted when the initial rotor alignment / position detection is done 4 e_stop Asserted when a user sends the switch-off command 5 e_fault Asserted when a fault situation occurs 6 e_fault_clear Asserted when a user sends the "clear faults" command or when the situation allows this 7 e_reset Asserted when a user sends the "reset"  command to start over with default settings 8 Output events are used to trigger the Motor Control State Handlers and correspond to actual state. These events are triggered with every state machine call. Therefore, the state machine shall be aligned with the control algorithm. For example, it shall be placed within the ADC "conversion completed" interrupt routine or PWM reload interrupt routine. Finite State Machine Usage The state machine shall be used in good alignment with the control algorithm. The usual way of controlling a motor is to have a periodic interrupt linked with the ADC conversion completed or with the PWM reload event (interrupt). The state machine shall be called within this event handler, right after all the external information is collected (voltages, currents, binary inputs, etc.) to let the state machine decide, which state should be called next. Internal event/state handling inside of the state machine is clearly described by the state machine block definition. Output event triggers are configured to provide clear function-based code interface to the state machine. That means, the output events shall be connected to a function designed to handle the state task. For example, in Run state, the run() output event is triggered with every state machine call, while within the Run state function the whole motor control algorithm is called. If an input information is supposed to switch the state, a simple condition shall be programmed to change the Event variable (defined as a global variable). For example, if a user sends the "stop" command, the Event is set to "e_stop" and the state machine will switch to the Init state. For more complex triggering of output functions, additional output events can be programmed within the state machine definition. Template state handler function is based on the function caller block. In general, the function blocks can work with global variables, thus there is no need for inputs or outputs. Thanks to global Event variable, event-driven state machine can react on events thrown inside a state handler function or outside of the state machine (e.g. based on other asynchronous interrupt). An example of a simple template is shown below. In this example, the function represents the Reset state, which is supposed to be run after the power-on reset or to set all the variables to its default settings. Therefore, the first part is dedicated to hardware-related settings, the second part is covering the application-related settings. The third part checks whether all the tasks are done. If yes, the e_reset_done event is thrown (stored into the Event variable). In this case, the ResetStatus variable is obviously always going from zero to two with no additional influence. Therefore, the final condition may be removed (even by the MATLAB optimization process during compilation). If there is an external condition, such as a waiting for an external pin to be set, then it makes sense to use such "status" variable as a green light for completing the state task and throwing the "done" event. Embedded C code Implementation In default settings, MATLAB Embedded Coder generates the state machine code in a fashion of switch-case structure. This might be not very useful for further code debugging or for manual editing. Therefore, the function call subsystem block parameters should be changed as shown below. The function packaging option is set to "Nonreusable function", other settings might be left at default values. This will keep the state machine code structure in switch-case, however the state handlers function calls will be generated as static functions (instead of putting the code inside the switch-case). Following code sample is a part of the state machine code generated in the stateMachineTest.c example code. The state machine decides based on the State variable, which is internally stored in the stateMachineTest_DW.is_c1_stateMachineTest. Based on the stateMachineTest_DW.Event, a transition is initiated. Finally, the state handler function is called, in this case stateMachineTest_Resetstate(). void stateMachineTest_step ( void ) { /* ...  */       switch ( stateMachineTest_DW . is_c1_stateMachineTest ) { /* ... */       case stateMachineTest_IN_Reset :             rtb_y = 1U ;             /* During 'Reset': '<S5>:35' */             if ( stateMachineTest_DW . Event == stateMachineTest_e_reset_done ) {               /* Transition: '<S5>:37' */               stateMachineTest_DW . is_c1_stateMachineTest = stateMachineTest_IN_Init ;               /* Entry 'Init': '<S5>:1' */               rtb_y = 2U ;             } else if ( stateMachineTest_DW . Event == stateMachineTest_e_fault ) {               /* Transition: '<S5>:46' */               stateMachineTest_DW . is_c1_stateMachineTest = stateMachineTest_IN_Fault ;               /* Entry 'Fault': '<S5>:18' */               rtb_y = 7U ;             } else {               /* Outputs for Function Call SubSystem: '<Root>/Reset state' */               /* Event: '<S5>:49' */               stateMachineTest_Resetstate ( ) ;               /* End of Outputs for SubSystem: '<Root>/Reset state' */             }             break ; /* ... */       } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ /* ... */ } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ The reset state function is compiled based on priorities set in each block of the Simulink model. If no priorities are set, the default ones are based on the order of adding them to the model. Therefore, it is very important to verify and eventually change the priorities as requested by its logical sequence. This setting can be changed in the block properties as shown below. The priority settings is shown after the model is updated (Ctrl+D) as a number in the upper right corner of each block. State Machine Test Application Testing application is designed to test all the features of the state machine, targeting the S32K144EVB. To indicate active states, RGB LED diode is used in combination with flashing frequency. On-board buttons SW2 and SW3 are used to control the application. The application is running in 10 ms interrupt routine (given by the sample time). There is an independent LPIT interrupt controlling the LED flashing. After the power-on reset, the device is configured and the RESET state is entered, where additional HW and application settings are performed. Then, the application runs into the INIT state with a simulated delay of approx. 2 seconds, indicated by the blue LED diode flashing fast. After the delay, the READY state is entered automatically. Both buttons are handled by another state machine, which detects short and long button press. While the short press is not directly indicated, the long press is indicated by the red LED diode switched on. By a short pressing of the SW2, the application is started, entering the CALIB state first, followed by the ALIGN state and finally entering the RUN state. The CALIB and ALIGN states are indicated by higher frequency flashing of the blue LED, while the RUN state is indicated by the green LED being switched on. The application introduces a simulation of the speed command, which can be changed by long pressing of the SW2 (up) or SW3 (down) within the range of 0 to 10,000. Moreover, to simulate a fault situation, the e_fault event is thrown once the speed command reaches value of 5,000. The FAULT state is entered, indicated by the red LED flashing. To clear the fault, both SW2 and SW3 should be pressed simultaneously. The INIT state is entered, indicated by the blue LED diode flashing fast. Following tables show the functions and LED indication. Button Press lenght Function SW2 short press Start the application SW2 long press Increase the speed command (indicated by the red LED diode ON) SW3 short press Stop the application SW3 long press Decrease the speed command (indicated by the red LED diode ON) SW2 + SW3 short press Clear faults State LED Flashing Reset - Init Blue period 50 Ready Blue period 500 Calib Blue period 250 Align Blue period 100 Run Green always on Fault Red period 100 any Red always on when a long press of SW2 or SW3 is detected Running the example The example can be built and run along with the Model Based Design Toolbox for S32K14x, v3.0.0. This version has been created using MATLAB R2017a. Please follow the instructions and courses on the NXP Community page prior to running this example. Usage of the S32K144EVB with no connected extension boards is recommended, however this example doesn't use any HW interfaces except of (please refer to the S32K144EVB documentation): S32K144 pin S32K144EVB connector Usage PTD15 J2.2 GPIO output / strength: High / Red LED PTD0 J2.6 GPIO output / strength: High / Blue LED PTD16 J2.4 GPIO output / strength: High / Green LED PTC12 J2.10 GPIO input / Button SW2 PTC13 J2.12 GPIO input / Button SW3 PTC6 J4.4 UART1 / RxD / FreeMASTER PTC7 J4.2 UART1 / TxD / FreeMASTER The application works also with the FreeMASTER application. Users can connect to the target and watch or control the application. The FreeMASTER project is attached as well, however, the ELF file location needs to be updated in the FreeMASTER project settings after the application is built and run.
View full article
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: 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 with the instruction on how to connect the MC3377xB and the MPC5744P via Model-Based Design Toolbox, please have a look on this question here: MPC5744P &MC33771B Configuration   Happy hacking! Marius
View full article
      Product Release Announcement Automotive Processing NXP Model-Based Design Toolbox for S32K1xx – version 4.2.0     Austin, Texas, USA July 20, 20 20 The Automotive Processing , Model-Based Design Tools Team at NXP Semiconductors, is pleased to announce the release of the Model-Based Design Toolbox for S32K1xx version 4.2.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 S32K142W and S32K144W, Battery Management Systems (support for MC3377xB), EEEPROM R/W operations, integration with Simulink Motor Control Blockset and Battery Management System Toolbox, new community requested features (like I2C multi transfer block, S32Design Studio importer for Simulink models, LIN CRC configuration) 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   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 4.0.0 RTM drivers from MATLAB® for NXP all S32K1xx derivatives : S32K142W MCU Packages with 48/64 LQFP (*new) S32K144W MCU Packages with 48/64 LQFP (*new) S32K116 MCU Packages with 32QFN and 48LQFP (*updated) S32K118 MCU Packages with 48/64 LQFP (*updated) S32K142 MCU Packages with 48/64/100LQFP (*updated) S32K144 MCU Packages with 48/64/100LQFP and 100BGA (*updated) S32K146 MCU Packages with 64/100/144LQFP and 100BGA (*updated) S32K148 MCU Packages with 144/176LQFP and 100BGA/QFP (*updated) Multiple options for packages and clock frequencies are available via Model-Based Design Toolbox S32K Simulink main configuration block   Battery Management System (BMS) support for MC3377xB – examples, documentation and FreeMASTER UI are available Special Simulink Blocks have been added to simplify the way a user can initialize such a controller, read vital parameters (like cell voltage, stack voltage, temperature, current) and manage the whole system. The entire suite of blocks is easily integrated within the new Battery Management Toolbox from Mathworks, so users can leverage these algorithms on top of our blocks. Integrates the Automotive Math and Motor Control Library release 1.1.21 for: S32K11x based on ARM M0+ cores; S32K14x based on ARM M4F cores;   Multiple S32K1xx peripheral support . The peripheral coverage for each of the S32K1 x x derivatives is shown below:        S 32K116      S32K118        S32K142        S32K144          S32K146      S32K148   Added support for EEEPROM These blocks allow users to make read/write operations to non-volatile memory (useful in applications that require parameters/states to be saved even when powered-off):   Updated Motor Control support New examples added for the following parts: -     MCSXTE2BK142 -     S32K11XEVBM -     XS32K14WEVB Additionally, Motor Control blocks can be easily integrated with the Motor Control Blockset from Mathworks, so users can leverage these algorithms on top of our existing blocks.     Extended support for MATLAB versions We extended support for our toolbox to cover a wider range of MATLAB releases – starting from R2016a and going up to R2020a. This way we want to avoid locking out users that have constraints regarding MATLAB versions.   New community-requested features In our efforts to make  NXP’s Model-Based Design Toolbox for S32K1xx version 4.2.0 fit the needs of the users, we have added the following requested features/updates: -     Added new I2C multi transfer block -     S32 Design Studio importer functionality extended for referenced models projects -     Updated LIN blocks to add CRC type configuration -     Updated ADC blocks to enable auto-calibration   100% S32K1xx supported peripheral coverage with examples . Approximatively 300 examples available as part of the toolbox that exercise all the functionalities supported   For more details, features and how to use the new functionalities, please refer to the Release Notes document attached.   MATLAB® Integration The NXP Model-Based Design Toolbox extends the MATLAB ® and Simulink ® experience by allowing customers to evaluate and use NXP’s S32K1xx MCUs and evaluation boards solutions out-of-the-box with: NXP Support Package for S32K1xx Online Installer Guide Add-on allows users to install 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.2.0 is fully integrated with MATLAB® environment in terms of installation, documentation, help and examples:   Target Audience This release (4.2.0) is intended for technology demonstration, evaluation purposes and prototyping for S32K116, S32K118, S32K142, S32K144, S32K146, S32K148, S32K142W and S32K144W MCUs and Evaluation Boards.   Useful Resources Examples, Trainings and Support : https://community.nxp.com/community/mbdt                                            
View full article
1. Introduction The scope of this article is to show how easy it is to use MBDT, FreeMASTER and some knowledge in electronics to create a simple and useful project: monitor USB voltage and current consumption.  I used this setup it to monitor USB voltage and current while my smartphone is charging, but it can be used in other purposes too, like monitoring power consumption of some devices connected on USB charger/power bank/PC, or it can be used to find some charging issues, or maybe you just want to find out if your phone charger supports fast charging, or to characterize a power bank.  2. Overview 2.1 Functional Description This project can measure USB voltage and current by measuring USB voltage and a voltage drop across a resistor through which current flows from a USB power source to a USB load. The voltage given by current flow is amplified by an electronic circuit and sampled by MPC5744P-DEVKIT board through the ADC converter, then data is sent to PC and then are displayed through a FreeMASTER project as numerical values and as oscilloscope chart. The MPC5744P-DEVKIT board is programmed by MBDT. To build this simple project, you need three components: Matlab with MBDT toolbox installed, FreeMASTER Run-Time Debugging Tool, a very simple electronic circuit, and an MPC5744P-DEVKIT.  As can be seen in fig.1, the project can be split into two main parts: Hardware Setup and Software Setup. Fig. 1: USB Voltage And Current Monitor block diagram 2.1 Hardware Setup Custom Electronic Board The simplest way to measure current is to use a simple resistor connected in series with the load (USB output in our case). The Ohm law gives us a linear relationship between voltage and current in an electrical circuit: U = R * I  U is the voltage (measured in volts V) drop across the resistor, R is the resistance of the resistor (measured in ohm Ω ) and I is the current (measured in amps A) which we need to measure. Most of the USB chargers can supply a maximum of 3A and most of the smartphones can drain less than 3A. Giving that I considered designing this circuit to measure around maximum 3A. Let suppose that we use a simple 1ohm resistor. If we do simple math using Ohm formula, then it can be seen that for 3A the voltage across our resistor (there) will be 3V (U = 1 * 3). Fig. 2: USB connectors and current "sensor" In Fig. 2 on the left side is a USB input connector, on the right side is the output USB connector and both GND lines are connected through R1 current sensor. The current "I" will flow, as can be seen in Fig. 2, from USB input through VBUS  line to VBUS on USB output, than will flow through our load connected to USB output and then through GND on the same connector thru R1 and at least to GND on USB input connector. This current will create a voltage across R1 (UR1) equal with 3V (if we use 3 amps current and 1-ohm resistor). One of USB standard charging it specifies that the lowest (standard) voltage it's 5V. In our case, using this 1 ohm resistor will cause 3V loss, then the voltage at USB outputs will be 2V (unacceptable). In most of the digital electronic circuits, when it's used 5 volts power, the voltage tolerance it's about 10% (0.5V) which means the voltage can be between 4.5V and 5.5V. Let's try to create a maximum voltage drop across this resistor about 3 times lower than the 0.5V, e.g.: 150mV. Then the current sensor resistor is R1 = 0.15V / 3A = 0.05ohm.  To measure this drop voltage we could use any ADC channel on MPC5744P-DEVKIT, but if the voltage reference of ADC is set to 5V, the resolution of ADC is 5V/4096 = 1.22mV, which means the equivalent ADC resolution corresponding to current measurement is about 24mA (1.22mV correspond to 24mA). If we consider electrical noise on USB connectors, it's very possible that the out signal will be "drowned" in electrical noise or the results will be not very satisfactory.  The solution to that problem is to "rescale" this 0V --> 0.15V range to 0V --> 5V. We can do that by using operational amplifier circuits.  I used what I found on the moment in my electronic components, an LM358 IC.  This IC is not the best, but for the demo, it's ok to be used.       Fig. 3: USB current and voltage monitor A few ideas of this electronic design:  this IC contains two operational amplifiers,  first amplifier coefficient is set thru R5 and R4 (34 amplification coefficient) and the signal is connected on his noninverting input, the lowest current that can be measured is approx. 0.7mA, the second amplifier is set as a buffer amplifier, note: if the maximum current used by the load is maximum 3A, the Zenner diode it's not necessary. By using this amplifier, the range is rescaled to 0 --> 5.1V.  To measure the voltage at USB input we use R9 and R10 divider resistor and will use the formula U_R9 = U_USB * ( R9/(R9 + R10)). And by using for R9 10K and for R10 33K  the voltage measured by ADC for maximum USB standard charging is U_R9 = 20V * (10/(43)) = 4.65V. This circuit has been developed on prototyping PCB. The outputs of this circuit are connected to two ADC (current signal to PTB13 and voltage signal to PTB14) channels of MPC5744P-DEVKIT and those can be found on CN1 connector ("USB voltage", "USB current" and GND). MPC5744P-DEVKIT Evaluation Board The main scope of this devkit is to get current and voltage data from the custom board and to convert it to digital data and send it to the PC through the UART interface.  As can be seen in fig. 4, I used three wires to connect the custom electronic board to the devkit (two ADC and GND).  On MPC5744P-DEVKIT the ADC voltage reference must be set to 5V (jumper J19 --> 2-3) and the data will be sent to PC through UART (USB --> OpenSDA). The  MPC5744P-DEVKIT must be connected to PC thru USB cable.  All other jumpers can be let in the default state. Fig. 4: Hardware setup (load is a USB led light) 2.1 Software Setup MBDT Application Model             For software development, I used Matlab   with  the  MBDT   toolbox. The first step is to create a new Simulink project using MBDT.  The project contains three main parts: configuration blocks variable declaration blocks main loop, where the values are taken from the output of ADC block, and after using some simple maths functions, resulted in values are stored in current and voltage variables. After getting the values from ADC blocks, we must apply some math functions to reverse the effect created in the electronic circuit. Part of the configuration blocks contain: MPC5744P configuration block, ADC configuration block, which has two channels are configured, FreeMASTER block used to observe the current, voltage, and other parameters over UART through the FreeMASTER protocol. Part of the variables declaration is used to declare all variables used to get values from ADC peripheric, intermediate values, and final values.  Part of the main loop consists of simple mathematical functions that have the role to convert ADC values to current and voltage values. The first thing executed is taking the ADC current and voltage values, then those values are converted to floating-point type the multiplied with a constant (ADC_Vref /ADC_resolution = 5/4095) which represent ADC voltage resolution. Then, for USB current value, the result must be divided with operational amplifier factor (34), after that, we could subtract from the result that operational amplifier input offset (if it is measured any relevant value) and the last thing to do to get the USB current is to convert from voltage to current using ohm law (U = R * I).  To get the USB voltage, the first step is similar to the USB current value, using the resistor divider formula we get the final value. For using different opamp IC, if the non-inverting input is too high, it is recommended to be measured while the electric circuit is on and the value to be updated in the model (variable Current_offset).  Fig. 5:  MBDT Application Model FreeMASTER project To view data in real-time, the first thing is to open the FreeMASTER project and, select "Tools", then "Connection Wizard ...", then hit "Next" button, select the first option "Use the direct connection to an on-board USB port", then select the serial com port assigned to  MPC5744P-DEVKIT and 115200 baud rate. The USB current and voltage can be observed In the FreeMASTER project as a numerical value and as an oscilloscope view by selecting "RAW data" to plot raw ADC USB current and voltage values. To plot the real USB current and voltage values, in the Project Tree, please select "Voltage and current" oscilloscope. Fig. 6:  FreeMASTER USB current and voltage monitor In Fig. 6 it can be seen current and voltage variations in time for fast charging transitions when my smartphone is connected to the original charger.
View full article
      Product Release Announcement Automotive Microcontrollers and Processors NXP Model-Based Design Toolbox for MPC57xx – version 3.2.0     Austin, Texas, USA April 1 4 th , 20 20 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.2.0. This release supports automatic code generation for peripherals and applications prototyping from MATLAB /Simulink for NXP’s MPC574xB/C/G/P/R and MPC577xB/C/E 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   Technical Support NXP Model-Based Design Toolbox for MPC57xx issues are tracked through the NXP Model-Based Design Tools Community space. https://community.nxp.com/community/mbdt   Release Content Automatic C code generation based on PA SDK 3.0.2 RTM drivers from MATLAB®/Simulink® for 21 NXP product families MPC574xB/C/G/P/R and MPC577xB/C/E derivatives : MPC5744B, MPC5745B, MPC5746B                                                 (*updated) MPC5744C, MPC5745C, MPC5746C, MPC5747C, MPC5748C       (*updated) MPC5746G, MPC5747G, MPC5748G                                                (*updated) MPC5741P, MPC5742P, MPC5743P, MPC5744P                              (*updated) MPC5743R, MPC5745R, MPC5746R                                                 (*new) MPC5775B, MPC5775E, MPC5777C                                                 (*new) Multiple options for MCU packages, Build Toolchains and embedded Target Connections are available via Model-Based Design Toolbox Simulink main configuration block   Multiple peripherals and drivers supported MPC574xP Ultra-Reliable MCU for Automotive & Industrial Safety Applications MPC574xB/C/G Ultra-Reliable MCUs for Automotive & Industrial Control and Gateway MPC574xR Ultra-Reliable MCUs for industrial and automotive engine/transmission control MPC577xB/C/E Ultra-Reliable MCUs for Automotive and Industrial Engine Management Add support for AUTOSAR Blockset for all MPC57xx parts to allow Processor-in-the-Loop simulation for Classic AUTOSAR Application Layer SW-C:     Add support for Three Phase Field Effect Transistor Pre-driver, MC33GD3000, MC34GD3000, MC33937, and MC34937 configuration and control Enhance MATLAB/Simulink support to all versions starting with 2016a to 2020a Enhance the example library with more than 140 models to showcase various functionalities: Core & Systems Analogue Timers Communications Simulations Motor Control Applications 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 the NXP solution directly from the Mathworks website or directly from MATLAB IDE. The Support Package provides a step-by-step guide for installation and verification.    NXP’s Model-Based Design Toolbox for MPC57xx version 3.2.0 is fully integrated with the MATLAB ® environment in terms of installation, documentation, help, and examples.     Target Audience This release (v.3.2.0) is intended for technology demonstration, evaluation purposes and prototyping for MPC574xB/C/G/P/R and MPC577xB/C/E MCUs and their corresponding Evaluation Boards: DEVKIT-MPC5744P PCB RevA SCH RevE (*new) DEVKIT-MPC5744P PCB RevX1 SCH RevB DEVKIT-MPC5748G PCB RevA SCH RevB DEVKIT-MPC5777C-DEVB                                                                      Daughter Card MPC574XG-256DS RevB Daughter Card X-MPC574XG-324DS RevA Daughter Card MPC5744P-257DS RevB1 Daughter Card SPC5746CSK1MKU6 Daughter Card MPC5777C-516DS                                                       Daughter Card MPC5777C-416DS                                                      Motherboard X-MPC574XG-MB RevD Motherboard MPC57XX RevC Daughter Card MPC5775B-416DS (*new) Daughter Card MPC5775E-416DS (*new) Daughter Card MPC5746R-144DS (*new) Daughter Card MPC5746R-176DS (*new) Daughter Card MPC5746R-252DS (*new)     Useful Resources Examples, Training , and Support : https://community.nxp.com/community/mbdt      
View full article
Having fun with MBDT for MPC57xx 3.1.0 and MPC5744P for Xmas tree by controlling the lights and sounds
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 1 6 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. 2 RTM 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
1. Introduction This article discusses various algorithms for controlling trajectory and speed for an autonomous vehicle.  The car is built with S32K144 and the NXP's Cup car chassis as explained in depth in this article: https://community.nxp.com/docs/DOC-341984. All software used for programming the car is done using MATLAB/Simulink toolbox called Model-Based Design Toolbox for S32K1xx - NXP Support Package S32K1xx - File Exchange - MATLAB Central. The goal of achieving imposed performances for this system is approached in a classical manner using a PID (Proportional Integral Derivative) controller and also by using modern control algorithms: LQG (Linear Quadratic Gaussian), LTR (Loop Transfer Recovery), H2 and H∞.   2. Vehicle Dynamics Model A logical way of creating a formal representation of the physical system is described in the following section. The significant contribution of such representation is outlined in the control algorithms design process. Validation of these algorithms in a simulation environment, where a mathematical model approximates the real system, is a procedure which is going to be undertaken to ensure rectitude and precision for the developed solutions. Simplifying assumptions must be made to create the context of ease in manipulating such a formal representation, considering the existing numerical algorithms. Therefore, the mathematical model will possesses a certain level of compromise between the simplicity of the representation and accuracy related to the real system. Before starting to model the car’s dynamics, a brief analysis of the system is introduced to offer a clear image on the process. The car can be controlled through three independent inputs, duty cycles which are given as inputs to the Simulink blocks: the duty cycle for the servomotor; the duty cycle for the 1st rear wheel and the duty cycle for the 2nd rear wheel. The output of the process is represented by the image camera sees in front of it, the array Y with the converted values of the analog signal transmitted by the sensor. Hence, a   Multiple Input Single Output (MISO)   process is modeled in the current section of the paper. The   actuators   are represented by the three motors, two to ensure traction of the car, and one servomotor responsible for the steering. The   plant   is represented by the actual vehicle, and the   sensor   is constituted by the camera which provides the image in front of the car. Thereby, Figure 2.1 illustrates the correspondence between the physical ensemble and the control theory components. Figure 2.1 Actuators, plant, sensor Before exposing the equations that describe the dynamics of the system, a representation of the forces that affect the vehicle is illustrated in Figure 2.2, where:   XR   and   YR   define the robot frame,   δ   represents the turning angle of the front wheels,   F   is the traction force generated by the two DC motors of the rear wheels,   Ff  denotes  the friction force that the vehicle must overcome during its movement,   L   is the length of the car, measured from the center of the front wheels to the center of the rear wheels,   Cx   and   Cy   reactive forces depending on the movement velocity and   ω the angular velocity. Figure 2.2 Forces acting on the vehicle Now, writing Newton’s law for the translation motion and considering the decomposition of the forces on the robot’s frame axis, the motion is described as well as longitudinal as latitudinal by: The traction and resistance forces can be expressed based on the two DC motors parameters: where:   ui   - voltage applied on the inner wheel motor,   uo   - voltage applied on the outer wheel motor (related to turning behavior),   km   - DC motor constant,   rw   - rear wheels diameter,   R   - winding resistance,   Bv   - resistance coefficient for the translation motion,   μ   - friction coefficient,   M   - mass of the vehicle, g   - gravitational acceleration. When it comes to the rotational motion, the equation which describes the vehicle dynamics is given by: where: MFx - moment of Fx force, Md - moment caused by the difference of speeds on the two rear wheels which triggers the car to change its orientation, MFfx - moment of Ffx force, which opposes to the rotational movement, Cw - reaction dependent to the angular velocity and J - moment of inertia. Considering thus the previous formulas for the traction and friction force, the final equation of the rotational movement is: where all the variables have the same meanings as already specified and more than that, Bw represents the resistance coefficient for the rotational motion.  To express the position of the vehicle on the track, an approach based on angles is going to be used to provide a suitable functional description of the process. Therefore,   θ  represents  the angle between the   YR-axis of the robot and the   XI-axis of an inertial frame, like in Figure 2.3 The   θ   angle provides information about the car’s position on the given track, and it represents the variable to be measured to ensure the desired behavior of the vehicle.  Figure 2.3 System output - θ angle Therefore, the differential equations that model the   vehicle’s dynamics  are written in the inertial coordinate system and obtained considering a Newtonian approach as in: The mathematical representation given by the previous differential equations is characterized by nonlinear dynamics. A linearization procedure is therefore implemented to obtain a state-space representation of the given model. For the particular model developed so far, considering the variables and their signification related to the vehicle’s dynamics, the state array is formed by:   x' = [θ vx vy ω], while θ  represents the output and u' = [δ ui uo] defines the control signals array. The differential equations of the vehicle dynamics are introduced in the Simulink environment for obtaining the linear system. Input and output ports are used for the controlled and measured variables, while a simple logic of mathematical operations blocks, integrator blocks, and signals connections are implemented. Before using the linmod Matlab function to obtain the linearized model, a static operating point must be chosen. When it comes to this, the following assumptions are made: the car travels a straight road, the front wheels are straight, no turning angle, the rear wheels have equal rotational speed and the car is perpendicular on the X-axis of the inertial system coordinate. All these specifications correspond to a duty cycle equal to 0.03, as mentioned previously. For the two rear wheels, a 10% speed is chosen. However, the transfer from the duty cycles transmitted to the motors and the inputs considered for the system in the current model should also be computed. For the two rear DC motors, the voltage applied is proportional to the duty cycle control signal. A 0% duty cycle (no rotational speed) is equal to a 0V power voltage. While the maximum voltage of the DC motors is 5V, and the maximum duty cycle is 100%, it is easy to determine the proportionality factor, which is equal to 5. When it comes to the conversion between the duty cycle of the servomotor and the turning angle of the front wheels, it must be taken into account that the maximum angle physically achievable for the front wheels is equal to 45 degrees. Therefore, the transfer can be modeled by: With all the transfers modeled and all the model's constants replaced with numerical values, a state-space representation is computed for the entire process and the system is described by the following minimal state-space representation: 3. Control Algorithms 3.1 Experimental PID Position Control The actual position of the car on the track is compared to a defined reference and it is desired to maintain the error between these variables as small as possible, with the purpose mentioned in the previous paragraph. The inputs on the rear motors are given by a constant duty cycle equal to 0.1, which represents 10% of the maximum speed that the car can reach. All these information are represented in a schematic manner in Figure 3.1.1 Figure 3.1.1 Position control loop 3.1.1 Position Computing and Reference Defining Relying on the array of intensities returned by the ADC, the following procedure was undertaken to gain knowledge about what the camera sees. The robot was firstly placed on one side of the track, and connected to the FreeMaster tool for real-time data collecting. The experiment was repeated for different positions of the vehicle, and the results are illustrated in the figures below:                              Figure 3.1.1.1 Exemplification of what camera sees for different positions of the car on the track Noticing how the image in front of the camera changes related to its position, it is desirable for the two dips on the graphics to be equally distant from the center of the array. A position finding algorithm is therefore implemented for searching the edges of the road. 3.1.2 Parameters Tunning Based on the error value, the steering input is computed. Bearing in mind the fact that the duty cycle for the servomotor should be in the range of 0.02 – 0.04, the control signal given to the actuator should be bounded for this particular input range. Thus, a scaling factor is introduced before the error is transmitted to the controller. Considering the error range, a convenient scaling factor is chosen. Irrespective of the correspondence of the errors to left or right halves of the road displacements, the magnitude of the signal should be processed by the controller in the same way. The symmetry has then to be dismissed because different values of the duty cycle should be computed to make the car turn left or right. Therefore, the PID controller can return a control signal which is maximum equal to 0.01, for an maximum error value, which then, based on the sign of the position index algorithm returned value, should be added to 0.03 (wheels not steered) for a movement to the left, or subtracted from 0.03 for a movement to the right. Following all the introduced information, the first step into the procedure of tuning the PID controller is to build a proportional controller. A maximum error value, divided by the scaling factor corresponds to a maximum 0.01 control signal. Moreover, knowing that for a proportional controller, which is discrete considering its use directly on the real process: the proportional parameter of the PID controller is computed from the previous formula. The result of the designed controlled system is now illustrated in Figure 3.1.2.1, extracted from the FreeMaster debug tool in real time, while the car completes multiple laps on the given track.The output of the system is illustrated on the Y-axis, the reference is marked with a black line, and the time scale is represented on the X-axis, in seconds. The dips on the graphical representation of the system’s output correspond to the curvatures of the road, where a significant error triggers the wheels steering to keep the car on the track. The wavy portion is the system’s output on the wavy piece of the road, and the almost straight area is the output provided when the car is on the straight piece of the track. It is noticeable that on the straight part of the track, the reference is not completely followed. Also, on a long straight road, only the proportional component is not able to ensure a steady state error equal to zero.                                          Figure 3.1.2.1 System reference and output with P controller Figure 3.1.2.2 Track components: straight, curve, wavy Rising even more the KR factor value does not solve this problem, because the risk of the system’s instability appears in this scenario. Thus, the integrative component should be used, and now the controller is a PI, with the following control law: The Ti value is chosen experimentally, and satisfying results are illustrated in the following figure:                                 Figure 3.1.2.3 System reference and output with PI controller A derivative component is not necessarily required, considering the form of the track (without sudden changes of direction). Inside the PID block which implements the controller in the Simulink environment, besides the parameters choice and also the upper and lower saturation limits of the control signal, the clamping anti-windup method is also used for preventing the controller output from saturating. The sampling time is left to be inherited, this option allowing the Matlab environment to choose the right sampling period considered regarding the timing in the given Simulink model. 3.2 Experimental PID Speed Control The center of the track is now followed, and the behavior of the vehicle is as desired. On longer tracks, the vehicle movement seems like a crawl, and the particularities of the system allow the control of three different inputs. A speed control algorithm is thus implemented to ensure a reduced time in completing a lap. Like any other car, the robot should be able to adapt its speed depending on the track to be traversed. Acceleration and deceleration features should be implemented into the current application to emulate the behavior of a real-life vehicle. Also depending on the road’s particularities, curvatures, distances, a speed limit should be left to be user’s choice. Intuitively, from a driver perspective, the speed should be reduced at the beginning of the curve and then gradually increased on the second part of the curve, as the car leaves it and heads to a straight piece of the road. Taking into consideration this real life behavior, the graphic evolution of the output of the system controlled with the PID position controller seems to illustrate this exact idea. It is noticeable that inside a curve, the error slowly increases as the car approaches the center of the turn, and then decreases while the exit becomes close. A proportional control signal to the speed of the two wheels can be thus computed to take care of this operating mode.The error signal is consequently fed to a P controller which amplifies it considering, for the beginning, that the maximum speed allowed is equal to 0.15 (15%). Therefore, the control loop is completed, as illustrated in the figure below: Figure 3.2.1 Position and speed control loop Assuming that the imposed speed limit is provided by a duty cycle equal to 0.15, as specified in the previous paragraph, and also that, during a turn, it must be reduced to 0.1, the KR factor of the two controllers, one for each rear wheel is given by: The KR general formula can be modified under the desired speed range (how fast should the car go and how fast should it take turns). The control signal given to the rear motors, uk = KRϵk is subtracted from the imposed speed limit to achieve the desired behavior on the curvatures of the road. The car travels the track faster now, but increasing the speed, even more, causes a side-slip of the vehicle during turns. This shortcoming could be improved by taking advantage of the fact that the two rear wheels can be controlled independently. Hence, inside a turn, the outer wheel should have a bigger rotation speed than the inner one, in the same way, an automobile operates. This differential control of the traction wheels is used to increase the stability of the system, improving, therefore, the performances of the vehicle. However, a way of computing the difference between the speeds of the two rear wheels must be implemented. The overall speed of the moving vehicle is given by the two duty cycle control signals, and it is: The ratio between the outer wheel speed and the inner wheel speed is experimentally chosen based on the formula: The experimental procedure is undertaken for obtaining a suitable value for the speed ratio started by choosing this factor equal to 1. For a speed ratio equal to 1 there is no differential control of the rear wheels, both of them having the same rotation speed. The speed ratio produced satisfactory results for a value equal to 1.3. A 1.4-speed ratio factor is also suitable for the application, but increasing it more could cause unwanted behaviors such as the car turning around its axis. With a 1.3-speed ratio factor, a 20% (0.2) speed limit was achieved, with a lower value of 15% (0.15) during turns. Increasing the speed, even more, 25% (0.25) and keeping the lower value at its previous setting produces, in some cases, side-slips of the vehicle outside the track. By reducing the vehicle turning speed, for example, 10% (0.1) does not solve the side-slip issue. The leading cause of this behavior is related to the oval shape of the track, with short straight segments. As on a winding road, the robot should also limit its speed because sudden acceleration and deceleration actions cause undesired system’s reactions and safety issues are definitely to be considered during control algorithms design. Mixing this way of computing two different duty cycles for the two rear wheels, with the proportional controller introduced in the first part of this subsection, which will provide the overall DT, the vehicle shows more stability during the turns than it did without the differential speed control and a bigger speed can be achieved without losing the position requirements. Figure 3.2.2 Computing the rear wheels control signals 3.3 LQG and LTR Unlike the PID regulator, the LQG and LTR control laws are going to be designed in a theoretical manner, based on the mathematical model of the system, obtained in the previous section. However, before implementing the controllers in the Simulink environment for proper simulation and validation of their results, a short analysis of the open loop system is going to be depicted in the next subsection. 3.3.1 Position Computing and Reference Defining As illustrated in the previous chapter of the thesis, the output of the mathematical representation is the angle θ measured between the Y-axis of the robot frame and the X-axis coordinate of the inertial frame. There are also three inputs of the system given by the values of the duty cycles transmitted to the motors. Thereby, the four matrices,A,B,C and D  are introduced as a state-space block in a newly created model in the Simulink environment. However, the simulation does not recognize the output of the system as an angle. Considering the work in a digital environment, its values are increasing and decreasing following the given inputs. This behavior is as expected, assuming that a constant speed on the rear wheels and a certain angle of the front ones produces a variation of the output, increasing or decreasing its value based on the steering direction. However, the output θ is an angle, so the subsequent processing of the signal is realized. The following assumptions are made: the value of θ is measured trigonometrical; the minimum value for θ is 0 radians, and the maximum value for θ is π. It is natural that for bigger angles than π, the real value of the angle is computed by theta real = theta measured − π. Before applying this verification and then modification of the measured value, it must be made sure that the output of the system is not negative; therefore a Simulink block is used to compute its absolute value. Figure 3.3.1.1 Theta angle conversion As noticeable in the previous figure, the system’s output changes its value when the vehicle is going inside curvature of the road, for example. As assumed during the linearization procedure, the car starts its movement from a position which is perpendicular on the X-axis of the inertial coordinate system, thus leading to a θ equal to π/2 . If the camera spots a dark value in front of the car, which represents a black edge that needs to not be crossed, based on the position where the edge is seen, a deviation angle α will be computed in order to express the fact that the car needs to change its direction, less or more abruptly.  Based on this deviation angle, the reference of the control loop is going to change its value to determine the vehicle to turn when edges are spotted. Therefore the reference of the system will be given by:   θ+α, with θ the system’s output. From the way of measuring the α angle, given by the following figure, it can be concluded that a positive α angle determines to steer to the left, while a negative one determines the steering to the right, as explicitly illustrated in the following figure: Figure 3.3.1.2 Deviations regarding the trajectory to be followed 3.3.2 Controller Implementation Firtsly, an LQG controller is implemented in the Simulink environment using the   lqg   Matlab function: where   sys   is the state-space representation of the system given by the   A,B,C   and   D   matrices. QXU   is the penalty matrix considering that the cost function to be minimized by the algorithm is written as: The   QWU noise covariance matrix is given by: The control signal u is computed with the help of an LQR (Linear Quadratic Regulator) such that J reaches is minimum value. A Riccati equation depending on the state-space representation of the system and the penalty matrices Q and R is solved with this purpose, but these details are not subject of the current description. However, for obtaining such a controller, a full state array x is required. The feasibility of this assumption is not guaranteed considering that in many control problems, not all the state components are measurable. If moreover, the process is affected by noise, a Kalman filter has to be used. After the Kalman filter estimates the full state of the system, the LQR algorithm computes optimally the control signal, based on the state estimation. This procedure is called the synthesis of a LQG controller.  Considering the penalty of the state deviation which needs to be accomplished and also the control signals limitations required for a safety operation mode, the values of these matrices are chosen conveniently. The returned controller is given by a state-space representation which is introduced into a state-space block in Simulink, and connected to the system considering a classical control loop. However, before doing so, the obtained controller is sampled with a convenient sampling period to ensure the functionality of the given process, using the c2d Matlab command. The control signals given by the discrete controller, before being fed to the system, are added to their linearization values and saturation blocks are also used to prevent the damages a very high control signal can produce on the system’s actuators. The implementation on the real system is illustrated in the figure below, where the deviation based on the array returned from the camera is given to the controller as an error signal, as mentioned previously. Figure 3.3.2.1 LQG control loop on the real system As mentioned previously, LQG controller is formed by a LQR and a Kalman filter.  However, when using a Kalman estimator together with a linear quadratic regulator, the robustness of the designed algorithm deteriorates. To overcome this loss of robustness, the LTR methodology is used in this example, as a second control option, to recover the robustness of the linear-quadratic regulator through a modified computation of this controller.  The same reference defining and position computing apply also for the LTR algorithm as well. No modifications are brought to the control loop, except for the controller, which is now computed using the ltrsyn command: where   sys   is the state-space representation given by the   A,B,C   and   D   matrices in.   Kf   represents the optimal gain filter matrix, while   Qf   and   Rf are identity noise covariance matrices. The recovery of the full-state feedback linear quadratic loop is thus realized with a gain specified by RHO.  3.4 H2 and H∞ Considering the particularities of the current application, the requirements defined for the H2/ H∞ control problem are:   small errors in reference tracking;   rejection of the disturbances   which appear at the system’s output; (Considering that the sensor of the system is the camera, which operates as described in the previous chapters, disturbances on the system’s output can be caused by light fluctuations, shadows, etc.) and   bounds for the control signals, knowing their technological limits. These requirements translate into the following transfers between the mentioned signals. ϵ = Sr, u = KSr and y = Sdo. The transfers are written considering a standard control loop as in the following figure: Figure 3.4.1 Standard control loop Computing a controller that satisfies the imposed performances requires the consideration of the system in a generalized form given by: In such a configuration, the partition of the inputs and the outputs has the following signification: u1 - external inputs (disturbances, noises, references); u2 - controlled inputs; y1 - controlled outputs (errors to be minimized, control signals to be bounded); y2 - measured outputs. In the case of the current application, this translates into: The closed-loop system is obtained by connecting the controller to the generalized system as in Figure 3.4.1. Figure 3.4.2 Closed loop system The purpose of the H2/ H∞ controller computing can be now expressed as: Given a generalized system T with the corresponding partitions of the inputs and the ouputs, the H2/ H∞ algorithms design the controller K which measures the system output y2 and computes suitable commandu2. In the same time, the controller K must be computed in order to ensure a stable closed loop system Ty1u1 and such that it minimizes the H2 norm of the closed loop system; respectively it bounds the H∞ norm of the closed loop system, ||Ty1u1 ||∞ < γ, for a given γ > 0.  Considering the imposed performance requirements the  generalized system is written in the following form: T represents the system in the generalized form, 1 stands for the number of outputs to be measured and 3 stands for the number of inputs to be controlled. G denotes the transfer function associated with the state-space representation of the system. A discretization procedure is applied in this case too. All the procedure described explicitly for solving the H2 control problem is applicable for the H∞ suboptimal problem too. The only difference is made by the Matlab command which computes the controller which is now hinfsyn and used as: 4. Results and Conclusions For each of the computed controllers, simulations are realized to validate their functionality on the given system. Each closed loop is analyzed for a step reference signal and the results are illustrated in the figures below:                                           Figure 4.1 Reference tracking and control signals computed by the LQG controller for a step reference                                                         Figure 4.2 Reference tracking and control signals computed by the LTR controller for a step reference                                                     Figure 4.3 Reference tracking and control signals computed by the H2 controller for a step reference                                                                                                     Figure 4.4 Reference tracking and control signals computed by the H∞ controller for a step reference The signals evolution over time, as noticeable in the illustrated graphics, does not highlight significant differences between the designed control algorithms. Control signals evolution over time also reflects with accuracy the real behavior of the car. For a positive error, one of the duty cycles of the rear wheels increases, while the other one decreases. For a negative error, they change their evolution symmetrically, thus differentiating between the two types of turning, to the left, respectively to the right. In the same time, the duty cycle control signal given to the servomotor shows a variation between 0.04 for a positive error and 0.02 for a negative one, keeping its values constant at 0.03 when no error is computed. However, H2 and H∞ algorithms represent powerful tools which do not exhibit their full-capacity advantages due to the low complexity of the system’s model. Therefore, a proportionate effort should be put into solving a real-life problem, considering its complexity and performance requirements. The LQG and LTR can also be interpreted as a particular case of the H2 control problem, as detailed in, this explaining the similarity between the time domain solutions between these two algorithms and H2. When it comes to the H∞ method, no significant advantages are enlightened by the time domain graphical evolution either. What is yet remarkable at this control option is represented by the advantages presented in the case of unstructured perturbations affecting the system’s model. As already mentioned in the paper, the nominal model approximates the real system. Therefore a behavioral uncertainty is present throughout the entire design process. Robustness related to this estimations is achieved with the H∞ control option. However, a statistical comparison is illustrated in the following table, which contains the values of the step-response characteristics, computed for the closed loop systems. Considering that the sampling time used for the simulation is equal to 0.02s, as mentioned in the previous chapter, the results are as in the following table: LQG LTR H2 H∞ RiseTime 0.016s 0.0121s 0.0076s 0.0068s SettlingTime 0.022s 0.0196s 0.015s 0.0144s Table 4.1 Step-response characteristics for the closed loop system The required performances are accomplished both with the classical and modern approaches. As concluded previously from the simulation results, no noticeable differences are in the real behavior of the four algorithms illustrated in the current chapter. The system’s model influences the car behavior slightly, compared to the classical PID perspective. Considering the neglect of some of the forces which affect the system, together with model parameters approximation, these results are as expected. Improved performances can be achieved as a future work by including the model uncertainties in a H∞ controller design procedure.
View full article
This video highlights the main features added in the version 4.1.0 of the NXP Model-Based Design Toolbox for S32K1xx Series
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, 201 9 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. 1 RTM drivers from MATLAB® for NXP all S32K1 x x 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 S32K1 x x derivatives is shown below: S 32K116 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 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 peripheral s 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 1 02 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 mode s 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
This short video shows how a NXP CUP Car can be controlled via an application developed with Model Based Design Toolbox for S32K microprocessors
View full article
  1. Introduction 1.1 A New Control Option For NXP Cup Race Car    NXP Cup car development kit is usually based on NXP's Freedom KL25Z board for motors control and image evaluation. However the control of the race car can be done with multiple NXP solutions.    In this article, a solution based on S32K144EVB board will be presented along with a programming approach based on MATLAB/Simulink Model-Based Design Toolbox for S32K. Additionally another tool provided by NXP - FreeMASTER - will be used to debug in real time the application.     As S32K144 pinout is not compatible with the default Landzo board pinout, an additional board to route the pins to the desired destination has been built. Complete details on the mapping of the pins are provided in the tutorial.   This article is structured as a tutorial detailing all the steps and providing all the source code to enable one to use this solution. However the control application is done very simple - on purpose - and uses just 10% of the speed to prove the concept.  Table 1. Freedom KL25Z vs. S32K144 features Freedom KL25Z Board Features S32K144 Board Features 32-bit ARM Cortex-M0+ core, u p to 48 MHz operation 32-bit ARM Cortex-M4F core,  u p to 112 MHz operation Voltage range: 1.71 to 3.6 V Voltage range: 2.7 V to 5.5 V • Up to 128 KB program flash memory • Up to 16 KB SRAM • Up to 512KB program flash memory • Up to 64 KB SRAM • Clock generation module with FLL and PLL for system and CPU clock generation • 4 MHz and 32 kHz internal reference clock • System oscillator supporting external crystal or resonator • Low-power 1kHz RC oscillator for RTC and COP watchdog •  4 - 40 MHz fast external oscillator (SOSC) with up to 50 MHz DC external square input clock in external clock mode •  48 MHz Fast Internal RC oscillator (FIRC) •  8 MHz Slow Internal RC oscillator (SIRC) •  128 kHz Low Power Oscillator (LPO) • 16-bit SAR ADC • 12-bit DAC • Analog comparator (CMP) containing a 6-bit DAC and programmable reference input  • Up to two 12-bit Analog-to-Digital Converter (ADC) with up to 32 channel analog inputs per module • One Analog Comparator (CMP) with internal 8-bit Digital to Analog Converter (DAC) •  Low-power hardware touch sensor interface (TSI) •  Up to 66 general-purpose input/output (GPIO) •   Non-Maskable Interrupt (NMI) •   Up to 156 GPIO pins with interrupt functionality • Two 8-bit Serial Peripheral Interfaces (SPI) • USB dual-role controller with built-in FS/LS transceiver • USB voltage regulator • Two I2C modules • One low-power UART and two standard UART modules   • Up to three Low Power Universal Asynchronous Receiver/Transmitter (LPUART/LIN) modules with DMA support and low power availability • Up to three Low Power Serial Peripheral Interface (LPSPI) modules • Up to two Low Power Inter-Integrated Circuit (LPI2C) modules • Up to three FlexCAN modules • FlexIO module for emulation of communication protocols and peripherals (UART, I2C, SPI, I2S, LIN, PWM, etc) • Six channel Timer/PWM (TPM) • Two 2-channel Timer/PWM modules • 2 – channel Periodic interrupt timers • 16-bit low-power timer (LPTMR) • Real time clock • Up to eight independent 16-bit FlexTimers (FTM) modules • One 16-bit Low Power Timer (LPTMR) with flexible wake up control • Two Programmable Delay Blocks (PDB) with flexible trigger system • One 32-bit Low Power Interrupt Timer (LPIT) with 4 channels • 32-bit Real Time Counter (RTC) • 4-channel DMA controller, supporting up to 63 request sources • 16 channel DMA with up to 63 request sources 1.2 Resources Model-Based Design Toolbox – Tool used to create complex applications and program the S32K144 MCU directly from the MATLAB/Simulink environment. This tool allows automatic code generation for S32K144 peripherals based on configuration of the Simulink model done by the user. S32K144-Q100 Evaluation Board – Evaluation board from the S32K14x family used for quick application prototyping and demonstration. NXP Cup Development Kit – Information about the hardware components of the development kit and instructions regarding the car assembling. Software which is helpful for the project design is also presented. FreeMaster Debugging Tool – Real-time data monitor tool which shows in both graphical mode (as a scope for example) and text mode the evolution of variables in time. It is suitable to monitor application behavior in real time during execution of the code.  TSL1401 Datasheet – Information regarding the camera configuration. Excel Spreadsheet (attached at the end of the document) with routing information to map pins from Landzo to S32K144 board. 2. Hardware Setup    After assembling all the hardware modules as indicated in the development kit the car will look like in the next image. It should be mentioned that for the S32K144 EVB to system board connection an S32K adapter board was created. Fig 1. Hardware setup 2.1  Hardware Modules    The hardware modules of this application and the way the peripherals of the S32K144 MCU are communicating with those is summarized in the Fig. 2. To understand more about the control of the motors, please check chapters 3.4.4 and 3.4.5. For learning how to debug the application using the Freemaster software, take a look at the chapter 4 where a detailed description is presented. A similar indication is given also for the camera information collecting. Chapter 3.4.1 and 3.4.2 provide a close-up image of the operations that need to be done in order to make the car “see”. Fig 2. System block diagram 2.2  Hardware Validation Steps    After connecting all the hardware modules, connect a USB cable to the PC. Connect other end of USB cable to mini-B port on FRDM-KEA at J7. When powered through USB, LEDs D2 and D3 should light green like in the picture below. Also, once the S32K144 board is recognized, it should appear as a mass storage device in your PC with the name EVB-S32K144.        Fig 3. LEDs to validate the correct setup 3. Model-Based Design Application 3.1  Application Description    The Model-Based Design approach consists of a visual way of programming, which is based on blocks. A block implements a certain functionality, such as adding two numbers. In case of the NXP's Model-Based Design Toolbox which is specifically developed for the S32K14x family, a block implements a functionality of a MCU peripheral, such as turning on the green led on the board. Each block has a different functionality and for a complex application, multiple components should be used together so they can provide the best solution for the problem proposed. For example, if you want to toggle the green led at every 10 seconds, you are going to add a new block to your design, one that can count those 10 seconds and then trigger an action when the count is over, which is toggling the led. Connection between the blocks should be made accordingly to your application system model. When building the model, the code that stands behind the blocks and implements the connection logic between them is automatically generated and downloaded on the embedded target. Doing so, code errors are certainly eliminated, and a faster design process is accomplished.    For using the Model-Based Design Toolbox for S32K, the MATLAB programming platform should be installed on the PC you are working on. Make sure that you respect all the System Requirements that you can find on the following link (Model Based Design Toolbox). Follow the installation steps from the Install and Configuration Steps and now you are ready to develop your own model-based design application.           3.2  Application Scheme    The generated code from the Simulink model is downloaded on the S32K144 MCU. A mapping between hardware and software for this application is illustrated in the figure below: Fig 4. Hardware to software mapping    The hardware components are controlled by the application through the peripheral functions of the S32K144 MCU. This board is connected to the other hardware modules by using an adapter board. In the link NXP Cup Development Kit there are information regarding how to connect the camera, servo and motors modules on the System and Driver Boards. Thus, the software generated signals are transmitted to the modules that need to be configured and controlled (camera, servo, motors). Fig 5. Application Scheme    When you open the Simulink model, this structure shown in Fig. 6 will be displayed. The functionalities are grouped in areas, which area containing a small description of what it is computed inside it. There are blocks and connections between them like mentioned before. Based on the image given by the camera, the steering and the speed of the car should be controlled. More details about how each of the subsystems works are provided in the following chapters. Fig 6. Simulink top level system 3.3 Application Logic    The application logic is described by the following block diagram. The signal from the camera is converted and the data is stored in an array. Based on the elements of the array (description of the image in front of the car), an algorithm will compute how much does the car have to steer its front wheels. This is expressed in a duty cycle value of a signal, signal which will be directly transmitted to the servo module. A constant speed, 10% of the maximum reachable of the car, it is also given as a duty cycle of the signal which will control the two rear motors. Fig 7. Application logic diagram   3.4 Simulink Model Components 3.4.1 Camera Configuration                 The camera module has a major importance in the project, because it is used to scan and process the track in front of the car. Firstly, for the main purpose of the application: control the car and maintain its position on the desired direction, the camera module should be configured so it can receive the analog signal properly. After the camera receives the analog signal, the application converts it into 128 digital values on the basis of which control decisions will be taken. There are 128 digital values for a conversion because the line scan camera module consists of a linear sensor array of 128 pixels and an adjustable lens. As specified in the datasheet, for the camera module configuration, two signals must be generated, a clock and a serial input (CLK and SI). Fig 8. Waveforms for camera configuration    To validate the functionality of this module, you should open the FreeMaster and check that the camera is working properly. Open the .pmp file and watch the conv variable evolving on the recorder. Put a white paper in front of your camera and then move an object in front of it. Every time the camera spots a dark color, its graphical evolution presents easy observable dips like in the picture below (blue graphic).                                                                                      Fig 9. Dips caused by dark objects CLK Signal    For the CLK signal generation, a FTM (FlexTimer) block is used. This block generates a PWM signal with a duty cycle given as an input (DTC – Dutcy Cycle Camera). The duty cycle has to be 0.5 (50%) as specified in the datasheet. The PWM signal is then passed to the corresponding pin of the camera module through the S32K144 board.    Check the Landzo_car pins to S32K144EVB file for the mapping and connections.     The frequency of the clock signal was chosen considering the imposed value range in the datasheet. (fclock between 5 and 2000 kHz).       Fig 10. Generating the CLK signal      When configuring the FTM block, the following block parameters will be available:                    Fig 11. FTM block parameters    The FTM functionality has 4 different modules, each of them with 8 channels grouped in pairs (for each channel an output pin can be selected). After checking the Landzo_car pins to S32K144EVB file for the corresponding pin of the camera CLK, the choice of the FTM module and the pair should be done (FTM0_CH1 means that the pin is connected to the FTM0 module, pair 0-1). It should also be mentioned that the camera module is connected on the CCD1 interface of the System Board in the hardware setup of this application. Another linear interface CCD2 is available for user usage, as specified in the description of the development kit. The frequency of the signal can also be set from the editbox in the Frequency Settings groupbox. An initial duty cycle value equal to 0.5 was set according to the datasheet.    There are two operation modes for each pair of channels and they can be chosen from the popup box next to the pair selection. These modes are called independent and complementary. Let’s give them a short description.    By setting channel n in the Complementary mode, the output for the channel n+1 will be the inverse of the channel n output and the block will have only one input. In the Independent mode, the channels have independent outputs, each one depending on the duty cycle given as an input on that channel (2 inputs for the block in this case). The CLK signal of the camera is transmitted to a single pin of the hardware module, so there is no need for two channels to be configured. Only one is enough to output the desired waveform (in complementary mode, only the first channel of a pair will be set; ex: channel 0, channel 2, channel 4, channel 6). That is why the Complementary option is chosen in this case. The input will be the 50% duty cycle on the basis of which the CLK signal will be generated. The channel 7 will now be the inverse of the channel 6 but in the next picture it can be observed that the channel 7 does not have a pin to output the signal to, because the inverted CLK signal is not needed in the current application.                   Fig 12. FTM output signals SI Signal      The SI signal’s period must provide enough time for 129 CLK cycles, as the timing requires (datasheet). 129 CLK cycles are needed with the purpose of acquiring 128 samples of the analog signal received by the camera. In order to meet all the specified conditions for a normal operation mode, the algorithm to create the CLK and SI waveforms as required uses two Periodic Interrupt Timers (PIT) blocks. Fig 13. PIT blocks    An interrupt represents a signal transmitted to the processor by hardware or software indicating an important event that needs immediate attention. The processor responds to this signal by suspending its current activities, saving its state and executing a function called an interrupt handler to deal with the event. The interruption is temporary, and, after the interrupt handler finishes, the processor resumes its normal activities.    A PIT block is used to trigger an interrupt handler to execute at every timeout of a counter. The Function-Call Subsystems linked to the PIT blocks represent the actions inside the interrupt handler. The interrupt handler will be triggered every Period(us). For the first PIT, it will be triggered every 20000us and for the second one every 100us. This means that every time the counter reaches the value specified in the block configuration parameters, the Function-Call Subsystem is triggered, the actions inside of it executed and the counter reinitialized. Fig 14. PIT block parameters    The PIT functionality has 4 channels, and they are implemented based on independent counters. The channel 0 is not available for user usage because it is configured to trigger the execution of the entire model at every period of time specified in the model configuration parameters.    The last checkbox from the block parameters is used to start the counter immediately after the application initialization, without waiting for other events.    Considering all the information mentioned above, the timing of creating the waveforms as required involves the following actions:      at every 100µs (CLK signal’s period) the next things happen: Fig 15. Actions in the 100us interrupt           C variable, which counts the clock cycles, is incremented; If C >=2, the SI signal is turned from high to low. (value 2 was chosen to keep the SI signal high for the convenient amount of time as specified by the tw, tsu, th and ts parameters. Their values can be found in the datasheet)                    Fig 16. Timing for camera configuration    A GPIO (General Purpose Input/Output) block is used for this and its role is to send the value given as an input to the selected pin which can be selected from the dropdown menu available in the block configuration parameters). Fig 17. Setting SI signal LOW Fig 18. GPIO block parameters A conversion is started and if C < 128, the converted values (analog-digital conversion of the received signal from the camera) are stored in an array of 128 elements (Store the converted values into an array subsystem is triggered) and into the conv array. Conv variable is used for the debugging process which will be later detailed.          at every 20ms (SI signal’s period) the next things happen:        SI signal is turned from low to high using the same GPIO functionality;       The clock cycles counter C is reinitialized;             Based on the  values of the array (high values for white, low values for dark) and on their indexes, the duty cycle ( DTS   – Duty Cycle Servo) which controls the              Servo is computed (it controls the car to turn left or right with a certain angle); Fig 19. Actions in the 20ms interrupt 3.4.2 Camera Reading    After the camera module is configured (SI and CLK signals generated as specified), the data acquisition can be started. The signal given by the camera is converted into digital values which are stored in an array. The conversion implies the usage of the ADC (Analog to Digital Converter) functionality. Taking this into consideration, a configuration block for the ADC should be added to the Simulink model.         Fig 20. ADC configuration block    The ADC of the S32K144 has two modules (ADC0, ADC1) each of them with up to 16 external analog input channels and up to 12-bit conversion resolution. The camera module is connected to the CCD 1 linear interface of the System Board. The Landzo_car pins to S32K144EVB file specifies that the pin of the camera module which receives the analog signal is ADC1_CH10, so the ADC 1 module should be configured. A 12-bit conversion resolution was chosen for improving the accuracy of the sampled data.     An analog to digital conversion should happen every 100us as specified in the Timing section, because 128 samples of the input signal need to be acquired (every time the C variable is incremented, a value should be stored in the conversion array). Fig 21. Start of conversion    Considering the facts mentioned in the previous paragraph, every time the subsystem of the PIT block is triggered, the conversion is started (an ADC Start block is used) and if C < 128 the sampled data is stored into the array that will consist the information on which basis the servo control decision will be taken. Variable C is the index of the array elements and each result of the conversion represents the value of an element. Following this algorithm, the Y array is created and it is going to be used in the next chapter where the algorithm which computes how much the car should steer, based on the image of the track in front of it, is described. For putting the values into the array an assignment block is used. Fig 22. Storing conversion values to Y array     3.4.3 Camera To Steering Algorithm    The algorithm presents a basic approach and uses an if-else logic. Before giving it a short description, a couple of things should be mentioned.   Considering the reference voltage of the ADC module of the microcontroller which is 5V and the 12 bit resolution of the conversion, the resolution on a quantum is 5 / 4095. But the camera is powered by a voltage approximately equal to 3.4V, thus resulting a value which varies around 3.4 / ( 5/4095) = 2785. This value is the maximum that the ADC can provide when the camera spots white in front of it. The light conditions in the room represent a major factor that contributes to variations of this value.   The Servo of this kit needs a 20ms period PWM signal with the pulses duration equal to 600µs for a neutral position of the wheels, 400µs for the wheels turned maximum left, and 800µs maximum right. This results in the following values for the duty cycle (0.03 - the car goes forward, 0.02 – the car turns maximum right, 0.04 – the car turns maximum left). The 0.02 value should be replaced by 0.023 in order to obtain a proper operation mode due to the servo’s construction particularities.      The array with the converted values (Y) is iterated. If a dark value is found (the difference between ‘maximum white’ and the value of the current element is bigger than a threshold), the duty cycle is computed to determine how much right or how much left the front wheels should turn. If a dark value is spotted in the first half of the array, the car should turn right, or left if found in the other. But the camera gives the image from right to left so the turning ways are opposite (left if a dark value is spotted in the first half of the array, right for the second one).    After determining the way of the steering, left or right, the DTS is computed proportionally with the index of the array where a dark value is found. If a value representing a dark color is spotted at the beginning or at the ending of the array, it means that the what needs to be avoided is not exactly in front of the car, but more to one side of it, so a steering with a small angle should be effective in order to keep the car on the runway. On the other hand, if a small value is found more to the middle of the array, a wider angle of steering should be computed in order to ensure the avoidance of the dark color and the car moving off the track.     Fig 23. Matlab function for computing the DTS 3.4.4 Set The Servo    The DTS is then passed to another FTM_PWM_Config block to generate the signal needed to control the Servo.       Fig 24. FTM block for controlling the servo      In order to do so, the block should be configured with the following parameters, which have the same signification as mentioned in chapter 3.4.1:                 Fig 25. FTM block parameters    According to the hardware connections from the S32K adapter board and the current setup, only one Servomotor is used, and this is the STEERINGPWM1 mentioned in the file with the mapping between the Landzo car pins and the S32K144 board. The allocated peripheral for this module is the FTM0_CH1, which means that the module 0 should be chosen from the configuration parameters together with the 0-1 pair of channels. To control the servo, only one signal is needed, so there is no need to use 2 channels. The complementary mode could have been used here, like in the camera CLK signal configuration, but doing so, only the configuration of channel 0 would have been possible and channel 1 is requested for the application. By choosing the independent mode, a duty cycle input will be available for the both channels of the pair, and because only channel 1 is needed for the control of this module, an input equal to 0 will be given to the other one. The frequency is set to 50Hz considering the motor construction particularities and a duty cycle equal to 0.03 (wheels not steered) is set as an initial value.     Fig 26. FTM output signals 3.4.5 Set The Motors    For the two rear motors, the same principle applies. The duty cycle (DT) is configured by default at the 0.1 value which will cause the car to move along the track with 10% of its maximum speed.     The frequency of the PWM signal that controls the motors is 5000Hz. This value is in the range specified in the datasheet of the motor drivers mentioned in the schematics.                 Fig 27. FTM block for controlling the traction motors     For the control of a single motor, two signals are needed. The schematics of the Motor Driver board indicate that for the control of each motor two integrated circuits are used (BTN7960). They form an H bridge which looks as in the picture below.                 Fig 28. H bridge    To make the motor spin, the potential difference of the points the motor is connected between must be different from 0. It can be observed that each integrated circuit needs an input signal. The pins that give the input signals to the circuits are corresponding to the output channels of the FTM block. Let’s take for example the 1st rear motor. It is controlled by a FTM Config block which outputs on the following channels.                     Fig 29. FTM output signals    By setting and keeping channel 3 of the FTM Config block channels to 0, an input equal to 0 will be transmitted to one of the BTN modules as an input on the IN pin (for example, to the right one). This will trigger the right lower transistor to act like a closed switch. The transistor above it will remain opened, so the voltage of the OUT point will be 0V. The channel 2 corresponds to the other integrated circuit, and a positive input will be received by this one on the IN pin (left side of the picture). Now, the left upper transistor will act like a closed switch, and the one below will remain open, making the OUT point’s potential to represent a positive value (depending on the duty cycle given as an input to the FTM block). Thus, a potential difference is created and the motor will start spinning. 3.4.6 Configuration Block    In addition to all these, the model needs also a configuration block which is used to configure the target MCU, the compiler, the system clock frequency, etc. A configuration block is needed in all the models because it ensures the communication with the target. Fig 30. Model configuration block    The operation frequency can be chosen from the MCU tab of the block parameters window. For this model, it was set at 80Hz. The board model, the SRAM and the clock frequency can also be set from the MCU tab. Fig 31. Configuration block MCU tab    If you want to change the compiler and also the optimization levels, click the Build Toolchain tab and take a look at the available options presented in the picture below. From this tab you can also choose the target memory for the model which can be FLASH or SRAM.                   Fig 32. Configuration block Build Toolchain tab    The application is downloaded on the target through OpenSDA. OpenSDA is an open standard serial and debug adapter. It bridges serial and debug communications between a USB host and an embedded target processor. Make sure that the Download Code after Build option is checked in order to see your application running on the target.                   Fig 33. Configuration block Target Connection tab    For additional information about the blocks used in this model, right-click on them and choose the ‘Help’ option available in the menu. 4. How To Debug The Application Using FreeMaster    In order to use FreeMaster for debugging and managing the information from your application, a FreeMaster configuration block must be used in the Simulink model. Fig 34. FreeMaster configuration block    The block parameters should be configured as in the following picture: Fig 35. FreeMaster configuration block parameters    The interface field specifies the communication interface between the application and the FreeMaster. LPUART1 is chosen in this example because it is directly connected to the OpenSDA. OpenSDA is an open standard serial and debug adapter. It bridges serial and debug communications between a USB host and an embedded target processor.    The BaudRate represents the speed of data transmission between the application and the FreeMaster and it is expressed in kbps. The receive data pin and the transmit data pin should be always configured to PTC6, respectively PTC7 (for the LPUART1 interface) because these pins are connected to the OpenSDA Receive and Transmit pins, as specified in the HMI Mapping.       Fig 36. OpenSDA to LPUART1 connection    By clicking the Show Advanced Options checkbox, multiple settings are available and their functionalities are all specified in the Help file which will open after clicking the Help button in the Block Parameters tab.    The variables that need to be observed changing over time must be declared Volatile. The variables already added to the FreeMaster project are declared using the Data Store Memory block.                 Fig 37. Global Variables    The Volatile option can be chosen from the Block Parameters Tab. After double clicking the Data Store Memory block, click the Signal Attributes tab and in the Code Generation groupbox, set the Storage Class option to Volatile (Custom), as in the picture below.  Fig 38. Data store memory block parameters    For calling the FreeMaster data acquisition each time a subsystem is triggered, a FreeMaster Recorder Call block should be added in the subsystem where the variables that you want to record are computed. Thus, a recorder block is placed in the subsystem which is triggered at 100us for recording the evolution of C and conv variables. Fig 39. FreeMaster recorder call    To check the functionality of the FreeMASTER, open the .pmp file with the same name as the Simulink model and click on the red STOP button in order to initialize the communication with the S32K144 evaluation board. Fig 40. Start/Stop FreeMaster communication    If errors appear, click on the Project menu and open the Options window. Make sure that the port value is the same as the one on which your S32K144 is connected (you can check the COM number of the evaluation board in the Device Manager window). Make sure also that the Speed is the same as the baud rate of the FreeMaster Config block.       Fig 41. FreeMaster communication setup    Click on the MAP Files tab and ensure that the default symbol file is the .elf file from the folder that is created when you build your Simulink model. It should be called (your_model_name.elf).           Fig 42. FreeMaster .elf file    Once the connection is set and the app working, you will observe how the values of the variables in the Variable Watch are changing.    Click on the Recorder option from the left side of the window in order to see the graphical evolution of the variables.    You can add or remove variables from the watch by right-clicking inside the Variable Watch area and choosing the Watch Properties options.    Right clicking on the Recorder will provide a Properties option as well. Use that for selecting the variables that you want to display and for many other options.           Fig 43. FreeMaster recorder properties 5. Autonomous Intelligent Car Demonstration And Hints For Improvement 5.1 Demo    If you want to make sure that everything works as it is supposed to before actually putting the car on the track, you can use the FreeMaster tool to visualize the evolution of the variables of your project. Considering every setup was made as specified, here is what you should expect to see. Fig 44. Variable Watch    The two rear motors duty cycle and also the one for the camera CLK signal should have constant values all the time (0.1 respectively 0.5). The DTS should vary its values between 0.023 and 0.04 as mentioned in the Camera to Steer algorithm chapter. C variable must be incremented every 100us and reset every 20ms, this meaning that when it reaches 200, it should be set back at 0. This evolution can also be graphically observed by using the recorder option. Conv variable and Y array represent the conversion result and all the bottoms of the conv graphical evolution represent the existence of a dark color in the visual field of the car.    A demonstration video with the car following the track for a lap is attached to the current content.   5.2 Improvement Areas    The application proposed uses a basic if-else algorithm in order to compute the steering of the front wheels based on the track in front of the car. A proof of the concept that the vehicle can be controlled and kept on the path using a S32K144 board and a Model Based Design approach is realized in the presented solution. Major improvements regarding the lap time could be achieved by developing a way to control also the car speed which now is at a constant value. Many other hardware and software solutions can be designed and implemented with the purpose of obtaining the fastest autonomous self driving car for the NXP Cup. NXP CUP - LINE FOLLOWER WITH MODEL-BASED DESIGN TOOLBOX FOR S32K MICROPROCESSOR
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
This video is part of the Module 7: Torque Control   Workshop module and shows how to implement a FOC and control the PMSM torque and flux using standard PI controllers. This method is used to spin the PMSM in open loop using Space Vector Modulation. The video shows how to implement a control system with two control loops: FAST and SLOW
View full article