RDDRONE-BMS772 Development Board Accessories RDDRONE-BMS772开发板配件 I apologize, you didn't understand me. My current research is about battery state estimation, which requires measuring the voltage, current, and temperature data of a real battery. Therefore, I don't need a battery simulator; I need a real battery. So, I need a battery compatible with my development board and a specific model of the corresponding battery charger. Also, are the PEMicro adapter and SEGGER J-Link Mini debugger mentioned in the link necessary hardware for debugging or programming the development board? Can't the development board be directly connected to a computer for debugging and programming? Are these adapters and debuggers available on the market? Furthermore, besides the hardware you mentioned, are there any other necessary hardware components for the development board? If so, please list the detailed accessory categories and their corresponding models. Thank you very much for your detailed answers to these questions. 抱歉，你没理解我的意思，我目前的研究是关于电池状态估计的，需要测量真实电池的电压电流和温度数据，所以我不需要电池模拟器，我需要的是真实的电池，所以我需要适配开发板的电池和对应电池充电器的具体型号；并且那个链接里提到的PEMicro适配器以及SEGGER J-Link Mini调试器是开发板调试或者烧录算法必须的硬件吗？开发板不能直接连接到电脑上进行调试和烧录程序吗？这些适配器和调试器在市面上可以买到吗？还有，开发板除了你提到的这几个硬件之外还有别的必须硬件吗？如果有的话请帮我列出详细的配件类别及其对应的型号；请您详细解答一下这些疑问，万分感谢。 Re: RDDRONE-BMS772 Development Board Accessories RDDRONE-BMS772开发板配件 Dear Fan007, For battery state estimation research, the RDDRONE-BMS772 supports real 3S to 6S Li-ion/LiPo battery packs (6 V to 26 V) and does not require a specific battery model. The selected battery must include a cell-balancing connector.  A charger compatible with the selected battery chemistry and cell count is required. No dedicated BMS communication interface is needed, as the RDDRONE-BMS772 can disconnect the charging path when necessary. For firmware development and debugging, NXP recommends an external SWD debugger such as a PEMicro Universal Multilink or SEGGER J-Link Mini. The RDDRONE-BMS772 does not include an onboard USB debug interface, so an external debugger is necessary. These debuggers are commercially available. For battery characterization and SOC/SOH algorithm development, a programmable electronic load (E-load) is also highly recommended to perform controlled charge/discharge testing.    With Best Regards, Jozef

pn7220 天线电流 您好，请问如何通过 libnfc-nxp-rfExt.conf 或其他配置文件配置 PN7220 的 NFC 天线电流？我们的测试表明天线电流过高，需要降低。 Re: pn7220 antenna current 你好@zhangkai 建议启用 DPC，但在启用 DPC 之前，需要对其进行校准。 Re: pn7220 antenna current 你好@zhangkai ， 如果您只需要降低/限制电流，您可以按照此处描述的方法进行操作： https://community.nxp.com/t5/NFC-Knowledge-Base/PN7642-Basic-RF-power-limitation-using-DPC/ta-p/2187514 BR 托马

S32K358 multi core data sharing Hello , I am trying to use shared memory in s32k358 multi core. I am following user define example,  When i try to assign some value in buzzer_state_shared_data_U32 ( currently only core 0 is accessing this memory), core 0 is hanging and swt resetting the controller. But when i flash the code in debug flash, its running properly. With power on reset, core 0 is hanging.  Why its running properly in when flashing and not running in power off and on. Re: S32K358 multi core data sharing Hello @Julián_AragónM , Thank you for your quick response, I check the startup files, SRAM Init is happening. I have attached my startup files and linker files. Please support me to resolve this issue Re: S32K358 multi core data sharing Hello @nirmal_masilamani, But when i flash the code in debug flash, its running properly. With power on reset, core 0 is hanging.  This is most likely caused by ECC RAM error. Usually, debuggers initialize the ECC on volatile memories, however, when powering on and off, debugger does not initialize RAM, and hardfault occurs when trying to access memory. This is usually done in the startup code, before main. The section should be also configured as non-cacheable. Regarding your second issue: but when i try to access it from timer ISR or OS task, core 0 going to hardfault. You can try to trace back your hardfault. Halt the core in the HardFault_Handler(), and find the SP value in the core registers: How To Debug A Fault Exception On ARM Cortex-M(V7M) MCU(S32K3XX). Best regards, Julián Re: S32K358 multi core data sharing Hello, When i access shared memory in main(), its working fine even in power off and on, but when i try to access it from timer ISR or OS task, core 0 going to hardfault. Please support me in this. Re: S32K358 multi core data sharing Hello @Julián_AragónM , Please support on this query. What i am missing here? Re: S32K358 multi core data sharing Hello @nirmal_masilamani, Are you able to access shared memory in main() after POR reset without debugger? Was the issue RAM initialization? but when i try to access it from timer ISR or OS task, core 0 going to hardfault. Were you able to identify the fault type as I mentioned in my previous reply? Have you also made sure the variable is placed in a non-cacheable area, or the cache is disabled? As suggestions: Keep volatile on core1Status and use __DMB()/__DSB() barriers on both the read (Core0) and write (Core1) sides. Your issue could also be caused by MPU configuration, if MPU_ENABLE is defined, please call the MPU config before any ISR or OS task starts executing. You can refer to the following links: Arm Cortex-M7 Devices Generic User Guide r1p2 & AN14715: S32K3XX Hardware Resource Isolation and Protection. Best regards, Julián

如何在LVGL中流畅地显示相机帧？ 您好，我正在使用MIMXRT1176DMAA芯片。该板配备MIPI摄像头和MIPI液晶显示屏，液晶显示屏主要用于显示LVGL GUI。 目前，我希望在屏幕上显示摄像头的图像，同时在摄像头画面上叠加一些 LVGL 标签。我尝试通过 LVGL Canvas 显示相机帧，但这种方法在将相机帧传输到 Canvas 时引入了额外的处理开销，导致 CPU 使用率高和相机画面卡顿。 请问这个问题有解决办法吗？例如，LCDIFV2 的层功能能否用于在不同的层上显示内容？非常感谢您能提供任何建议。 Re: How to smoothly display camera frames in LVGL? 你好@Vinos ，如果这不是秘密，那解决方案是什么？ 此致敬礼 Re: How to smoothly display camera frames in LVGL? 已解决。 Re: How to smoothly display camera frames in LVGL? 经过尝试，我发现只有在 LVGL 任务关闭时，相机屏幕才能流畅运行。目前，Layer0 是 GUI，Layer1 是摄像头。当 Layer0 关闭且 Layer1 打开时，我想添加另一个 Layer2。在 Layer3 的中心，应该有一个空心圆，除了弧形部分以外，其余部分都是透明的。 因此，我使用了 ARGB4444 格式，并通过在 LCD 上绘制一个正方形进行了简单的测试（启用 Layer0 并禁用 Layer1；或者禁用 Layer0 并启用 Layer1）。然而，生成的图像并不透明。每当调用 LCDIFV2_SetLayerBlendConfig 函数时，LCD 上的 Layer3 都不会显示图像。但是，如果将此函数注释掉，液晶显示屏将显示预期的非透明图像。 以下是代码，请参考 SDK 中的示例“lcdifv2_embedded_alpha_cm7”。 #define LCD_WIDTH 480 #define LCD_HEIGHT 640 #define CENTER_LAYER 2 #define DEMO_FB0_ADDR ((uint32_t)s_frameBuffer[0]) AT_NONCACHEABLE_SECTION_ALIGN( uint8_t s_frameBuffer[1][LCD_HEIGHT][LCD_WIDTH][2], 32); void DEMO_FillFrameBuffer(void) { uint32_t x, y; for (y = 0; y < LCD_HEIGHT; y++) { for (x = 0; x < LCD_WIDTH; x++) { s_frameBuffer[0][y][x][0] = 0x11; s_frameBuffer[0][y][x][1] = 0x11; } } } void lcd_center_layer_init() { DEMO_FillFrameBuffer(); /* Layer 1: ARGB4444 */ const lcdifv2_buffer_config_t fb1Config = { .strideBytes = (LCD_WIDTH * 2), .pixelFormat = kLCDIFV2_PixelFormatARGB4444, }; const lcdifv2_blend_config_t blend1Config = { .alphaMode = kLCDIFV2_AlphaEmbedded, }; LCDIFV2_SetLayerBufferConfig(LCDIFV2, CENTER_LAYER, &fb1Config); LCDIFV2_SetLayerSize(LCDIFV2, CENTER_LAYER, 240, 240); LCDIFV2_SetLayerOffset(LCDIFV2, CENTER_LAYER, 0, 0); /* comment or not */ LCDIFV2_SetLayerBlendConfig(LCDIFV2, CENTER_LAYER, &blend1Config); LCDIFV2_SetLayerBufferAddr(LCDIFV2, CENTER_LAYER, DEMO_FB0_ADDR); LCDIFV2_EnableLayer(LCDIFV2, CENTER_LAYER, true); LCDIFV2_TriggerLayerShadowLoad(LCDIFV2, CENTER_LAYER); } 我的代码有错误吗？谢谢。 Re: How to smoothly display camera frames in LVGL? @Vinos ，你好！ 请查看以下链接： https://github.com/lvgl/lvgl/issues/262我相信这对您的询问会很有帮助。 如果对你有帮助，请告诉我！ 埃德温。 Re: How to smoothly display camera frames in LVGL? 谢谢你的建议。我尝试了第二种解决方案，但是在 LVGL 中，背景是白色的，上面有一些标签。实际结果是，除了标签之外，白色背景完全覆盖了相机图像。如何将这些白色背景设置为透明？ Re: How to smoothly display camera frames in LVGL? 嗨@Vinos ， 我不清楚您打算如何申请这份申请，所以以下是我的建议： 请参考示例“SDK_MIMXRT1170-EVK\boards\evkmimxrt1170\driver_examples\csi\mipi_rgb”。需要将摄像机捕获的视频与 LVGL 的帧缓冲区进行合成。有两种方法可以做到这一点： 1）将相机图像从相机输出缓冲区复制到LVGL的帧缓冲区。虽然可以用 memcpy 实现，但性能会很差，所以我建议改用 DMA。 2) 直接使用另一层 LCDIFv2 作为相机的输出缓冲区，然后 LCDIFv2 硬件在显示屏上合成不同的层而无需复制。 BR， 埃德温。

