DMAディスクリプタを使用して1024バイトを超えるデータを受信する（LPC55S69） コミュニティの皆様、こんにちは。 DMAの最大転送サイズが1024バイトであることを考慮すると、 DMAを介して大量のデータ（2000バイト以上）をLPC55S69ボードに受信する方法を見つけるのに苦労していました。 「usart_dma_double_buffer_transfer」の例を見てみましたが、例えば以下のような機能が古くなっていました。 DMA_PrepareTransfer() は DMA_PrepareChannelTransfer() に、DMA_SubmitTransfer() は DMA_SubmitChannelTransfer() に、DMA_CreateDescriptor() は DMA_SetupDescriptor() に変更されました。SO、例には表示されなかったこれらの新しい関数の新しい入力パラメータ、特に新しいDMA_SetupDescriptor()にあるDMAの転送構成パラメータ "xfercfg" を入力するのに少し迷ってしまいました。 [[ ## completed ##]] 「dma_channel_chain」というサンプルコードも確認しましたが、新しい関数のいくつかについて別の視点を得るのに役立ちましたが、まさに私が探していたものではありませんでした。 さらに、 DMA卓球アプリケーション - NXPコミュニティという記事も見ましたが、私が使っていたLPCボードとは完全に互換性がありませんでした。 オンラインで得た情報をまとめ、キーボードに頭を打ち付けて、 ついに目的の場所にたどり着き、DMAを通じて大量のデータを受け取った。 （データはそれぞれ1024バイトの3つの異なるバッファに保存されます） SO、この 機会にコードを共有して、同じ 道を歩んでいる方の助けになれたり、指針を提供できればと思っています。また、この素晴らしいコミュニティから学んだことを少しでも還元したいと思っています。 (これは質問というわけではなく、議論の余地があるトピックであることを考えると、ここに投稿しても問題ないことを願っています。) 幸運を祈ります！ #include "fsl_usart_dma.h" #include "fsl_dma.h" #define NUMBER_DESCRIPTORS 3 #define DESCRIPTOR_TRANSFER_SIZE 1024 #define RX_BUFFER_SIZE 1024 uint8_t g_data_buffer[RX_BUFFER_SIZE]; uint8_t g_data_1[RX_BUFFER_SIZE]; uint8_t g_data_2[RX_BUFFER_SIZE]; uint8_t g_data_3[RX_BUFFER_SIZE]; /* Custom Descriptors (Must be 16-byte aligned) */ SDK_ALIGN(dma_descriptor_t g_Desc[NUMBER_DESCRIPTORS], 16); /* equal to writing: __attribute__((aligned(FSL_FEATURE_DMA_LINK_DESCRIPTOR_ALIGN_SIZE))) dma_descriptor_t g_Desc[NUMBER_DESCRIPTORS] = {0}; or DMA_ALLOCATE_LINK_DESCRIPTORS_AT_NONCACHEABLE(g_Desc, NUMBER_DESCRIPTORS); */ /* Function definitions ****************************************************************************/ //Initialising Rx DMA to receive data bigger than 1024 bytes. void init_USART_DMA(void){ //Channel configuration for DMA descriptor dma_channel_config_t channelConfig; /* 1. System/Peripheral Level Init */ // Done in peripheral.c, initialized the functions USART_Init(), DMA_EnableChannel(), DMA_CreateHandle(), USART_TransferCreateHandleDMA(). /*I have not used the function DMA_SubmitChannelDescriptor(), by giving as input the g_ChannelTable, as it would not allow to receive data. the g_ChannelTable variable should be initalized as follow: //Allocates the mandatory, 512-byte aligned master table in RAM used by the hardware to manage all DMA channels SDK_ALIGN(dma_descriptor_t g_ChannelTable[FSL_FEATURE_DMA_MAX_CHANNELS], 512); then call the function here in the code DMA_SubmitChannelDescriptor(FLEXCOMM5_USB_PC_RX_Handle,g_ChannelTable); */ /* 2. Enable USART RX DMA requests */ USART_EnableRxDMA(FLEXCOMM5_USB_PC_PERIPHERAL, true); /* 3. Prepare the Descriptor Configuration Variable Flags */ //Intermediate Descriptors, where it jumps from one to another /* Common XFER configuration options for intermediate descriptors (1, 2,...) */ /* reload = true (keeps the chain moving to the next descriptor) */ /* intA = false (we only want the final interrupt when everything is done) */ uint32_t intermediatexfercfg = DMA_CHANNEL_XFER( true, /* reload: true to move to the next descriptor */ false, /* clrTrig: false */ false, /* intA: false */ false, /* intB: false */ sizeof(uint8_t), /* width: 1 byte for USART char processing */ kDMA_AddressInterleave0xWidth, /* srcInc: 0x (read from fixed USART FIFO address) */ kDMA_AddressInterleave1xWidth, /* dstInc: 1x (increment buffer pointer by 1 byte) */ DESCRIPTOR_TRANSFER_SIZE /* totalBytes: DESCRIPTOR_TRANSFER_SIZE */ ); //Final Descriptor, where it stops jumping to another descriptor /* Final XFER configuration options for the last descriptor */ /* reload = false (this is the end of the chain) */ /* clrTrig = true (stop the DMA hardware channel) */ /* intA = true (fire the completion interrupt) */ uint32_t finalxfercfg = DMA_CHANNEL_XFER( false, /* reload: false because this is the terminal descriptor */ true, /* clrTrig: true to clear peripheral hardware requests */ true, /* intA: true to fire our completion interrupt */ false, /* intB: false */ sizeof(uint8_t), /* width: 1 byte for USART char processing */ kDMA_AddressInterleave0xWidth, /* srcInc: 0x (read from fixed USART FIFO address) */ kDMA_AddressInterleave1xWidth, /* dstInc: 1x (increment buffer pointer by 1 byte) */ DESCRIPTOR_TRANSFER_SIZE /* totalBytes: DESCRIPTOR_TRANSFER_SIZE */ ); /* 4. Configure the Custom Descriptors structure */ //Descriptor #0 DMA_SetupDescriptor( &g_Desc[0], intermediatexfercfg, (void *)&FLEXCOMM5_USB_PC_PERIPHERAL->FIFORD, /* Source address: USART FIFO Read Register */ &g_data_1[0], /* Destination address: RAM buffer */ &g_Desc[1] /* Point to next descriptor */ ); //Descriptor #1 DMA_SetupDescriptor( &g_Desc[1], intermediatexfercfg, (void *)&FLEXCOMM5_USB_PC_PERIPHERAL->FIFORD, /* Source address: USART FIFO Read Register */ &g_data_2[0], /* Destination address: RAM buffer */ &g_Desc[2] /* Point to next descriptor */ ); //Descriptor #2 (final) DMA_SetupDescriptor( &g_Desc[2], finalxfercfg, (void *)&FLEXCOMM5_USB_PC_PERIPHERAL->FIFORD, /* Source address: USART FIFO Read Register */ &g_data_3[0], /* Destination address: RAM buffer */ NULL /* Final descriptor, does not move to another*/ ); /* 5. Set up Head Transfer to execute first descriptor first */ /* Point the initial hardware channel block straight to the first buffer to save data */ DMA_PrepareChannelTransfer( &channelConfig, /* 1. Pointer to configuration structure */ (void *)&FLEXCOMM5_USB_PC_PERIPHERAL->FIFORD, /* 2. Source start address */ (void *)&g_data_1[0], /* 3. Destination start address */ DMA_CHANNEL_XFER( /* 4. Initial transfer settings bitmask */ true, /* reload: true to step into linked descriptor */ false, false, false, sizeof(uint8_t), kDMA_AddressInterleave0xWidth, kDMA_AddressInterleave1xWidth, DESCRIPTOR_TRANSFER_SIZE ), kDMA_PeripheralToMemory, /* 5. Transfer type enum path */ NULL, /* 6. Hardware Trigger parameters (NULL uses default peripheral request) */ &g_Desc[1] /* 7. Address of next descriptor. (including already 2nd descriptor, as this will already transfer all the data to begining of rxBuffer like first descriptor would have done*/ ); DMA_SubmitChannelTransfer(&FLEXCOMM5_USB_PC_RX_Handle,&channelConfig); DMA_StartTransfer(&FLEXCOMM5_USB_PC_RX_Handle); } LPC55xx ペリフェラル Re: Using DMA Descriptors to receive Data bigger than 1024 bytes (LPC55S69) こんにちは、 調査結果とコードを共有していただきありがとうございます。このコミュニティは発見を共有したり、質問したり、指導やサポートを提供したりするのに素晴らしい場所SO、ここに投稿していただき感謝しています。 さらにご不明な点やご要望がございましたら、お気軽にお問い合わせください。 敬具、ルイス

SGTL5000XNLA3/R2 はアクティブな部分です チームの皆さん、こんにちは。 この部品SGTL5000XNLA3/R2はアクティブですか？新しいデザインにCANを使えますか? データシートはEOLと記載されています Re: SGTL5000XNLA3/R2 is part is active わかりました。ご回答ありがとうございます。 Re: SGTL5000XNLA3/R2 is part is active SGTL5000XNLA3 製品情報 |NXP Semiconductors guoweisun_0-1785821314080.png データシートには以下のように記載されています。 guoweisun_1-1785824177846.png

S32K324 FlexIO SPI Master Emulation (S32DS 3.5 / RTD 4.0.0 ) Hello, I am configuring a FlexIO-emulated SPI Master on an S32K324 to communicate with an external SPI slave device. Due to trace routing on our custom board, the physical lines targeting this device are wired to the chip's default FlexSPI0 pins. Therefore, I must use the emulated Flexio_Spi driver stack. this is my setup BUS_FLEXSPI0_UP_SBC_CS PTD8 fxio_d11 BUS_FLEXSPI0_UP_SBC_CLK PTD9 fxio_d0 BUS_FLEXSPI0_UP_SBC_MOSI PTD15 fxio_d10 BUS_FLEXSPI0_UP_SBC_MISO PTD22 fxio_d27 My Environment: IDE:S32 Design Studio for S32 Platform (Version: 3.5, Build id: 240726 Update 13) CPU : S32K324 SDK: Real-Time Drivers (RTD) Version 4.0.0 (Production Release) Is there an official NXP application note or guide that illustrates the end-to-end integration stack specifically for RTD 4.0.0? I need a reference that covers everything from assigning the pins in the tool, mapping the shifters/timers, up to initializing the driver in the main application code. Re: S32K324 FlexIO SPI Master Emulation (S32DS 3.5 / RTD 4.0.0 ) Hello @Kazarian , There is no dedicated application note, to my knowledge, that describes the full end-to-end integration of FlexIO-emulated SPI specifically for S32K324 with RTD 4.0.0 and with this exact pin assignment. The closest official reference is the example project included in the S32K3 RTD package. Please check the RTD example similar to  Lpspi_Flexio_Ip_Transfer_S32K344. This example demonstrates the intended RTD integration flow for FlexIO-based SPI transfer, including the FlexIO SPI driver initialization and the relation between LPSPI and FlexIO SPI instances.   For your custom board, the main points to adapt are the following (as a general guidance): Pins configuration Configure the listed pins in the Pins tool as FlexIO signals: PTD8 → FXIO_D11, chip select PTD9 → FXIO_D0, clock PTD15 → FXIO_D10, MOSI PTD22 → FXIO_D27, MISO Make sure the MISO pin has the input buffer enabled. Also verify in the S32K324 IOMUX/pinout documentation that these FlexIO functions are available for your exact package. FlexIO SPI configuration In the FlexIO SPI configuration, map the SPI signals to the corresponding FlexIO pin numbers, not only to the physical MCU pins: SCK = FXIO_D0 MOSI = FXIO_D10 CS = FXIO_D11 MISO = FXIO_D27 Assign the required FlexIO timers and shifters consistently with the generated configuration. Best regards, Pavel

etpuc mpc5775 我想运行 eTPUC 中 cw 函数选择器中的一个函数。我知道 etpuc 的起始/结束 RAM 地址（与 mpc5777c_vars_c.h 相同）。我相应地修改了 etpuc 的my_system_etpu_init 函数。我只是复制函数文件（比如crank），然后为etpuc生成新文件。 在运行所有程序并暂停程序时，调试器卡住，显示“PC：找不到“0x800400”的源”。 哪里出了问题？ Re: etpuc mpc5775 下面有几篇应用笔记，关于 etpu 初始化代码有哪些更改？ AN5374：应用程序中的 eTPU 库使用 – 应用笔记 AN4907：发动机控制 eTPU 库 – 应用笔记 AN2864：eTPU 的通用 C 函数 – 应用笔记 AN4908：发动机控制 eTPU 演示应用 – 应用笔记 Re: etpuc mpc5775 eTPU代码是如何生成的？您是使用函数选择器生成了完整的函数集，还是只复制了 CRANK 函数文件？ 能否分享一下您修改后的 my_system_etpu_init() 实现？ 初始化过程中，生成的 eTPU 代码映像是否已成功加载到 SCM 中？ 能否提供生成的 eTPU 项目文件（例如：etpu_set.c，etpu_set.h）？ 电脑总是停在 0x800400 这个错误代码处，还是会变化？

使用 DMA 描述符接收大于 1024 字节的数据 (LPC55S69) 大家好， 考虑到 DMA 的最大传输大小为 1024 字节，我一直难以找到一种方法，通过 DMA 将大量数据（超过 2000 字节）接收到我的 LPC55S69 板。 我查看了示例“usart_dma_double_buffer_transfer”，但是其中一些函数已经过时，例如： DMA_PrepareTransfer() 变为 DMA_PrepareChannelTransfer()，DMA_SubmitTransfer() 变为 DMA_SubmitChannelTransfer()，DMA_CreateDescriptor() 变为 DMA_SetupDescriptor()。因此，我在填写这些新函数的新输入参数时有点迷茫，这些参数在示例中没有出现，主要是参数“xfercfg”，即新 DMA_SetupDescriptor() 中 DMA 描述符的传输配置。 我还查看了示例“dma_channel_chain”，它帮助我从另一个角度了解了一些新功能，但它并不完全符合我的需求。 此外，我还查看了NXP 社区的文章“DMA Ping-Pong 应用” ，但它与我正在使用的 LPC 板并不完全兼容。 在综合了我能从网上获取的信息，并绞尽脑汁敲击键盘之后，我终于达到了我想要的目标，即通过 DMA 接收大量数据。（将数据保存到 3 个不同的缓冲区中，每个缓冲区大小为 1024 字节） 因此，我借此机会分享这段代码，希望能对那些曾经和我一样迷茫的人有所帮助或提供一些指导。我也想尽我所能，将我从这个美好的社区学到的一切回馈给大家。 （希望在这里发帖没问题，因为这与其说是一个问题，不如说是一个可以讨论的话题。） 祝你好运！ #include "fsl_usart_dma.h" #include "fsl_dma.h" #define NUMBER_DESCRIPTORS 3 #define DESCRIPTOR_TRANSFER_SIZE 1024 #define RX_BUFFER_SIZE 1024 uint8_t g_data_buffer[RX_BUFFER_SIZE]; uint8_t g_data_1[RX_BUFFER_SIZE]; uint8_t g_data_2[RX_BUFFER_SIZE]; uint8_t g_data_3[RX_BUFFER_SIZE]; /* Custom Descriptors (Must be 16-byte aligned) */ SDK_ALIGN(dma_descriptor_t g_Desc[NUMBER_DESCRIPTORS], 16); /* equal to writing: __attribute__((aligned(FSL_FEATURE_DMA_LINK_DESCRIPTOR_ALIGN_SIZE))) dma_descriptor_t g_Desc[NUMBER_DESCRIPTORS] = {0}; or DMA_ALLOCATE_LINK_DESCRIPTORS_AT_NONCACHEABLE(g_Desc, NUMBER_DESCRIPTORS); */ /* Function definitions ****************************************************************************/ //Initialising Rx DMA to receive data bigger than 1024 bytes. void init_USART_DMA(void){ //Channel configuration for DMA descriptor dma_channel_config_t channelConfig; /* 1. System/Peripheral Level Init */ // Done in peripheral.c, initialized the functions USART_Init(), DMA_EnableChannel(), DMA_CreateHandle(), USART_TransferCreateHandleDMA(). /*I have not used the function DMA_SubmitChannelDescriptor(), by giving as input the g_ChannelTable, as it would not allow to receive data. the g_ChannelTable variable should be initalized as follow: //Allocates the mandatory, 512-byte aligned master table in RAM used by the hardware to manage all DMA channels SDK_ALIGN(dma_descriptor_t g_ChannelTable[FSL_FEATURE_DMA_MAX_CHANNELS], 512); then call the function here in the code DMA_SubmitChannelDescriptor(FLEXCOMM5_USB_PC_RX_Handle,g_ChannelTable); */ /* 2. Enable USART RX DMA requests */ USART_EnableRxDMA(FLEXCOMM5_USB_PC_PERIPHERAL, true); /* 3. Prepare the Descriptor Configuration Variable Flags */ //Intermediate Descriptors, where it jumps from one to another /* Common XFER configuration options for intermediate descriptors (1, 2,...) */ /* reload = true (keeps the chain moving to the next descriptor) */ /* intA = false (we only want the final interrupt when everything is done) */ uint32_t intermediatexfercfg = DMA_CHANNEL_XFER( true, /* reload: true to move to the next descriptor */ false, /* clrTrig: false */ false, /* intA: false */ false, /* intB: false */ sizeof(uint8_t), /* width: 1 byte for USART char processing */ kDMA_AddressInterleave0xWidth, /* srcInc: 0x (read from fixed USART FIFO address) */ kDMA_AddressInterleave1xWidth, /* dstInc: 1x (increment buffer pointer by 1 byte) */ DESCRIPTOR_TRANSFER_SIZE /* totalBytes: DESCRIPTOR_TRANSFER_SIZE */ ); //Final Descriptor, where it stops jumping to another descriptor /* Final XFER configuration options for the last descriptor */ /* reload = false (this is the end of the chain) */ /* clrTrig = true (stop the DMA hardware channel) */ /* intA = true (fire the completion interrupt) */ uint32_t finalxfercfg = DMA_CHANNEL_XFER( false, /* reload: false because this is the terminal descriptor */ true, /* clrTrig: true to clear peripheral hardware requests */ true, /* intA: true to fire our completion interrupt */ false, /* intB: false */ sizeof(uint8_t), /* width: 1 byte for USART char processing */ kDMA_AddressInterleave0xWidth, /* srcInc: 0x (read from fixed USART FIFO address) */ kDMA_AddressInterleave1xWidth, /* dstInc: 1x (increment buffer pointer by 1 byte) */ DESCRIPTOR_TRANSFER_SIZE /* totalBytes: DESCRIPTOR_TRANSFER_SIZE */ ); /* 4. Configure the Custom Descriptors structure */ //Descriptor #0 DMA_SetupDescriptor( &g_Desc[0], intermediatexfercfg, (void *)&FLEXCOMM5_USB_PC_PERIPHERAL->FIFORD, /* Source address: USART FIFO Read Register */ &g_data_1[0], /* Destination address: RAM buffer */ &g_Desc[1] /* Point to next descriptor */ ); //Descriptor #1 DMA_SetupDescriptor( &g_Desc[1], intermediatexfercfg, (void *)&FLEXCOMM5_USB_PC_PERIPHERAL->FIFORD, /* Source address: USART FIFO Read Register */ &g_data_2[0], /* Destination address: RAM buffer */ &g_Desc[2] /* Point to next descriptor */ ); //Descriptor #2 (final) DMA_SetupDescriptor( &g_Desc[2], finalxfercfg, (void *)&FLEXCOMM5_USB_PC_PERIPHERAL->FIFORD, /* Source address: USART FIFO Read Register */ &g_data_3[0], /* Destination address: RAM buffer */ NULL /* Final descriptor, does not move to another*/ ); /* 5. Set up Head Transfer to execute first descriptor first */ /* Point the initial hardware channel block straight to the first buffer to save data */ DMA_PrepareChannelTransfer( &channelConfig, /* 1. Pointer to configuration structure */ (void *)&FLEXCOMM5_USB_PC_PERIPHERAL->FIFORD, /* 2. Source start address */ (void *)&g_data_1[0], /* 3. Destination start address */ DMA_CHANNEL_XFER( /* 4. Initial transfer settings bitmask */ true, /* reload: true to step into linked descriptor */ false, false, false, sizeof(uint8_t), kDMA_AddressInterleave0xWidth, kDMA_AddressInterleave1xWidth, DESCRIPTOR_TRANSFER_SIZE ), kDMA_PeripheralToMemory, /* 5. Transfer type enum path */ NULL, /* 6. Hardware Trigger parameters (NULL uses default peripheral request) */ &g_Desc[1] /* 7. Address of next descriptor. (including already 2nd descriptor, as this will already transfer all the data to begining of rxBuffer like first descriptor would have done*/ ); DMA_SubmitChannelTransfer(&FLEXCOMM5_USB_PC_RX_Handle,&channelConfig); DMA_StartTransfer(&FLEXCOMM5_USB_PC_RX_Handle); } LPC55xx 外设 Re: Using DMA Descriptors to receive Data bigger than 1024 bytes (LPC55S69) 你好， 感谢您分享您的研究结果和代码。社区是分享发现、提出问题、提供指导和支持的好地方，所以我们感谢您在这里发帖。 如果您需要任何进一步的帮助，请与我们联系。 此致敬礼，路易斯

etpuc mpc5775 eTPUCのcw関数セレクタから関数の1つを実行させたいです。私はetpucの開始/終了RAMアドレスを認識しています（mpc5777c_vars_c.hと同じです）。それに応じて、etpuc 用にmy_system_etpu_init を修正しました。私は（crankのような）関数ファイルをコピーして、etpuc用の新しいファイルを生成するだけです。 すべてを実行してプログラムを中断すると、デバッガーが停止します。PC: "0x800400" のソースが利用できません 何が問題なのでしょうか？ Re: etpuc mpc5775 以下にいくつかのアプリケーションノートがありますが、ETPUイニシエーションコードについて何が変更されましたか? AN5374:アプリケーションにおけるeTPUライブラリの使用 – アプリケーションノート AN4907:エンジン制御eTPUライブラリ – アプリケーションノート [[ ## completed ##]] AN2864:eTPUの一般的なC機能 – アプリケーションノート AN4908:エンジン制御eTPUデモアプリケーション – アプリケーションノート [[ ## completed ##]] Re: etpuc mpc5775 eTPUコードはどのように生成されたのですか？関数セレクタを使って完全な関数セットを生成しましたか?それともCRANK関数ファイルをコピーしただけですか? あなたの修正されたmy_system_etpu_init()実装を教えてもらえますか? 初期化中に生成されたeTPUコードイメージはSCMに正常にロードされましたか？ 生成されたeTPUプロジェクトファイル(例:)etpu_set.c、etpu_set.h)? PCは常に0x800400で停止するのですか、それとも毎回異なるのですか？

无法为 SE051C2 生成代码 各位同事，大家好！我正在尝试将 SE051 与 FRDM-MCXN947 开发板集成。我参考了 AN13030 指南，并按照所有步骤操作，直到运行 Python 脚本生成代码，但遇到了以下错误： 找不到“cmake.exe”。假设'cmake.exe'已在路径中并且正在运行。 信息： __main__ ：正在预处理 C:\Users\yash.bawankar\Downloads\se05x_mw_v04.08.01\simw-top/ext/open62541/tools/schema/Opc.Ua.NodeSet2.Minimal.xml 信息： __main__ ：正在为后端生成代码：open62541 信息： __main__ ：节点集生成代码已成功打印 请告诉我我遗漏了什么。 FRDM 培训 MCX N 安全（Edgelock | 安全启动 | OTP） Re: Unable to generate code for SE051C2 你好@yashbawankar ， 你是打算在窗户下面建造微波设备吗？如果答案是肯定的，请确保满足以下先决条件： • 已安装 Visual Studio • 已安装 Python 3.8 32 位版本 有关先决条件安装步骤的更多详细信息，请参阅https://www.nxp.com/docs/en/application-note/AN12398.pdf 。您可以在https://www.nxp.com/docs/en/application-note/AN12398.pdf的第 8 章中找到 cmake 安装步骤。 希望对您有所帮助。 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------

SE051C2のコードを生成できません こんにちは、チームの皆さん。SE051をFRDM-MCXN947ボードに統合しようとしています。ガイドを読AN13030んで、Pythonスクリプトを実行するまですべての手順を踏んでコードを生成しましたが、このエラーが出ています: 「cmake.exe」は見つかりませんでした。「cmake.exe」がパスに含まれており、実行中であることを前提とします。 情報:__main__:P再解析 C:\Users\yash.bawankar\Downloads\se05x_mw_v04.08.01\simw-top/ext/open62541/tools/schema/Opc.Ua.NodeSet2.Minimal.xml INFO: __main__ :バックエンドのコードを生成中: open62541 INFO: __main__ :NodeSet生成コードが正常に出力されました 何か見落としている点があれば教えてください。 FRDMトレーニング MCX N セキュリティ（EdgeLock | セキュアブート | OTP） Re: Unable to generate code for SE051C2 こんにちは、 @yashbawankar さん。 MWをビルディングしていますか?はいの場合、以下の前提条件を満たしていることを確認してください。 • Visual Studioがインストールされています • Python 3.8 32ビット版がインストールされている 前提条件となるインストール手順の詳細については、 https://www.nxp.com/docs/en/application-note/AN12398.pdfを参照してください。cmake のインストール手順については、 https://www.nxp.com/docs/en/application-note/AN12398.pdfの第 8 章を参照してください。 お役に立てば幸いです。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -------------------------------------------------------------------------------

S32K324 FlexIO SPI 主控仿真（S32DS 3.5 / RTD 4.0.0） 你好， 我正在配置 S32K324 上的 FlexIO 模拟 SPI 主设备，使其与外部 SPI 从设备通信。由于我们定制电路板上的走线布局，指向该设备的物理线路连接到了芯片的默认 FlexSPI0 引脚。因此，我必须使用模拟的 Flexio_Spi 驱动程序栈。 这是我的配置 BUS_FLEXSPI0_UP_SBC_CS PTD8 fxio_d11 BUS_FLEXSPI0_UP_SBC_CLK PTD9 fxio_d0 BUS_FLEXSPI0_UP_SBC_MOSI PTD15 fxio_d10 BUS_FLEXSPI0_UP_SBC_MISO PTD22 fxio_d27 我的环境： IDE：S32 平台的 S32 设计工作室（版本：3.5，内部版本号：240726 更新 13） CPU：S32K324 SDK：实时驱动程序 (RTD) 版本 4.0.0（正式版） NXP 是否有官方的应用笔记或指南专门介绍 RTD 4.0.0 的端到端集成堆栈？我需要一份参考，引用，内容涵盖从工具中分配引脚、映射移位器/定时器，到在主应用程序代码中初始化驱动程序的所有内容。 Re: S32K324 FlexIO SPI Master Emulation (S32DS 3.5 / RTD 4.0.0 ) 你好@Kazarian ， 据我所知，目前还没有**专用的**应用笔记描述如何将 FlexIO 模拟的 SPI 完整地集成到 S32K324 和 RTD 4.0.0 中，并采用这种精确的引脚分配。 最接近的官方参考资料是 S32K3 RTD 软件包中包含的示例项目。请查看与 Lpspi_Flexio_Ip_Transfer_S32K344 类似的 RTD 示例。 本示例演示了基于 FlexIO 的 SPI 传输的预期 RTD 集成流程，包括 FlexIO SPI 驱动程序初始化以及 LPSPI 和 FlexIO SPI 实例之间的关系。   对于您的定制板，需要调整的主要要点如下（作为一般性指导）： 引脚配置 在“引脚”工具中将列出的引脚配置为 FlexIO 信号： PTD8 → FXIO_D11，片选 PTD9 → FXIO_D0，时钟 PTD15 → FXIO_D10，MOSI PTD22 → FXIO_D27，MISO 请确保 MISO 引脚已启用输入缓冲。 另外，请查看 S32K324 IOMUX/引脚图文档，确认这些 FlexIO 功能是否适用于您的特定封装。 FlexIO SPI 配置 在 FlexIO SPI 配置中，应将 SPI 信号映射到相应的 FlexIO 引脚编号，而不仅仅是物理 MCU 引脚： SCK = FXIO_D0 MOSI = FXIO_D10 CS = FXIO_D11 MISO = FXIO_D27 根据生成的配置，分配所需的 FlexIO 定时器和移位器。 顺祝商祺！ 帕维尔

Unable to generate code for SE051C2 Hello Team, I am trying to Integrate SE051 with FRDM-MCXN947 board, by reading AN13030 guide, I followed all the steps till running python script to generate code but I am getting this error:  Could not find 'cmake.exe'. Assuming 'cmake.exe' is in path and running. INFO:__main__:Preprocessing C:\Users\yash.bawankar\Downloads\se05x_mw_v04.08.01\simw-top/ext/open62541/tools/schema/Opc.Ua.NodeSet2.Minimal.xml INFO:__main__:Generating Code for Backend: open62541 INFO:__main__:NodeSet generation code successfully printed Please let me know what am I missing. FRDM-Training MCXN Security(Edgelock | secure boot | OTP) Re: Unable to generate code for SE051C2 Hi @yashbawankar , Are you building the MW under windows? If yes, please make sure the following Prerequisite are met: • Visual studio installed • Python 3.8 32 bit installed and please refer https://www.nxp.com/docs/en/application-note/AN12398.pdf  for more details on prerequisite installation steps. and you may find cmake install steps in chapter 8 within https://www.nxp.com/docs/en/application-note/AN12398.pdf . Hope that helps, Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------

Using DMA Descriptors to receive Data bigger than 1024 bytes (LPC55S69) Hello Community,  I was having difficulties to find a way to receive big amounts of data (over 2000 bytes) via DMA to my LPC55S69 board, considering that DMA has a maximum transfer size of 1024 bytes. I had a look at example "usart_dma_double_buffer_transfer" however some functions were outdated, considering for example: DMA_PrepareTransfer() became DMA_PrepareChannelTransfer(), DMA_SubmitTransfer() became DMA_SubmitChannelTransfer() and DMA_CreateDescriptor() became DMA_SetupDescriptor(). So i was a bit lost filling the new input parameters of these new functions that did not appear in the example, mostly the parameter "xfercfg" Transfer configuration for DMA descriptor present in new DMA_SetupDescriptor(). I also had a look at example "dma_channel_chain" which also helped me to get another view on some of the new functions, however it was not exactly what i was looking for.  In addition i took a look at the article DMA Ping-Pong application - NXP Community however it was not exactly compatible to the LPC board i was using. After putting altogether the information from what i could acquire online and smashing my head a bit against the keyboard i finally made it to arrive to the point i wanted, receiving big amounts of data via DMA. (Saving data in 3 different buffers, each with 1024 bytes of size) So i'm using this opportunity to share the code in the hope of being helpful or giving some guidance to maybe someone that finds itself in the same road i was before. Also trying to give back a bit from all the things i have learned from this beautiful community. (Hope that is fine that this is posted here, considering is not exactly a question, but is also a topic open for discussions). Best of luck! #include "fsl_usart_dma.h" #include "fsl_dma.h" #define NUMBER_DESCRIPTORS 3 #define DESCRIPTOR_TRANSFER_SIZE 1024 #define RX_BUFFER_SIZE 1024 uint8_t g_data_buffer[RX_BUFFER_SIZE]; uint8_t g_data_1[RX_BUFFER_SIZE]; uint8_t g_data_2[RX_BUFFER_SIZE]; uint8_t g_data_3[RX_BUFFER_SIZE]; /* Custom Descriptors (Must be 16-byte aligned) */ SDK_ALIGN(dma_descriptor_t g_Desc[NUMBER_DESCRIPTORS], 16); /* equal to writing: __attribute__((aligned(FSL_FEATURE_DMA_LINK_DESCRIPTOR_ALIGN_SIZE))) dma_descriptor_t g_Desc[NUMBER_DESCRIPTORS] = {0}; or DMA_ALLOCATE_LINK_DESCRIPTORS_AT_NONCACHEABLE(g_Desc, NUMBER_DESCRIPTORS); */ /* Function definitions ****************************************************************************/ //Initialising Rx DMA to receive data bigger than 1024 bytes. void init_USART_DMA(void){ //Channel configuration for DMA descriptor dma_channel_config_t channelConfig; /* 1. System/Peripheral Level Init */ // Done in peripheral.c, initialized the functions USART_Init(), DMA_EnableChannel(), DMA_CreateHandle(), USART_TransferCreateHandleDMA(). /*I have not used the function DMA_SubmitChannelDescriptor(), by giving as input the g_ChannelTable, as it would not allow to receive data. the g_ChannelTable variable should be initalized as follow: //Allocates the mandatory, 512-byte aligned master table in RAM used by the hardware to manage all DMA channels SDK_ALIGN(dma_descriptor_t g_ChannelTable[FSL_FEATURE_DMA_MAX_CHANNELS], 512); then call the function here in the code DMA_SubmitChannelDescriptor(FLEXCOMM5_USB_PC_RX_Handle,g_ChannelTable); */ /* 2. Enable USART RX DMA requests */ USART_EnableRxDMA(FLEXCOMM5_USB_PC_PERIPHERAL, true); /* 3. Prepare the Descriptor Configuration Variable Flags */ //Intermediate Descriptors, where it jumps from one to another /* Common XFER configuration options for intermediate descriptors (1, 2,...) */ /* reload = true (keeps the chain moving to the next descriptor) */ /* intA = false (we only want the final interrupt when everything is done) */ uint32_t intermediatexfercfg = DMA_CHANNEL_XFER( true, /* reload: true to move to the next descriptor */ false, /* clrTrig: false */ false, /* intA: false */ false, /* intB: false */ sizeof(uint8_t), /* width: 1 byte for USART char processing */ kDMA_AddressInterleave0xWidth, /* srcInc: 0x (read from fixed USART FIFO address) */ kDMA_AddressInterleave1xWidth, /* dstInc: 1x (increment buffer pointer by 1 byte) */ DESCRIPTOR_TRANSFER_SIZE /* totalBytes: DESCRIPTOR_TRANSFER_SIZE */ ); //Final Descriptor, where it stops jumping to another descriptor /* Final XFER configuration options for the last descriptor */ /* reload = false (this is the end of the chain) */ /* clrTrig = true (stop the DMA hardware channel) */ /* intA = true (fire the completion interrupt) */ uint32_t finalxfercfg = DMA_CHANNEL_XFER( false, /* reload: false because this is the terminal descriptor */ true, /* clrTrig: true to clear peripheral hardware requests */ true, /* intA: true to fire our completion interrupt */ false, /* intB: false */ sizeof(uint8_t), /* width: 1 byte for USART char processing */ kDMA_AddressInterleave0xWidth, /* srcInc: 0x (read from fixed USART FIFO address) */ kDMA_AddressInterleave1xWidth, /* dstInc: 1x (increment buffer pointer by 1 byte) */ DESCRIPTOR_TRANSFER_SIZE /* totalBytes: DESCRIPTOR_TRANSFER_SIZE */ ); /* 4. Configure the Custom Descriptors structure */ //Descriptor #0 DMA_SetupDescriptor( &g_Desc[0], intermediatexfercfg, (void *)&FLEXCOMM5_USB_PC_PERIPHERAL->FIFORD, /* Source address: USART FIFO Read Register */ &g_data_1[0], /* Destination address: RAM buffer */ &g_Desc[1] /* Point to next descriptor */ ); //Descriptor #1 DMA_SetupDescriptor( &g_Desc[1], intermediatexfercfg, (void *)&FLEXCOMM5_USB_PC_PERIPHERAL->FIFORD, /* Source address: USART FIFO Read Register */ &g_data_2[0], /* Destination address: RAM buffer */ &g_Desc[2] /* Point to next descriptor */ ); //Descriptor #2 (final) DMA_SetupDescriptor( &g_Desc[2], finalxfercfg, (void *)&FLEXCOMM5_USB_PC_PERIPHERAL->FIFORD, /* Source address: USART FIFO Read Register */ &g_data_3[0], /* Destination address: RAM buffer */ NULL /* Final descriptor, does not move to another*/ ); /* 5. Set up Head Transfer to execute first descriptor first */ /* Point the initial hardware channel block straight to the first buffer to save data */ DMA_PrepareChannelTransfer( &channelConfig, /* 1. Pointer to configuration structure */ (void *)&FLEXCOMM5_USB_PC_PERIPHERAL->FIFORD, /* 2. Source start address */ (void *)&g_data_1[0], /* 3. Destination start address */ DMA_CHANNEL_XFER( /* 4. Initial transfer settings bitmask */ true, /* reload: true to step into linked descriptor */ false, false, false, sizeof(uint8_t), kDMA_AddressInterleave0xWidth, kDMA_AddressInterleave1xWidth, DESCRIPTOR_TRANSFER_SIZE ), kDMA_PeripheralToMemory, /* 5. Transfer type enum path */ NULL, /* 6. Hardware Trigger parameters (NULL uses default peripheral request) */ &g_Desc[1] /* 7. Address of next descriptor. (including already 2nd descriptor, as this will already transfer all the data to begining of rxBuffer like first descriptor would have done*/ ); DMA_SubmitChannelTransfer(&FLEXCOMM5_USB_PC_RX_Handle,&channelConfig); DMA_StartTransfer(&FLEXCOMM5_USB_PC_RX_Handle); } LPC55xx Peripherals Re: Using DMA Descriptors to receive Data bigger than 1024 bytes (LPC55S69) Hello, Thank you for sharing your findings and code. The community is a great place to share discoveries, ask questions, and provide guidance and support, so we appreciate you posting it here.  If you need any further assistance, please let us know. Best Regards, Luis

etpuc mpc5775 I would like to run one of function from cw function selector in eTPUC. I am aware of the starting/ending ram addresses of the etpuc (it is same as mpc5777c_vars_c.h). I modified my_system_etpu_init for the etpuc accordingly. I just copy the function files (like crank) and generate new files for etpuc.  While running all and suspend the program, the debugger's stuck PC: No source available for "0x800400"  What should be wrong? Re: etpuc mpc5775 There are several application notes as below, what have been changed about etpu initiailzation code? AN5374: eTPU library usage in an application – Application Note AN4907: Engine Control eTPU Library – Application Note AN2864: General C Functions for the eTPU – Application Note AN4908: Engine Control eTPU Demo Application – Application Note Re: etpuc mpc5775 How was the eTPU code generated? Did you use the Function Selector to generate a complete function set, or did you only copy the CRANK function files? Can you share your modified my_system_etpu_init() implementation? Is the generated eTPU code image successfully loaded into SCM during initialization? Can you provide the generated eTPU project files (e.g. etpu_set.c, etpu_set.h)? Is the PC always stopping at 0x800400, or does it vary?

IMX8M Plus GPU DRAM contention We are running Yocto Linux on an IMX8M Plus What we have noticed is that during any GPU activity, we get huge latency spikes for memory access from the CPU (1-3ms spikes). This is a huge issue, as we are using XDP for networking. We have tried tuning IMX8MP_ICM_A53, IMX8MP_ICM_GPU3D and IMX8MP_ICM_GPU2D, setting them to 7, 2, 2 for QoS control. This made the latency spikes less frequent, but they are still there. The only option we found was doing absolutely no GPU activity or removing the GPU from the device tree, however this is not acceptable for our use-case. Are there some other setting that could be tuned to alleviate this behavior? We cannot have the GPU locking the DRAM for more than a 50-100 μs at most Graphics & Display Linux Re: IMX8M Plus GPU DRAM contention Hi @richardlovgren, Thank you for contacting NXP Support! Could you please tell me which BSP version you are using? Does this issue reproduce on an EVK as well, or is it only occurring on your custom hardware? Could you also provide the log files, your device tree, and any other relevant information so that I can investigate and diagnose the issue on my side? Additionally, please share the exact steps to reproduce the problem, so I can try to replicate it in my setup. Best regards, Chavira

S32K324 FlexIO SPIマスターエミュレーション（S32DS 3.5 / RTD 4.0.0） こんにちは、 S32K324上でFlexIOエミュレーションによるSPIマスターを構成し、外部のSPIスレーブデバイスと通信できるようにしています。当社独自の基板における配線経路の都合上、このデバイスを対象とする物理的な配線は、チップのデフォルトのFlexSPI0ピンに接続されています。したがって、エミュレートされたFlexio_Spiドライバースタックを使う必要があります。 これが私のセットアップです BUS_FLEXSPI0_UP_SBC_CS PTD8 fxio_d11 BUS_FLEXSPI0_UP_SBC_CLK PTD9 fxio_d0 BUS_FLEXSPI0_UP_SBC_MOSI PTD15 fxio_d10 BUS_FLEXSPI0_UP_SBC_MISO PTD22 fxio_d27 私の環境： IDE:S32 Design Studio for S32 プラットフォーム(バージョン:3.5、ビルドID:240726 Update 13) CPU:S32K324 SDK:リアルタイム・ドライバ(RTD)バージョン4.0.0(本番リリース) RTD 4.0.0専用のエンドツーエンド統合スタックを示す公式のNXPアプリケーションノートやガイドはありますか?ツール内のピン割り当て、シフターやタイマーのマッピング、ドライバの初期化まで、メインアプリケーションコード内のすべてを網羅したリファレンスが必要です。 Re: S32K324 FlexIO SPI Master Emulation (S32DS 3.5 / RTD 4.0.0 ) こんにちは、 @Kazarian さん、 私の知る限り、RTD 4.0.0およびこのピン割り当てを対象としたS32K324向けにFlexIOエミュレートされたSPIの完全なエンドツーエンド統合を説明した専用のアプリケーションノートはありません。 最も近い公式な参照は、S32K3 RTDパッケージに含まれる例プロジェクトです。Lpspi_Flexio_Ip_Transfer_S32K344と同様のRTDの例を確認してください。 この例は、FlexIOベースのSPI転送における意図されたRTD統合フローを示しており、FlexIO SPIドライバーの初期化やLPSPIとFlexIO SPIインスタンス間の関係も含まれます。   カスタムボードを作成する際に考慮すべき主なポイントは以下のとおりです（一般的なガイドラインとして）。 ピンの構成 PinsツールにリストされているピンをFlexIO信号として設定します。 PTD8 → FXIO_D11、チップセレクト PTD9 → FXIO_D0、クロック PTD15 → FXIO_D10、MOSI PTD22 → FXIO_D27、MISO MISOピンが入力バッファを有効にしていることを確認してください。 また、S32K324 IOMUX/pinoutのドキュメントで、これらのFlexIO機能があなたのパッケージに対応していることも確認してください。 FlexIO SPI構成 FlexIO SPI構成では、SPI信号を物理的なMCUピンだけでなく対応するFlexIOピン番号にマッピングします。 SCK = FXIO_D0 MOSI = FXIO_D10 CS = FXIO_D11 MISO = FXIO_D27 生成された構成に合わせて、必要なFlexIOタイマーとシフターを適切に割り当ててください。 よろしくお願いいたします。 パベル

IMX8M Plus GPU 动态随机存取存储器(DRAM) 竞争 我们在 IMX8M Plus 上运行 Yocto Linux。 我们注意到，在任何 GPU 活动期间，CPU 访问内存时都会出现巨大的延迟峰值（1-3 毫秒峰值）。这是一个大问题，因为我们使用 XDP 进行网络连接。 我们尝试调整 IMX8MP_ICM_A53、IMX8MP_ICM_GPU3D 和 IMX8MP_ICM_GPU2D，将它们设置为 7、2、2 以进行 QoS 控制。这使得延迟峰值出现的频率降低，但它们仍然存在。我们发现的唯一选择是完全不进行任何 GPU 活动或从设备树中删除 GPU，但这对于我们的使用场景来说是不可接受的。是否还有其他设置可以调整以缓解这种现象？GPU锁定动态随机存取存储器\(DRAM\)的时间不能超过50-100微秒。 图形与显示 Linux Re: IMX8M Plus GPU DRAM contention 嗨@richardlovgren ， 感谢您联系恩智浦技术支持！ 请问您使用的是哪个BSP版本？ 这个问题在 EVK 上也会出现吗？还是只出现在你的定制硬件上？ 能否也提供日志文件、设备树以及其他相关信息，以便我能够调查和诊断问题？ 此外，请分享重现问题的具体步骤，以便我可以在我的环境中尝试重现该问题。 此致， 查维拉

SGTL5000XNLA3/R2 部分处于激活状态 大家好， SGTL5000XNLA3/R2 这个部件是否处于激活状态？我们可以把它用于新设计吗？ 数据手册中提及的EOL Re: SGTL5000XNLA3/R2 is part is active 好的，谢谢你的回复。 Re: SGTL5000XNLA3/R2 is part is active SGTL5000XNLA3 产品信息 | 恩智浦半导体 guoweisun_0-1785821314080.png 数据表显示： guoweisun_1-1785824177846.png

SGTL5000XNLA3/R2 is part is active Hi Team, is this part is active SGTL5000XNLA3/R2? Can we use it for new design Datasheet mentioned asEOL Re: SGTL5000XNLA3/R2 is part is active Ok. Thanks for the response Re: SGTL5000XNLA3/R2 is part is active SGTL5000XNLA3 Product Information | NXP Semiconductors guoweisun_0-1785821314080.png datasheet shows : guoweisun_1-1785824177846.png

IMX8M Plus GPU DRAM競合 IMX8M PlusでYocto Linuxを運用しています 私たちが気づいたのは、GPUの作業中にCPUからのメモリアクセス時に1〜3msの急激なレイテンシスパイクが発生することです。これは非常に大きな問題です。なぜなら、私たちはネットワーク接続にXDPを使用しているからです。 QoS制御のために、IMX8MP_ICM_A53、IMX8MP_ICM_GPU3D、IMX8MP_ICM_GPU2Dを7、2、2に設定して調整を試みました。これによりレイテンシの急上昇は少なくなりましたが、それでも存在しています。唯一見つけた選択肢は、GPUの活動を一切行わないか、デバイスツリーからGPUを削除することでしたが、これは私たちの用途には受け入れられません。この挙動を緩和するために調整できる他の設定はありますか?GPUがDRAMをロックする時間はせいぜい50〜100μs以上は許されません グラフィックスとディスプレイ Linux Re: IMX8M Plus GPU DRAM contention こんにちは@richardlovgren。 NXPサポートにご連絡いただきありがとうございます! どのBSPバージョンを使っているのか教えていただけますか? この問題はEVKでも再現しますか？それとも、カスタムハードウェアでのみ発生しますか？ ログファイルやデバイスツリー、その他関連情報も教えていただけますか?私側で問題を調査・診断できるように。 また、問題を再現するための正確な手順も教えてください。私のセットアップで再現できるよう。 よろしくお願いします、 チャビラ

Automotive Steering Control Using FRDM-A-S32K3XX Microcontrollers 1. Overview This module demonstrates how to implement a steering control system using Pulse Width Modulation (PWM) on NXP S32K3 microcontrollers. The application reads an analog input from a potentiometer (simulating a steering wheel) and converts it into a servo motor position. As the input changes, the servo motor reacts in real time, mimicking how steering systems work in modern vehicles. This example is based on Application Code Hub demonstrations for: PWM-Based Steering Control for FRDM-A-S32K344 PWM-Based Steering Control for FRDM-A-S32K312 In this workshop, a POT Click simulates the steering wheel position. When the student rotates it, an analog voltage proportional to the angle is read by the MCU through the ADC, scaled in software, and converted into a PWM duty cycle. The PWM is generated by the Servo Click (configured by the MCU over I²C) and drives a Micro Servo motor SG 180°, whose angle tracks the potentiometer in real time. Beyond the technical implementation, the course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples. 2. Learning Scope After completing this course, participants should be able to:   Understand a basic steering control system and the ideas behind EPS and steer-by-wire. Use the POT Click as a simulated steering-wheel input. Acquire analog values (0–3.3 V) using the ADC and understand analog-to-digital conversion. Perform signal scaling from the ADC range to a servo angle / PWM duty cycle. Generate PWM signals to drive a servo motor. Configure the Servo Click over I²C using the OE (Output Enable) pin. Recognize the actuation data flow: sensor input → MCU processing → PWM actuation. Import, build, flash, and debug an ACH project in S32 Design Studio 3.6.5. Understand why steering functions are relevant for functional safety. 3. System Architecture The three elements capture exactly the basic idea of the system in the demo: Input: Potentiometer (POT Click simulates the steering-wheel position) Processing: S32K3 MCU (reads the ADC, scales the value, commands the actuator) Output: Servo motor controlled via PWM (Micro Servo SG 180°) This matches the classic flow of an embedded actuation system: sensor → processing → actuator. Functional Flow The system operates continuously as follows: The potentiometer generates an analog voltage based on its position The ADC converts this voltage into a digital value The application scales this value into a steering angle The system generates a PWM signal based on the angle The servo motor moves accordingly This loop runs continuously to ensure real-time control. Designer.png Steering Monitoring Application Architecture 4. Key Concepts 4.1 ADC (Analog-to-Digital Converter) The POT Click outputs 0–3.3 V depending on the wiper position. The ADC samples this voltage at regular intervals and quantizes it into a digital code (a 12-bit ADC produces values between 0 and 4095). The further the potentiometer is turned, the higher (or lower) the digital sample. ADC acquisition is the foundation of automotive sensing — used for torque, throttle, battery voltage, and many others. 4.2 Signal Scaling — From ADC to Servo Angle The ADC range (for example 0–4095) and the servo range (0°–180°, expressed as a PWM duty cycle) are different. The application performs a linear mapping so that one end of the potentiometer corresponds to one steering extreme and the other end to the opposite. This is the same scaling used in real EPS systems, where a hardware reading is converted into a normalized control command. 4.3 PWM — Pulse-Width Modulation and Servo Control PWM switches a digital output on and off at a fixed frequency, varying the duty cycle (the fraction of time the signal is high). A hobby servo such as the SG 180° interprets this duty cycle as a position command. In this demo, the PWM is not generated by the MCU itself but by the Servo Click's dedicated PWM controller, which the MCU configures over I²C — a typical embedded pattern that offloads time-critical signal generation and keeps the CPU free for application logic. 4.4 I²C — Configuring the Servo Click I²C — Inter-Integrated Circuit is a two-wire serial bus made of SDA (data) and SCL (clock). The S32K3 uses LPI2C1 on PTC6 (SDA) and PTC7 (SCL) to configure the Servo Click — PWM frequency, channel, and duty cycle. The OE — Output Enable pin on PTB17 is an additional control line that enables or disables the PWM outputs without reconfiguring the chip, which is also useful for a quick "safe stop" behavior. 4.5 POT Click as Steering Wheel The POT Click is a simplified, safe stand-in for a real steering sensor. The student rotates it by hand, the voltage changes, the MCU reads it through the ADC, scales it, and the servo reacts. 4.6 Data Flow at a Glance Physical rotation → analog voltage → ADC sample → scaled command (angle / duty cycle) → I²C configuration of the Servo Click → PWM signal → servo angle. This direct chain from the student's hand to the servo shaft is the main educational value of the demo. 5. Hardware and Software Setup Required Hardware Component Image Purpose FRDM-A-S32K312 FRDM-A-S32K312.png Alternative MCU platform used to run the steering application and process steering inputs. FRDM-A-S32K344 S32K344MINI-EVB.png Alternative MCU platform used to run the steering application and control connected peripherals. FRDM-K64 Click Shield frdm-k64-click.jpg mikroBUS expansion board used to connect Click modules to the FRDM platform. Servo Click servo-click.jpg PWM driver board used to control the servo motor position. POT Click pot-click.jpg  Potentiometer module used to simulate steering wheel input. Micro Servo SG 180°                     micro-servo-motor-sg-180-degree.jpg Actuator used to convert control signals into steering movement. USB-C / 12 V supply — Provides power and enables programming and debugging of the system. The example applications demonstrate how these peripherals are connected to the MCU pins and used to simulate steering wheel input and actuator control. Steering Control Monitoring on FRDM-A-S32K312 Steering Control Monitoring on FRDM-A-S32K344 S32K312_Steering.png  S32K344_Steering.png     Software Environment S32 Design Studio IDE S32K3 Automotive Software Package Application Code Hub project import PWM-Based Steering Control for FRDM-A-S32K344 PWM-Based Steering Control for FRDM-A-S32K312 6. Implementation Guide Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio Select “Import project from Application Code Hub” Search for the steering demo Use the GitHub link for automatic configuration Select main branch Import project Project successfully appears in workspace 2 Build the Application Right-click project Select “Update Code and Build Project” Confirm SDK component management Build completes with no errors and generates .elf file 3 Connect Hardware Connect USB cable (and 12V supply for S32K312) Attach click boards Verify wiring Board is powered and detected by IDE 4 Flash and Run Open Debug Configurations Select “debug_flash_pemicro” Start debugging Application runs continuously 5 Functional Validation Rotate the potentiometer Observe servo movement Servo follows potentiometer position in real time 7. Signal Behavior and Control Logic Steering_Control_Signal.png Figure: Steering control signal mapping. The 12-bit ADC value (0–4095) is linearly mapped to a servo angle (0°–180°) and a matching PWM duty cycle (1.0–2.0 ms), with reference points at Left, Center and Right. At startup the servo moves to the neutral position; during operation, any input change produces an immediate, proportional reaction — implementing a basic steer-by-wire behavior. 8. Troubleshooting Issue Possible Actions Board Not Detected Check USB cable and drivers Verify debugger connection Restart IDE No Servo Movement Verify PWM configuration Check servo wiring Ensure correct power supply Incorrect Behavior Check ADC configuration Validate scaling function Ensure PWM duty cycle mapping is correct Unstable Movement Add signal filtering Check power stability 9. Extending the Application The basic implementation can be extended in several ways: Steering Range Control Restrict or extend the actuator's range of motion Define software-based limits to protect the mechanics Input Direction Inversion Reverse how the actuator responds to the input Useful for left-hand vs. right-hand drive calibration Noise Filtering Apply software filtering to stabilize readings Avoid jitter near the center position Scaling Logic Exploration Identify and analyze how the input is mapped to the output Connect software math with hardware behavior Fault-Handling Behavior Add a mechanism that reacts to a detected fault Transition the system into a safer state State Machine Implementation A more advanced approach is to implement a state machine: Idle Active Fault 10. Safety Context This example reflects key automotive principles: Continuous monitoring of driver input Immediate response to control signals Reliable actuator control In real systems: Redundancy is required Fault detection mechanisms are implemented Systems must comply with ISO 26262 (functional safety standard) Steer-by-wire systems require high reliability since there is no direct mechanical link. 11. Conclusion This module demonstrates how a simple embedded system can implement steering control using ADC input and PWM output. It shows how: Analog input is acquired Data is processed in real time Actuators are controlled using PWM Result on FRDM-A-S32K312 Result on FRDM-A-S32K344 S32K312_Steering_Demo.gif S32K344_Steering_Demo.gif The course provides a strong foundation for more advanced systems, including filtering, state machines, and safety-oriented designs.

Automotive Transmission Control Using FRDM-A-S32K344 Microcontrollers 1. Overview The application demonstrates actuator control concepts commonly encountered in automotive transmission systems using the FRDM-A-S32K344 development platform. The application showcases how analog input acquisition, signal processing, and actuator control can be combined to emulate the behavior of an automotive transmission control module. The solution is based on an Application Code Hub example designed for the FRDM-A-S32K344 platform. Transmission Control Module On FRDM-A-S32K344  The demonstration uses a potentiometer as the primary input device, representing the driver's throttle command. The analog signal is sampled using the ADC peripheral and fed into a transmission model that simulates vehicle speed, automatically selects one of six forward gears or neutral, and estimates engine RPM. The current gear is physically indicated by a servo motor, while a DC motor reflects the throttle input through a variable PWM duty cycle, emulating the drivetrain response of a real vehicle.   The example highlights the interaction between analog sensing, ADC conversion, transmission control algorithms, I²C communication, PWM generation, and actuator control commonly found in automotive embedded systems.   More than a technical course, this program embodies the Eat-Sleep-Code-Repeat approach to learning, where students learn by doing. By repeatedly designing, coding, testing, and refining automotive embedded applications on real hardware platforms, participants build both practical skills and the confidence needed to tackle real-world engineering challenges. 2. Learning Scope This article focuses on both practical implementation and core embedded system concepts: Analog signal acquisition using ADC Potentiometer-based continuous control inputs PWM generation using the eMIOS peripheral I²C communication with an external PWM controller Servo motor position control through an external PWM driver DC motor speed control with a dead-band region Automatic gear selection with shift hysteresis Engine RPM estimation and smoothing Real-time embedded control loops running at a fixed update rate Signal mapping and actuator response The example provides a practical introduction to automotive control systems where continuous sensor values drive actuator behavior through a simulated transmission model. 3. System Architecture The system follows a typical embedded control structure organised around a periodic control loop: Input: Analog throttle signal from the potentiometer Processing: S32K3 microcontroller running the transmission model (vehicle speed, gear selection, RPM) Output: Servo motor position (via I²C to an external PWM controller) and DC motor speed (via eMIOS PWM) Functional Flow The potentiometer voltage is sampled by the ADC and converted into a throttle command The MCU updates the transmission model, computing the simulated vehicle speed and selecting the appropriate gear The current gear is sent to the external PWM controller through I²C, which positions the servo motor accordingly The DC motor speed is updated through an eMIOS PWM channel proportional to the throttle command The entire cycle repeats at a fixed update rate to keep the actuators synchronised Transmission_Control_Architecture.png Transmission Control Application Architecture 4. Key Concepts 4.1 Control Principle Unlike systems based on push buttons or digital switches, this implementation uses a continuous analog input signal. The potentiometer provides a variable voltage level that represents the driver's throttle command. This value is continuously monitored and converted into a digital representation using the ADC peripheral. The processed value feeds a transmission model that simulates vehicle speed, selects a gear, and estimates engine RPM, which are then translated into commands for the servo (gear display) and the DC motor (speed). This approach allows smooth transitions instead of abrupt state changes and better reflects real-world automotive control systems. 4.2 Analog Input Acquisition The potentiometer acts as a variable voltage divider. As the potentiometer position changes, the output voltage changes continuously, the ADC acquires the voltage, and the MCU converts it into a throttle percentage. This value becomes the primary input variable for the transmission model. This process mirrors how many automotive sensors operate, where physical movement or operating conditions are converted into an analog voltage signal that must be processed by the control unit. 4.3 Servo Motor Control via I²C and External PWM Controller Unlike the DC motor, the servo motor is not driven directly by an MCU PWM channel. Instead, the MCU sends I²C commands to an external PWM controller located on the Servo Click board, which in turn generates the PWM pulses required to position the servo shaft. The transmission model computes the current gear and provides it as an input; the MCU translates the gear number into a pulse-width value and sends it to the external controller. Each discrete gear position corresponds to a specific servo angle, so the servo acts as a physical gear indicator on a graduated scale. 4.4 PWM-Based DC Motor Control The DC motor is driven directly by the MCU through the eMIOS peripheral, which generates the PWM signal required by the DC Motor 2 Click H-bridge driver. As the potentiometer value increases, the PWM duty cycle also increases, resulting in higher motor speed. When the throttle is at zero, the motor is stopped; above zero, the duty cycle is clamped to a minimum dead-band value (approximately 20 % of the full range) to guarantee reliable motor start-up, and then scales linearly up to full speed. This mirrors the response of a real drivetrain to a throttle input. 4.5 Automatic Gear Selection with Hysteresis The transmission model implements six forward gears plus neutral. Rather than mapping the throttle directly to a gear, the model maintains an internal simulated vehicle speed, which increases when the throttle is applied and decreases when it is released. Gear selection is performed by comparing the vehicle speed against a set of predefined thresholds: An upshift occurs when the simulated speed rises above the upper threshold of the current gear. A downshift occurs when the speed drops below the lower threshold of the current gear. The distance between the up and down thresholds forms a hysteresis band, preventing rapid oscillation between two gears when the speed hovers near a shift point. When the throttle is held at zero for a sustained period, the model detects idle and gradually downshifts back to neutral, mirroring the behaviour of a real automatic gearbox. 4.6 Engine RPM Estimation In parallel with gear selection, the model estimates an engine RPM value based on the throttle input and the currently engaged gear. On each gear change, the RPM is smoothly adjusted — decreasing on upshifts and increasing on downshifts — to reproduce the characteristic behaviour of an automatic transmission. This smoothing avoids abrupt jumps and gives a more realistic feel to the simulation. 4.7 Signal Mapping The application transforms the continuous throttle input into two coordinated actuator commands: a discrete gear position displayed by the servo, and a continuous PWM level applied to the DC motor. The conceptual mapping is shown below. Throttle Input Transmission State Servo Position (Gear Indicator) DC Motor Speed 0 % (idle) Neutral Rest position Stopped Low 1st – 2nd gear Low-gear positions Dead-band minimum → low speed Medium 3rd – 4th gear Mid-range positions Medium speed High 5th – 6th gear High-gear positions Maximum speed This mapping demonstrates how a continuous sensor input can be transformed into both a discrete state (gear) and a continuous actuator command (motor speed). 4.8 Data Flow at a Glance Physical rotation of the potentiometer → analog voltage → ADC sample → throttle percentage → transmission model (vehicle speed, gear, RPM) → I²C command to the external PWM controller (servo position) and eMIOS PWM signal (DC motor speed). All stages are re-evaluated at a fixed update rate to keep the actuators synchronised. This direct chain from the student's hand to the actuators is the main educational value of the demo. 5. Hardware and Software Setup Required Hardware Component Image Purpose FRDM-A-S32K344 FRDM-A-S32K344FRDM-A-S32K344 MCU platform used to run the transmission control application, execute the transmission model, and drive the connected peripherals through ADC, eMIOS PWM, and I²C. FRDM K64 click shield                  frdm-k64-click mikroBUS expansion adapter that connects Click modules to the FRDM board. Servo Click                          servo-click Expansion board carrying an external PWM controller. It receives I²C commands from the MCU and generates the PWM pulses that drive the servo motor. Micro Servo Motor SG 180°                         micro-servo-motor-sg-180-degree Actuator used to physically indicate the currently selected gear on a graduated scale. DC Motor 2 Click   dc-motor2-click Compact add-on board with a PWM-controlled, full-bridge brushed DC motor driver. It receives the eMIOS PWM signal directly from the MCU. DC Motor                       DC MotorDC Motor Simulates the vehicle drivetrain speed, reflecting the throttle input applied by the user. USB-C cable — Provides power and enables programming and debugging. The example application demonstrates how these peripherals are connected to the MCU pins and used to simulate a complete transmission control chain, from throttle input to gear indication and drivetrain speed. Transmission Control Full Setup on FRDM-A-S32K344 Transmission Full SetupTransmission Full Setup The hardware configuration allows simultaneous control of a position actuator (servo motor driven through I²C) and a speed-controlled actuator (DC motor driven through eMIOS PWM). Software Environment S32 Design Studio IDE S32K3 Real-Time Drivers (RTD) Application Code Hub project import Transmission Control Module On FRDM-A-S32K344  6. Implementation Guide Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio Select “Import project from Application Code Hub” Search for transmission control example Use the GitHub link for automatic configuration Select main branch Import project Project appears in workspace 2 Build the Application Compile the project Check for errors Confirm SDK component management Successful build with no errors 3 Connect Hardware Connect the board via USB-C Attach FRDM K64 Click Shield, Servo Click and DC Motor 2 Click Wire the servo motor, DC motor and potentiometer Verify wiring before powering the system Board powers up and is detected by IDE 4 Flash and Run Program the MCU Start execution Application runs continuously 5 Functional Validation Rotate the potentiometer Observe the servo pointer moving between the gear positions Observe the DC motor speed changing proportionally to the throttle Release the potentiometer and observe the transmission gradually downshifting back to neutral Gear indicator and motor speed respond consistently to throttle changes 7. Signal Behavior and Control Logic The following diagram illustrates how the transmission model selects the current gear based on the simulated vehicle speed, applying a hysteresis band to prevent frequent shifting around each threshold.   Transmission_Gear_Selection.png The transmission continuously compares the simulated vehicle speed against a set of predefined speed thresholds, one per gear. An upshift occurs when the vehicle speed rises above the upper threshold of the current gear (blue lines), while a downshift occurs only when the speed drops below the lower threshold of that gear (red dashed lines). The distance between the two thresholds forms a hysteresis band that prevents rapid oscillation between adjacent gears when the vehicle speed hovers near a shift point. When the throttle is held at zero for a sustained period, the transmission detects idle and gradually downshifts back to neutral, mirroring the behaviour of a real automatic gearbox. 8. Troubleshooting Issue Possible Actions Board Not Detected Verify USB connection Check drivers Restart IDE DC Motor Not Responding Check eMIOS PWM configuration Verify motor driver wiring and external power supply Confirm code execution Servo Not Moving Check I²C wiring (SDA / SCL) and pull-up resistors Verify that the external PWM controller is powered Confirm the servo is connected to the correct channel and powered by 5 V Incorrect Behavior Validate the ADC input range Inspect GPIO configuration for motor direction pins Verify transmission control logic implementation Unstable / Jittery Output Add software filtering on ADC readings Check power supply stability Verify grounding between motor drivers and MCU 9. Extending the Application The application can be enhanced by adding: Closed-Loop Control Integrate feedback sensors to dynamically adjust actuator outputs Compare commanded vs. actual position/speed for corrective action Additional Transmission Modes Extend the current six-gear + neutral model with Park and Reverse modes for a full PRND emulation Map potentiometer regions or dedicated inputs to specific transmission states Safety Functions Implement input plausibility checks on the throttle signal Add fault monitoring and safe-state transitions in case of sensor or actuator failure CAN Communication Transmit gear, RPM, and speed information over CAN or CAN FD networks Integrate with larger automotive powertrain systems Continuous Versus Discrete Control Compare button-based (discrete) and potentiometer-based (continuous) input styles Emulate electronic throttle control, position sensing, or actuator positioning applications 10. Safety Context Transmission control is part of vehicle motion systems, requiring: Reliable signal processing Deterministic control behavior Safety-aware design In production systems: Redundant checks are implemented Fault detection is mandatory Standards such as ISO 26262 apply Automotive transmission control units also implement input plausibility checks and safe-state fallback strategies to prevent unintended gear engagement or actuator runaway. 11. Conclusion This transmission control demonstration illustrates how the S32K344 platform can combine analog sensing, ADC conversion, I²C communication, PWM generation, and actuator control to implement a complete embedded control application. Using a potentiometer as a continuous input source, the system processes the throttle signal through a transmission model with six forward gears plus neutral, hysteresis-based gear selection, and RPM estimation, and translates the result into real-time commands for both a servo motor (gear indicator) and a DC motor (drivetrain speed). The project provides practical insight into the operation of automotive control systems and serves as a foundation for more advanced transmission, actuator, and motion-control applications. Result on FRDM-A-S32K344 Transmission resultTransmission result The course provides a strong foundation for more advanced systems, including closed-loop feedback control, additional transmission modes, CAN communication, and safety-oriented designs typical of automotive transmission control modules. The course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples.