S32K ナレッジベース

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

S32K Knowledge Base

ラベル

ディスカッション

ソート順:
*All of the source code placed is for example use only. Document listed is only for your information only. NXP does not accept liability for use of this code or document in the user’s application. Map: https://bra.in/3vGE9q Resource: My Brain (thebrain.com) Links Community relative for S32K S32K S32DS: S32 Design Studio S32K SDK: S32 SDK S32K Safety: SafeAssure NDA Model-based Design: NXP Model-Based Design Tools Documentation Reference Manual Rev12.1 Data Sheet Rev12 Hardware Design Guide: AN5426, Hardware Design Guidelines for S32K1xx Microcontrollers  (REV 4)  Errata Application Note Tool & Software Design & Solution  S32DS IDE for ARM S32k1: S32 Design Studio IDE for Arm® based MCUs | NXP   S32SDK for ARM S32K1: Automotive S32 SDK for Arm® devices | NXP  Embedded Software Unified Bootloader Framework Unified bootloader stack based on UDS and CAN/LIN TP protocol. AUTOSAR MCAL Tips/FAQ  Safety Process to apply access to Safety Docs and Support: Functional Safety documents AVAILABLE | Require access to the SafeAssure NDA group S32K Safety Enablement: https://community.nxp.com/t5/S32K/S32K-safety-documents-and-demo-code-with-SDK/m-p/1156735#M8231 Hard Fault Fault handling on S32K144  AN12522, S32K1xx ECC Error Handling – Application note  (REV 0) S32K1xx系列MCU的常见内核异常(Fault Exception)及处理详解(以S32K144为例介绍) [FAQ] AUTOSAR MCAL   Where can I find compiler and compiler option info for specific MCAL package? Can I use different compiler version or compiler options for specific MCAL package? Where can I download MCAL package? How to get latest MCAL HF version from your NXP website account if you have already registered and applied MCAL SW package. What does HF(Hot Fix) mean? Can we use it for production? How to calculate current (power consumption) of S32K? S32K Power Estimation Tool (PET) released Enwei Hu 公众号 "汽车电子expert成长之路"原创: 历史文章分类列表目录(点击文章标题直接跳转,截止2020年4月20日)  1. 汽车电子ECU bootloader开发系列 汽车电子ECU bootloader开发要点详解 汽车电子ECU bootloader开发之S32K1xx系列MCU NVM驱动独立安全bootloader开发详解 S32K1xx ECU bootloader开发之RAM NVM驱动(S19文件)生成与集成调用和测试详解 汽车电子ECU bootloader开发之S32K144的CAN bootloader开发详解(工程源代码开源供大家参考) 汽车电子ECU bootloader开发开发之S32K1xx系列MCU bootloader开发要点详解 汽车电子ECU BootLoader开发之基于CAN总线通信的MPC574xP系列MCU bootloader开发详解 汽车电子ECU BootLoader开发之基于CAN总线通信的S12(X) 系列MCU独立NVM驱动安全bootloader  浅谈嵌入式软件开发之Qorivva MPC57xx和S32R系列多核MCU启动配置与bootloader开发要点详解 Qorivva MPC56xx系列MCU启动过程全解析(基于CW IDE应用工程--EAB I、链接文件、启动文件和map文件) 浅谈嵌入式MCU软件开发之startup过程详解(从复位向量到main函数之前的准备工作) 浅谈嵌入式MCU软件开发之S32K1xx系列MCU启动过程及重映射代码到RAM中运行方法详解 CodeWarrior IDE使用Tips之利用prm链接文件实现储存器数据填充和代码编译结果CRC校验和自动生成详解 汽车电子ECU BootLoader开发系列相关文章链接与资源汇总; 2. 浅谈嵌入式MCU软硬件开发系列 浅谈嵌入式MCU开发中的三个常见误区 浅谈嵌入式 MCU 软件开发之应用工程的堆与栈 浅谈嵌入式MCU软件开发之中断优先级与中断嵌套 浅谈嵌入式MCU软件开发之代码风格与代码优化 深入浅出谈嵌入式MCU 内核之ARM Cortex-M系列CPU内核功能特性概述与对比(强烈推荐!!!) 浅谈嵌入式MCU软件开发之内存分配详解--链接文件与map文件中段的分配使用和使用注意事项 浅谈嵌入式MCU硬件设计之MCU最小系统电路 浅谈嵌入式MCU软件开发之startup过程详解(从复位向量到main函数之前的准备工作) 浅谈嵌入式MCU软件开发之S32K1xx系列MCU启动过程及重映射代码到RAM中运行方法详解 浅谈嵌入式MCU软件开发之S32K1xx系列MCU CPU内核性能优化方法详解 浅谈嵌入式软件开发之Qorivva MPC57xx和S32R系列多核MCU启动配置与bootloader开发要点详解 浅谈嵌入式系统软件开发之S32K1xx系列MCU的MPU配置与使用详解 浅谈嵌入式软件开发之MagniV S12Z系列MCU内核Machine Exception异常原理与恢复 浅谈嵌入式软件开发之重定向标准输入输出设备使用printf()函数格式化输出调试信息(基于S32DS IDE和MPC5744P) 浅谈嵌入式MCU软件开发之startup过程详解(在CodeWarrior 5.1 中实现RAM自定义初始化) 嵌入式软件开发之S12(X)系列MCU的far和near函数指针调用详解(S12G128 CW 5.x Project) 浅谈嵌入式MCU软件开发之S12(X)系列MCU 中断ISR在CodeWarrior 5.1 IDE 中的三种写法 浅谈嵌入式软件开发之Qorivva MPC56/57xx系列MCU的Power e200内核寄存器功能和内核调试技巧介绍 嵌入式软件开发之调试器(Debugger)使用--PEMicro Multilink功能介绍与使用FAQ 浅谈嵌入式MCU软件开发之MCU芯片内部Bandgap参考电压(带隙基准)和集成温度传感器的工作原理和使用详解 浅谈嵌入式MCU软件开发之条件断点的设置与使用详解(以S32DS IDE + U-Multink debugger为例介绍) 浅谈嵌入式软件开发之使用Srecord工具实现S19文件数据填充和CRC校验和自动计算与存储方法详解 浅谈嵌入式MCU软件开发之使用makefile脚本编译和调试NXP S32 SDK应用工程详解 3. 外设使用Tips系列 S32K1xx系列MCU使用Tips之SDK软件架构和使用详解 S12(X)系列MCU的片上存储器资源与分页访问机制详解(一) S12(X)系列MCU的片上存储器资源与分页访问机制详解(二) S12(X)系列MCU的加密(Secure)原理和解密(Unsecure)方法 Qorivva MPC56xx系列MCU的Flash加密解密原理与工程实现方法详解 使用 Cyclone 离线编程器对 S12(X)和 MagniV S12Z 系列 MCU 片上 NVM 编程  S32K1xx系列MCU使用Tips--功能介绍及软件开发和硬件设计FAQ  S32K1xx系列MCU使用Tips--Flash加密后不断复位无法连接调试器的问题解决 S32K14x系列MCU使用Tips之硬件FPU特性介绍和使用详解 外设使用Tips之Qorivva MPC56xx_57xx系列MCU内核异常(IVORx)与IRQ中断处理详解 外设使用Tips之Qorivva MPC56xx/57xx系列MCU的模式控制与切换(片上外设资源使能与功耗控制) 外设使用Tips之MCU内部集成IRC时钟工作原理、特性和trim原理及方法详解(以KEA系列MCU的ICS为例) 外设使用Tips之S12G系列MCU Startup之前的复位过程详解(COP看门狗复位和时钟监测复位中断识别与处理)  外设使用Tips之MPC57xx系列MCU C55 Flash模块详解及其SSD(标准软件驱动)使用 外设使用Tips之MSCAN接收ID滤波器设置 外设使用Tips之TIM定时器使用FAQ和使用经验 外设使用Tips之MPC574xP系列汽车级MCU的SWT看门狗定时器配置与使用 NXP汽车MCU开发详解之KEA系列汽车MCU开发指南 S32K1xx系列MCU应用指南之芯片锁死(lockup)复位原因分析与恢复方法详解 关于使用J-LINK开发S32K1xx系列MCU应用程序的使用说明和注意事项 NXP S12G_XE系列汽车MCU软件开发指南 资料分享--S12XE 系列MCU XGATE协处理器开发常见问题(Q&A) S32K1xx系列MCU应用指南之相同封装不同型号(part number)间相互替换的软件与硬件设计注意事项 4. S32K SDK使用详解系列 S32K SDK使用详解之S32 SDK软件编程思想详解 S32K SDK使用详解之S32 SDK软件架构详解 S32K SDK使用详解之Keil MDK开发S32K1xx系列MCU应用程序(使用Processor Expert配置SDK) S32K SDK使用详解之GHS Multi(Eclipse插件)开发S32K1xx系列MCU应用程序(使用PE配置SDK) 浅谈嵌入式MCU软件开发之使用makefile脚本编译和调试NXP S32 SDK应用工程详解 浅谈嵌入式MCU软件开发之S32K1xx系列MCU CPU内核性能优化方法详解 S32DS GNU GCC编译优化选项与配置方法详解及S32 SDK代码编译优化选项设置建议 S32K系列MCU应用开发详解直播ppt高清pdf版本下载与直播视频回放链接 S32DS使用Tips--SDK使用常见问题(FAQ)答疑 S32K SDK使用详解之interrupt_manager组件配置与使用详解 S32K SDK使用详解之Flash驱动组件使用(FTFC Flash控制器功能详解与使用FAQ & Tips) S32K SDK使用详解之PinSettings组件配置与使用详解(S32K1xx PORT 和GPIO模块) 5. S32K1xx应用指南系列 S32K1xx系列MCU的常见内核异常(Fault Exception)及处理详解(以S32K144为例介绍) S32K1xx系列MCU应用指南之芯片锁死(lockup)复位原因分析与恢复方法详解 S32K1xx系列MCU的EEE(Emulated EEPROM)使用详解 S32K1xx系列MCU应用指南之FlexIO和CSEc硬件加密模块的使用详解 S32K1xx系列MCU应用指南之WDOG看门狗模块使用详解 S32K1xx系列MCU应用指南之存储器ECC功能使用详解(一) S32K1xx系列MCU应用指南之存储器ECC功能使用详解(二) S32K1xx系列MCU应用指南之RTC模块使用详解 S32K1xx系列MCU应用开发指南之IAR toolchain样例工程及使用常见问题(FAQ) S32K1xx系列MCU的低功耗实现要点详解(基于S32K144 EVB-Q100x Rev C测试) 6. 细说汽车电子通信总线系列 细说汽车电子通信总线之CAN 2.0 总线协议详解 细说汽车电子通信总线之CAN-FD 总线协议详解 细说汽车电子通信总线之LIN总线协议详解 细说汽车电子通信总线之常见汽车电子串行通信总线(CAN、LIN、DSI、ISO-9141、SWCAN、J 1850)对比 7. S32DS IDE使用Tips系列 S32DS使用Tips--S32DS for Power V1.2 链接文件和启动过程详解 S32K1xx系列MCU使用Tips之SDK软件架构和使用详解 S32DS GNU GCC编译优化选项与配置方法详解及S32 SDK代码编译优化选项设置建议 S32DS IDE使用Tips--应用程序开发实战实用技巧总结与详解(工欲善其事必先利其器) S32DS使用Tips--SDK使用常见问题(FAQ)答疑 S32DS IDE使用Tips--应用工程调试常见问题(FAQ)答疑 S32DS IDE使用Tips之Classic CW(2.10)和EclipseCW(10.x和11.x)应用工程移植指南 S32DS 使用Tips之S32DS for Power不同版本之间的GNU工具链差异与外设寄存器位域访问问题总结 S32DS使用Tips之S32DS for Power v1.1应用工程升级到v1.2重新编译运行程序跑飞问题解决 S32DS 使用tips--S32DS for ARM v1.3工程到S32DS for ARM V2.0迁移升级方法和注意事项 S32DS 使用 tips--工程属性配置(编译选项和C编译器、汇编器及链接器设置) S32DS使用Tips--如何编译生成和调用静态库 S32DS使用Tips--如何通过创建新的编译目标(Build Target)在同一个S32DS工程中同时编译静态库和应用程序 S32DS使用Tips--如何配置和使能Attach功能定位软件程序bug和完成bootloader与应用程序工程的联合调试 CodeWarrior与S32DS IDE使用 Tips之如何在应用工程中保留定义但未使用的全局常量、变量(用于参数标定) S32DS 使用 tips--使用Flash from file下载S19或elf文件 S32DS for ARM v2018.R1安装IAR Eclipse插件调用IAR工具链开发S32K系列MCU应用程序详解 浅谈嵌入式MCU软件开发之条件断点的设置与使用详解(以S32DS IDE + U-Multink debugger为例介绍) S32DS IDE使用Tips之配置objcopy选项生成S3行的S19文件和指定每行S19文件的最大数据长度的方法和步骤详解 8. CodeWarrior IDE使用Tips系列 CodeWarrior IDE使用tips之bug定位绝技--hotsync与attach调试 CodeWarrior IDE使用Tips之Qorivva MPC56xx新建应用工程选项、调试高级选项及下载过程控脚本详解 CodeWarrior IDE使用tips之prm链接文件详解(自定义存储器分区以及自定义RAM数据初始化与在RAM中运行函数) CodeWarrior IDE使用Tips-Qorivva MPC56xx应用工程map文件全解析(CW 2.10/10.x ) CodeWarrior IDE使用tips之map文件详解 CodeWarrior IDE 版本选择与 License功能(feature)和价格,授权形式差异、激活方法与安装使用 答疑解惑之Win10操作系统中CodeWarrior IDE USB dongle  license安装问题解决方法详解 CodeWarrior IDE使用Tips之利用Hiwave读取S12(X)系列MCU片上NVM命令脚本(CW 5.x IDE) CodeWarrior IDE使用Tips-如何编译生成和调用静态库 CodeWarrior与S32DS IDE使用 Tips之如何在应用工程中保留定义但未使用的全局常量、变量(用于参数标定) CodeWarrior IDE使用Tips之如何通过prm文件指定汇编代码函数、全局变量和常量的储存地址 CodeWarrior IDE使用Tips之利用prm链接文件实现储存器数据填充和代码编译结果CRC校验和自动生成详解 CodeWarrior IDE使用Tips之burner工具使用详解(实现不同类型存储器地址间的转换和NVM编程格式文件的输出) CodeWarrior IDE使用Tips--使用burner将elf文件转换生成HEX和BIN文件的方法和步骤详解 CodeWarrior IDE使用Tips之利用Hiwave读取S12(X)系列MCU片上NVM命令脚本(CW 5.x IDE) S32DS IDE使用Tips之Classic CW(2.10)和EclipseCW(10.x和11.x)应用工程移植指南 9.   汽车ECU参数标定系列 汽车ECU参数标定之配置e200系列CPU内核MMU实现Qorivva MPC56xx_57xx系列MCU的参数在线实时标定 汽车ECU参数标定之配置Overlay RAM实现Qorivva MPC57xx系列MCU参数在线标定和代码重映射原理和方法详解 CodeWarrior IDE使用Tips之如何通过prm文件指定汇编代码函数、全局变量和常量的储存地址 CodeWarrior与S32DS IDE使用 Tips之如何在应用工程中保留定义但未使用的全局常量、变量(用于参数标定) CodeWarrior IDE使用tips之prm链接文件详解(自定义存储器分区以及自定义RAM数据初始化与在RAM中运行函数) CodeWarrior IDE使用tips之map文件详解 S32DS使用Tips--S32DS for Power V1.2 链接文件和启动过程详解 10.  工欲善其事必先利其器系列 工欲善其事必先利其器之NXP汽车MCU系列产品家族(Family)功能特性及应用介绍 工欲善其事必先利其器之NXP汽车MCU开发资料和开发软件获取与使用指南 11.  答疑解惑系列 疑难答疑之S12G系列MCU使用Hiwave和BDM调试器debug时无法使用逻辑地址查看和保存P-flash问题的解决 疑难答疑之S32DS IDE调试启动过程详解与调试目标复位方法和步骤详解 答疑解惑之S12(X)系列MCU的CodeWarrior 5.x应用工程下载调试过程详解以及如何保护NVM存储器不被擦除 答疑解惑之Win10操作系统中CodeWarrior IDE USB dongle  license安装问题解决方法详解 12. 产线批量Flash编程与ESD/EOS保护系列 使用 Cyclone 离线编程器对 S12(X)和 MagniV S12Z 系列 MCU 片上 NVM 编程 使用Cyclone 离线编程器对S32K1系列MCU进行NVM(P-Flash, D-Flash和EEE)编程的方法与步骤详解 13.  其他 汽车电子expert成长之路微信公众号原创技术分享文章全集-2019年度精编版 汽车电子expert成长之路微信公众号原创技术分享文章集合2017~2018年 最新最全的NXP Techday和Connect(原Freescale FTF)技术培训资料下载链接 汽车以太网(100BASE-T1)转工业以太网(100BASE-TX)转换器工作原理介绍 使用关键词回复功能找到感兴趣的公众号原创技术文章    
記事全体を表示
******************************************************************************* The purpose of this demo application is to place variables in DTCM memory for the S32K3xx MCU.  ------------------------------------------------------------------------------ * Test HW: S32K3X4EVB-Q172 * MCU: S32K312 * Compiler: S32DS3.5 * SDK release: RTD 3.0.0 * Debugger: PE Micro * Target: internal_FLASH ******************************************************************************** ZERO table : is for bss segment variables :  contains RAM start & end address of BSS section which need to be initialized with ZER). Init_table : is for DATA segment variables : contains RAM start address of DATA section & START & end address of ROM address where the initialization values of the variables are stored.   Startup file startup_cm7.s call function init_data_bss() . Inside this function uses these section :-- Variables declared :-- Linker file changes :--   startup_cm7.s file changes :--   MAP file :--     Debug window results :--         https://www.kernel.org/doc/html/v5.9/arm/tcm.html   Due to being embedded inside the CPU, the TCM has a Harvard-architecture, so there is an ITCM (instruction TCM) and a DTCM (data TCM).  The DTCM can not contain any instructions, but the ITCM can actually contain data.   TCM is used for a few things: FIQ and other interrupt handlers that need deterministic timing and cannot wait for cache misses. Idle loops where all external RAM is set to self-refresh retention mode, so only on-chip RAM is accessible by the CPU and then we hang inside ITCM waiting for an interrupt. Other operations which implies shutting off or reconfiguring the external RAM controller.  
記事全体を表示
Customer may need more high performance via S32K3xx. How to optimization user's code?  As following have some suggestions:  1. Most of user code allocate to P-Flash and enable I-Cache 2. Allocate system stack to D-TCM and enable D-Cache 3. Execute code frequently allocate to I-TCM. E.g., ISRs etc. 4. OS' task stack allocate to D-TCM 5. vector table allocate to D-TCM Please note: 1. Due to enable D-Cache, other masters(E.g., DMA, HSE, another APP cores) access theses area of cacheable will be impact. So, theses area need to allocate to non-cacheable area. 2. If another master(E.g., DMA, HSE and another APP cores) access the D-TCM need to over back door. E.g., core1/DMA/HSE access core0' DTCM needed to over backdoor.  Information: S32K3' Coremark in RM, theses Coremark' value are from ARM. If used IAR/GHS etc and set compiler flag, then the Coremark value is very closely with RM. If used GCC, then the Coremark value will less than RM. BR Tomlin    
記事全体を表示
Audio Video Bridging(AVB) is a protocol for the transport of audio and video streams over Ethernet-based networks, which makes it possible to deliver high volumes of data in real-time to multiple destinations with very low latency. This reference design board demonstrates the usage for AVB over S32K148. Alternatively, it can be an S32K148 evaluation board of 100pin version besides S32K148EVB-Q144 and S32K148EVB-Q176. Below shows the board layout, diagram, and main features. Figure 1. S32K148AVB-RDB Layout   S32K148AVB-RDB Diagram(Rev B) Figure 2. S32K148AVB-RDB Diagram S32K148AVB-RDB Features Figure 3. S32K148AVB-RDB Features In terms of the software, we provide several examples to show the AVB/TSN usages and other applications. The avb_listener_talker project is the main example which implements most features and demonstrates by connecting 2 AVB boards by Ethernet cable.   Figure 4. S32K148AVB-RDB Code Examples Below software stack and middleware are implemented. ✓ RTOS: FreeRTOS ✓ Peripherial Driver: SDK RTM 3.0 (Work with Processer Expert) ✓ AVB Stream: RTM 1.0 ✓ AVB AudioIf: RTM 1.0 ✓ gPTP Stack Version: 1.3.4 ✓ Lwip Stack Version: 2.1.2 •Note: Even though we did a lot of tests, it’s still the customer’s responsibility to ensure the total quality by themselves when it’s integrated into a real application project, all the sample codes and user guide documentation are just reference for the customer. •Note: We do not have an FCC or CE certificate for this board.   Now we have 50 pcs boards available in Chongqing, China. For applying for the board, please contact NXP sales or GPIS marketing.  Since the AVB stack is not free of use, for accessing the code please contact NXP sales or GPIS marketing. For technical discussion, please contact Jeremy.he@nxp.com or Frankie.zeng@nxp.com.  
記事全体を表示
To accelerate S32K demand creation and support urgent evaluation requriement in Great China, we build one batch boards locally. These boards will only be given out to our potential opportunities for free. The boards are made by China local partner and verified by AE and FAE team. if you have any question on this kind of board, please go to China Auto CAS or Auto MCU marketing for support. 1. Board overview   2. Pinout 3. Test point 4. Block diagram 3. The main difference between NXP official S32K EVB and this FRDM-S32K144 board are OpenSDA firmware and CAN PHY The original OpenSDA firmware in this board is from MBED which is not supported by S32DS, thus we need to change to PEmicro OpenSDA firmware, and then we can use S32DS for development.   Unplug the USB cable (if attached). Press and hold the Reset button. Plug in a USB cable from a USB Host to the OpenSDA USB port. Release the RESET/Bootloader button. A removable drive will be visible in the host file system with a volume label of BOOTLOADER. Drag/drop or copy/paste attached firmware “DEBUG-FRDM-K64F_Pemicro_v108a_for_OpenSDA_v2.0.bin” into the removable drive. Unplug the USB cable and plug it in again. The OpenSDA application should now be running. The CAN physical is different. This board used standalone CAN PHY but not CAN SBC. Please refer SCH file for debug.   Original Attachment has been moved to: dmeo2.rar
記事全体を表示
You can find here a reference code for a march c software test in order to test RAM memories
記事全体を表示
This example code brief  :-- 1> Tested without the SL of BMS, so no dependency on the BMS Safety library. 2> Its tested on 2 AFE MC33774 board connected in TPL 3> Change following macro in mc33774_cfg.h file  to change the numbers of AFE connected in TPL. RTD : 3.0.0 P07 BMS SDK : 1.0.2 This example does this task :-- Application Measurement. SYNC measurement Periodic Measurement. Read AFE temperature. Cell balancing timer method. Reading the Cell balancing status register & fault registers. =================== Setup used ============ Attached code is tested with TWO MC33774 AFE connected in TPL mode.         =============== MCU Pins used =========== TPL1-TX :-- TPL1TXCSB  --> PTC6/LPSPI0_PCS1 TPL1TXSCLK --> TPL12TXCLK --> PTE1/LPSPI0_SCK    TPL1TXDATA --> TPL12TXDATA --> PTE2/LPSPI0_SOUT    TPL1-RX :-- TPL1RXCSB  --> PTB17/LPSPI1_PCS3 TPL1RXCLK  --> PTB14/LPSPI1_SCK TPL1RXDATA --> PTB15/LPSPI1_SIN     ================= EVB Link ================== https://www.nxp.com/design/design-center/development-boards-and-designs/18-cell-battery-pack-emulator-to-supply-mc33774-bcc-evbs:BATT-18EMULATOR https://www.nxp.com/design/design-center/development-boards-and-designs/analog-toolbox/evaluation-board-for-mc33664atl-isolated-network-high-speed-transceiver:FRDMDUALK3664EVB https://www.nxp.com/design/design-center/development-boards-and-designs/mc33774ata-evaluation-board-with-isolated-daisy-chain-communication:RD33774ADSTEVB https://www.nxp.com/design/design-center/development-boards-and-designs/automotive-development-platforms/s32k-mcu-platforms/s32k3x4evb-t172-evaluation-board-for-automotive-general-purpose:S32K3X4EVB-T172   ================== Measurement types used in example ===== Periodic measurement is done by 33774 , this is cyclic Other Two : application , sync  need send command to start Application measurement , need send app_capture command twice , and then read the result. Synchronous measurement take out the Primary adc result(VC)and secondary result(VB) .But the VC and VB result comes from different adc. Period measurement start when you send  API "MSR_StartMeasurement" and then 774 will do period measurement automatically periodically :--   Why we need to measure Vc & Vb both :-- ASIL-D ,yes we can measurement VC channel by primary ADC and measurement VB by secondary ADC from hardware VC and VB are come from same point of battery cell. Now 2 ADC compare with each other, that lead to high safety (ASIL D). Primary & Secondary Device temperature reading :-- This API is used for it MC33774_CDD_BCC_SWC_Running_Slot4(). ============= Cell Balancing =========== Cell Balancing method used :-- MC33774 balance will switch between odd channel (1,3,5,7,... 17) and even channel (2,4,6,8,..18) by 500ms period , (250ms for odd and then switch to even 250ms and then odd 250ms...)it is because of IC design and cannot change by software.   MC33774 have lots of balance method  this example uses "timer method ". How to check Balancing is enabled :-- Following function MC33774_CDD_BCC_SWC_Running_Slot5() read the : Balance status & fault registers BAL_SWITCH_STAT0, BAL_SWITCH_STAT1 represent the balancing MOSFET current status.   Measure the voltage drop across the balancing register is the best approach. You will see the voltage drop appears every 250ms if PWM is 100%.  Please check the schematic of the 33774 EVB, find the balancing resistor on which channel balancing is enabled.     ======= How much time to wait to extract the measurements results ======= 240 us is the time of one SCAN Time between each Application measurement sequence. Min App measure time for 16 sample :-- 4.08ms = (16+1) *240 Min 1 SYNC measurement time, for 16 samples = 18 cycle ≈ 18 * (16*240us) ≈ 69 ms ============= Using Debugger ============ Debugger breakpoint will cause the communication timeout at the AFE, which will RESET the AFE. To use the debugger while development you need to disable the communication timeout. In S32DS MEX file you cannot disable the timeout function ( limit the value of 0~255) Disable Communication timeout in code :--   ================= Results for FIRST AFE =========================== Application Measurement : Cell voltage result :-- SYNC measurement : VC, VB same for both primary & Secondary  measure :--      
記事全体を表示
[S32K3 Tools Part] How to port RTD's existing MCAL demo to other K3 chips  1. Abstract     From the release notes of NXP's RTD4.0.0, we can see that the supported chip models are very complete: Fig 1 From this point, we can know that RTD4.0.0 can cover all S32K3 series chips. But if you want a ready-made demo, such as MCAL demo, you can see it under the ready-made demo path, for example: C:\NXP\SW32K3_S32M27x_RTD_R21-11_4.0.0\eclipse\plugins\Dio_TS_T40D34M40I0R0\examples\EBT Just S32K344,S32K358,S32K388,S32K396,S32M276。 Therefore, if you use other S32 chips, such as K312, in actual use, although it is within the range supported by RTD, but there is no ready-made demo to use, you need to do the porting by yourself. This article will explain how to port the RTD4.0.0 K344 MCAL demo to S32K312 and configure the corresponding EB project. First, implement the execution in the command line. After success, port the working MCAL code EB project to S32DS. 2. Platform and migration steps 2.1 Platform Description This article is based on RTD4.0.0: SW32K3_S32M27x_RTD_R21-11_4.0.0 For other versions with patch or HF, the operation process is the same! Hardware platform: S32K312 mini EVB or S32K312EVB Other official EVBs, such as S32K31XEVB, or the customer's own S32K3 hardware board also have the same steps. Due to the lack of official EVB boards, this article is based on S32K312 mini EVB, combined with P&E Multilink simulator download simulation. The platform situation is as follows: Fig 2 2.2 Migration steps The reference demo can be any existing demo in RTD4.0.0. In order to simplify the process, this article takes DIO as an example: C:\NXP\SW32K3_S32M27x_RTD_R21-11_4.0.0\eclipse\plugins\Dio_TS_T40D34M40I0R0\examples\EBT\S32K3XX\Dio_Example_S32K344 2.2.1 Copy the project and configure 2.2.1.1 Copy the project In order not to affect the original RTD default demo, here we directly copy a Dio_TS_T40D34M40I0R0 and open the path: C:\NXP\SW32K3_S32M27x_RTD_R21-11_4.0.0\eclipse\plugins Copy Dio_TS_T40D34M40I0R0 and save it in a folder named: Dio_TS_T40D34M40I0R0_miniK312_doc The process for other chips is similar. You only need to change the chip name and related configuration to the required chip. Open folder: C:\NXP\SW32K3_S32M27x_RTD_R21-11_4.0.0\eclipse\plugins\Dio_TS_T40D34M40I0R0_miniK312_doc\examples\EBT\S32K3XX Copy Dio_Example_S32K344 to Dio_Example_S32K312 Fig 3    Open path: C:\NXP\SW32K3_S32M27x_RTD_R21-11_4.0.0\eclipse\plugins\Dio_TS_T40D34M40I0R0_miniK312_doc\examples\EBT\S32K3XX\Dio_Example_S32K312\TresosProject  Modify the EB project Dio_Example_S32K344 to Dio_Example_S32K312 Fig 4 2.2.1.2 Configure the project Enter the newly created Dio_Example_S32K312, open the path with VScode, and save the VScode workspace to this path. Modify project_parameters.mk: GCC_DIR = C:/NXP/S32DS.3.5_RTD400/S32DS/build_tools/gcc_v10.2/gcc-10.2-arm32-eabi TRESOS_DIR = C:/EB/tresos_29_0_0 PLUGINS_DIR = C:/NXP/SW32K3_S32M27x_RTD_R21-11_4.0.0/eclipse/plugins EXAMPLE_DERIVATIVE = S32K312 TRESO_PROJECT_NAME = Dio_Example_S32K312 ​ Fig 5 Fig 6 Check_build_params.mk, delete the following code: ifeq ("$(wildcard $(T32_DIR)/bin/windows/t32marm.exe)","") $(error Invalid path set to Trace32. \ The provided path: from project_parameters.mk T32_DIR=$(T32_DIR) is invalid!) endif This part is used for lauterbach trace32. If it is not deleted, an error will be reported. 2.2.2 EB project configuration The following is the configuration of the EB project. Open the EB tresos Studio 29.0 software and import the project. File->Import->General->Existing Projects into Workspace, add the EB project path: C:\NXP\SW32K3_S32M27x_RTD_R21-11_4.0.0\eclipse\plugins\Dio_TS_T40D34M40I0R0_miniK312_doc\examples\EBT\S32K3XX\Dio_Example_S32K312\TresosProject\Dio_Example_S32K312 Note, do not click copy projects into workspace!!! Select the project Dio_Example_S32K344, right-click the mouse, and rename it to: Dio_Example_S32K312 Fig 7 Double-click someId to open the configuration module. Open the Resource module, General->ResourceSubderivative select the target chip partbumber, here select: s32k312_hdqfp172 Fig 8 After saving, you will find many errors reported as follows: Fig 9 There is no need to worry too much here, because if you analyze it carefully, you will find that it is actually because there are many modules on K344 that K312 does not have. So enter the error prompt location and delete the missing K312 module. Mcu->McuModeSettingConf->McuPeripheral If you click in, you can find that if the K312 does not have a module, there is a red cross in front of the peripheral Name. Fig 10 The direct method is to delete all the error items, a total of 41. After deleting, you can find that all the problems are gone: Fig 11 Select someId in the project, right-click, and click Generate Code. You can see that the project can be generated without any errors. Fig12 Don't take it lightly here. Although the code can be generated without error, there is still a place that needs to be modified. Here, we can firstly close the EB tresos tool, then open terminal->new terminal in VScode and enter: Fig13 We can see the error content is : mcucgm0_clockMux0/McuClockMux0Divider5, McuClockMux0Divider6, McuClkMux0Div5_En, McuClkMux0Div6_En. Open S32KRM here, and you can see that K312 actually does not have MUX_0_5,6. Fig 14 At this time, when I opened the EB tresos software again, there was indeed such an error on the interface, and there was no divider 5,6 option in mcucgmClockMux0. Fig 15 Don't worry at this time, there is a way to fix this problem. Close the EB tresos tool and open the text: C:\NXP\SW32K3_S32M27x_RTD_R21-11_4.0.0\eclipse\plugins\Dio_TS_T40D34M40I0R0_miniK312_doc\examples\EBT\S32K3XX\Dio_Example_S32K312\TresosProject\Dio_Example_S32K312\config\ Mcu.xdm file. Directly turn off the enablement and value configuration of divider 5 and 6 in the file. Modify the following code:Modified to:The main thing is to change the enable and frequency value of Mux0Divider5,6 hidden in the file. Reopen it and you can see that the error disappears. Right-click on the EB project someId, generate project, and the code can be generated normally without error. Here is a little trick: In order to prevent the mismatch between the previously generated code and the latest EB project, you can also change: C:\NXP\SW32K3_S32M27x_RTD_R21-11_4.0.0\eclipse\plugins\Dio_TS_T40D34M40I0R0_miniK312_doc\examples\EBT\S32K3XX\Dio_Example_S32K312\generate Folder:src,include clean it,then regenerate in EB tresos when generating a project. Close the EB software and enter make generate again in the terminal of the Vscode project You can see that there are no problems at this time: Fig 16  3.Command line compilation and result testing From the above steps, the code and EB configuration migration of an existing RTD K344 project to a K312 MCAL project has been completed. Now, through VScode, command line form, generate main.elf, and then download and test. Command: make generate make build the main.elf can be found in the following folder path: C:\NXP\SW32K3_S32M27x_RTD_R21-11_4.0.0\eclipse\plugins\Dio_TS_T40D34M40I0R0_miniK312_doc\examples\EBT\S32K3XX\Dio_Example_S32K312\out Regarding testing, because there is a main.elf file and PE Multilink, you can create a new K312 project in S32DS. The debug interface is PE Multilink. After compiling and generating the code, copy main.elf to the Debug_FLASH folder of the new project. In the S32DS debug configuration, directly replace the C/C++ application with main.elf and download it for testing.  Fig 17 As you can see, you can enter the debug interface, and the LED light on the actual test board can flash successfully. This means that the MCAL code has been successfully ported to K312. 4. S32DS project migration and testing       In the previous document: https://community.nxp.com/t5/S32K-Knowledge-Base/S32K3-Tools-Part-How-to-import-RTD-EB-project-into-S32DS/ta-p/1966207 Previously, the RTD MCAL EB project was transplanted to the K344 project of S32DS. Simply modify the project name, project chip model, ld file, driver file inclusion, etc., then clean the project and compile the project.      It is assumed here that you already have an RTD MCAL project imported into the S32DS project, and then modify it based on this. 4.1 S32DS Project Configuration     Because the folder was copied under the original RTD folder, there is a newly created folder in the S32DS project Mcal_Plugins->Link_Source. This folder needs to be excluded from compilation: Select Dio_TS_T40D34M40I0R0_minik312_doc, right-click Build path->remove from->Debug_FLASH.      Fig 18 Rename the project from Mcal_Dio_S32K344_RTD400 to Mcal_Dio_S32K312_RTD400. Modify the following project configuration, project->properties: (1)preprocessor S32K344->S32K312 Fig 19   (2) Sstandard S32DS C Linker->General Modify "${MCAL_PLUGIN_PATH}/Platform${MCAL_MODULE_NAME_SUFFIX}/build_files/gcc/linker_flash_s32k344.ld" To "${MCAL_PLUGIN_PATH}/Platform${MCAL_MODULE_NAME_SUFFIX}/build_files/gcc/linker_flash_s32k312.ld" After modification, click apply and close Now, change the main.c content to the content in path:  C:\NXP\SW32K3_S32M27x_RTD_R21-11_4.0.0\eclipse\plugins\Dio_TS_T40D34M40I0R0_miniK312_doc\examples\EBT\S32K3XX\Dio_Example_S32K312\src\main.c Add header file: #include "Port_Cfg.h" Comment code: // #include "check_example.h" // Exit_Example(TRUE);   4.2 EB project replacement Copy: C:\NXP\SW32K3_S32M27x_RTD_R21-11_4.0.0\eclipse\plugins\Dio_TS_T40D34M40I0R0_miniK312_doc\examples\EBT\S32K3XX\Dio_Example_S32K312\TresosProject\Dio_Example_S32K312\config All the .xdm file to the S32DS EB folder, replace the old file: Mcal_Dio_S32K312_RTD400\Tresos_Project\Mcal_Dio_S32K344_RTD400\config Use the EB tresos open the above project, then Generate project,after the code is generated, close the EB project, back to the S32DS side. 4.3 MCAL S32DS project testing clean project:project->clean project,  then build the project Fig 20 You can see that it can be compiled successfully, then RUN->debug configuration selects the downloaded code xxx_Debug_FLASH_PNE. Note that you need to change the Device from S32K344 to S32K312 Fig 21 After successful configuration, click debug, download the code and simulate. The results are as follows: Fig 22 As you can see, we can successfully enter debug, and the light on the board is actually blinking, which means that the RTD MCAL project demo can be successfully ported to S32K312 S32DS.          
記事全体を表示
[S32K3 Tools Part] How to use VScode to compile EB MCAL project       For EB configured MCAL code, it is usually based on RTD and then compiled using the command line. When I first started learning, I always opened the relevant files directly to modify them, and then used the window cmd method to type commands. This method is very clumsy. Therefore, this article will show how to use VScode to open and compile a RTD4.0.0 S32K344 MCAL project. Of course, for MCAL EB projects, before compiling, you need to use the EB tool to open the configuration file of the corresponding project, and then close it after the project is generated. 1 VScode tool and configuration VScode download link: https://code.visualstudio.com/Download After downloading, install it. Here are some installation plug-ins I often use:   Fig 1 Fig 2 You can search in extensions and install it directly. 2. Use VScode to compile the RTD MCAL project This article takes RTD4.0.0, SW32K3_S32M27x_RTD_R21-11_4.0.0 as an example, and the platform is the official S32K344-EVB board. The code takes Dio_TS_T40D34M40I0R0 project as an example. In order not to affect the original routine, Dio_TS_T40D34M40I0R0 is copied and saved as Dio_TS_T40D34M40I0R0_vscode 2.1 Use EB tresos generate the configuration Open EB tools, import the project in path: C:\NXP\SW32K3_S32M27x_RTD_R21-11_4.0.0\eclipse\plugins\Dio_TS_T40D34M40I0R0_vscode\examples\EBT\S32K3XX\Dio_Example_S32K344\TresosProject Fig 3 Double-click someId, then right-click. If you do not need to make custom configurations, just click generate project. Wait for the generation to complete without errors and close the EB IDE. Fig 4 2.2 VScode  open project    First open VScode and select the project path in open Folder: C:\NXP\SW32K3_S32M27x_RTD_R21-11_4.0.0\eclipse\plugins\Dio_TS_T40D34M40I0R0_vscode\examples\EBT\S32K3XX\Dio_Example_S32K344 Fig 5 After opening, you can see that all the files in the path have been put in: Fig 6 You can save the workspace so you don't need to open the folder every time. File->Save workspace as, save to the path: C:\NXP\SW32K3_S32M27x_RTD_R21-11_4.0.0\eclipse\plugins\Dio_TS_T40D34M40I0R0_vscode\examples\EBT\S32K3XX\Dio_Example_S32K344   2.3 Modify mk file The project mk file needs to be modified to specify gcc, tresos paths, etc. Modify points:project_parameters.mk GCC_DIR = C:/NXP/S32DS.3.5_RTD400/S32DS/build_tools/gcc_v10.2/gcc-10.2-arm32-eabi TRESOS_DIR = C:/EB/tresos_29_0_0 PLUGINS_DIR = C:/NXP/SW32K3_S32M27x_RTD_R21-11_4.0.0/eclipse/plugins Fig 7 Modify points: check_build_params.mk Delete ifeq ("$(wildcard $(T32_DIR)/bin/windows/t32marm.exe)","") $(error Invalid path set to Trace32. \ The provided path: from project_parameters.mk T32_DIR=$(T32_DIR) is invalid!) Endif Fig 8 Then save all files:File->save all 2.4 Compile the file Terminal->New Terminal Enter the following command: >make generate >make build Fig 9 Fig 10 As you can see, after make build, an elf file has been generated in the out folder. This elf file can be directly downloaded using two methods: (1) S32DS empty project link to elf to download (2) Lauderbach directly download elf file   2.5 debug the generated elf file Since the S32K344-EVB has an onboard opensda tool, we directly use the S32DS empty project to link to the generated main.elf file to download and debug. Create a new S32DS project, and the interface is PE Multilink, then directly change the elf file to main.elf in the debug configuration, and then put the previously generated elf file into the folder of the new S32DS project:  \Debug_FLASH Fig 11 Then, enter debug mode, the results are as follows: Fig 12 As you can see, the chip has entered debug mode and can run successfully. Running at full speed, you can see the onboard red light flashing, so at this point, VSCode has compiled the MCAL code and run successfully.  
記事全体を表示
To restrict the S32K3 MCU access by JTAG the process depends on whether HSE FW is used or not. With HSE FW (not covered in this document): 1. Set up ADKP (Application Debug Key/Password). 2. Make sure the password mode or challenge-response mode. 3. Move the lifecycle to the IN-FIELD stage. NOTE: All the above steps can only be done via HSE services (not via IVT or by direct flash programming). Without HSE FW: WARNING: ONCE YOU REALIZE THIS PROCESS YOU CAN NOT CONFIGURE HSE IN THE DEVICE. NOTE: All the following codes represent just the essential part of the application and, where made using the S32K344 (not EVB), S32DS v3.5, the S32K3 Real-Time Drivers Version 3.0.0 (released on March 31, 2023) and a modified version of the C40_Ip_Example_S32K344, unless otherwise mentioned. As the debugger the PEmicro’s USB Multilink Universal FX was used, unless otherwise mentioned. 1. Program the field CUST_DB_PSWD_A: The UTEST Sector is an OTP (One Time Programmable). This causes the erase operations not to be allowed. You only going to be able to append new data or configuration and read data. This UTEST memory field is defined with a size of 32 bytes located from addresses 1B00_0080h to 1B00_009Fh, but its real size is 16 bytes because from 1B00_0090h to 1B00_009Fh is reserved (Table 184. UTEST memory location usage by SBAF of the S32K3xx Reference Manual, Rev. 7). To write the desired password in the UTEST Sector is the same process used to program data in other blocks. I. First, the sector needs to be unlocked to realize program operations. UTEST has its register PFCBLKU_SPELOCK[SLCK]. II. Once the sector is unlocked, write the 16-byte length password at 1B00_0080h. The following changes need to be done in the example code: /*============================================================================ * LOCAL MACROS ============================================================================*/ #define FLS_MASTER_ID 0U #define FLS_BUF_SIZE 16U #define FLS_SECTOR_ADDR 0x1B000080U #define FLS_SECTOR_TEST C40_UTEST_ARRAY_0_S000 NOTE: Make sure that the definition FLS_MAX_VIRTUAL_SECTOR located in C40_Ip_Cfg.h has the same value as the C40_UTEST_ARRAY_0_S000 and that C40_SECTOR_ERROR is one value greater than C40_UTEST_ARRAY_0_S000.  For example instead of: #define FLS_MAX_VIRTUAL_SECTOR (527U) … #define C40_SECTOR_ERROR (528U) Needs to be: #define FLS_MAX_VIRTUAL_SECTOR (528U) … #define C40_SECTOR_ERROR (529U) /*============================================================================ * GLOBAL CONSTANTS ============================================================================*/ uint8 TxBuffer[FLS_BUF_SIZE] = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F}; /* Password */ You can confirm the password was written by using the Memory Viewer (not covered by this document).   2. Advance the MCU's lifecycle: I. First, set the address of the lifecycle configuration word in the IVT/boot header. For more information refer to sections 32.5 (Image vector table) and 32.5.3 (Structure definition of image vector table) of the S32K3xx Reference Manual, Rev. 7. NOTE: Make sure that the structure of the boot_header (located in Project_Settings -> Startup_Code -> startup_cm7.s) is defined as shown below:     #define LF_CONFIG_ADDR (0x007D2000) /* The LC word can be at any flash address, taking care that does not interfere with HSE */     II. Once defined LF_CONFIG_ADDR, write in such address the value for the LC word corresponding to the target lifecycle: Life cycle stage Valid Values for LC Advancement OEM_PROD DADA_DADAh IN_FIELD BABA_BABAh The following changes need to be done in the example code (the changes can be done in the same project used before):     /*=========================================================================== * LOCAL MACROS ===========================================================================*/ #define FLS_MASTER_ID 0U #define FLS_BUF_SIZE 8U #define FLS_SECTOR_ADDR 0x007D2000U #define FLS_SECTOR_TEST C40_CODE_ARRAY_0_BLOCK_3_S489 /* Look into C40_Ip_Cfg.h file to find the corresponding sector */ /*=========================================================================== * GLOBAL CONSTANTS ===========================================================================*/ uint8 LC_TxBuffer[FLS_LC_SIZE] = {0xDA, 0xDA, 0xDA, 0xDA, 0x0, 0x0, 0x0, 0x0}; /* Minimum data length 8 bytes */     Once the LC word is written in the memory, you can confirm the LC word was written by using the Memory viewer (not covered by this document). III. Reset the MCU NOTE: Directly from the reset pin (RESET_B), not the debugger. If the procedure was done correctly you should see the following message: Now to unlock the MCU, PEmicro provides some Python scripts (PEmicro support files package) to facilitate the authentication of the debugger when the password is set. In summary: I. Make sure to have already installed Python (3.5 or later). II. Open Command Prompt. III. Use cd to change the current working directory to where the file package is. IV. Run the script using: py authenticate_password_mode.py -hardwareid=USB1 -password=… Where hardwareid, is the debug hardware IP address, name, serial number, or port name. And the password is the preconfigured 16-byte hexadecimal. NOTE: This steps need to be done each time the MCU is reset or power cycled.  Once the debugger has been authenticated, you are going to be able to securely debug the device under S32DS. NOTE: Just make sure that In S32DS when you configure the Debug Configurations of a project, change the Target to the one that says "SECUREDEBUG". This is because during debug entry a hard reset is toggled which clears the authentication. You can follow the below steps for this:  
記事全体を表示
What is “Flash Driver” (The following content is taken from Klaus Emmert->“FLASH Bootloader User Manual Version 2.7”) “The Flash Driver(actual flash algorithm) is the hardware dependent code for performing the flash functions.In most cases, programming flash memory from flash is not possible.Therefore the Flash Driver is downloaded and executed into RAM to allow programming of the application.The advantage of downloading the flash algorithm into RAM is that updates to the flash algorithms are possible without the need to reprogram the primary bootloader. The algorithm is cleared from RAM upon completion of the download to avoid accidental calls to the flash functions while in application. In special cases the flash algorithms are kept in flash memory and copied to RAM when needed. Of course the possibility of changing the flash algorithms is no longer available when this configuration is used. Moreover, there is a risk that the flash memory will be unintentionally erased from an accidental call to these functions. A remedy to correct this would be to encrypt the corresponding program code, such as e.g an XOR or the like.”   Regarding the demos -The software is using “S32 Design Studio for S32 Platform V3.4” and the SDK is “RTM 4.0.3” - Hardware based on S32K142-EVB -two demo provided, one for making “flash driver”, another is for testing the flash driver image     ·“Flash_Driver_Source_Project”  this routine used for making flash driver image.     ·“Flash_Driver_Source_Project_Test” this routine used for testing flash driver image.   ·Flash driver image making process 1.Create a new project and add the flash component       Refer to the demo provided and modified main.c file. Note 1 define function index table in main.c 2.Modify the link file Note 2 modified S32K142_32_flash.ld file   Note 3 modified S32K142_32_flash.ld file 3.Add “attribute” commands for the functions necessary to operate flash   Note 4 add "attribute" to function,like this         If another function is referenced in a function, then we also need to add “attribute” to the referenced function. 4.Compile the project and check the xx.map file to confirm whether the allocated address space is correct.   Note 5 check Flash_Driver_Source_Project.map 5.Make flash driver   Note 6 create flash image   Note 7 choose image format   Note 8 make flash driver image       New a “xx.s19” file and then copy the data which range of 0x1fffe000~0x1ffffffff into this file   Note 9 change link order if necessary       If some functions are distributed in different files, the function address allocated can be changed by changing the link order.   The process of testing the flash driver image 1.Create a new project without adding flash component.       You still need to create a new project, but you don’t need to add the Flash component to it. 2.Modify the link file as before. 3.Refer to the provided demo and modify main.c file. 4.Compile the project, check the .map file, and confirm whether the address space of the allocated array location is correct   Note 10 make sure Function_TABLE already put on the right place 5.Enter debug section, import the prepared flash driver image.   Note 12 import flash driver image before operate flash module 6.Test whether the flash driver can work normally.   Note 13 check the test result So far, we know how to make a flash driver image and how to test the flash driver image. This method is not limited to making functions related to flash operations, and other functions can also be used in this way, but there are few applications with such application scenarios.
記事全体を表示
Hi Everyone, Here I'd like to share three S32K1xx SDK FlexCAN PD and PAL component sample projects to demonstrate its basic and advanced features: 1. S32K144_CAN_PAL_SamplePrj_Basic_TxRx_ID_FiltersConfig_SDKRTM3P0 Functions implementation key points and tips: This sample project is made to demonstrate the following S32K1xx FlexCAN features with SDK FlexCAN PAL driver: 1. Configure to receiver the following exact 16 standard ID CAN message with RxFIFO 8x ID filter table with format type-B(2x 16-bit ID) Standard ID: 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x111, 0x222, 0x333, 0x444, 0x555, 0x666, 0x777, 0x788 The RxFIFO is configured to use CPU interrupt for CAN message receive, and CAN_PAL cannot support DMA for RxFIFO directly. Note: A. FlexCAN of S32K1xx dose not support to receive CAN-FD message frame with RxFIFO, so no CAN-FD support in this demo project. B. All the filter table elements must be configured to contain only standard or extend ID, if it contains both standard and extend ID, the IDE-bit mask will be ignored.  C. After RxFIFO enabled, MB0~MB5 is used as the RX FIFO, at least MB6~MB7 are used as the ID filter table(to store the acceptance ID), the actual available MB number is determined by RxFIFO ID filter table size, details please refer to section--55.4.6 Rx FIFO structure of S32K1xx RM Rev.12.1  2. Configure two extra individual MBs to receive: RX_MB1: 16 standard ID CAN 2.0 message with the lower 4LSB masked(mask=0x7F0, acceptance ID = 0x123): 0x120 ~ 0x12F and  RX_MB2: 4 standard ID CAN 2.0 message with the ID8 and ID9 masked(mask=0x4FF, acceptance ID = 0x256): 0x056, 0x156, 0x256 and 0x356 Both the RxFIFO and individual MBs RX use non-blocking receive method/API with MB TX/RX complete ISR callback installed to set a new circle buffer for next message frame receive 3. Configure one individual MB to blocking transmit a standard CAN 2.0 message with ID = 0x100 periodically(period = 5ms), and also send back the received CAN messages(if it's available) to the CAN bus as a response. 4. Provide the FlexCAN bus-off manual recovery configuration API and interrupt ISR callback codes for reference, changing the macro CAN_BUSOFF_RECOVERY_MANUAL(in include/Config.h) to select the bus off recovery method(enable the macro definition: manual recovery, comment the macro definition: automatic recovery); Note: In this sample project, the macro CAN_BUSOFF_RECOVERY_MANUA is commented by default, so manual recovery codes does not work. To make the bus-off recovery callback work, user should replace the flexcan PD driver codes and S32K144_feature.h with S32K1xx RTM 4.0.0(which can be downloaded from nxp.com with registered account login and then installed stand-alone or installed via S32DS v3.3 IDE update). This is not done this sample project!!!  5. There 3 on-board RGB LED are used to indicate the FlexCAN working status: red RGB LED will be toggled after RXFIFO received a CAN message; blue RGB LED will be toggled after individual MB received a CAN message; green RGB LED will be turn ON after enter bus-off and turn OFF after exist bus-off(recover successfully). To run this sample project, the following HW and SW require: SW: S32DS for ARM v2.2 IDE with S32K1xx SDK RTM 3.0.3 installation HW: S32K144EVB-Q100 Rev.C with a DC-12V adapter for its power supply by J16 and a USB-to-CAN adapter(such as PEAK CAN) to connect PC with J13 of the EVB 2.S32K144_CAN_PAL_CANFD_ClassicCAN_Mix_TxRx_Wakeup_SDKRTM3P0 Functions implementation key points and tips: This sample project is made to demonstrate the following S32K1xx FlexCAN features with SDK FlexCAN PAL driver: 1. Configure to enable CAN-FD with 500 Kbit/s arbitration phase bitrate and 2Mbit/s data phase bitrate, so it can support both classic CAN 2.0 A/B and CAn-FD message frame transfer. Note: A. The RxFIFO is disabled to work with CAN-FD message frame. B. After CAN-FD enabled, CAN-FD message frame data length can support up to 64 Bytes, so the actual available MB number is determined by the max frame data length need to support, details please refer to section--55.4.5 FlexCAN message buffer memory map of S32K1xx RM Rev.12.1  C. In order to support bitrate bigger than 1Mbit/s for CAN-FD data phase with bitrate switch enabed, PE clock source of CAN_PAL should be configured to use peripheral clock(80MHz generated from SPLL) instead of 8MHz oscillator clock; 2. Configure 3 individual MBs to receive: RX_MB0: 16 extend ID CAN 2.0/FD message with the lower 4LSB masked(mask=0x1FFFFFF0, acceptance ID = 0xfff021): 0xfff020 ~ 0xfff02F RX_MB1: 16 standard ID CAN 2.0/FD message with the lower 4LSB masked(mask=0x7F0, acceptance ID = 0x123): 0x120 ~ 0x12F RX_MB2: 4 standard ID CAN 2.0/FD message with the ID8 and ID9 masked(mask=0x4FF, acceptance ID = 0x256): 0x056, 0x156, 0x256 and 0x356 Both the RxFIFO and individual MBs RX use non-blocking receive method/API with MB TX/RX complete ISR callback installed to set a new circle buffer for next message frame receive 3. Configure 3 individual MBs to transmit: TX_MB0: send back any CAN(2.0/FD) messages received from RX_MB0; TX_MB1: send back any CAN(2.0/FD) messages received from RX_MB1; TX_MB2: send back any CAN(2.0/FD) messages received from RX_MB2; 4. Configure one individual MB(TX_MB3) to blocking transmit a standard CAN FD message with ID = 0x100 periodically(period = 5ms) and length = 64 bytes, and also send back the received CAN messages(if it's available) to the CAN bus as a response. 5. Provide the FlexCAN bus-off manual recovery configuration API and interrupt ISR callback codes for reference, changing the macro CAN_BUSOFF_RECOVERY_MANUAL(in include/Config.h) to select the bus off recovery method(enable the macro definition: manual recovery, comment the macro definition: automatic recovery); Note: In this sample project, the macro CAN_BUSOFF_RECOVERY_MANUA is commented by default, so manual recovery codes does not work. To make the bus-off recovery callback work, user should replace the flexcan PD driver codes and S32K144_feature.h with S32K1xx RTM 4.0.0(which can be downloaded from nxp.com with registered account login and then installed stand-alone or installed via S32DS v3.3 IDE update). This is not done this sample project!!!  6. Provided the sample codes of how to configure FlexCAN as the VLPS low-power mode wakeup source, RXD of FlexCAN0 is configured as GPIO IRQ interrupt with falling edge trigger before entering VLPS mode, and after wakeup, re-configure it back to RXD function. Note: A. S32K1xx FlexCAN is unable to work as the VLPS wakeup source B. After wakeup, it's necessary to call SDK clock_manager's API--CLOCK_SYS_UpdateConfiguration() to reconfigure the system clock, or it will use 8MHz SIRC, 48 MHZ FIRC and SPLL are disabled after wakeup. c. By default, after receive ID = 0x123(it can be configured via macro LP_REQUEST_ID in /include/Config.h ) standard CAN(CAN 2.0 or CAN-FD), the MCU will go to VLPS mode 7. There 3 on-board RGB LED are used to indicate the FlexCAN working status: blue RGB LED will be toggled after individual MB received a CAN message; green RGB LED will be turn ON after enter bus-off and turn OFF after exist bus-off(recover successfully). To run this sample project, the following HW and SW require: SW: S32DS for ARM v2.2 IDE with S32K1xx SDK RTM 3.0.3 installation HW: S32K144EVB-Q100 Rev.C with a DC-12V adapter for its power supply by J16 and a USB-to-CAN adapter(such as PEAK CAN) to connect PC with J13 of the EVB 3.S32K144_FlexCAN_PD_SamplePrj_RxFIFO_DMA_Receive_SDKRTM3P0 Functions implementation key points and tips: This sample project is made to demonstrate the following S32K1xx FlexCAN features with SDK FlexCAN PD driver: 1. Configure to receiver the following exact 16 standard ID CAN message with RxFIFO 8x ID filter table with format type-B(2x 16-bit ID) Standard ID: 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x111, 0x222, 0x333, 0x444, 0x555, 0x666, 0x777, 0x788 The RxFIFO is also configured to use eDMA channel 0 for CAN message receive, user can easily change to use CPU interrupt for RxFIFO in processor expert flexcan component configuration if required. Note: A. FlexCAN of S32K1xx dose not support to receive CAN-FD message frame with RxFIFO, so no CAN-FD support in this demo project. B. all the filter table elements must be configured to contain only standard or extend ID, if it contains both standard and extend ID, the IDE-bit mask will be ignored.  C. After RxFIFO enabled, MB0~MB5 is used as the RX FIFO, at least MB6~MB7 are used as the ID filter table(to store the acceptance ID), the actual available MB number is determined by RxFIFO ID filter table size, details please refer to section--55.4.6 Rx FIFO structure of S32K1xx RM Rev.12.1  2. Configure one extra individual MB(MB8) to receive 16 standard ID CAN 2.0 message with the lower 4LSB masked(mask=0x7F0, acceptance ID = 0x123): 0x120 ~ 0x12F; Both RxFIFO and individual MB RX use non-blocking receive method/API with MB TX/RX complete ISR callback installed to set a new circle buffer for next message frame receive 3. Configure one individual MB(MB9) to blocking transmit a standard CAN 2.0 message with ID = 0x100 periodically(period = 5ms), and also send back the received CAN messages(if it's available) to the CAN bus as a response. 4. Provide the FlexCAN bus-off manual recovery configuration API and interrupt ISR callback codes for reference, changing the macro CAN_BUSOFF_RECOVERY_MANUAL(in include/Config.h) to select the bus off recovery method(enable the macro definition: manual recovery, comment the macro definition: automatic recovery); Note: In this sample project, the macro CAN_BUSOFF_RECOVERY_MANUA is enabled by default, and manual recovery codes works. To make the bus-off recovery callback work, user should replace the flexcan PD driver codes and S32K144_feature.h with S32K1xx RTM 4.0.0(which can be downloaded from nxp.com with registered account login and then installed stand-alone or installed via S32DS v3.3 IDE update). This is already done this sample project!!!  5. There 3 on-board RGB LED are used to indicate the FlexCAN working status: red RGB LED will be toggled after RXFIFO received any CAN message; blue RGB LED will be toggled after individual MB received any CAN message; green RGB LED will be turn ON after enter bus-off and turn OFF after exist bus-off(recover successfully). To run this sample project, the following HW and SW require: SW: S32DS for ARM v2.2 IDE with S32K1xx SDK RTM 3.0.3 installation HW: S32K144EVB-Q100 Rev.C with a DC-12V adapter for its power supply by J16 and a USB-to-CAN adapter(such as PEAK CAN) to connect PC with J13 of the EVB Attached are the sample project for your reference, and details can also be fiound with the detailed comments in source codes. Hope it can help you, and any comments/questions are welcomed, and you can just ask in this thread and I will try to anwser them. Best regard, Enwei Hu(胡恩伟).  
記事全体を表示
Greetings, if you want to use the open source EmbSysRegView plugin in your Eclipse environment: this article describes how to add the S32K CMSIS-SVD files to it: Adding CMSIS-SVD Files to EmbSysRegView 0.2.6.r192 and Eclipse Happy SVDing 🙂 Erich
記事全体を表示
******************************************************************************** Detailed Description: This example shows the use of SRAM retention after SW reset. The SW reset is triggered by pressing the SW3 button on the S32K144 EVB The reset is delayed in RCM module: 514 LPO cycles. In the RCM interrupt, SRAMU_RETEN and SRAML_RETEN are cleared allowing to retain SRAM data during the reset. After software reset, SRAMU_RETEN and SRAML_RETEN are set to1 to allow accesses to SRAM.  During software initialization in the startup_S32K144.S, ECC RAM initialization is skipped.  After that, we can check the written data before reset are still placed in the SRAM.  ------------------------------------------------------------------------------ Test HW: S32K144EVB-Q100 MCU: S32K 0N57U Debugger: S32DSR1 ********************************************************************************
記事全体を表示
********************************************************************************  Detailed Description:  Example shows how to use FlexCAN 0 Pretended networking mode to allow FlexCAN  module to wake up MCU from STOP mode.  Wake up by Timeout and wake up by Match events are enabled.  Also pin interrupt can be used to exit STOP mode.  So MCU enters STOP mode by pressing SW3 button.  MCU exits STOP mode when one of following happens:  - no CAN message comes in 8sec (CAN PN timeout event)  - message with standard ID 0x554 or 0x555 comes (CAN PN match event)  - SW2 button is pressed (PTC12 interrupt)  In run mode blue LED is dimming and the rate is different for each wakeup event  ------------------------------------------------------------------------------  Test HW: S32K144 EVB-Q100  MCU: FS32K144UAVLL 0N57U  Fsys: 160MHz  Debugger: Lauterbach, OpenSDA  Target: internal_FLASH ********************************************************************************
記事全体を表示
*******************************************************************************  The purpose of this demo application is to present a usage of the  FS26 watchdog timer refresh using the SBC_FS26 CDD  ------------------------------------------------------------------------------ * Test HW: S32K3X2EVB-Q172 * MCU: S32K312 * Compiler: S32DS3.5 * SDK release: RTD 3.0.0 * Debugger: PE micro * Target: internal_FLASH ******************************************************************************** Watchdog type :-- NXP eval boards has ASIL-D FS26 part with challenger watchdog. The OTP of FS26 on the board uses challenger watchdog. Change watchdog in code :-- FS26 watchdog is started in disabled mode (means infinite period). Later on we change the watchdog time in the code :--     Array Index for watchdog refresh timing  :-- Example will run once you press switch USER_SW0 connected on PTB26 on the Evaluation board :-- Please add this type of check in your code, during development process so that, avoid any error due to FS26 watchdog mis trigger. When you use Debug FLASH then in that case code goes to flash memory & can cause your MCU to frequent RESET, which caused issue for reprogramming the NEW firmware on the board FLASH memory. If we add this type of check then we can avoid the Faulty FS26 Software to stop misbehaving before flashing new firmware on the board.    
記事全体を表示
******************************************************************************************************* * Detailed Description: This demo showcases how to use eMIOS in Input Capture mode with DMA. It demonstrates how timestamp data from captured input signals is stored and how a GPIO toggle provides a simple visual confirmation that the interrupt is being triggered as expected.   * eMIOS Pwm: Configures EMIOS 0 Channel 1 as OPWMB (Output Pulse Width Modulation Buffered). This channel generates a waveform that will be captured by Channel 9 * eMIOS Icu with DMA: Configures EMIOS 0 Channel 9 in ICU_MODE_TIMESTAMP using SAIC (Single Action Input Capture) mode. This channel captures the timestamps of the waveform generated by Channel 1. After a predefined number of captures, a DMA interrupt is triggered. ******************************************************************************************************* * Test HW: S32K3X4EVB-T172 * MCU: S32K344 * Debugger: S32DS 3.6.2, OpenSDA * Target: internal_FLASH *******************************************************************************************************
記事全体を表示
S32K344 + MC33664 + MC33774 : RTD 3.0.0 : BMS SDK 1.0.2 :-- https://community.nxp.com/t5/S32K-Knowledge-Base/S32K344-MC33664-MC33774-RTD-3-0-0-BMS-SDK-1-0-2/ta-p/2028783 S32K344 + MC33665 + MC33774 : RTD 3.0.0 : BMS SDK 1.0.2 :-- https://community.nxp.com/t5/S32K-Knowledge-Base/S32K344-MC33665-MC33774-RTD-3-0-0-BMS-SDK-1-0-2/ta-p/2127108 S32K344 + MC33664 + MC33775 : RTD 3.0.0 : BMS SDK 1.0.2 :-- https://community.nxp.com/t5/S32K-Knowledge-Base/S32K344-MC33664-MC33775-RTD-3-0-0-BMS-SDK-1-0-2/ta-p/2127049 S32K344 + MC33665 + MC33775 : RTD 3.0.0 : BMS SDK 1.0.2 :-- https://community.nxp.com/t5/S32K-Knowledge-Base/S32K344-MC33665-MC33775-RTD-3-0-0-BMS-SDK-1-0-2/ta-p/2127140 S32K144 : RTD-1.0.1 porting for : BCC_S32K144_FreeMASTER :-- https://community.nxp.com/t5/S32K-Knowledge-Base/S32K144-RTD-1-0-1-porting-for-BCC-S32K144-FreeMASTER/ta-p/2130167
記事全体を表示
******************************************************************************************** * Test HW: S32K312 EVB-Q172 * MCU: S32K312 * Compiler: S32DS3.5 * SDK release: RTD 3.0.0 * Debugger: PE Micro * Target: internal_FLASH ******************************************************************************************** The objective of this demo application is to generate an interrupt by comparing DAC internal reference voltage against any analog input which is connected in analog mux input channels(IN0 : IN7). In this demo code,            1)LPCMP0 is used - DAC output is  given to comparator minus (INM) and                                                      AIN2 is given to comparator plus (INP).                From S32K3 RM, highlighted the channels used for reference.                Green color represents DAC, Pink color represents AIN2 which is selected from PMUX          2) From S32K RM,                "Compares two analog input voltages applied to INP and INM,                   COUT_RAW is high when the INP input voltage is greater than the INM input voltage,                   COUT_RAW is low when the INP input voltage is less than the INM input voltage"                So in this demo code,                RED LED is ON , if AIN2 Voltage > DAC Internal reference voltage(COUT is HIGH)                GREEN LED is ON, If AIN2 Voltage < DAC Internal reference voltage (COUT is LOW)   Modules used:           Modifications in LPCMP module:   Modifications in IntCtrl_IP module: Modifications in the "Cmp_Ip_IrqHandler" function in "Cmp_IP.c" source file: Note: Not sure how it got missed or from where to get COUT status, so added manually to get COUT status from CSR register in the Cmp_Ip_Irqhandler once code generation is completed. GPIO selection details: How to test ? a) Connect jumper wire at the PTC2 in the EVB as highlighted in EVB below. b) RED LED ON -> Jumper wire connects to 5V      GREEN LED ON-> Jumper wire connects to GND Connect male jumper wire at PTC2 Thanks & regards, Krishnakumar V
記事全体を表示
【RTD400 MCAL 3】 K312 MCU clock system configuration 1. Abstract This document is talking about how to configure the clock system in the MCU of the K3 chip MCAL. This topic was always disdainful to talk about when I was doing LLD before, because the clock system of K3 is too simple, with internal fast and slow clock sources, external fast and slow clock sources, a PLL multiplier, and then various core peripherals to share. K3's RM even made a few options to frame the rules. From the perspective of LLD, especially the perspective of S32DS CT configuration, it is even more concise and clear. Here is a CT picture to show it:   Fig 1     Fig 2 With such a clock system, you can generate code with just a few taps and pokes. However, LLD is too free, and MCAL often encounters problems. Therefore, I decided to spend some time to understand the entire clock system of this MCAL MCU. This article takes K312 as an example to explain. Other K3 series are similar. 2. Clock system theory and configuration 2.1 K312 clock system From the clock chapter of RM, you can see the whole system block diagram:     Fig 3 This block diagram clearly shows the situation of each part. There are four clock sources: Internal fast clock FIRC: 48MHz, +/-5% error, maximum startup time 25us Internal slow clock SIRC: 32KHz, +/-10% error, maximum startup time 3ms External fast clock FXOSC: 8-40MHz, startup stabilization time FXOSC_CTRL[EOCV] × 128 External slow clock SXOSC: 32.768KHz, startup stabilization time SXOSC_CTRL[EOCV] x 128 One PLL: input 8-40MHZ, VOC output 640M-1280Mhz, PLL_PHIn_CLK output 25-480MHz. MUX_0: Output CORE_CLK, AIPS_PLAT_CLK, AIPS_SLOW_CLK, HSE_CLK, DCM_CLK MUX_1: Output system timer STM0_CLK MUX_3: Output FLEXCAN0-2 clock MUX_4: Output FLEXCAN3-5 clock MUX_5: Output CLKOUT_STANDBY MUX_6: Output CLKOUT_RUN MUX_11: Output TRACE_CLK RTC_CLK: RTC clock 2.1.1 PLL From the PLL perspective, we need to know which values ​​the frequency multiplier is related to, which can be calculated using the following formula:     Fig 4 If it is an integer, the red box in the above figure is the common method, and this article will also use the above method to configure. PLL_PHI is the clock output by the final PLL, which is provided to the MC corresponding to other MUXs for selection. 2.1.2 MUX_0 System The MUX_0 system with details can be seen from RM:     Fig 5 As you can see, the clock source of MUX_0 can be two types: PLL or internal FIRC. Then the core clock can be generated later, AIPS_PLAT_CLK, AIPS_SLOW_CLK, HSE_CLK, DCM_CLK. So what is the specific frequency of the generated clock? In principle, it can meet the maximum clock corresponding to each module, but the K3 series also makes some option recommendations. For example, K312 recommends using option B mode when RUN, especially the HSE clock, which usually needs to strictly meet the option recommendation. 2.1.3 MUX_6 Clock output In order to check the corresponding clock situation in the chip, the corresponding clock can be output through the CLKOUT pin. The CLKOUT pin can correspond to the selection of multiple clock sources. The specific situation is as follows:     Fig 6 The yellow content in the figure is what K312's CLKOUT_RUN can support. After the clock is configured, the corresponding clock will be selected to test whether the output is consistent with the configuration. 2.1.4 option B Recommended Solution In this article, K312 will configure the clock of option B in EB.     Fig 7 2.2 EB configuration        First, create a new K312 EB project. For the specific creation method, please refer to the previous article: [S32K3 Tools Part] How to port RTD's existing MCAL demo to other K3 chips This article will focus on the clock configuration corresponding to the MCU module based on RTD400 MCAL. For MCU configuration, two documents need to be consulted as reference books: C:\NXP\SW32K3_S32M27x_RTD_R21-11_4.0.0\eclipse\plugins\Mcu_TS_T40D34M40I0R0\doc: RTD_MCU_UM.pdf and RTD_MCU_IM.pdf If you don’t know how to configure, just follow the default values ​​recommended by the document. The following figure is an overview of the MCU. The main configured modules have the following three components: General, McuClockSettingConfig, McuModeSettingConf     Fig 8 2.2.1 General configuration In addition to Figure 8, you need to turn on the internal and external fast and slow clock control and PLL control, and add the corresponding API, as well as the crystal oscillator frequency. If this is not turned on, the corresponding configuration later will not be able to be configured.     Fig 9 2.2.2 McuClockSettingConfig configuration        This is the core area of ​​MCU clock configuration, which includes clock source, PLL, and various MUX conditions. First, you need to add a clock configuration:     Fig 10 Click in and there will be detailed configuration:     Fig 11 There are 17 items in total. You can keep the default configuration for options 1 and 6. Since the board does not connect to the external slow crystal oscillator 5, it is not configured. The rest should be configured according to the actual situation. The following explains them one by one: 2.2.2.1 McuFIRC configuration    Internal fast clock, 48MHz:     Fig 12 2.2.2.2 McuSIRC configuration Internal slow clock 32Khz     Fig 13 2.2.2.3 McuFXOSC configuration External crystal oscillator 16MHZ, fill in according to the actual connection situation.     Fig 14 2.2.2.4 McuCgm0ClockMux0 configuration Mux0 configuration, here are configured core clock, AIPS_PLAT_CLK, AIPS_SLOW_CLK, HSE, DCM_CLK, is to meet the optionB requirements, and the clock comes from PLL_PHI0_CLK. When actually configuring, first configure the PLL clock to output the correct PLL_PHI0_CLK, PLL_PHI1_CLK clock.     Fig 15 2.2.2.5 McuCgm0ClockMux1 configuration     Fig 16 It can be configured according to the clock source required by the actual module. 2.2.2.6 McuCgm0ClockMux3 configuration Configure the clock source of the FLEXCAN0-2 module:     Fig 17 2.2.2.7 McuCgm0ClockMux4 configuration Configure the clock source of the FLEXCAN3-5 module:     Fig 18 2.2.2.8 McuCgm0ClockMux5 configuration Configure the clock source of the CLKOUT_STANBY module:     Fig 19 2.2.2.9 McuCgm0ClockMux6 configuration Configure the clock source of the CLKOUT_RUN module     Fig 20 2.2.2.10 McuCgm0ClockMux11 configuration Configure the clock source of the TRACE_CLK module     Fig 21 2.2.2.11 McuRtcClockSelect configuration Configure the clock source of the RTC module     Fig 22 2.2.2.12 McuPLL configuration Configure the clock source of the PLL module     Fig 23 2.2.2.13 McuClockReferencePoint configuration Configure the reference clock and the clock source selection interface of the peripheral modules.     Fig 24 At this point, the clock configuration is complete. For verification, you can use the CLKOUT_RUN output to output the corresponding clock to pin PTD10 for viewing. 2.2.3 McuModeSettingConf  configuration In Mcu's McuModeSettingConf->McuPeripheral, you need to turn on the peripherals you want to use:     Fig 25 2.2.4 PORT  configuration Because the internal clock needs to be output to CLKOUT_RUN, K312's PTD10 MSCR106 is checked, so the PORT pin is added as follows:     Fig 26 3. Test Result Next, on the S32K312-EVB board, we modify the clock source of EB's CLKOUT_RUN to test whether the clock matches the configuration. Commonly used MCU-related drivers are as follows:     Fig 27 The calling sequence of system startup MCU initialization is as follows: 1). Mcu_Init() 2). Mcu_InitClock() 3). Mcu_GetPllStatus() - Till PLL is locked. 4). Mcu_DistributePllClock() 5). Mcu_SetMode() 6). Mcu_InitRamSection() - If required The corresponding main code is as follows: #include "Mcu.h" #include "Mcu_Cfg.h" #include "Port.h" #include "Dio.h" #include "Port_Cfg.h" #include "Platform.h" void TestDelay(uint32 delay); void TestDelay(uint32 delay) { static volatile uint32 DelayTimer = 0; while(DelayTimer < delay) { DelayTimer++; } DelayTimer = 0; } /** * @brief Main function of the example * @details Initialize the used drivers and uses the Icu * and Dio drivers to toggle a LED on a push button */ int main(void) { uint8 count = 0U; uint8 u8TimeOut = 100U; /* Initialize the Mcu driver */ #if (MCU_PRECOMPILE_SUPPORT == STD_ON) Mcu_Init(NULL_PTR); #elif (MCU_PRECOMPILE_SUPPORT == STD_OFF) Mcu_Init(&Mcu_Config_VS_0); #endif /* (MCU_PRECOMPILE_SUPPORT == STD_ON) */ /* Initialize the clock tree and apply PLL as system clock */ Mcu_InitClock(McuClockSettingConfig_0); #if (MCU_NO_PLL == STD_OFF) while ( MCU_PLL_LOCKED != Mcu_GetPllStatus() ) { } Mcu_DistributePllClock(); #endif /* Apply a mode configuration */ Mcu_SetMode(McuModeSettingConf_0); /* Initialize all pins using the Port driver */ Port_Init(NULL_PTR); /* Initialize Platform driver */ Platform_Init(NULL_PTR); while (count++ < 10) { Dio_WriteChannel(DioConf_DioChannel_Digital_Output_LED_Q172, STD_HIGH); Dio_WriteChannel(DioConf_DioChannel_Digital_Output_LED_Q257, STD_HIGH); TestDelay(5000000); Dio_WriteChannel(DioConf_DioChannel_Digital_Output_LED_Q172, STD_LOW); Dio_WriteChannel(DioConf_DioChannel_Digital_Output_LED_Q257, STD_LOW); TestDelay(5000000); } // Exit_Example(TRUE); return (0U); } #ifdef __cplusplus } #endif 3.1 CLKOUT FIRC_CLK DIV2     Fig 28 It can be seen that the original 48Mhz clock of FIRC is divided by 2 and the clock waveform of 24Mhz is obtained, which is correct! 3.2 CLKOUT SIRC_CLK DIV2     Fig 29 It can be seen that the original 32Khz clock of SIRC is divided by 2 and the clock waveform of 16khz is obtained, which is correct! 3.3 CLKOUT FXOSC_CLK DIV10     Fig 30 It can be seen that the original 16Mhz clock of FXOSC is divided by 10 and the clock waveform of 1.6Mhz is obtained. 3.4 CLKOUT PLLPH0 CLK DIV10     Fig 31 It can be seen that the original 120Mhz clock of PLLPH0 is divided by 10 and the 12Mhz clock waveform is obtained, which is correct. 3.5 CLKOUT CORE CLK DIV10     Fig 32 It can be seen that the original 120Mhz clock of CORE is divided by 10 and the 12Mhz clock waveform is obtained, which is correct. 3.6 CLKOUT PLLPH1 CLK DIV4     Fig 33 It can be seen that the original 48Mhz clock of PLLPH1 is divided by 4 and the 12Mhz clock waveform is obtained. 3.7 CLKOUT HSE CLK DIV10     Fig 34 It can be seen that the original 60Mhz clock of HSE is divided by 10 and the clock waveform of 6Mhz is obtained, which is correct. 3.8 CLKOUT AIPS_PLAT CLK DIV10     Fig 35 It can be seen that the original 60Mhz clock of AIPS_PLAT_CLK is divided by 10 and the clock waveform of 6Mhz is obtained, which is correct. 3.9 CLKOUT AIPS_SLOW CLK DIV10     Fig 36 It can be seen that the original 30Mhz clock of AIPS_SLOW_CLK is divided by 10 and the clock waveform of 3Mhz is obtained, which is correct.  
記事全体を表示