在基于 MC9S12X256 16 位处理器的 SCI 系统上实现 I2C MC9S12XS256 微控制器没有专用的 I2C 端口，但是 SCI 子系统能否用于与 I2C 显示器或类似配件通信？ Re: implementing I2c on the sci system on an MC9S12X256 16 BIT I2C 无法与 SCI/LIN 直接通信，因为它们的硬件引脚定义不同。 如果必须使用 I2C 通信，则可能需要使用网关来传输协议（例如 MC9S12）。 Re: implementing I2c on the sci system on an MC9S12X256 16 BIT 嗨@fluffyflex ， 它只能通过GPIO进行模拟： https://www.nxp.com/docs/en/application-note/AN5264.pdf https://www.nxp.com/docs/en/application-note-software/AN5264SW.zip 此致， 丹尼尔 Re: implementing I2c on the sci system on an MC9S12X256 16 BIT 谢谢你提供的信息！我会利用这些信息来实现模拟I2C。 此致

Does i.MX95 support LPDDR5X memory? Does i.MX95 support LPDDR5X memory? If MR8[1:0]=01 or MR5 ID is not in your support list How do i.MX95 check supported or not? check MR register? Re: Does i.MX95 support LPDDR5X memory? Thanks for your quickly apply. Re: Does i.MX95 support LPDDR5X memory? As you said "MR8[1:0] = 01 means the device is LPDDR5X-only " MR8[1:0]=00 support LPDDR5, MR8[1:0]=01 support LPDDR5x. So what should MR8[1:0]=?? support LPDDR5 and LPDDR5x ? Re: Does i.MX95 support LPDDR5X memory? Yes, i.MX95 can work with many LPDDR5X devices, but only if those devices also support LPDDR5 backward-compatibility mode. i.MX95 does NOT support LPDDR5X-only devices.  Therefore, checking whether a memory is supported is not simply a matter of looking at MR8[1:0] or MR5 vendor ID alone. MR8[1:0] = 01 means the device is LPDDR5X-only → treat it as not supported for i.MX95, because NXP states LPDDR5X-only devices cannot be used. MR5 manufacturer/device ID is not in NXP’s validated list → it is not validated by NXP , but that alone is not the same as “impossible.” You still need to confirm from the memory datasheet that the part supports LPDDR5 mode and matches the supported density/organization/timing constraints, then validate it in the board design.

S32DS 3.5 How can I obtain the toolchain classification report for S32DS3.5, including... What about the TI/TD/TCL reports on analysis and use of constraints and known limitations? Re: S32DS 3.5 Hi, lhy These types of documents have security attributes and require an NDA. Please submit a case through the internal support system. https://support.nxp.com BR Joey Re: S32DS 3.5 thank you

S32 设计工作室许可证问题 您好。 我最近更换了笔记本电脑，并在新电脑上重新安装了S32设计工作室。 但是，我遇到了许可证激活错误——软件无法激活，因为许可证仍然绑定到我之前的笔记本电脑上。 我尝试通过 NXP 许可证管理器退回许可证，但收到一条消息，称许可证无法退回。 请问您能否帮我从旧电脑上停用/释放许可证，以便我可以在新笔记本电脑上激活它？（我的）许可证密钥为 81B8-B707-440D-FE7C） 谢谢你的帮助。 Re: S32 Design Studio License Problem 你好， 可用许可证数量已增加。

キーファクタープラグインで画像を作成する際のエラー spsdkとspsdk-pluginsをインストールして、keyfactorプラグインを使ってRT1064用のイメージを作成しました。venvでbuild_image_win.batファイルを起動すると、エラーが発生します。 SPSDKError: SPSDK: シグネチャプロバイダーはconfig type=keyfactorから作成できませんでした;url=... ログファイルに以下のエラーが表示されています。 INFO:spsdk.utils.service_provider:読み込み中プラグイン: spsdk.sp INFO:spsdk.utils.service_provider:キーファクター型のSignatureProviderが見つかりませんでした。 デバッグ:spsdk.apps.utils.utils:SPSDK:シグネチャプロバイダーはconfig type=keyfactorから作成できませんでした。URL 以下に示すように、環境のアクティブな Python エントリ ポイントを検査するテストを実行しました。 "python -c "import importlib.metadata;print([p.namep は に importlib.metadata.entry_points(group='spsdk.sp')]))」テスト結果は良好で、重要な要素はアクティブなPythonエントリポイントにあります。 ビルドバッチファイルとYAMLファイルを添付しました。 この問題をどう解決すればいいですか? Re: Error when building a image using keyfactor plugin こんにちは、 @cleo さん、 プラグインが正常に読み込まれなかったようです。https://github.com/nxp-mcuxpresso/spsdk_plugins/tree/master/keyfactorのガイドに従いましたか？ https://github.com/nxp-mcuxpresso/spsdk_pluginsを参照してください。詳細については、こちらをご覧ください。 お役に立てば幸いです。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -------------------------------------------------------------------------------

S32 Design Studio License Problem Hello. I recently changed my laptop and reinstalled S32 Design Studio on the new machine. However, I am encountering a license activation error — the software is unable to activate because the license is still bound to my previous laptop. I attempted to return the license through the NXP License Manager, but received a message stating that the license return is not possible. Could you please help me deactivate/release the license from my old machine so that I can activate it on my new laptop?(my license key is 81B8-B707-440D-FE7C) Thank you for your assistance. Re: S32 Design Studio License Problem Hi,  the number of available licenses has been increased. 

MC9S12X256 16ビットのSCIシステムでI2Cを実装する MC9S12XS256マイクロコントローラには専用のI2Cポートはありませんが、SCIサブシステムはI2Cディスプレイや類似のアクセサリと通信するために使えますか? Re: implementing I2c on the sci system on an MC9S12X256 16 BIT I2CはSCI/LINとは異なるハードウェアピン定義であるため、直接通信できません。 MC9S12でI2Cが必須の場合、プロトコルを転送するためにゲートウェイを使用する必要があるかもしれません。 Re: implementing I2c on the sci system on an MC9S12X256 16 BIT こんにちは、 @fluffyflex さん。 GPIOを用いてのみエミュレート可能です: https://www.nxp.com/docs/en/application-note/AN5264.pdf https://www.nxp.com/docs/en/application-note-software/AN5264SW.zip よろしくお願いいたします。 ダニエル Re: implementing I2c on the sci system on an MC9S12X256 16 BIT 情報ありがとうございます！それを参考に、I2Cのシミュレーションを組み込んでみます。 よろしくお願いします。

i.MX95はLPDDR5Xメモリをサポートしていますか? i.MX95はLPDDR5Xメモリをサポートしていますか? もしMR8[1:0]=01またはMR5 IDがサポートリストにない場合 i.MX95がサポートされているかどうかを確認するにはどうすればよいですか？MR登録簿を確認してください。 Re: Does i.MX95 support LPDDR5X memory? 迅速なご応募ありがとうございます。 Re: Does i.MX95 support LPDDR5X memory? あなたが言ったように、「MR8[1:0] = 01 は、デバイスが LPDDR5X 専用であることを意味します」 MR8[1:0]=00はLPDDR5をサポートし、MR8[1:0]=01はLPDDR5xをサポートします。 では、MR8[1:0]=??LPDDR5とLPDDR5xはサポートできますか? Re: Does i.MX95 support LPDDR5X memory? はい、i.MX95は多くのLPDDR5Xデバイスで動作しますが、それらのデバイスがLPDDR5の後方互換性モードをサポートしている場合に限ります。 i.MX95はLPDDR5X専用デバイスをサポートしていません。 したがって、メモリがサポートされているかどうかを確認するには、単にMR8[1:0]やMR5のベンダーIDだけを見るだけでは不十分です。 MR8[1:0] = 01 はデバイスがLPDDR5Xのみであることを意味します NXPはi.MX95では サポートされていない として扱→。NXPはLPDDR5Xのみデバイスは使用できないと明記している。 MR5の製造元/デバイスIDはNXPの検証済みリストに含まれていません。 → それは NXPによる検証は行われていません しかし、それだけでは「不可能」と同じではない。それでも、メモリデータシートで部品がLPDDR5モードをサポートし、対応される密度・組織・タイミングの制約に合致しているかを確認し、基板設計で検証する必要があります。

Error when building a image using keyfactor plugin I have installed spsdk and spsdk-plugins to build an image for RT1064 using the keyfactor plugin. When I am launching in venv the build_image_win.bat file I keep getting an error  SPSDKError: SPSDK: Signature provider could not be created from config type=keyfactor;url=... The log file shows the below error. INFO:spsdk.utils.service_provider:Loading plugins: spsdk.sp INFO:spsdk.utils.service_provider:SignatureProvider of type keyfactor was not found. DEBUG:spsdk.apps.utils.utils:SPSDK: Signature provider could not be created from config type=keyfactor;url I ran a test to  inspect the environment's active Python entry points as shown below "python -c "import importlib.metadata; print([p.name for p in importlib.metadata.entry_points(group='spsdk.sp')])"  " and the result of the test is good, keyfactor is in the active Python entry points. I have attached the build batch file and the yaml file. How can I fix this issue? Re: Error when building a image using keyfactor plugin Hi @cleo ， Looks like the plugin was not loaded successfully. Did you follow the guide from  https://github.com/nxp-mcuxpresso/spsdk_plugins/tree/master/keyfactor ?  Please refer to https://github.com/nxp-mcuxpresso/spsdk_plugins for more details. 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. -------------------------------------------------------------------------------

How to smoothly display camera frames in LVGL? Hello, I am using the MIMXRT1176DMAA chip. The board is equipped with a MIPI camera and a MIPI LCD, and the LCD primarily used for displaying LVGL GUI. Currently, I would like to display the camera's images on the screen while overlaying some LVGL labels on top of the camera feed. I have attempted to display the camera frames through an LVGL Canvas, but this approach introduced additional processing overhead in transferring camera frames to the Canvas, resulting in high CPU usage and choppy camera feed. Could you please advise if there is a solution to this issue? For instance, can the Layer feature of LCDIFV2 be utilized to display content on different layers? I would greatly appreciate any suggestions you could provide. Re: How to smoothly display camera frames in LVGL? Hello @Vinos , what was the solution if it's not a secret? Kind regards Re: How to smoothly display camera frames in LVGL? Solved. Re: How to smoothly display camera frames in LVGL? After trying, I found that the camera screen only works smoothly when the LVGL task is closed. Currently, Layer0 is the GUI and Layer1 is the camera. I would like to add another Layer2 when Layer0 is closed and Layer1 is opened. In the center of Layer3, there should be a hollow circle with transparency in all parts except for the arc. Therefore, I used the ARGB4444 format and performed a simple test by drawing a square on the LCD(Layer0 enable and Layer1 disable;or Layer0 disable and Layer1 enable). However, the resulting image was not transparent. Whenever the LCDIFV2_SetLayerBlendConfig function is called, there is no image on Layer3 on the LCD. However, if this function is commented out, the LCD displays the expected non-transparent image. Below is the code,reference the example " lcdifv2_embedded_alpha_cm7" in SDK #define LCD_WIDTH 480 #define LCD_HEIGHT 640 #define CENTER_LAYER 2 #define DEMO_FB0_ADDR ((uint32_t)s_frameBuffer[0]) AT_NONCACHEABLE_SECTION_ALIGN( uint8_t s_frameBuffer[1][LCD_HEIGHT][LCD_WIDTH][2], 32); void DEMO_FillFrameBuffer(void) { uint32_t x, y; for (y = 0; y < LCD_HEIGHT; y++) { for (x = 0; x < LCD_WIDTH; x++) { s_frameBuffer[0][y][x][0] = 0x11; s_frameBuffer[0][y][x][1] = 0x11; } } } void lcd_center_layer_init() { DEMO_FillFrameBuffer(); /* Layer 1: ARGB4444 */ const lcdifv2_buffer_config_t fb1Config = { .strideBytes = (LCD_WIDTH * 2), .pixelFormat = kLCDIFV2_PixelFormatARGB4444, }; const lcdifv2_blend_config_t blend1Config = { .alphaMode = kLCDIFV2_AlphaEmbedded, }; LCDIFV2_SetLayerBufferConfig(LCDIFV2, CENTER_LAYER, &fb1Config); LCDIFV2_SetLayerSize(LCDIFV2, CENTER_LAYER, 240, 240); LCDIFV2_SetLayerOffset(LCDIFV2, CENTER_LAYER, 0, 0); /* comment or not */ LCDIFV2_SetLayerBlendConfig(LCDIFV2, CENTER_LAYER, &blend1Config); LCDIFV2_SetLayerBufferAddr(LCDIFV2, CENTER_LAYER, DEMO_FB0_ADDR); LCDIFV2_EnableLayer(LCDIFV2, CENTER_LAYER, true); LCDIFV2_TriggerLayerShadowLoad(LCDIFV2, CENTER_LAYER); } Is there any error in my code? Thank you. Re: How to smoothly display camera frames in LVGL? Hi again @Vinos, Please look into the following link: https://github.com/lvgl/lvgl/issues/262 I believe it will prove very useful for your inquiry. Let me know if it helps! Edwin. Re: How to smoothly display camera frames in LVGL? Thank you for your suggestion. I have tried the second solution, but in LVGL, the general background is white and there are some labels on top. The actual result is that the white background completely covers the camera image except for the labels. How can I make these white backgrounds transparent? Re: How to smoothly display camera frames in LVGL? Hi @Vinos, I am not aware of how you are approaching this application, so here is my recommendation on how to do so: Refer to the example "SDK_MIMXRT1170-EVK\boards\evkmimxrt1170\driver_examples\csi\mipi_rgb". The captured video from camera needs to be composited with framebuffer of LVGL. There are two methods to do this: 1) Copying the camera image from camera output buffer to framebuffer of LVGL. This can be done with memcpy but it will result in bad performance, so I'd recommend using DMA instead. 2) Using another layer of LCDIFv2 as output buffer of camera directly, then LCDIFv2 h/w composites different layers on display without copy. BR, Edwin.

