1. 项目背景与整体方案设计1.1 为什么是S32K1 EB Tresos这个组合先交代一下我这个项目的背景。前阵子接了一个车身控制器BCM的项目主控选的是NXP S32K148176pin封装需要跑CAN通信和UDS诊断同时带几路高边驱动和LIN从节点。因为项目要过AUTOSAR相关的客户审核MCAL层必须用EB Tresos来生成配置代码而不是直接用NXP提供的裸机SDK。在汽车电子这一行MCALMicrocontroller Abstraction Layer就是连接芯片寄存器操作和上层AUTOSAR基础软件比如CanIf、PduR、Com之间的那一层。S32K1是NXP主打的通用MCU系列主打性价比和低功耗在BCM、T-BOX、车窗控制这类节点上非常常见。EB Tresos则是Elektrobit出品的AUTOSAR配置工具后来被Continental收购现在很多Tier1和Tier2都在用它来生成MCAL代码。选型的时候我也纠结过一套NXP自家的S32 Configuration Tools它也能生成MCAL但客户指定了EB Tresos的工程格式而且后续要用EB Tresos做DBC到CAN矩阵的映射、配置CanNm和CanTp所以最后就锁定EB Tresos这条路。1.2 这套方案的最终形态整个CAN驱动的配置目标是这样S32K148内部有3个FlexCAN模块分别是CAN0、CAN1、CAN2。项目里CAN0作为主CAN通道跑500kbps接UDS诊断和标定CAN1跑250kbps接车内舒适网络的信号CAN2这个模块在S32K1系列上比较特殊它只有32个MBMessage Buffer而不是64个而且和FlexCAN0共用一部分时钟和中断资源做的时候要注意别踩资源冲突的坑。底层MCAL需要生成的驱动模块包括Can_17_FlexCan、CanTrcv_34_FlexCanTrcv如果收发器是NXP自家的TJA1043之类或者用SPI外挂收发器配置以及可选的CanNm、CanSM、CanTp这些基础服务模块。我这里用到的CAN收发器是TJA1043外接在CAN0和CAN1上CAN2因为链路不需要太多直接接了TJA1051。为什么要把收发器也放进MCAL配置因为AUTOSAR架构里收发器驱动CanTrcv是独立于CAN控制器驱动的它负责管理收发器的正常/待机/睡眠模式切换尤其是TJA1043这种带INH引脚和唤醒功能的收发器必须在MCAL阶段就把唤醒源、模式控制、失败处理这些逻辑给理顺否则后面做网络管理CanNm的时候总线休眠和唤醒会出现一堆诡异问题。注意S32K1的FlexCAN模块在低功耗模式下只有CAN0可以配置为FlexCAN的Stop模式唤醒源CAN1和CAN2不行。如果你要做CAN唤醒一定要把唤醒通道放在CAN0上别问我怎么知道的第一次画原理图的人十个有九个踩这个。2. EB Tresos配置前的准备工作2.1 版本和License第一道坎这里必须先说一个很多人不问清楚就上手、结果卡了三天的问题EB Tresos的版本和License。EB Tresos目前常见的版本有EB tresos 22.x、23.x、24.x不同版本对S32K1的MCAL插件版本要求不一样。S32K1的MCAL插件在NXP官网的S32K1 AUTOSAR MCAL包里面需要注册NXP账号并且走一遍瑞萨Renesas的审批流程没错NXP的MCAL现在已经归瑞萨管了。下载下来之后是一个压缩包里面包含EB tresos插件、静态代码、文档和例程。我建议直接用EB tresos 23.0以上版本配合S32K1_MCAL 4.4或4.5版本插件。如果你用的是旧版24位License或者Demoware跑起来会频繁弹窗而且最关键的是Demo License对CAN通道数量有限制以前我在一个项目上试用版只能配置2个CAN第三路CAN模块在生成代码的时候直接被跳过了查半天查不出原因最后才发现是License的锅。安装完插件之后EB Tresos启动时会让你选择工作空间新建工程时选“S32K1XX”系列模板然后导入MCAL插件模块。正常来说左侧工程浏览器会出现Can、CanTrcv、Lin、Spi、Mcu、Port、Dio、Gpt等模块如果模块列表不完整多半是插件导入路径有问题或者是NXP的AUTOSAR包解压后没有指向正确的插件目录。2.2 搞清芯片的CAN硬件资源配置前必须看的框图在EB Tresos里动手勾选之前我强烈建议你先把S32K148参考手册里FlexCAN模块的时钟树和中断映射看清楚。S32K148的FlexCAN时钟来源有两种选择一种是系统时钟比如80MHz或100MHz另一种是FIRC48MHz。这里有个很重要的计算逻辑CAN位时间的分配是基于CAN时钟频率来做的如果CAN时钟从80MHz分频到500kbps那PBRPrescaler就是8Seg1取13个TqSeg2取6个Tq加上Sync Seg的1个Tq总共20个Tq一个位时间20/80MHz250ns这样500kbps就出来了。中断这块也要提前规划S32K148的FlexCAN0和FlexCAN1可以映射到不同的中断向量CAN2和CAN0在低功耗唤醒等场景下是有共享资源的。最好先在EB Tresos的Mcu模块里把时钟树配好再进Can模块配置波特率和中断优先级否则会出现“Mcu时钟没输出CAN模块寄存器里时钟位是0”这种低级但极其坑人的问题。我现在做的这个项目CAN时钟源选择的是80MHz的系统时钟CAN0配置500kbpsCAN1配置250kbpsCAN2因为要接收较少的报文直接跑250kbps。三个通道的中断优先级分别设成10、12、14PCA优先级分配在EB Tresos里直接填数字数字越小优先级越高注意别把所有通道都设成同一个优先级否则中断嵌套的时候会乱。提示S32K1 MCAL的Can模块里有个节点叫CanControllerBaudRateConfig这里是配置波特率采样点的地方。采样点建议设在80%左右别听某些老工程师说75%就行实测在CAN FD这种高速率和短帧间隔的场景下80%的噪声容限明显更好。2.3 SPI外挂收发器的物理层配置有一类项目不是用S32K1内部FlexCAN自带的收发器控制器而是通过SPI接口去控制一颗外部的CAN收发器芯片比如TJA1145或者UJA1169。这种情况在车身控制模块里特别常见因为省电设计要外挂一个专门的收发器管理电源和唤醒。我当时这套BCM方案里的CAN2通道就用了一颗TJA1145通过SPI0去读写它的寄存器。这里需要你提前把Spi模块在EB Tresos里配好然后去CanTrcv模块里选择对应的收发器类型——如果MCAL包里有TJA1145的驱动就直接选没有的话就得自己写CanTrcv的外部驱动回调工作量会大不少。我这边因为刚好用的NXP生产的TJA1145MCAL的CanTrcv驱动里有现成的配置项只需要把Spi通道的片选、波特率、DMA与否设置好就行。这里有个细节TJA1145如果开启了内部的休眠模式MCAL生成代码之后上电时需先做SPI读写测试看收发器有没有正确响应如果读取的ID不对大概率是SPI时钟极性/相位配错了或者片选极性反了。3. CAN驱动配置的核心步骤与细节拆解3.1 创建工程并导入MCAL插件第一步打开EB Tresos新建一个工程选择芯片型号为S32K148。工程向导会让你勾选需要的模块至少把Can、CanTrcv、Mcu、Port、Spi、PduR这几项选上。第二步导入NXP的MCAL插件内容。这一步是很多新手容易搞混的因为EB Tresos的工程本身只是一个配置文件壳子真正的底层驱动代码是安装插件时复制到eclipse目录下或者以链接的方式关联进工程的。如果插件关联失败最后代码生成的时候会提示缺少Static_code文件。第三步在工程左侧的模块列表里双击Can_17_FlexCan模块开始做CAN控制器的详细配置。这里一个模块代表一个物理CAN控制器实例如果在S32K148上要用3路CAN就需要在Can模块里配置多个Controller每个Controller对应CAN0/CAN1/CAN2。需要注意S32K1 MCAL包里的Can模块名字通常带芯片后缀Can_17_FlexCan和STM32那种裸奔寄存器操作完全不是一个风格。AUTOSAR MCAL配置的特点是“一个模块实例对应一个物理外设”但每个实例内部又可以分成多个Controller和多个HardwareObject。3.2 CanController配置时钟、波特率、采样点在Can_17_FlexCan模块内部首先配置全局参数比如CAN时钟源选择和中断优先级分配。S32K148的MCAL里提供了一个叫CanClockReference的点用来选择CAN模块的时钟源是系统时钟还是FIRC。这里建议直接选系统时钟因为系统时钟精度可控而FIRC精度只有几个百分比到高低温情况下漂移会比较明显对CAN通信的采样点影响较大。然后进入CanController节点这个节点要配置CAN波特率。每个控制器节点下有一个CanControllerBaudRateConfig的数组每个数组元素对应一组波特率参数。参数包括CanControllerBaudRate目标波特率比如500000或250000CanControllerBaudRateConfigID索引ID用于多速率切换CanControllerPropSeg传播段CanControllerSeg1相位缓冲段1CanControllerSeg2相位缓冲段2CanControllerPrescaler分频系数CanControllerSyncJumpWidth同步跳转宽度这些值需要根据CAN时钟频率和期望波特率来算。比如CAN时钟80MHz500kbps分频系数Prescaler8总线时间TQ8/80MHz100ns一个位时间20 TQ2us正好500kbps。此时PropSeg可以设0Seg1设13Seg2设6SJW设4采样点(113)/2070%不对我上面说了要80%那怎么凑其实这里Sampling Point的计算是(1Seg1)/(1Seg1Seg2)如果想让采样点在80%那(1Seg1)/(1Seg1Seg2)0.8也就是20个TQ里前16个TQ采样。通常做法是Seg1设14Seg2设5再加上Sync Seg的1总共20。这样(114)/2075%还不是80%。要达到80%可以改成Seg115Seg24总共115420采样点(115)/2080%。S32K1的FlexCAN支持Seg1最大16Seg2最大8所以这种配置完全合法。我在生产项目里用的就是Seg115Seg24SJW4Prescaler8800kbps不对80MHz/810MHz10MHz/20500kbps对的采样点80%。比默认的75%更稳一点尤其是总线比较长、节点多的时候。3.3 HardwareObject配置MB的分配和使用模式接下来是CAN驱动配置最让人头疼的部分CanHardwareObject。这部分对应FlexCAN里的Message Buffer需要把所有用到的邮箱都提前规划好。S32K148的CAN0和CAN1各有64个MBCAN2只有32个MBMB的ID从0到63。每个MB可以配置为接收或发送还可以配置为FIFO模式或普通模式。在EB Tresos的CanHardwareObject里每一个MB对应一个CanHardwareObject节点需要配置CanHardwareObjectType接收RECEIVE还是发送TRANSMITCanHandleType基础邮箱模式还是FIFO模式CanHwObjectCount对象个数一般设1CanIdType标准帧还是扩展帧还是两者都支持CanObjectIdHTH或HRH的句柄ID用于上层映射我在项目里给CAN0分配了6个接收MB1个发送MB再配一个FIFO用于接收诊断报文。CAN1分配8个接收MB2个发送MB。CAN2因为波特率低、报文少只分配了4个接收MB和1个发送MB。这里要提个实战经验MB的编号并不是随便分配的FlexCAN的接收匹配是从MB0开始往后查的发送则优先使用编号较小的空闲MB。接收MB编号越小匹配优先级越高。如果在配置里第0个MB配给低频低优先级报文而高频报文放在MB15那中断来了之后报文处理顺序会出问题。所以接收MB的顺序最好按报文的实时性要求从低到高排列MB0放最重要的报文。3.4 CAN收发器CanTrcv的配置CanTrcv模块在EB Tresos里是CanTrcv_34_FlexCanTrcv这个模块纯属NXP的私有实现标准AUTOSAR里并没有把它统一。它的作用是控制收发器芯片比如使能/禁用收发器、查询收发器状态、设置收发器工作模式。如果你用的收发器是TJA1043这种带SPI接口的需要在CanTrcv模块里配置SPI通道的片选号、CS极性、SPI时钟频率等。如果是普通收发器比如TJA1051不需要额外配置模块只是做简单的电平控制。因为TJA1043有Standby模式、Normal模式和Sleep模式MCAL里提供了一组枚举值对应这些模式。配置的时候可以先选默认Normal模式然后在代码里根据网络管理状态切换。我实际踩过一个坑在调试CAN0的时候收发器模式下发了Normal命令但是总线上一点波形都没有。后来发现是TJA1043的INH引脚接的是MCU的一个GPIO而这个GPIO在Port模块里被配置成了高电平输出恰好把TJA1043的INH拉到了低电平收发器直接进Standby了。最后把Port的初始电平改成低电平输出问题立刻解决。这种问题EB Tresos里根本查不到真的只能靠示波器和逻辑分析仪慢慢定位。3.5 中断优先级和回调函数的映射CAN驱动要跑起来中断配置必须正确。在EB Tresos里Can模块的中断是在CanGeneral里面配置的比如Can_17_FlexCan的全局中断使能和中断优先级、以及每个Controller的FIFO中断和MB中断。S32K148的CAN0和CAN1各有独立中断向量CAN2就不一样它和CAN0共用一部分中断逻辑。我这边将CAN0的普通中断优先级设为11FIFO中断设为11CAN1设成12CAN2设成13。在Mcu模块里还要使能对应的中断向量否则配置了也会静默失效这是MCAL常见问题。回调函数这边MCAL会生成Can_17_FlexCan_RxIndication和Can_17_FlexCan_TxConfirmation这样的上层接口函数这些函数是给上层模块CanIf调的不需要你手动实现但你需要确认CanIf和PduR的配置已经连接好否则报文到了MCAL一层没人管白白丢包。4. 上层模块连接与PDU映射4.1 PduR和CanIf的配置AUTOSAR的架构里MCAL的Can模块不是直接和业务逻辑打交道的它上面还有一层CanIfCAN接口模块再往上才是PduRPDU路由和应用层。CanIf负责把CAN报文映射到对应的PDUProtocol Data Unit并管理报文收发确认、错误处理等。PduR则负责路由PDU到对应的上层模块比如CanTp或Com。配置顺序是这样先在PduR模块里定义好需要使用的PDU每个PDU要配置DLC数据长度、Hth发送句柄或Hrh接收句柄然后到CanIf模块里把PDU和具体的CAN ID、收发类型、底层CanHardwareObject关联起来。这一步比较考验对AUTOSAR概念的理解如果PDU和Hth对应错了编译能过运行起来就是发不出去或者收不到。我还遇到过一个神奇的问题配置完CanIf之后发送一个周期报文TX中断也触发了可是到总线上看就是没有数据。后来发现CanIf模块里的CanIfTxConfirmPduSupport配置成FALSETX确认回调没有传给上层导致上层误以为发送失败把报文停了。这个属于配置项语义理解不到位但代码是不报错的卡了我一个下午。4.2 周期报文和事件报文的发送方式CAN报文中周期报文如50ms或100ms周期和事件报文如故障触发发送在EB Tresos里的配置方式是不同的。周期报文需要在CanIf模块里配置CanIfTxPduData并设置发送周期同时使用CanIf_Transmit函数触发。事件报文则在需要发送的时刻调用CanIf_Transmit底层用同一个Hth发送。有一种常见做法是在CAN驱动配置完成后额外添加一个OS任务周期调用CanIf_Transmit或者Can_Write。对于周期报文你就可以直接在任务里周期调用Can_Write把报文填进去。Can_Write函数会找一个空闲的发送MB把报文写入并触发发送。这里有个性能优化的点如果只使用一个发送MB周期报文调用Can_Write时如果上一个报文还没发完函数会返回CAN_BUSY上层要么丢包要么需要重发。所以发送MB的数量最好和周期报文的路数差不多或者把发送方式改成“使用FIFO发送”这样即使一帧接着一帧也能排队发送。我自己在实际项目中是在CanIf里配置了3个发送PDU对应3个HTH底层用3个发送MB分别发送50ms周期报文、100ms周期报文和故障事件报文。这样互不干扰即使某个报文因为总线忙被阻塞也不会影响其他通道。5. 常见问题与排查技巧实录5.1 配置和生成的代码没进工程这个问题可以说是遇到最多的了。在EB Tresos里完成后台代码生成却发现编译工程里根本没有生成的文件。主要原因是GENERATED_CODE路径没有指到工程目录或者EB Tresos工程和编译工程不在同一个workspace里。NXP官方MCAL包发布时带有两个目录一个存放EB Tresos的插件工程另一个存放编译的IDE工程比如S32 Design Studio。需要手动把EB Tresos生成的代码路径指向IDE工程里的“output”文件夹或者直接把生成的代码拷贝到IDE工程中。最简单的方法是在EB里生成到默认目录然后把生成的output文件夹整个复制到S32DS工程的src目录下。如果你用的是S32 Design Studio配合EB Tresos网上能搜到一个名为“S32K1xx_MCAL_IntegrationGuide”的PDF这里面写清楚了路径怎么映射。很多工程编译报的小毛病其实都是这一步没做对。5.2 Can_Write返回BUSY的闪断问题这个Bug在项目调试中非常典型。周期发送一个报文示波器上看起来一切正常但上层检测到偶发漏发。查下来发现Can_Write函数偶尔会返回CAN_BUSY上层写了重发逻辑但重发也有延迟导致报文周期偶尔跳变。原因就是接收MB和发送MB是共用一组硬件的发送的时候如果正好来了一个接收中断接收中断服务函数可能会临时占用CPU导致发送时机延迟。另一个原因是发送MB配置太少上一帧没发完下一帧就来了。解决方法是增加发送MB数量或者配置成发送队列TX Queue模式。FlexCAN支持把一个MB配置为FIFO模式发送FIFO可以让多帧数据自动排队发送这对提高总线利用率非常有效。我当时把CAN0的发送方式改成FIFO模式配置了8个发送MB丢包率直接降为0。5.3 采样点不对导致的周期性错误帧CAN通信中有时候会出现一种奇怪的现象单独两个节点通信一切正常但是加上第三个节点后第三个节点就疯狂报错甚至影响整个网络的通信。检查CAN_H和CAN_L电平都正常但错误计数在不断增加。这种问题的很大概率是采样点设置不和。不同节点的采样点差异过大在一个节点采样的时候另一个节点的电平还在跳变就容易误码。AUTOSAR规范建议所有节点采样点尽量一致BCM项目里一般要求所有ECU的采样点都设在80%左右。排查方法是使用CANoe或者周立功的CAN分析仪查看总线上节点的错误帧类型和错误计数器。如果错误帧是Form Error或者Stuff Error基本就是采样点的问题需要重新调整Seg1和Seg2的比例。我在一个项目里曾经遇到其他供应商的ECU采样点设在了70%而我们的是80%结果那个ECU一上总线整个网络的错误率就飙升。后来我们统一把采样点改成75%左右才解决有时候妥协比硬刚更实际。5.4 用周立功CAN盒做调试的几个细节调试CAN驱动必然要用到CAN分析工具我在项目里用的比较多的是周立功的USBCAN-II和USBCANFD-200U。周立功CAN盒的驱动安装有个细节——很多人在Windows上装完驱动后设备管理器能看到设备但打开ZCANPRO居然识别不到通常是USB驱动和上位机版本不匹配。建议直接装周立功官网最新的CANPro或者ZCANPRO软件它会自动装好对应驱动。装好之后在ZCANPRO里添加通道设置波特率500k就能正常收发了。如果识别不到试一下换一个USB口或者把设备的“USB Selective Suspend”选项关掉这个选项经常导致USB设备丢掉。另外用周立功CAN盒接收时要注意它和ECU的CAN_H和CAN_L要共地否则容易出现乱码。我在实验室里试过一次没共地收到的报文全是0x7FE这种垃圾ID排查了半天才发现是地线没接。5.5 NXP的FreeMASTER和Trace工具辅助调参最后提一下NXP的调试工具链。S32K1系列如果裸机开发可以用S32 Design Studio自带的调试器。如果要做实时变量查看和参数标定NXP官方推荐FreeMASTER工具它可以通过UART或者CAN来实时查看芯片内部的变量。我的实践经验是在调试CAN驱动时用FreeMASTER通过UART比如LPUART把MCAL内部的一些关键变量——比如Can_17_FlexCan的收发错误计数、MB状态寄存器内容——传出来看效果非常好。比如CAN总线有错误我可以把错误计数器读出来分辨是发送错还是接收错、是位错误还是填充错误。这种定位速度比盲改配置快了一个数量级。如果项目里必须用CAN Trace功能S32K1 MCAL的Can模块也支持Can_17_FlexCan_SetControllerMode等函数来做总线状态查询你可以周期调用它监控每个下CAN控制器的BusOff状态当总线上出现BusOff时MCAL会有回调函数通知上层你可以在回调里做恢复处理这个必须要做——因为如果不处理BusOff总线就彻底瘫了直到你手动复位。6. 避坑指南与经验总结6.1 配置顺序不能乱EB Tresos配置MCAL顺序很重要。我的习惯是先配置Mcu时钟树确保FlexCAN的时钟源有输出再配置Port引脚将CAN的TX/RX引脚复用为CAN功能接着配置Can控制器波特率采样点再配置CanHardwareObject邮箱分配然后配置CanTrcv和Spi如果用到最后配置PduR和CanIf做PDU映射如果先配Can再配Mcu可能出现生成代码的时候某些寄存器初始化顺序不对尤其Mcu模块里有个McuClockSettingConfig它会统一初始化系统时钟和总线时钟如果Can模块先于Mcu模块执行初始化CAN控制器可能读到一个未使能的时钟直接进HardFault。6.2 保存和比较配置版本EB Tresos的工程文件是一堆.arxml文件建议把这些文件纳入Git之类的版本管理。每次改动配置后编译之前先用EB Tresos的“Check Configuration”功能过一遍很多低级错误比如CAN ID重复、DLC超长、HTH索引超出范围在check阶段就会报出来不用等编译再报。我在项目里还会定时把生成的代码和上一版做个diff看看到底改了什么有时候EB Tresos会因为你改了一个无关选项导致大量代码重生成这种变更如果没有版本控制排查回归问题会非常痛苦。6.3 不要过度迷信Demo代码NXP的MCAL包里的示例工程S32K148_MCAL_CAN改一改就能跑这个没问题但要注意示例工程可能只覆盖了部分芯片型号和引脚配置。实际项目里你用的引脚、时钟、波特率几乎都不一样所以一定要理解每个配置项的含义而不是拷贝Demo配置。比如Demo里CAN0用的是PTA12/PTA13复用而你板子上用的是PTD0/PTD1漏改Port配置就会出现代码明明对了示波器却量不到信号的问题。还有Demo里CAN的采样点设置在75%但上面说了实际干线较长的网络建议调到80%左右。6.4 MCAL调试验证清单每次配完CAN驱动我建议按这个顺序过一遍用示波器看TX引脚是否有波形先查物理层用CAN分析工具看是否发送出周期报文再查数据链路短接CAN_H和CAN_L看是否能产生错误帧验证收发器模式用另一块开发板或CAN盒做收发通信验证采样点一致性跑一段时间CAN通信看错误计数器是否有累积验证稳定性最后再做总线休眠唤醒测试确认CanTrcv的模式切换验证网络管理链路这套流程走下来CAN驱动的可靠性基本就有保障了。6.5 关于周立功CAN盒驱动安装的一个小补充因为项目上要用周立功的CAN盒时不时抓包这里补充一下windows下驱动安装的步骤。去周立功官网下“USBCAN-II 驱动及示例程序”一般是个压缩包解压后有一个setup.exe安装完插上设备Windows会自动识别为“ZLG USBCAN-II”。然后在设备管理器里确认没有黄叹号。接着装上“CANPro 协议分析软件”启动后选择设备类型“USBCAN-II”设置波特率500k打开通道。如果软件启动时提示“打开设备失败”大概率是软件版本和设备固件不匹配去官网找对应固件升级工具刷一下就行。另外一个容易忽略的点USBCAN-II的CAN_H和CAN_L接线别接反接反的话数据是收不到的但设备不会报错。这个我见过好几个工程师被坑过看着工具正常打开但就是没波形折腾半天发现只是两根线换一下的事。最后再说两句这些就是我在S32K1 MCAL配置CAN驱动这条路上积攒的一些实战经验。MCAL这东西一开始接触会觉得配置项太多、太繁琐尤其是从裸机开发转过来的很容易被EB Tresos里层层嵌套的配置界面搞得头晕。但多做两个项目之后你会发现只要把时钟树、CAN控制器、邮箱、收发器、PDU这五块逻辑理清楚剩下的就是细枝末节的体力活。我个人的一个习惯是每次拿到新的板子先花一天时间把最小CAN驱动调通不管上层协议就用周期发送函数往总线上发数据用周立功CAN盒在那边看着。只要这一层通了后面接Diagnostic、接NM、接COM就都水到渠成。千万不要一上来就把所有功能都堆到一起配置出了问题根本无从下手。希望这篇实战笔记能帮到正在折腾S32K1和EB Tresos的朋友。如果后面有空我再写一篇关于CAN FD和S32K3系列MCAL配置的对比那个坑也不少等攒够素材了再说。