使用 keyfactor 插件构建镜像时出错 我已经安装了 spsdk 和 spsdk-plugins，以便使用 keyfactor 插件为 RT1064 构建镜像。当我在虚拟环境中运行 build_image_win.bat 文件时，一直出现错误。 SPSDK错误：SPSDK：无法根据配置 type=keyfactor;url=... 创建签名提供程序 日志文件显示以下错误。 信息：spsdk.utils.service_provider：正在加载插件：spsdk.sp INFO:spsdk.utils.service_provider:未找到类型为 keyfactor 的 SignatureProvider。 调试：spsdk.apps.utils.utils：SPSDK：无法根据配置 type=keyfactor;url 创建签名提供程序 我运行了一个测试来检查环境中活动的 Python 入口点，如下所示。 "python -c "import importlib.metadata;print([p.namefor p in importlib.metadata.entry_points(group='spsdk.sp')])"测试结果良好，关键因素在于活跃的 Python 入口点。 我已附上版本批处理文件和 yaml 文件。 我该如何解决这个问题？ Re: Error when building a image using keyfactor plugin 嗨@cleo ， 插件似乎加载失败。您是否按照https://github.com/nxp-mcuxpresso/spsdk_plugins/tree/master/keyfactor中的指南操作？请参考https://github.com/nxp-mcuxpresso/spsdk_plugins更多详情请见下文。 希望对您有所帮助。 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------

MCXC242VFM vs MCXC244VFM pinout differences Hello there, I'm designing a board with the MCXC242VFM chip, but I wanted to make it pin to pin compatible with the MCXC244VFM in case I need more FLASH and RAM. From the MCUXpresso Config Tool I see that there's a few pins that differ between MCXC242VFM and MCXC244VFM, but I cannot find any documentation that explains in detail the difference of pinouts.; only thing I can find online on NXP website is that from the product selection tool the MCXC242VFM is reported to have no I2S and 24 GPIOs, while the MCXC244VFM has 1 I2S and 23 GPIOs. For my project I'm not interested in the I2S. Can someone please point me to a document that clearly states the differences of pinout and pins assignment between these two chips? Kind regards, Michele Perla Board Design MCXC Package and IO|GPIO Re: MCXC242VFM vs MCXC244VFM pinout differences Hi @MichelePerla  The MCXC242VFM and MCXC244VFM are both available in the 32-QFN package, but they should not be assumed to be fully pin-to-pin compatible. Please compare the pin assignment tables in the MCX C24X and MCX C44X reference manual. In particular, several pins differ between the two devices. For example, pin 5 is USB_VDD on MCXC242VFM but VOUT33 on MCXC244VFM; pin 6 is PTE16 on MCXC242VFM but VREGIN on MCXC244VFM; and pin 9 also has different analog/reference-related definitions. Therefore, if the board is intended to support both devices, these pins must be reviewed carefully in the schematic and PCB design. MCXC242 RM: MCX C24X Sub-Family Reference Manual MCXC244 RM: MCX C44X Sub-Family Reference Manual Hope it helps. BR Alice

S32K358マルチコアデータ共有 こんにちは 、 私はs32k358マルチコアで共有メモリを使用しようとしています。 私はユーザー定義の例に従っています。 buzzer_state_shared_data_U32で値を割り当てようとすると(現在はコア0のみがこのメモリにアクセスしています)、コア0がハングし、SWTがコントローラーをリセットします。 しかし、デバッグフラッシュにコードを書き込むと、正常に動作します。電源リセット後、コア0がハングアップしています。 フラッシュ中は正常に動作するのに、電源のオンオフでは動作しないのはなぜですか？ Re: S32K358 multi core data sharing こんにちは、 @Julián_AragónM さん、 迅速なご対応ありがとうございます。 起動ファイルを確認したところ、SRAMの初期化が実行されている。 起動ファイルとリンカーファイルを添付しました。この問題を解決するために、ぜひ私をサポートしてください Re: S32K358 multi core data sharing こんにちは、 @nirmal_masilamani さん、 しかし、デバッグフラッシュにコードを書き込むと、正常に動作します。電源リセット後、コア0がハングアップしています。 これはおそらくECC RAMのエラーが原因です。通常、デバッガは揮発性メモリ上でECCを初期化しますが、電源オン・オフ時にRAMを初期化せず、メモリへのアクセス時にハードフォールトが発生します。 これは通常、メイン関数の前に実行される起動コード内で行われます。 このセクションはキャッシュ不可に設定する必要があります。 2つ目の問題についてですが、タイマーISRやOSタスクからアクセスしようとすると、コア0がハードフォールに切り替わります。 ハードフォルトを遡って追跡してみることもできます。HardFault_Handler()でコアを停止し、コアレジスタでSP値を見つけます:How To Debug A Fault Exception On ARM Cortex-M(V7M) MCU(S32K3XX)。 よろしくお願いします、 ジュリアン Re: S32K358 multi core data sharing こんにちは、 main()で共有メモリにアクセスすると、電源オフ・オンでも問題なく動作しますが、タイマーISRやOSタスクからアクセスしようとすると、コア0がハードフォールに切り替わります。 どうか私をサポートしてください。 Re: S32K358 multi core data sharing こんにちは、 @Julián_AragónM さん、 この質問についてサポートしてください。私が何か見落としているのでしょうか？ Re: S32K358 multi core data sharing こんにちは、 @nirmal_masilamani さん、 PORリセット後にデバッガなしでmain()の共有メモリにアクセスできますか?問題はRAMの初期化だったのでしょうか？ しかし、タイマー、ISR、OSタスクからアクセスしようとすると、コア0がハードフォールトに切り替わります。 前回の返信でお伝えしたように、故障の種類を特定できましたか？ 変数がキャッシュされない領域に配置されているか、またはキャッシュが無効になっていることを確認しましたか？ 提案として： core1Status を揮発性のままにしておき、読み取り側 (Core0) と書き込み側 (Core1) の両方で__DMB()/__ DSB() バリアを使用します。 問題がMPU設定が原因かもしれません。もし定義MPU_ENABLEなら、ISRやOSタスクが実行される前にMPU設定を呼び出してください。 以下のリンクを参照してください:Arm Cortex-M7 デバイス汎用ユーザーガイド r1p2 & AN14715: S32K3XX ハードウェアリソースのアイソレータと保護。 よろしくお願いします、 ジュリアン

MCXC242VFM 与 MCXC244VFM 引脚排列差异 你好呀， 我正在设计一款采用 MCXC242VFM 芯片的电路板，但我希望它能与 MCXC244VFM 引脚兼容，以防我需要更大的 FLASH 和 RAM。 从 MCUXpresso 配置工具中，我发现 MCXC242VFM 和 MCXC244VFM 之间有一些引脚不同，但我找不到任何文档详细解释引脚排列的差异。我在 NXP 网站上唯一能找到的信息是，根据产品选择工具显示，MCXC242VFM 没有 I2S 接口，有 24 个 GPIO 接口，而 MCXC244VFM 有 1 个 I2S 接口和 23 个 GPIO 接口。我的项目对 I2S 不感兴趣。 请问谁能提供一份文档，清楚地说明这两款芯片的引脚排列和引脚分配的区别？ 此致敬礼， 米歇尔·佩拉 电路板设计 MCXC 代码包，软件包和 I/O|GPIO Re: MCXC242VFM vs MCXC244VFM pinout differences 嗨@MichelePerla MCXC242VFM 和 MCXC244VFM 均采用 32-QFN 封装，但不应假定它们引脚完全兼容。请比较 MCX C24X 和 MCX C44X 参考手册中的引脚分配表。 具体来说，这两个设备有几个引脚不同。例如，MCXC242VFM 的引脚 5 为 USB_VDD，而 MCXC244VFM 的引脚 5 为 VOUT33；MCXC242VFM 的引脚 6 为 PTE16，而 MCXC244VFM 的引脚 6 为 VREGIN；引脚 9 的模拟/参考相关定义也不同。因此，如果板要支持这两个设备，则必须在原理图和 PCB 设计中仔细检查这些引脚。 MCXC242 RM： MCX C24X 子系列参考手册 MCXC244 RM： MCX C44X 子系列参考手册 希望对您有所帮助。 BR 爱丽丝

S32DS 3.5 S32DS3.5のツールチェーン分類レポート（以下を含む）はどのように入手できますか？TI/TD/TCLの制約と既知の制限の分析と使用に関するレポートはどうでしょうか？ Re: S32DS 3.5 こんにちは、 lhy これらの文書はセキュリティ上の特性を持つため、秘密保持契約（NDA）が必要です。社内サポートシステムを通じてご依頼ください。 https://support.nxp.com BR ジョーイ Re: S32DS 3.5 よろしくお願い申し上げます。

デジタル信号の電圧変換ってどうやればいいの？ (日本語ブログ) 0. 目次 0. 目次 1. 電圧レベル・トランスレータって？ 2. デジタル信号 2.1 様々なデジタル信号 2.2 CMOSとTTL：単純な電圧のHIGHとLOWによる論理レベルの信号 2.3 入出力電圧の規定：VOH / VOL と VIH / VIL 2.3.1 出力電圧の規定：VOHとVOL 2.3.2 入力電圧の規定：VIHとVIL 2.3.3 VOH / VOL と VIH / VIL の関係 3. 基本的な電圧レベル変換の方法：片方向信号の変換 3.1 チップの電源電圧が違っても変換の必要がない例 コラム：TTLのVIH(min) = 2.0V，VIL(max) = 0.8Vはどうやって決まっている？ 3.2 変換が必要な例 3.2.1 オープンドレイン出力による変換 3.2.2 標準ロジック(汎用ロジック)チップを用いた変換 4. 自動方向切り替えが必要な双方向信号の変換 4.1 単体MOSトランジスタによる双方向変換 4.2 専用品による双方向変換 4.2.1 I²C信号電圧変換チップ 4.2.2 高速化を図った双方向オープンドレイン信号電圧変換チップ 4.2.3 双方向プッシュプル信号電圧変換チップ 4.2.4 I3C信号電圧変換チップ 4.2.5 バッファによる変換 5. まとめ 5.1 ブログ内で紹介した方式/品番の比較 6. 参考資料 1. 電圧レベル・トランスレータって？ デジタル回路同士をつなぐとき，単純に信号線を直結すればいい… ということはなくて，「論理レベルの電圧」が合わないと，動作しなかったり，不安定になったり，最悪の場合チップを壊してしまうことがあります． そんなときに便利に使えるのが電圧レベル・トランスレータ(Voltage Level Translator．電圧レベル・シフタとも呼ぶ)です． 電圧レベル・トランスレータは，異なる電源電圧のデジタル回路間で信号をやり取りできるようにする回路です． 例えば，次のようなケースで必要になります． 3.3V マイコン ↔︎ 5V センサ の接続 1.8V FPGA ↔︎ 3.3V 周辺デバイス の接続 図1：信号電圧の違い   このブログでは，デジタル回路で使われる論理回路の種類(*TTL，*LVTTL，*CMOS)の電圧レベルの違いから，それを判断する上で重要なV OH /V OL /V IH /V IL の意味について解説します．さらに様々な変換の方法の中から，どのような電圧レベル・トランスレータを選べばよいかを解説します． さらにこのブログでは信号の方向を自動で検出して変換を行う電圧レベル・トランスレータの具体例を見ていきます． NXPではSDカード/SIMカード向けや，*GTL↔︎TTLレベル変換のような特定用途向け電圧レベル・トランスレータもラインナップしていますが，このブログは汎用またはシリアル・バス用途をターゲットにした製品の解説となります． *TTL（Transistor-Transistor Logic） *LVTTL（Low Voltage Transistor-Transistor Logic） *CMOS（Complementary Metal-Oxide-Semiconductor） *GTL（Gunning Transceiver Logic） 2. デジタル信号   2.1 様々なデジタル信号 いわゆる「デジタル信号」は論理レベルの1と0を電気的に表現したものです．この論理レベルの1と0を扱う回路設計方法には歴史的に様々なものがあります．論理レベルを単純な電圧のHIGHとLOWで表現するものや，電圧の差を利用してHIGH/LOWを表現するものなど． 単純なHIGH/LOWを5V/0Vで表すTTL．さらにそのTTLを低電圧化し3.3V/0Vで表すLVTTLなどバイポーラ・トランジスタ回路を基準に電圧レベルが決められたもの． 同様にバイポーラ・トランジスタを使いながらも負電源を使い低振幅で差動で動作論理レベルを実装し，高速化が図られたECL．基準電圧を設けて低振幅のシングルエンド信号でHIGH/LOWを伝達するGTLなど... また単純なHIGH/LOWでの表現でも低消費電力化を目的に開発された4000シリーズと呼ばれるCMOS汎用ロジックでは，HIGHレベルとして3V〜18Vを使うことができました． https://en.wikipedia.org/wiki/Logic_family このブログでは，上記のような様々な論理レベルの中でも，単純なHIGHとLOWの電圧で論理を表現するTTL(LVTTL)とCMOSの電圧レベルの扱いについて解説します． その他の信号変換には専用チップが用いられるため，ここでは扱いません． このほか近年では半導体技術の微細化・高速化・低消費電力化が進むとともに，電源に使われる電圧は低くなってきています．このため信号電圧差を橋渡しする電圧レベル・トランスレータは特に重要になってきています． 図2：信号波形 - 電圧の高低(HIGH/LOW)で論理レベルを表す   2.2 CMOSとTTL：単純な電圧のHIGHとLOWによる論理レベルの信号 デジタル回路に使われる単純な電圧のHIGHとLOWによる論理レベルの信号には，HIGHを電源電圧で，LOWを0Vとするものが一般的です．電源電圧が異なってもHIGH/LOWの電圧レベルが同じであれば，そのまま信号をやり取りすることができます． たとえばTTL(LVTTL)は入力される信号が2.0V以上であればHIGH，0.8V以下であればLOWと解釈します．このような取り決めがあるため，TTL信号であれば互いに電源電圧が異なってもHIGH/LOWの電圧レベルは変わりません． いっぽう，CMOSは電源電圧の半分の電圧を基準にしてHIGH/LOWを定義します．このためCMOSは電源電圧が異なるとHIGH/LOWの電圧レベルも変わります． 図3：入力信号電圧の規定   2.3 入出力電圧の規定：V OH  / V OL  と V IH  / V IL デジタル回路ではHIGHとLOWとして出力される電圧と，入力される信号をHIGHとLOWに判断する電圧が規定されています．これらは使用する各チップの仕様で規定されているため，データシートで確認する必要があります． V OH  : HIGHレベル出力電圧 (HIGH-level output voltage) V OL  : LOWレベル出力電圧 (LOW-level output voltage) V IH  : HIGHレベル入力電圧 (HIGH-level input voltage) V IL  : LOWレベル入力電圧 (LOW-level input voltage) 2.3.1 出力電圧の規定：V OH とV OL 出力ではHIGH/LOWを出力する際の電流を考えておかねばなりません．電流は負荷により増減します． HIGH出力での最大流出電流時に保証できる電圧をV OH (min)，LOW出力での最大流入電流時に保証できる電圧をV OL (max)と呼びます． V OH (min)は回路出力段の上側のトランジスタがONになったときに出力される電圧です．このトランジスタには「ON抵抗」と呼ばれる抵抗分があります． トランジスタから流れ出る電流が大きい場合，"トランジスタの抵抗分 x そこに流れる電流"で電圧が発生．すると出力はその電圧分だけ電源電圧から下がってしまいV OH が低くなってしまいます．このため，あらかじめ想定される最大流出電流のときに保証できる最小の電圧がV OH (min)となります． 図4：デジタル信号出力回路(プッシュプル)   図5：HIGH出力電圧は負荷によって変化する   V OL はこの逆となります．回路出力段の下側のトランジスタがONになったとき，流れ込む電流が大きいと，上記と同様にトランジスタのON抵抗によって発生する電圧によって，出力は0Vより上がってしまいます．これを考慮し，あらかじめ想定される最大流入電流のときに保証できる最大の電圧がV OL (max)となります． 図6：LOW出力電圧も負荷によって変化する   2.3.2 入力電圧の規定：V IH とV IL 入力にはHIGHとLOWを判断するための電圧レベルがあります．V IH (min)とV IL (max)です．電圧がV IH (min)以上であればHIGHと判断され，V IL (max)以下であればLOWと判断されます． CMOS入力では電源電圧の1/2がHIGHとLOWの基準となりますが，これをそのままV IH (min)とV IL (max)とはしていません．これはチップごとのバラツキなどによって閾値が上下するためです．また，遅く立ち上がる信号に乗ったノイズなどによるグリッチが出力に現れることを軽減するため，入力にはヒステリシスを持たせることが一般的です．このような理由によりV IH (min)とV IL (max)はある程度の電圧差を設けて規定されます． 2.3.3 V OH  / V OL  と V IH  / V IL  の関係 正常な信号のやり取りを行うには，出力と入力の関係は下式を満たす必要があります． HIGHレベル： V OH (min) > V IH (min) LOWレベル： V OL (max) < V IL (max) この関係が守られていれば，出力側の回路は，次の入力側の回路に対してHIGH/LOWを正しく伝えることができます．さらにこの互いの電圧差である「V OH (min) - V IH (min)」や「V IL (max) - V OL (max)」は「ノイズ・マージン」となり，ノイズ耐性を高く保つための目安になります． 図7：V OH (min) / V OL (max) と V IH (min) / V IL (max) 3. 基本的な電圧レベル変換の方法：片方向信号の変換   3.1 チップの電源電圧が違っても変換の必要がない例 『「V OH (min) > V IH (min)」かつ「V OL (max) < V IL (max)」』の関係が成り立つ場合には基本的には電圧レベル変換は必要ありません．たとえばTTLとLVTTLはそれぞれのチップに使われる電源電圧は違うものの，入出力電圧の規定は同一です． TTL(5V)とLVTTL(3.3V)ではどちらも，V OH (min)は2.4V，V OL (max)は0.4Vです．V IH (min)/V IL (max)も，どちらも2.0V/0.8Vなので問題なく互いに接続できます． ただし出力電圧が入力側チップの電源電圧よりも高い場合には注意が必要です．出力側が5V，入力側が3.3V電源を使うチップである場合には，入力側は「5Vトレラント入力」に対応していなければなりません． 5Vトレラント入力とは，5VのHIGH信号を3.3Vの電源電圧で動作するチップの入力に接続しても問題なく動作する入力のことです．一般的なチップの入力には静電気対策のためのESD保護回路が入っていますが，このESD保護回路が次の図のような回路で構成されていると5Vを入力した際に入力から3.3Vの電源に電流が逆流してしまい，チップを破壊してしまうことがあります．このような問題を起こさないための対策が取られた入力が5Vトレラント入力です．トレラント入力にはESD保護がないわけではなく，電源電圧より高い信号が入力されても問題がないような構造を持つESD保護回路が組み込まれています． 図7のようなESD保護ダイオードは，入力側チップの電源が切られている時にも問題を引き起こします．チップごとに個別に電源のON/OFF管理を行うようなシステムの場合，入力側チップがOFFになっているにも関わらず出力側の信号が電源に回り込み，入力側チップを動作させてしまうことがあります． 図7：ESD保護ダイオード - 非トレラント入力 コラム：TTLのV IH (min) = 2.0V，V IL (max) = 0.8Vはどうやって決まっている？ CMOSの入力閾値が電源電圧の中点(VCC/2)を基準にしているのに対し，TTLのV IH (min)/V IL (max)は2.0V/0.8Vという，電源電圧(5V)に対して特に綺麗な比率ではない値になっています．これには，TTLの入力段がバイポーラ・トランジスタで構成されていることが関係しています． 標準TTLロジックIC:SN7400(2入力NAND)の内部回路例 『最新汎用ロジック・デバイス規格表 1988』(CQ出版)に掲載されていたもの 標準的なTTLゲートの入力段は，多重エミッタの入力トランジスタと，その後段のフェーズスプリッタ・トランジスタが直列に重なった構造をしています．ゲートが実際に反応し始める「スイッチング・スレッショルド」は，この2段に重なったPN接合の順方向電圧で決まります．シリコンのPN接合1個あたりの順方向電圧はおよそ0.6〜0.7Vなので，2段重なると合計でおよそ1.3〜1.5V付近がTTLゲートの実質的なスイッチング・スレッショルドとなります． ただしこの約1.4Vという値はあくまで「典型値(typical)」であり，個体差や温度などのバラツキによってロットごと・条件ごとに変動します．そこでデータシート上の規定値であるV IH (min)とV IL (max)は，この約1.4Vの典型値に対して上下に十分なマージンを取り，「ここまで下がれば確実にLOWと判定できる(V IL (max)=0.8V)」「ここまで上がれば確実にHIGHと判定できる(V IH (min)=2.0V)」という，保証値として規定されています． さらにこの値は単独で決められているわけではなく，2.3.3節で説明したV OH /V OL との関係も踏まえて設計されています．標準TTLでは出力段の構成により，HIGH出力は電源電圧にはならず，少し低い(上記回路例では130Ωの抵抗，トランジスタとダイオードで発生する電圧分だけ低い)電圧になります（VOH(min)=2.4V）．これとVOL(max)=0.4Vを組み合わせると， HIGH側ノイズ・マージン：V OH (min) − V IH (min) = 2.4 − 2.0 = 0.4V LOW側ノイズ・マージン：V IL (max) − V OL (max) = 0.8 − 0.4 = 0.4V のように，上下対称に0.4Vのノイズ・マージンが確保されるよう設計されています．つまりTTLの2.0V/0.8Vという「電源電圧に対して半端」に見える数字は，バイポーラ・トランジスタの接合電圧という物理的な実体と，ノイズ・マージン設計という2つの要請から導かれた，合理的な値だったということになります． SN7420(4入力NAND)の入力ピン3つをHIGH，1つに100kHzの三角波を入力(ch1)した様子 無負荷状態の出力(ch2)だがHIGHのとき4V未満の出力となっている(Vcc=5V) なお，本コラムで紹介した回路は無印(74LS00や74HC00のようにLS/HCなどの付かないもの．英語では“バニラTTL”と呼ばれることもある)標準TTLの例ですが，V IH /V IL の規定が同じ理由（入力段のバイポーラ接合特性）は74LSなど他のTTLファミリにも共通しています．   3.2 変換が必要な例   TTLやLVTTLでは電圧レベルが揃っているため上記のような接続が可能ですが，電源電圧の違うCMOSチップ同士や，CMOSとTTLチップの接続では論理レベルが合わない場合が多く発生します．前述の『「V OH (min) > V IH (min)」かつ「V OL (max) < V IL (max)」』の関係が成り立たない，またはその差が小さくなってしまい，ノイズ・マージンが取れないような状況がそれにあたります． この問題を解決するのが電圧レベル・トランスレータです． 図9：論理レベルが合わない例(1)：充分なHIGH電圧が入力されない   図10：論理レベルが合わない例(2)：充分なLOW電圧が入力されない     3.2.1 オープンドレイン出力による変換 電圧レベル変換チップを用いなくても，簡単に電圧レベル合わせを行う方法はあります． 信号の方向が出力側チップ→入力側チップで固定され切り替わることがないのなら．HIGH側の出力をオープンドレイン出力にすることで，入力側の電圧に合わせる方法です．オープンドレインはデジタル回路の出力段の上側のトランジスタがない構成のもので，入力側チップの電源電圧に接続されたプルアップ抵抗によってHIGHの電圧を得ます． 図11：デジタル信号出力回路(オープンドレイン)   オープンドレインは単純で安価な方法ですが，いくつかの注意点があります． まず出力側がオープンドレイン出力が可能なものである必要があります．多くのマイコンのGPIOピンなどでは設定によってこの出力が可能です． まず出力側がオープンドレイン出力が可能なものである必要があります．多くのマイコンのGPIOピンなどでは設定によってこの出力が可能です．もしオープンドレイン出力に設定できないプッシュプル出力固定など場合には，外付けのトランジスタなどを使ってオープンドレイン出力に変換する必要があります． さらにプルアップ抵抗の選択も重要です． プルアップはHIGHの電圧を得るために必要な抵抗ですが，抵抗値が小さすぎるとLOW出力時に流れる電流が大きく(負荷が大きい状態に)なり，消費電力が増える上にV OL の上昇を招いてしまいます． 逆に大きすぎると配線とピンによる容量の影響を受け，LOWからHIGHへの立ち上がりが遅くなってしまい，通信速度の低下が起こります． 3.2.2 標準ロジック(汎用ロジック)チップを用いた変換 単純な電圧レベル変換であれば標準ロジックを用いる方法もあります．たとえばNexperia社の74AVCH4T245は4ビットの双方向レベル変換を行うことができるCMOS汎用ロジックチップです． このチップでは0.8V〜3.6Vの信号を変換することができ，信号の方向をDIRピンによって切り替えることもできます．信号速度は変換を行う電圧にも依存しますが，100M〜380Mbps程度に対応可能です． 図12：標準ロジックの例 - 74AVCH4T245 このチップを用いると高速な信号の双方向電圧変換が可能ですが，方向の制御は外部からの信号によって行わなければなりません．このような制御はパラレル・バスのREAD/WRITEのような信号によって可能ですが，プロトコルによって通信方向が切り替わるシリアル・バスのような通信には適用が困難です． 図13：標準ロジックの例．信号の方向を外部から指定しなくてはならない 4. 自動方向切り替えが必要な双方向信号の変換 これまでに紹介した"オープンドレイン出力"や"標準ロジックチップを用いた電圧変換方法"では，主に一方向のみの変換を行うもの，あるいは外部信号による方向の切り替えが必要なものでした． I²C，I3Cのような信号の方向がダイナミックに変化するような通信には，方向が自動で検出して切り替わる「双方向の電圧レベル変換」が必要です．このような信号の方向を外部から制御するのは難しく，前述のようなバッファ・チップで実現するのは困難です． さらにI²Cはオープンドレイン信号であるため，オープンドレインの標準ロジック・バッファを互いに違う向きに接続するようなことができません．図14はその例です．オープンドレイン・バッファを互いに反対方向に接続しています．バッファの両側がHIGHの時は問題ありませんが，どちらかが一旦LOWになると，バッファは互いの入力をLOWに引っ張ったままとなり，HIGHに戻すことができなくなります． 図14：通常のオープンドレイン・バッファでは双方向通信を自動切替できない   4.1 単体MOSトランジスタによる双方向変換   これまでI²Cの信号電圧変換には，単純な回路が用いられることがありました．その最も簡単なMOSトランジスタを使った方法をその例として挙げます． 図15：MOSトランジスタを使った変換の例   図15はI²Cの仕様書version2.1(2000年)から引用したもので，3.3Vと5Vの信号を2本の信号にそれぞれ1個のMOSトランジスタ(TR1, TR2)を用いる例です．このような単純なトランジスタ単体での変換例は，後述する問題点があるため現在のI²Cの仕様書からは削除されていますが，原理を理解するために紹介します． SDAとSCLと呼ばれるI²Cの信号線は，どちらもオープンドレイン出力の双方向信号となっています．3.3V側と5V側にそれぞれプルアップ抵抗が接続されています． この回路では3.3V側，5V側の信号がHIGHである場合，このトランジスタのゲート(g)とソース(s)間は同電位となるため，ソース(s)とドレイン(d)OFF状態となって互いの接続が切れた状態に置かれます．この状態で3.3VがLOWに変化すると，3.3V側のトランジスタ(のsとdの間)がONになり，5V側の信号もLOWになります． 3.3V側がHIGHで5V側がLOWに変化した場合には，まず3.3V側から5V側への寄生ダイオード(ボディ・ダイオード)がONになります．ダイオードがONになるとソース(s)の電圧が降下．その結果トランジスタがONになり，3.3V側の信号もLOWになります． このようにトランジスタをスイッチとして使う非常に単純な仕組みで電圧レベル変換ができるのですが，ここには問題もあります．トランジスタのバラツキが信号変換の閾値に影響すること．さらに今日ではより低い信号電圧を扱うことが増えてきており，たとえば信号電圧が1V程度では，このような回路では十分なゲート(g)とソース(s)間電圧(Vgs)が得られないため動作させることができません． 追記：図15と同じ回路は，NXPから半導体ディスクリート/ロジック製品事業が分社化されて誕生したNexperia社のアプリケーションノートAN10441「Level shifting techniques in I²C-bus design」として今も公開されています．I²C仕様書とは別に2007年に初版(Rev.01)のアプリケーションノートが発行され，2020年にNexperiaブランドへ改訂(Rev.2)されています． 4.2 専用品による双方向変換   「電圧レベル・トランスレータ専用IC」を用いることで，I²C, I3Cのような双方向通信を行うバスの電圧レベル変換を容易に行うことができます． 4.2.1 I²C信号電圧変換チップ PCA9306，NVT20xxシリーズ(NVT2001/02, NVT2003/06, NVT2008/10)は双方向信号の変換に特化した電圧レベル・トランスレータです．これらのチップでは複数の信号線(複数ビットの信号線)をまとめて扱うことができます．これらはI²C信号の電圧変換チップとされていますが，信号の仕様が合えば他の目的(SPIやその他のプッシュプル信号など)にも使うことができます． PCA9306，NVT20xxシリーズは同じ内部構造を持ち，プルアップ抵抗は，変換する電圧差が1V以上であれば電圧の高い側だけに接続すれば良いようになっています． 図16はその内部構造と外部チップの接続を示したものです(アプリケーションノートAN11127：「Bidirectional voltage level translators NVT20xx and PCA9306」のFig.2から抜粋)．このチップ内部には信号線数(ビット数)+1個のMOSトランジスタが内蔵されています．各トランジスタはソースとドレインが可換の構造となっています． 信号を伝達するための経路のトランジスタはパス・トランジスタと呼ばれ，残りの1個はリファレンス・トランジスタと呼ばれます． 図16：NVT20xx(PCA9306) - チップ動作の解説図   回路を見てみると，リファレンス・トランジスタのゲートとドレイン間はショートされており，200kΩの抵抗を介して高い電圧側の電源に接続されています．リファレンス・トランジスタの残りの端子：ソースは低電圧側の電源に接続されています．このような接続により，リファレンス・トランジスタは1個のダイオードとなっており，このゲート電圧は低電圧側の電源よりもダイオード1個分高い電圧となります． 残りのパス・トランジスタはドレイン側が高い電圧側の信号線と1kΩのプルアップ抵抗に，ソース側は低い電圧側の信号線，さらにゲートはリファレンス・トランジスタのゲートに接続されています．パス・トランジスタの高い側，低い側の信号がどちらもHIGHになっている時，高い側は1kΩによってプルアップされた電圧となります． パス・トランジスタはいわゆる「ソースフォロワ」と呼ばれる回路を構成しています．低い電圧側の端子(ソース端子)は，ゲートに印加されている電圧よりトランジスタをONにするために必要なVgs分だけ低い電圧が現れます．つまり低電圧側の電源と同じ電圧となります．トランジスタはONでもOFFでもない半分ONの状態(線形領域での動作)になっています． この状態で，高または低のどちら側かの信号がLOWになると，ゲートと信号端子の電圧差によりトランジスタがON(完全にONとなった飽和領域での動作)になり，反対側の端子もLOWになります． このシリーズで扱える信号速度は，プルアップと信号線の容量の影響を受けます．データシートでは，PCA9306は2MHzまで．NVT20xxシリーズでは192Ωのプルアップ抵抗を使用し，容量50pFの条件で最大33MHzまでの信号速度に対応可能とされています．1MHz程度の信号であれば，プルアップ抵抗や容量をあまり気にしなくても(通常I²Cで使うような範囲内を想定)で問題なく動作します．しかしこのチップをプッシュプルのより高速な信号を扱う場合には特製の把握と慎重な部品選択が必要になります． このタイプの電圧レベル・トランスレータ動作の詳細は，「PCA9306の中身と動作」の記事で紹介されています． 4.2.2 高速化を図った双方向オープンドレイン信号電圧変換チップ 高速化を図った双方向オープンドレイン信号変換チップとして，NTS030xシリーズ(NTS0302JK, NTS0304E)を紹介します． このチップは2ビットまたは4ビットの双方向信号変換を行うことができ，オープンドレイン信号であれば2Mbps(1MHz)，プッシュプル信号であれば20Mbps(10MHz)の信号に対応可能です．   図17：NTS030x - チップ内部ブロック図   図17はNTS030xの信号1ビット分の内部構造です． 図ではT3のトランジスタがパス・トランジスタとなっており，ゲート端子バイアス電圧がかけられているので，AとBと書かれた信号のどちらかがLOWとなった時にONとなります． AとBの両方がHIGHの時はT3がOFFになり，AとBはそれぞれの電源に比較的大きいプルアップ抵抗(10kΩ)で接続されているのでそれぞれの電圧となります． このチップにはT3のほかにT1とT2が存在しています．このT1とT2は「エッジレート・アクセラレータ」と呼ぶ機能のために使われます．このうちの片方，T1に注目しこの動作を解説します． T1はA側に置かれ，ソース端子はA信号に，ドレイン端子はA側電源に接続されています．ゲート端子はこれを制御する「ONE-SHOT AND SLEW RATE CONTROL」と書かれたブロックに接続されています． 「ONE-SHOT AND SLEW RATE CONTROL」ブロックは反対側のB信号に接続されていて，B側の信号のLOWからHIGHへの変化を検出．これを検出した時に一時的にT1をONにして，プルアップの10kΩ抵抗をバイパスして電流を流す事により，A側の信号のHIGHへの変化を加速します．このように信号の立ち上がりを速くすることで，より高速な信号を扱うことができるようにしています． ちなみに，このT1をONにする際のスルーレートは制御されていて，急な電流増加によるリンギング発生を抑えることも考慮されています． もういっぽうのT2はこの同じ仕組みが逆方向に作られており，B側信号にも適用されるようになっています． このNTSシリーズにはもう一つの使いやすい点があります． ここまで説明したMOSトランジスタ単体やPCA9306/NVT20xxの場合，どちらかの電源がOFFになった場合，他方の信号をLOWにしてしまうという問題がありました．NTS030xではこの問題を解決するために，両方の電源がONになっていない場合は，互いに影響が出ないように信号ピンをハイ・インピーダンス状態とするよう動作します．このような機能を使うことにより，システムの電源を部分的にON/OFF制御するような使い方が可能になります． NTS030xシリーズと同等品で，より高速の信号に対応するためスルーレート制御機能の無いNTS010xシリーズ(NTS0102, NTS0104)も用意されています． なお，NTS0304Eには，すぐに簡単な動作検証ができるように評価基板：NTS0304EUK-ARDが用意されています．NTS0304EUK-ARD基板の概要と動かし方はこちらの動画「NTS0304EUK-ARDの動かし方」をご参考ください． 4.2.3 双方向プッシュプル信号電圧変換チップ さらにこのNTS030xシリーズをプッシュプル信号だけで使う場合のより高速なオプションとしてNTB010xシリーズ(NTB0102, NTB0104)があります． HIGHまたはLOWで安定した状態では4kΩを通して信号を駆動．NTS030xシリーズ同様のワンショット機能をHIGHとLOW側の両側に持たせ，いずれかの端子で信号の変化があった場合にこれを用いて，反対側信号を変化させる機構を持っています． このような機構により，信号方向の自動検出機能を持ちながら70〜80Mbpsの速度の信号電圧変換が可能です．   図17：NTB010x - チップ内部ブロック図 4.2.4 I3C信号電圧変換チップ I3Cはオープンドレインとプッシュプルを切り替えながら通信を行う仕様を持ち，オープンドレインではI²Cと互換〜4MHzの周波数．プッシュプル時は12.5MHzのクロックが使われます．信号の電圧は通常1V〜3.3Vの範囲で使われるため，電圧差がある場合には，信号仕様に合わせた動作をする電圧レベル・トランスレータが必要になります． 図18はP3A1604の1ビット分の内部ブロック図です．このチップでは図の通り，LOW→HIGHだけでなくHIGH→LOWの変化を加速する仕組みとON/OFFの切り替えができるプルアップ抵抗が内蔵されています．   図18：P3A1604 - チップ内部ブロック図 P3A1604は4ビット用のI3C電圧レベル・トランスレータ．この他にも2ビット用のP3A9606も用意されています．   4.2.5 バッファによる変換 もう一つの双方向信号の変換方法として，専用品のバッファを使う方法があります． バッファの本来の目的は，駆動能力の増強や接続している信号線の容量の分離などですが，電圧の変換に対応した製品も存在します． 双方向のオープンドレイン信号を相互にバッファするには，このブログの中で説明したように単純なバッファでは実現できません．そのため双方向オープンドレイン信号用として様々な工夫がされたバッファ製品が用意されています． バッファについての詳細はまた次の機会に解説する予定です． 5. まとめ 電圧レベル・トランスレータは，異なる電源電圧を持つデジタル回路間で安全かつ確実に信号をやり取りするために不可欠な部品です．TTLやLVTTL，CMOSなど論理レベルの規定や，VOH/VOL/VIH/VILの関係を理解することで，適切な接続や変換方法を選択できます． 片方向の変換にはオープンドレイン出力や標準ロジックIC，双方向の変換にはMOSトランジスタや専用IC（PCA9306/NVT/NTS/NTB/P3Aシリーズなど）が利用できます． 特にI²CやI3Cなど双方向通信が必要なバスでは，信号方向の自動検出機能を持つ電圧レベル・トランスレータが有効です． また，近年の半導体技術の進化により，低電圧化・高速化が進み，より厳密な電圧レベル管理が求められるようになっています．電圧レベル変換の方法や選択肢は多岐にわたりますが，信号仕様や速度，システムの電源管理など用途に応じて最適な方法・部品を選ぶことが重要です． 5.1 ブログ内で紹介した方式/品番の比較 方式/品番 用途 ビット数 方向切替 オープンドレイン対応 低電圧側[V] 高電圧側[V] ビットレート[bps] オープンドレイン出力での変換 汎用 1 片方向 - - - - 標準ロジック(例:74AVCH4T245) 汎用(パラレルバスなど) 4 + 4 外部制御 非対応 0.8 ~ 3.6 0.8 ~ 3.6 100M ~ 380M 単体MOSトランジスタによる双方向変換 I²C, 汎用 1 自動 対応 トランジスタの仕様による ~ 1M PCA9306 I²C, 汎用 2 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz．条件による) NVT2001 I²C, 汎用 1 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NVT2002 I²C, 汎用 2 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NVT2003 I²C, 汎用 3 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NVT2006 I²C, 汎用 6 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NVT2008 I²C, 汎用 8 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NVT2010 I²C, 汎用 10 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NTS0302JK I²C, SPI, 汎用 2 自動 対応 0.95 ~ 3.6 1.65 ~ 5.5 2M @オープンドレイン, 20M @プッシュプル NTS0304E I²C, SPI, 汎用 4 自動 対応 0.95 ~ 3.6 1.65 ~ 5.5 2M @オープンドレイン, 20M @プッシュプル NTS0102 I²C, SPI, 汎用 2 自動 対応 1.65 ~ 3.6 2.3 ~ 5.5 50M @プッシュプル NTS0104 I²C, SPI, 汎用 4 自動 対応 1.65 ~ 3.6 2.3 ~ 5.5 50M @プッシュプル NTB0102 SPI, 汎用 2 自動 非対応 1.2 ~ 3.6 1.65 ~ 5.5 70M ~ 80M NTB0104 SPI, 汎用 4 自動 非対応 1.2 ~ 3.6 1.65 ~ 5.5 70M ~ 80M P3A9606 I3C, I²C, SPI, 汎用 2 自動 対応 0.72 ~ 1.98 0.72 ~ 1.98 (12.5MHz) P3A1604 I3C, I²C, SPI, 汎用 4 自動 対応 0.72 ~ 1.98 1.62 ~ 3.63 6.8M @オープンドレイン, 40M @プッシュプル 表1：ブログ内で紹介した方式/品番の比較   6. 参考資料 製品紹介ページ：電圧レベル変換器 NXP システム・マネジメントI2C, I3C, SPIセレクタ・ガイド I2C バス仕様およびユーザーマニュアル (Rev5.0 日本語版) I2C バス仕様およびユーザーマニュアル (Rev7.0 英語版) NXPコミュニティ・ブログ：I3Cバスの概要 ～次のシリアルバス～ 日本語ウェビナー動画：『【今知っておくべき】次世代インターフェース「I3C」の基礎』  Qiita @teddokano：PCA9306の中身と動作 変更履歴： 2025-08-28：初版 2025-08-28：NTS0304EUK-ARDの紹介と動画公開ブログへのリンクを追記 2026-04-10：表1の低電圧側[V]，高電圧側[V]の訂正 2026-06-20：第3.1節「コラム：TTLのVIH(min) = 2.0V，VIL(max) = 0.8Vはどうやって決まっている？」を追加．標準TTLロジックIC:SN7400(2入力NAND)の内部回路例，SN7420の出力波形を追加 2026-07-10：第4.1節に，図15の回路がNexperia社アプリケーションノートAN10441としても公開されている旨を追記 ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。） このブログでは，デジタル回路で使われる論理回路の種類(*TTL，*LVTTL，*CMOS)の電圧レベルの違いから，それを判断する上で重要なV OH /V OL /V IH /V IL の意味について解説します． さらに様々な変換の方法の中から，どのような電圧レベル・トランスレータを選べばよいかを解説します． 特に特別な扱いが必要となる，双方向オープンドレイン信号の変換について詳しく見てみます Interface introduction 日本語ブログ