Understanding the PCIe M.2 Key E of iMX95EVK The i.MX95 EVK features an M.2 Key E slot, typically used for WiFi/BT combo cards. While plugging in a module is straightforward, understanding how the PCIe link actually comes up require diving into hardware signals, firmware initialization, and software enumeration.  In this blog, we will: - 1. Examine the M.2 Key E physical connector and identify PCIe signals on it. 2. Understand what those PCIe signals do and why are they needed? 3. What could be the possible routes while debugging PCIe in a system?   Introduction It is worth mentioning that M.2 Key E is not always used for PCIe. Rather it also supports other interfaces like USB 2.0, UART, SDIO. Our focus will specifically be on PCIe.  This blog assumes that you have a basic understanding of PCIe. What is PCIe? Why is it used? What is a link and lane? among other details. For the uninitiated, feel free to pause here and explore the web to get a basic understanding before eventually coming back to this blog. One of the links that prove to be resourceful yet crisp:- Microsoft PowerPoint - 03-05_-_Winkles_-_PCI_Express_Basics At this point, if you have physical access to the board, feel free to inspect and look at the M.2 Key E PCIe slot. M.2 keys are essential notches on connectors. It looks something like this: -   M.2 Key E slotM.2 Key E slot Figure-1 There are several M.2 key types that support PCIe, each designed for different use cases. Some of them are: - Slot type         Common-uses                                                Form Factor Key M :-          NVMe SSDs (supports x4)                             2280, 22110,2260,2242,2230 Key B  :-          SATA, cellular modems (supports x2)        2242,2260, 2280 Key E  :-          Wifi/BT modules (supports x1)                     2230, 1630, 3030 Key A :-           Wifi/BT (supports x2)                                    2230, 1630, 3030 These slots come in different form factors as you can see from the above list. The form factor refers to the width and length of the module. Each M.2 size uses a code that shows these dimensions. For example, “2280” means the module is 22 mm wide and 80 mm long. Similarly, "22110" means 22mm wide and 110mm long. On i.MX 95 evaluation kits and carrier boards, the M.2 Key E slot typically uses the 2230 form factor. For educational purpose we only refer to an illustration of M.2 connector from iMX95EVK schematic. Readers may obtain the schematic/design files from the NXP's official website.  The below image shows the M.2 Key E connector and the PCIe signals coming in and out of the iMX95EVK board's M.2 key E header.   M.2 Key E schematicM.2 Key E schematic Figure-2 The M.2 Key‑E slot is the Wi‑Fi/BT connector, and the PCIe-related nets exposed there include the PCIe differential data pair(s), reference clock, reset, clock request, and wake signals. M.2 Key E signals For PCIe bring‑up, the most important signals on this slot are: 1. PCIE1_TX0_P, PCIE1_TX0_N → slot PET_P0, PET_N0 Direction - Output from i.MX95 RC to Endpoint module PCIe transmit pair from host/root complex. With these signals, the root complex (i.MX95 side) transmits toward the Wi‑Fi module In the Image above that shows M.2 Key E connector, please observe that there's a capacitance of 0.22uF on each of the lines of a TX differential pair.   As per the PCIe specification, there are 3 main reasons to place coupling capacitors on the Tx lines: a. DC Isolation: - Since the differential signal is recovered by measuring the potential difference between the pairs, the AC caps remove any DC offset induced on the signal when a driver and receiver run at different voltages. This factors out any ground offset between a motherboard and a PCIe card. b. Detecting plug/unplug events: - Some PCIe endpoints are hot-swappable. The capacitors on a Tx pair allow the driver to use an RC time constant to detect the presence of a receiver at the end of a lane. c. Detecting Lane count: - In components that have multiple PCIe lanes, the plug/unplug events will occur across each lane, and the number of triggered lanes can be sensed by the PCIe-capable device. Note - The capacitors also need to pass as much signal as possible up to high frequencies, meaning they should have high enough self-resonant frequency. 2. PCIE1_RX0_P, PCIE1_RX0_N → slot PER_P0, PER_N0 Direction - Input to i.MX95 RC from module PCIe receive pair to host/root complex. With these signals, the root complex (i.MX95 side) receives from the Wi‑Fi module. TX0_P/N and RX0_P/N are the high-speed differential PCIe lane signals. These are the lines that carry: a. LTSSM training traffic b. configuration transactions c. memory reads/writes d. Interrupts as PCIe messages (MSI/MSIX) In a hardware bring-up, if these pairs are swapped or there's a missing AC coupling, the link will not train properly. As seen in Figure-2, The Key‑E connector exposes a second PCIe lane group (PET_P1/N1, PER_P1/N1, REFCLK_P1/N1, PERST1, CLKREQ1, PEWAKE1), but for a normal M.2 Wi‑Fi module usually x1 PCIe is used. 3. PCIE_WIFI_CLK_P, PCIE_WIFI_CLK_N / PCIE1_CLKIN_P, PCIE1_CLKIN_N → slot REFCLK_P0, REFCLK_N0 Direction - Clock output toward module PCIe needs a stable, low-jitter reference clock. The slot exposes REFCLK sourced from the board PCIe clock path. In PCIe, mainly there are 2 types of clocking:- a. Common reference clock - Both link partners share exact same 100MHz clock source   Figure-3Figure-3 b. Independent reference clock - Link partners using different 100MHz clock source Figure-4Figure-4 iMX95EVK by default uses Common reference clock, meaning that the host[iMX95EVK] and the PCIe endpoint connected to it would be sharing the 100MHz clock source. In the schematic image, PCIE_WIFI_CLK_P and PCIE_WIFI_CLK_N [100MHz] going towards the M.2 Key E slot are coming from the Si5332 clock generator on the board. In other words, it can be said that - the PCIe M.2 Key.E Wi-Fi module expects the iMX95EVK board to provide it the 100MHz reference clock. PCIe uses CDR (Clock Data Recovery), in which the clock is embedded in the data stream itself, not sent as a separate signal. So PCIe TX/RX pairs carry: - a. Data (encoded using 8b/10b or 128b/130b) b. Clock (embedded in signal transitions) Note: - CDR needs a reference frequency to lock onto. Both link partners must operate at the same base frequency, otherwise bit errors and even link failures can occur. Standard Ref clock used - 100MHz Differential clock (+-300ppm) Question - why not just send a separate clock signal instead of CDR? - That's because like in the older parallel buses, there would be clock skew issues at high speeds. More pins would be required. With CDR, fewer signals are used (just RX/TX pairs) and the clock travels with the data itself.   Figure-5Figure-5 The image above indicates that the PCIe link partners have PLL that uses REFCLK to generate the internal clocks. Each device uses their respective PLLs to generate higher-frequency clocks: Gen1: 2.5 GT/s (Giga-transfers/second) Gen2: 5.0 GT/s Gen3: 8.0 GT/s Gen4: 16.0 GT/s   what does it mean? - PLL uses REFCLK to generate internal clocks - A PLL is a frequency multiplier circuit that takes a low-frequency input (reference clock) and generates a higher-frequency output that's phase-locked (synchronized) to the input.   Figure-6Figure-6 Figure-7Figure-7 Figure-8Figure-8 Figure-9Figure-9 Question - Why use PLL internally instead of sending High-Frequency clock directly ? - Following are the reasons: - a. Routing a high frequency clock directly from host's main oscillator to PCIe slot would cause signal degradation, EMI and power loss. b. Difficult to route on the PCB. c. Using PLLs internally is much cheaper. d. At multi-GHz speeds, tiny deviation in clock timing can lead to data transmission errors. The PLL's loop filter continuously aligns the phase of the high-speed output signal with the reference clock.   Question - If CDR embeds clock in data transmission, then why is Reference clock provided as a separate signal?   Figure-10Figure-10 As can be seen from the above image, CDR doesn't work in isolation. It extracts clock from data, but it needs to know what frequency to look for. Without a reference clock, CDR sees transitions in data stream, but it doesn't know if it's 2.5, 5.0, 8.0GHz or some other frequency for that matter.   Imagine trying to catch a ball: Without REFCLK (no reference): - You don't know if the ball is coming at 10 mph or 100 mph Question - What would happen if the link partners have even minimal difference in reference clock? - As per the specification, small differences are tolerable (±300 ppm), but larger differences cause link failure. ±300 ppm means: 100 MHz ± 300 ppm = 100 MHz ± 0.03 MHz = 99.97 MHz to 100.03 MHz For 2.5 GHz (after ×25 multiplication): 2.5 GHz ± 300 ppm = 2.5 GHz ± 0.75 MHz = 2,499.25 MHz to 2,500.75 MHz   During link training, devices exchange training sequences: Transmitter sends: 10101010... at 2.5000 GHz Receiver expects: 10101010... at 2.5025 GHz The receiver's CDR tries to lock but phase keeps drifting. -Bit errors accumulate -Link training timeout -Link stays in "Detect" state This ultimately results in PCIe link failures.   4. PCIE1_RST_B -> slot PERST0 (active low reset) - PCIe reset Direction - Output from host to module It is PCIe reset to the endpoint. It is like host indicating to EP - "now you may start PCIe" The endpoint card should stay in reset until: 3.3V rail is valid REFCLK is stable host side PCIe controller is ready Then the host de-asserts PERST# and the endpoint begins PCIe initialization. The firmware/software driver sequencing is wrong if:   reset may be released too early endpoint may boot before clock/power are stable endpoint may remain held in reset host may start LTSSM while endpoint is still not alive And then if you go on debugging such a board, you notice reference clock and power rails are fine at the moment of probing but somehow PCIe never enumerates. So, timing of PERST# signal is of utmost importance.   Event Symptom PERST# never deasserts Card stays invisible PERST# deasserts too early Intermittent or no enumeration   5. WiFi_CLKREQ_B / PCIE1_IMX_CLKREQ_B / slot CLKREQ0 - PCIe clock request Direction - Open-drain Bi-directional In PCIe, CLKREQ# is an active-low bidirectional, open drain sideband signal which can be used by root complex and endpoint. It allows multiple devices to share a single wire. Devices can pull the CLKREQ# low to signal state changes and release it to floating state, allowing an external resistance to pull it high. Let's try to understand what open-drain bidirectional signal means:   An open-drain output can do only two things: pull the line low (drive a logic 0), or release the line and become high-impedance (Hi-Z).   It cannot actively drive the line high by itself. So, if you want the line to be high when nobody is pulling it low, you must provide a pull-up resistor to a supply rail (for example 3.3 V) Hence electrically the line becomes: -   No one pulls low --> pull-up resistor makes line HIGH Any device pulls low --> line becomes LOW   Bi-directional open-drain means: - Both connected devices: can observe/read the line state, and can also assert the line by pulling it low. So it is a shared wire where both sides participate. The circuit looks something like this: -   Figure-11Figure-11 One can observe from the above circuit diagram that the host-side PCIE1_IMX_CLKREQ_B and the module-side WiFi_CLKREQ_B are tied together through 0 Ohm links onto a single shared net. A 10K Ohms resistance to pull the line high to VDD_3V3 when nobody is driving it low. Here bi-directional means: -   the SoC side can observe the state of the shared line and can also assert it by pulling LOW, the Wi‑Fi endpoint side can also observe the same shared line and can also assert it by pulling LOW. For PCIe CLKREQ#, that means the two ends of the link (upstream port / downstream port) are connected to the same physical signal, and either side can request “clock” by pulling it low. Why is CLKREQ# used in PCIe? It is used by link partners to request reference clock for power state coordination. What this means is - with the help of this signal, power consumption can be managed by allowing either link partners to request, start or stop the 100MHz reference clock. Root complex monitors the CLKREQ# pin to detect when an endpoint is requesting a clock to wake up the link. In some SoC designs, the host can also drive this pin to control clock gating or to indicate an exit from low-power state. Endpoint pulls CLKREQ# low to request that the host resume providing the reference clock so the device can transition from a sleep state back to active data transmission. This signal is essential for the software to enable the ASPM/low-power states. If it is not routed on the board correctly: -   link may come up initially but fail in suspend/resume L1/L1SS transitions may break the module may disappear after idle periods Wi‑Fi may fail after runtime PM kicks in Question - What happens if the CLKREQ# signal was implemented as normal push-pull instead of open-drain Bi-directional signal? - one side could accidentally drive HIGH while the other drove LOW, creating contention and a direct short circuit between the power supply and ground. Open drain avoids that because nobody ever actively drives HIGH. If either side wants LOW, it simply sinks the line. Otherwise, both sides release the line, and the pull-up makes it HIGH. Question - Why active-low and why not active-high? - In a shared open-drain system, LOW is the easy state to actively assert. Open-drain hardware naturally pulls downward to ground using an NMOS / sink path, while HIGH is simply the released state created by the pull-up resistor. So active-low is the most natural form for such a signal What exactly happens on the wire in different cases ? Considering an open-drain bi-directional CLKREQ# has pull-up resistance to 3.3V  Case-A: No link partner needs the clock RC releases the line EP releases the line pull-up resistance pulls the wire HIGH results in CLKREQ#=1 de-asserted Case-B: Endpoint needs the clock endpoint pulls wire LOW host may still be released result: wire goes LOW anyway both sides read CLKREQ# = 0 (asserted) Case-C Host needs the clock host pulls wire LOW endpoint may be released result: wire goes LOW both sides see request asserted Case-D Both sides need the clock both may pull LOW simultaneously no conflict, because both are only sinking the line line stays LOW safely 6. WL_PCIE1_WAKEOUT_B / slot PEWAKE0 - PCIe wake Direction - Input to host from module It is an active-low sideband signal to wake up the host from sleep or low-power state. The hosts go to deep sleep states to conserve power. During this time, the main PCIe clock and data lanes are often completely powered down or disabled. This Wake# signal in M.2 Key E provides a direct out-of-band communication line to alert the host. The M.2 card detects an event that requires the host attention and then pulls the WAKE# low. Upon detecting this transition, the host powers up the necessary rails and re-enable the PCIe clock to fully resume the system. Some use-cases:- a. Wake on Wireless LAN - allows the host to wake up if a Wi-Fi card detects specific network traffic b. Bluetooth Device connection - allows the host to wake up when a paired Bluetooth device attempts to connect  7. M2_KE_PWREN and M2_KE_PD_B Direction - Output from PCAL IO Expander to load switch   M2_KE_PWREN - M.2 Key E Power Enable It is a board control signal used to enable power to the Key‑E slot / module power path. VCC_KE_3V3 is disabled by default to reduce transient power consumption so this control signal is used to turn that power on when the platform is ready. If M2_KE_PWREN is not asserted, the Wi‑Fi module may look completely dead even if PCIe routing is perfect, because the slot power rail may still be off M2_KE_PD_B - M.2 Key‑E Power-Down, active low if M2_KE_PD_B is driven LOW, the board is intentionally telling the module to stay in a disabled / power-down type condition, and if M2_KE_PD_B is HIGH, the module is allowed to operate normally. PD_B is different from PWREN: PWREN is about supplying / enabling slot power PD_B is about telling the module whether it should remain powered-down or active The PCAL IO Expander is controlled via I2C and used as one of the board's GPIO control. If M2_KE_PWREN is not implemented correctly, you may see: no 3.3 V at the socket no current draw from the module no PCIe enumeration If M2_KE_PD_B is incorrect, you may see: slot rail present, but module still appears dead or partially inactive no PCIe link-up even though REFCLK and PERST# seem okay confusing behavior where power looks present, but the module is effectively held off Note: - As seen in the Image, The Key‑E connector exposes a second PCIe lane group (PET_P1/N1, PER_P1/N1, REFCLK_P1/N1, PERST1, CLKREQ1, PEWAKE1), but for a normal M.2 Wi‑Fi module usually x1 PCIe is used. Debugging lens   Assuming, you have connected the PCIe M.2 Key E Wi-Fi card such as this one - AW693 on iMX95EVK. And booted it up with the latest Linux BSP. You notice that on 'lspci', there is no respective device entry for this M.2 module. There are 2 routes of debugging from this point onwards, assuming that the PCIe card is not faulty:- Hardware perspective: - Is VCC_KE_3V3 present and stable? Are the PCIe pairs routed correctly and with the intended controlled impedance? Is REFCLK present at the module? Is PERST# timing sane? Is CLKREQ# behaving or stuck? Is the module actually powered/enabled versus held in M2_KE_PD_B/power control state?  Software perspective: - Is the PCIe RC node enabled in firmware/device tree? Is the controller coming out of reset? Is LTSSM starting? Does the kernel ever detect link up? Does configuration space read succeed? Is ASPM/clock PM breaking early bring-up? So, one of the intuitive debugging steps can be: -          1. Observe link training in the software by checking: - kernel logs PCIe controller status LTSSM state if available whether device appears in config space 2. Check if the module gets 3.3V at the slot or not? 3. Check whether PERST# is initially asserted low and later released high. 4. Check whether the 100 MHz PCIe reference clock is present at the slot. 5. Observe CLKREQ# behavior before/after reset release. 6. Only after you have verified that the PCIe link is stable, move on to debug ASPM, suspend/resume or wake handling logic. There's a reason we start with checking the software first as it doesn't involve physical efforts of connecting probes to the test-points and setting up a scope for it. Debugging the software by putting logs or observing PCIe initialization in 'dmesg' is the quickest way to check what's wrong. If you do not get a clue, then you should definitely consider the hardware perspective. That's all for today. This was a rather lengthy blog but rightly so. This will help to build up an understanding of how PCIe cards work from a perspective of embedded software engineer so that we move on to understand how it is brought up via firmware/software. Feel free to DM in case of any doubts/comments. Until next time!   The i.MX95 EVK features an M.2 Key E slot, typically used for WiFi/BT combo cards. While plugging in a module is straightforward, understanding how the PCIe link actually comes up require diving into hardware signals, firmware initialization, and software enumeration.  In this blog, we will: - 1. Examine the M.2 Key E physical connector and identify PCIe signals on it. 2. Understand what those PCIe signals do and why are they needed? 3. What could be the possible routes while debugging PCIe in a system? IMX95EVK

在基于 NXP 的 SoM（Layerscape SoC）上调用 DDR 在我公司的几个月内，我们将准备好推出新的SoM（建立在恩智浦 LS1028 SoC 之上）。因此，我想向您--更有经验的开发人员--请教一些知识，您是如何进行 DDR 更新的？使用什么工具？如何进行 DDR 初始化？您要执行哪些步骤？关于 DDR 有哪些常见误区？我应该注意什么？ Re: DDR bring-up on NXP based SoM (Layerscape SoC) 关于 DDR 验证，请遵循《QCVS_DDR_用户指南》。 成功完成 QCVS 验证后，点击"Generate processor expert code" 的图标，在 \ \Generated_Code\ddr_init1.c,then将优化的计时参数集成到 ATF ddr_init.c 中。   QCVS DDR 是 codewarrior Developer Suite Level 的一个工具。 您还可以从以下链接下载 codewarrior Developer Suite Level Evaluation Edition。 https://www.nxp.com/design/software/development-software/codewarrior-development-tools/codewarrior-network-applications/codewarrior-development-suites-for-networked-applications:CW-DS-NETAPPS 评估版可免费使用，但有时间限制。   调试工具用于连接 LS1028A 客户板和 codewarrior 开发者套件级别，请在以下链接中找到该工具： https://www.nxp.com/design/design-center/development-boards-and-designs/CW_TAP CodeWarrior TAP 高性能探针基础单元，支持以太网和 USB（单独订购提示）。 cwh-ctp-base-he CWH-CTP-CTX10-YE Layerscape 处理器（Coretex 10 引脚）   DDR 布局应遵循 AN5097 AN5097，DDR4 同步动态随机存取存储器(SDRAM) 内存接口的硬件和布局设计注意事项

HSE_b: Not allowed to import RSA key to RAM I'm trying to understand how to use the key import service by importing a single 1024-bit RSA public key into the RAM catalog, but the server responds HSE_SRV_RSP_NOT_ALLOWED. My test application formats the RAM key catalog as follows: { { muMask = HSE_MU0_MASK | HSE_MU1_MASK, groupOwner = HSE_KEY_OWNER_ANY, keyType = HSE_KEY_TYPE_RSA_PUB, numOfKeySlots = 2, maxKeyBitLen = HSE_KEY1024_BITS, }, { muMask = HSE_MU0_MASK | HSE_MU1_MASK, groupOwner = HSE_KEY_OWNER_ANY, keyType = HSE_KEY_TYPE_ECC_PUB_EXT, numOfKeySlots = 2, maxKeyBitLen = HSE_KEY256_BITS, }, { muMask = 0, groupOwner = 0, keyType = 0, numOfKeySlots = 0, maxKeyBitLen = 0 }, } and I get server reply HSE_SRV_RSP_OK. I then try to import an RSA key with the following key info: { keyFlags = HSE_KF_USAGE_VERIFY, keyBitLen = HSE_KEY1024_BITS, keyCounter = 0x0, smrFlags = 0x0, keyType = HSE_KEY_TYPE_RSA_PUB, specific = { pubExponentSize = 4, } } and my request is as follows: { targetKeyHandle = 0x20000, pKeyInfo = 0x20401f74, pKey = { 0x210034b4, 0x21003534, 0x0}, keyLen = { 0x80, 0x4, 0x0}, } . I have set HSE_RAM_PUB_KEY_IMPORT_POLICY_ATTR_ID to HSE_KM_POLICY_ALLOW_RAM_PUB_KEY_IMPORT, and read it back as the same. LC attribute is 0x04, HSE error flags are 0x0000, HSE status flags are 0x0B60. Firmware version reads as 0x0F SoC ID 0x0000 FW type 0x02 major 0x32 minor 0x00 patch. Re: HSE_b: Not allowed to import RSA key to RAM Hi @Emma_G-gbg  Your parameters are correct, I can see nothing wrong there. If you have super user rights, it’s not even necessary to set that attribute. I was testing something very similar yesterday, so I just slightly updated my code to import 1024bit RSA public key with 4-bytes public exponent. It looks like this: lukaszadrapa_0-1779214365290.png lukaszadrapa_1-1779214375658.png Notice that it’s not necessary to set pubExponentSize when importing RSA public key. HSE ignores this parameter. It uses keyLen[1] instead. Parameter pubExponentSize is used when reading the keyInfo by service HSE_SRV_ID_GET_KEY_INFO. This is what I got when I read the keyInfo of that key: lukaszadrapa_2-1779214411712.png Isn’t that just data cache issue? Could you try to disable data cache to see if it makes a difference? Regards, Lukas Re: HSE_b: Not allowed to import RSA key to RAM Thank you, I had missed filling in cipher and auth key handle information, I hadn't checked so I thought HSE_INVALID_KEY_HANDLE would be zero. It's currently working with at least some of the values in cached memories, with cache maintenance operations before and after service calls. Since we are adding HSE services to an existing project we are precluded from changing the cache structure, but so far everything has worked as long as we make sure it's actually written to the shared memory, although I did also try disabling the cache for the relevant memories, which made no difference.

MR-VMU-RT1176 我想建造一架门到门的送货无人机。我能参加你们的创业计划吗？我现在没有注册公司。 我的第一个问题是，你们现在出售无人机开发套件吗？ 我有一个实现从门到窗目标的想法。我怎样才能以不公开的方式告诉你？ 如果 KIT-HGDRONEK66 不再销售。我可能会改用 VMU-RT1176 构建。   Re: MR-VMU-RT1176 你好@00000、 感谢您与我们联系。 请查看KIT-HGDRONEK66 的状态，它已存档。 Celeste_Liu_0-1779079159422.png 请考虑 MR-VMU-RT1176 产品信息 | 恩智浦半导体作为替代方案。 希望对您有所帮助。 BR 西莱斯特

imx8qm jailhouse Hi all, Is there any document showing all the steps to have a demo running on imx8qm mek board with jailhouse? I was going over this: L5.4.70_2.3.3_LINUX_DOCS but all I could find is a reference to device trees: Hypervisor Jailhouse Enables the Jailhouse Hypervisor device trees. • imx8qxp-mek-root.dtb: DTB for root-cell I do not know what to do with this info. That is why I need a step by step instruction list. Br, Mircea Re: imx8qm jailhouse @Jerry137207  Hi, Are you running jailhouse on top of hw ? Re: imx8qm jailhouse Hi @Rita_Wang  I am using MCIMX8QM soc I need to run android and freertos on top of hypervisor. Which hypervisor i can use ? Re: imx8qm jailhouse Waste of time. Nothing works out of the box on nxp imx8qm, at least not with the software provided by nxp. Android does not run in jailhouse, on imx95 they have a small android demo running in xen. freertos can run on the second core m3 core, you can flash the emmc with android and have it like that running. no hypervisor needed. Re: imx8qm jailhouse hi @Ahelion i am planning to use MCIMX8QM-CPU soc  i need to bringup freertos and Android on top on this do we need hypervisor here, and also Jailhouse is already present in the latest version of android ? Re: imx8qm jailhouse Hi, Ahelion: I'm interested in runing multiple OS based on jailhouse, but related information is lack. I've sucessfully run jailhouse test demo in Imx8qm mek board. If you would like share info each other, plz email me: [email protected]. Re: imx8qm jailhouse I can tell you right now, it is not supported. I could not get jailhouse or xen to work on imx8qm. Whatever documentation i find is referencing linux4.9, which can not be build anymore. Re: imx8qm jailhouse Hi, Yes, the xen is supported on the i.MX8QM. You can refer to the attach document. Wish you have a nice day Best Regards Rita Re: imx8qm jailhouse any ideea?  Found out that the latest linux kernel does support the lates XEN How can I get Linux and Android running at the same time? Re: imx8qm jailhouse OK, I will help confirm. Re: imx8qm jailhouse L5.4.70_2.3.3, i was following this quide, so all bsp-s mentioned here I am using. Re: imx8qm jailhouse Which version BSP are you want to use? Re: imx8qm jailhouse @Rita_Wang Xen willl support on latest kernal 6x? Re: imx8qm jailhouse @Rita_Wang i have one more we are buying MCIMX8QM soc  i need to run android and freertos as guest which hypervisor support on this latest kernel? jailhouse supports on latest kernel for my requirement  Re: imx8qm jailhouse Hi @Shivu_Guru_24 , Sorry for late reply. For the XEN the on latest kernal 6x do not support it. If customer want to use, they can do porting themself. In our BSP 4.14.98 support it. Customer and refer it: Embedded Linux for i.MX Applications Processors | NXP Semiconductors   图像.png Hope this can do help for you Wish you have a nice day Best Regards Rita Re: imx8qm jailhouse Hi @Shivu_Guru_24 , Jailhouse is a Type 1 hypervisor for i.MX 8. Xen is not support in the latest version BSP. Wish you have a nice day Best Regards Rita

链接文件 我试图将 HCS12 控制器的代码从 cosmic 移植到 CodeWarrior 5.2，当我试图使用 #pragma CODE_SEG PAGE_32 在 PAGE 32 部分下创建一个函数时，只有部分在映射文件中更新，起始地址保持不变。 Re: Linker file 你好，@Aswin_5232、 您没有说明 MCU 的部件编号。 改用类似的方法： 链接器 SEGMENTS PAGE_32 = READ_ONLY 0x8000 TO 0xBFFF PAGE 32; END PLACEMENT MyPage32Funcs INTO PAGE_32; END   主要 #pragma CODE_SEG MyPage32Funcs void MyFunc(void) { ... } #pragma CODE_SEG DEFAULT 此致， 丹尼尔 Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.

Zephyr SDK install error in Windows: setup.cmd Toolchain download failed Recently some Windows users started reporting issues installing the Zephyr SDK, required for building Zephyr applications.  Users first ran into this issue using NXP's MCUXpresso Installer, but had the same issue trying to manually install the Zephyr SDK. The root cause is that setup.cmd and these other tools use wget to download the individual toolchain packages.  And apparently recent changes in Windows or security settings interpret this wget download as unsecure, and wget is blocked. Context The Zephyr SDK is a package of multiple toolchains that support all the hardware platforms and CPU architectures available in Zephyr.  The binary bundle releases for download are available in two options: Minimal and Full.  For example, these bundles can be downloaded here for v0.17.4, currently the latest release. The Full bundle is a large download and includes all the toolchains and other tools in that download package.  The Minimal bundle is much smaller and does not contain any toolchains and allows users to choose the toolchains to download and install.  Minimal has an extra step after download to run the setup script and the user selects the tools to download.  In Windows, this script is setup.cmd. If installing the Minimal bundle and wget downloads are blocked for setup.cmd, then the Zephyr SDK install fails.  MCUXpresso Installer v25.12 and other install options use the Minimal bundle, and can be blocked by this issue. Workaround NXP is working on improving the MCUXpresso Installer to address this issue.  But in the meantime, downloading and installing the Full bundle avoids using wget and avoids this issue.   Download the Full bundle, here for v0.17.4, and extract the bundle in your user folder.  After extracting, the full Windows path will be  C:\Users\ \zephyr-sdk-0.17.4 .  West and other build tools will find this folder during the build.  The Zephyr SDK can also be installed elsewhere using an environment variable, see the Zephyr SDK documentation.  After extracting, run the setup.cmd to finish setup.  But with the Full install, setup.cmd will not need to download with wget. Be aware, this article was written when v0.17.4 was the latest release of the Zephyr SDK.  Check here for the latest release. Return to Zephyr Knowledge Hub

CAN UDSアップデートのためのS32K144統合ブートローダ構成 こんにちは、 私は、S32 Design Studio を使用して、S32K144 EVB 上の NXP Unified Bootloader ソース コードを操作しています。私の目的は、MCU にブートローダを統合し、UDS を使用して CAN 経由でアプリケーション ファームウェアを更新することです。ブートローダーをフラッシュする前に、ソース ファイルまたは構成を変更する必要があるかどうかを確認したいと思います。たとえば、CAN ID やボーレートなどの CAN パラメータを設定したり、S32K144 EVB の HAL/ドライバー移植ファイルを変更したりしますか?または、ブートローダーを何も変更せずにそのまま EVB にフラッシュして評価することはできますか? ブートローダをプログラミングした後、それが正しく実行されていることを確認し、CAN 経由でアプリケーションのフラッシュをテストしたいと思います。ブートローダ モードを強制する方法、ブートローダの実行を確認する方法 (UART ログ、CAN 応答、デバッガなど経由)、ブートローダがアプリケーションにジャンプする方法など、推奨される検証手順について説明していただけますか? さらに、正しいアプリケーション フラッシュ開始アドレス、リンカー設定、ベクター テーブルの場所、必要なスタートアップ コードの変更など、ブートローダーで動作するようにアプリケーション プロジェクトを構築する方法に関するガイダンスも必要です。最後に、S32K144 を使用した UDS フラッシュに使用される一般的な PC 側ツールと、CAN 経由で統合ブートローダをテストするための推奨 CAN インターフェース ハードウェアについて知りたいと思います。 Re: S32K144 Unified Bootloader Configuration for CAN UDS Update こんにちは@padmaja 、 残念ながら、コミュニティで共有されている統合ブートローダーは非公式のデモ版のみ提供されています。 現状のまま 保証もサポートもありません。現在、このデモをサポートするリソースがありません。ドキュメントを通じてご質問にお答えするよう努めますが、フォローアップが表示された場合は、代わりにサポート ページにお問い合わせください。 アプリケーションを MCU にフラッシュし、ECU-BUS 機能のテストを開始できます。CAN ID、ボーレートなどを変更する必要はありません。両方を参照できます 統合ブートローダ – ユーザーガイドとUDS ブートローダ実装ガイド。 Open Bus Toolを使用する前に、CANブートローダをMCUにダウンロードする必要があります。これは、S32DSを使ってプロジェクトをコンパイルすることで実行できます。また、コミュニティ投稿「 HOWTO: S32 Design Studioを使用してマイクロコントローラに個別のelf/srec/hexファイルをダウンロードする」に記載されているように、elf/binaryファイルをアップロードすることもできます。 Open Bus Toolを使用すると、CANバス経由でアプリケーションをダウンロードできます。PEAK CANバスインターフェースをサポートしています。APPプロジェクトは統合ブートローダパッケージに含まれています。 ツールで読み込む必要があるJSONファイルも存在します。このJSONファイルには、フラッシュドライバ（flash_api.bin）とAPPファームウェア（APPファームウェアのフォーマットはS19/hex/binary）に関する情報が含まれています。 よろしくお願いします、 ジュリアン

您知道 PCA9698 的状态吗？ 我想我可能需要这样的东西。其现状如何？有没有更新的类似产品？ 兰迪 Re: Do you know the status of PCA9698 ? 你好，兰迪、 PCA9698 目前仍在生产，但 HVQFN56 版本 (PCA9698BS) 已经停产。TSSOP56 版本（PCA9698DGG）仍然完全有效并受支持，是新设计的推荐选择。没有较新的恩智浦设备能够在单芯片中提供相同的 40 位 GPIO 数量和电流能力，因此，如果需要该功能，PCA9698DGG 仍然是最合适的解决方案。 BRs, Tomas

在线纠错码：它的作用以及如何实现 在线纠错码 (Inline ECC) 是一种能够实时检测并纠正内存或存储设备中发生的位错误的机制。在i.MX 8M Plus等 DDR 控制器上启用在线纠错码功能会降低 DDR 访问性能，但由于 ECC 区域仅占用大约八分之一的 DDR 容量，因此无需额外添加专用内存来存储 ECC 码（从而降低了物料清单成本）。 本文解释了内联 ECC 的功能，并介绍了如何实现它。   1. i.MX 8M Plus 在线 ECC 功能   i.MX 8M Plus DDR 控制器支持在线 ECC，可保护系统免受软错误（例如由 α 射线、中子等引起的 DRAM 位翻转）的影响。它为每 64 位数据存储 8 位 ECC（纠错码），从而能够纠正单比特错误并检测双比特错误。 由于没有专门用于存储 ECC 的内存，因此大约 1/8 的 DDR 容量被用作 ECC 区域。 由于 32 位数据总线在数据和 ECC 之间共享，启用内联 ECC 功能会降低 DDR 访问性能。   1.1.单比特纠错 (SEC) SEC 是 DDR 控制器的一项功能，用于检测单比特错误并将其纠正为正确的值。 Keita_Nagashima_4-1765435456176.png 图1 SEC示意图   1.2.双比特错误检测 (DED) DED 是 DDR 控制器的一项功能，用于检测双比特错误。 Keita_Nagashima_5-1765435507241.png 图2 DED概念图 笔记： 实际上，SEC 和 DED 是在 64 字节对齐的数据区（加上 8 字节的 ECC）中检测的，而不是在 8 字节中检测的。   2.内联 ECC 内存映射（概要）   根据 DDR 容量的不同，设置内联 ECC 内存映射的方法也会有所不同。   2.1.DDR密度是2的幂（二进制对齐密度） 例如，对于 1、2、4、8、16GB 的情况， DDR的低地址7/8用作数据区，高地址1/8用作ECC区。ECC区通常不可访问。 数据区域最多分为八个区域：区域 0 至 6 和其他区域。每个区域都可以启用或禁用 ECC 功能。 区域 0 至 6 的容量相同，分别设置为 DDR 容量的 1/8、1/16、1/32 或 1/64。其余区域均为其他区域。 以下是当区域 0 到 6 的容量设置为 1/8 时的内存映射。在这种情况下，没有其他区域。 Keita_Nagashima_2-1765437269920.png 图 3内存映射示例 (1/8) 下面显示的是当区域 0 到 6 的容量设置为 1/16 时的内存映射。 Keita_Nagashima_3-1765437330955.png 图 4内存映射示例 (1/16) 2.2.非 2 的幂次方的 DDR 密度（非二进制对齐密度） 例如，对于 3、6 或 12 GB 的情况（i.MX 8M Plus LPDDR4 EVK 为 6 GB，因此这适用于这种情况）。 将整个 DDR 分成三份，每份的容量是 2 的幂。 3GB内存，1GB x 3 6GB内存，2GB x 3 12GB版本，4GB x 3 对于分为三部分的低地址区域，进行如下设置：2.1. 当 DDR 容量为 2 的幂时。 三段式地址划分中，上两个地址区域的设置与下地址区域的设置相同。 下面显示的是设置为 1/8 时的内存映射。 Keita_Nagashima_4-1765437541555.png 图 5 DDR 容量不是 2 的幂（1/8）时的内存映射示例 3.使用 DDR 寄存器编程辅助工具进行设置   使用DDR 寄存器编程辅助工具(DDR RPA) 配置内联 ECC。 笔记： 请准备一个 DDR RPA，该 RPA 可以运行禁用内联 ECC 的 DDR 压力测试（并且还可以验证其是否可以运行 u-boot）。 由于存在漏洞，i.MX8MP LPDDR4/DDR4 RPA v6 或更早版本无法正常工作内联 ECC。请使用 v7 或更高版本。除非有特殊情况，否则请使用最新版本的 DDR RPA。（截至 2024 年 9 月，最新版本为 v9。） Linux BSP 的 U-Boot 中包含的 i.MX 8M Plus EVK 的lpddr4_timing.c 文件。以及ddr4_timing.c虽然乍一看似乎可以正常工作，因为它包含了定义 CONFIG_IMX8M_DRAM_INLINE_ECC ，但内联 ECC 设置存在问题，无法正常工作。即使您使用的是 EVK 进行测试，也请使用 DDR RPA 和 DDR Tool 生成 lpddr4_timing.c/ddr4_timing.c 文件。 3.1.启用在线 ECC 在 DDR RPA 寄存器配置表中，将内联 ECC 项设置为启用。   Keita_Nagashima_1-1765438351335.png 3.2.内存映射   3.2.1.DDR密度是2的幂（二进制对齐密度） 如果 DDR 容量是 2 的幂，请使用 ECC_Config_BinaryAligned 表。 指定区域 0 至 6 的容量。（1/8、1/16、1/32 或 1/64） 启用或禁用 0 至 6 区及其他区域的 ECC（受保护或未受保护）。 这是区域 0 到 6 的容量设置为 1/8 时的示例。 Keita_Nagashima_2-1765438431895.png 图 6 DDR RPA 设置 (1/8) 这是一个将 0 到 6 区的容量设置为 1/16 的示例。 Keita_Nagashima_3-1765438479461.png 图 7 DDR RPA 设置 (1/16) 3.2.2.非 2 的幂次方的 DDR 密度（非二进制对齐密度） 如果 DDR 容量不是 2 的幂，请使用 ECC_Config_nonBinaryAligned 表（i.MX 8M Plus LPDDR4 EVK 就是这种情况，容量为 6GB）。 指定区域 0 至 6 的容量。（1/8、1/16、1/32 或 1/64） ECC 启用或禁用内存区域 0 中的区域 0 到 6 以及其他区域（受保护或未受保护）的 ECC。 ECC 内存区域 1/2 将自动设置为与 ECC 内存区域 0 相同的设置。 这是区域 0 到 6 的容量设置为 1/8 时的示例。 Keita_Nagashima_6-1765438674787.png Keita_Nagashima_5-1765438582315.png Keita_Nagashima_7-1765438743893.png 图 8 DDR RPA 设置 (1/8) 这是一个将 0 到 6 区的容量设置为 1/32 的示例。 Keita_Nagashima_8-1765438820847.png Keita_Nagashima_9-1765438875946.png Keita_Nagashima_10-1765438920329.png 图 9 DDR RPA 设置 (1/32) 4.使用 DDR 工具进行测试并生成 lpddr4_timing.c/ddr4_timing.c 文件   您可以使用 DDR 工具来检查 DDR RPA 中所做的设置的运行情况。 如果 DDR 压力测试通过，则生成 lpddr4_timing.c/ddr4_timing.c 以合并到 U-Boot 中。   5. U-Boot 中的内联 ECC 实现   5.1.替换 lpddr4_timing.c/ddr4_timing.c lpddr4_timing.c 或者将 ddr4_timing.c 替换为 DDR RPA 和 DDR Tool 生成的文件。 uboot-imx/board/freescale/imx8mp_evk/lpddr4_timing.c uboot-imx/board/freescale/imx8mp_evk/ddr4_timing.c   5.2.添加配置 将 CONFIG_IMX8M_DRAM_INLINE_ECC=y 添加到您的 U-Boot 配置文件中。 将清单 1添加到 uboot-imx/configs/imx8mp_evk_defconfig CONFIG_IMX8M_DRAM_INLINE_ECC=y 笔记： U-Boot 配置文件 imx8mp_evk_inline_ecc_defconfig 是在 Linux BSP 5.4 中添加的，但由于维护不当，已被弃用。使用 EVK 进行测试时，更安全的做法是将配置添加到 imx8mp_evk_defconfig 中并使用它。 5.3.更改Linux保留区域¶ 软件禁止访问 ECC 区域。因此，设备树会动态修改，以便 Linux 内核（以及其他系统软件）将 ECC 区域视为保留区域。默认值硬编码为与 EVK 的 DDR 容量相匹配（LPDDR4 为 6GB，DDR4 为 4GB），因此如果 DDR 容量与 EVK 的容量不同，则必须修改代码。 使用uboot-imx/board/freescale/imx8mp_evk/imx8mp_evk.c中的函数 ft_board_setup 来更改 ECC 区域，使其与实际 DDR 容量相匹配。例如，对于 DDR4，ECC 区域的起始地址和大小是硬编码的，假定 DDR 容量为 4GB。 列表 2： DDR4 容量硬编码为 4GB phys_addr_t ecc_start = 0x120000000; size_t ecc_size = 0x20000000; 如果实际 DDR 容量为 2GB，则从物理地址 0x40000000 到 0xc0000000 的 1/8 (256MB) 高地址保留为 ECC 区域。 示例 3 ：将 DDR 内存容量更改为 2GB phys_addr_t ecc_start = 0xb0000000; size_t ecc_size = 0x10000000; imx8mp_evk.c 如果您不使用它，则需要添加与 ft_board_setup 函数等效的处理。   5.4.搬迁支持 如果 DDR 容量为 2GB 或更小，且未安装 OPTEE，U-Boot 会尝试重定位到 DDR 的最高地址，但由于该地址与 ECC 区域重叠，因此会在重定位过程中卡住。为避免这种情况，请添加 imx8mp_evk.h 文件。将 ECC 区域容量从 DDR 容量定义 PHYS_SDRAM_SIZE 中减少 (1/8)。 清单 4 uboot-imx/include/configs/imx8mp_evk.h -#define PHYS_SDRAM_SIZE 0x80000000 +#define PHYS_SDRAM_SIZE 0x70000000   5.5.排除对 ECC 区域的访问处理 如果 U-Boot 中还有其他代码访问了 ECC 区域，则需要排除对 ECC 区域的访问。例如，如果内存测试访问了整个 DDR 区域，则需要修改该测试，使其不再访问 ECC 区域。 参考： https ://github.com/nxp-imx/uboot-imx/blob/lf-6.1.55-2.2.0/configs/imx8mp_evk_defconfig#L10-L11   6. Linux 系统运行检查   6.1.查看启动日志 确保在 Linux 启动时已安装 EDAC 驱动程序。（EDAC = 错误检测和纠正）i.MX 8M Plus 的 EDAC 驱动程序位于linux-imx/drivers/edac/synopsys_edac.c 。 清单 5检查启动日志 root@imx8mp-lpddr4-evk:~# dmesg | grep EDAC [ 0.116733] EDAC MC: Ver: 3.0.0 [ 1.874689] EDAC MC0: Giving out device to module 1 controller synps_ddr_controller: DEV synps_edac (INTERRUPT)   6.2.检查内存映射 使用命令 cat /proc/iomem 确认 ECC 区域已按照5.3 节“更改 Linux 保留区域”中的配置设置为保留。以下是 i.MX 8M Plus LPDDR4 EVK（DDR 容量 6GB）的示例。 列表 6检查内存映射 root@imx8mp-lpddr4-evk:~# cat /proc/iomem | grep reserved ... b0000000-bfffffff : reserved ... 130000000-13fffffff : reserved ... 1b0000000-1bfffffff : reserved   6.3.检查何时发生 ECC 错误 根据应用说明AN13566 - i.MX 8 系列上的 ECC ，i.MX 8M Plus 中的 DDR 控制器没有故意生成 ECC 错误的功能。 3.2.9通过软件注入ECC错误 ECC 错误注入是系统级软件验证的一个有用的可选功能。与边带 ECC 不同，它没有专门的硬件支持。但是，可以通过软件注入错误，方法是通过“ECC_REGION_PARITY_LOCK”寄存器解锁 ECC 区域并覆盖 ECC 奇偶校验位。当从受保护的内存区域读取相应的地址时，根据引入的错误类型，会产生可纠正的或不可纠正的 ECC 错误。 注意：DDR 控制器不支持 ECC 数据中毒。参考手册将进行更新，移除此功能。 因此，我们解锁ECC区域，并从内核层面修改ECC区域以模拟ECC错误并进行测试。基本思路如下： 将 8 字节值 0xffffffff_ffffffff 写入 DataAddr。DDRC 向 DDR 写入数据的同时，还会写入 1 字节的 ECC 纠错码。 解锁 ECC 区域，允许核心访问 ECC 区域。 获取与 DataAddr 对应的 ECC 字节的地址，并读取 ECC 的一个字节。 将反转后的值 0xffffffff_fffffffe 写入 DataAddr。同时更新 ECC 1 字节。 ECC 1 字节，ECC 读取于 3。将字节值写回。 锁定 ECC 区域，禁止从核心访问 ECC 区域。 读取 DataAddr 的值。此时，由于 ECC 不一致，单比特纠错被激活，并读取纠错后的 8 字节值 0xffffffff_ffffffff。同时，内核也会收到一个可纠正错误中断通知。 笔记： 由于这涉及到访问 DDR，因此必须在非缓存区域执行测试。 Keita_Nagashima_11-1765439108812.png 图 10单比特纠错 (SEC) 测试方法¶   双比特错误检测 (DED) 调试也可以用同样的方法进行。   7.参考资料 应用说明： AN13566 - i.MX 8 系列的 ECC 应用说明：AN13616 - 验证 i.MX 8 直列式 ECC 引擎功能（请联系您的 NXP 代表以获取此文档） i.MX 8M 系列 DDR 工具发布 - NXP 社区 i.MX 8M Plus DDR寄存器编程辅助工具 (RPA) - NXP社区 8.注意 本文档是使用恩智浦产品的参考指南。 有关正式规格，请参阅产品手册和应用说明。 实际操作可能因各种条件（例如所使用的软件版本）的不同而与所述内容有所不同。 并非所有功能都已验证，因此请务必验证和测试产品，以确保其符合您的预期用途。 =========================​ 我们目前无法 回复 此帖子“ 评论”部分的评论。 对于由此造成的不便，我们深表歉意。如有任何疑问， 请 参考“ 如何就 技术问题 联系 NXP （ 日语 博客 ） ” 。 （如果您已经是 恩智浦的 分销商或 与 恩智浦 有业务往来 ，您可以直接联系负责人。 ） 在线纠错码 (Inline ECC) 是一种能够实时检测并纠正内存或存储设备中发生的位错误的机制。在i.MX 8M Plus等 DDR 控制器上启用在线纠错码功能会降低 DDR 访问性能，但由于 ECC 区域仅占用大约八分之一的 DDR 容量，因此无需额外添加专用内存来存储 ECC 码（从而降低了物料清单成本）。 本文解释了内联 ECC 的功能，并介绍了如何实现它。 i.MX 处理器 日本博客

iMX RT700 EVK accessing SDIO Card Trying to access 1.8V SDIO card on RT700 EVK. Set jumpers JP65 and JP66 to 1-2 using a sample enhanced with debug statements. SDCARD fatfs freertos example. Card inserted. SDCARD fatfs freertos example. Card inserted. --- SD Card Init --- SD card init failed! Status: 1834 Possible causes: - Card doesn't support 1.8V signaling - Voltage switch failed - Card communication error Trying basic card detection... OCR: 0x 0 Flags: 0x 0 Re: iMX RT700 EVK accessing SDIO Card Hi @MikeAtPhantom , Thank you so much for your interest in our products and for using our community. Please carefully check the readme file. I did a test for you, the SDK demo runs okay. HW: MIMXRT700-EVK    JP65 1-2 connected SW:  mimxrt700evk_sdcard_fatfs_freertos_cm33_core0 SD:    SanDisk  Ultra   32G mayliu1_0-1768795490345.png Please use Recommend SD Cards , and try to run the example again. Best Regards MayLiu

i.MX RT1060 API の LPSPI_MasterTransferEDMA は 24 ビットのフレーム サイズをサポートしていませんか? LPSPI を使用して DMA 経由で 24 ビット フレームを書き込もうとしています。アプリケーションは重要ではありませんが、私の例では、メモリから外部 DAC にデータを送信することです。私はこれを DMA で動作させたいと思っています。なぜなら、最終的には TCD のリンク リストを PIT と一緒に使用して、CPU オーバーヘッドなしで DAC を継続的に更新するためです。これは外部 ADC および DAC を使用する一般的なアプリケーションです。16 ビット DAC/ADC には 24 ビットのフレーム要件があることも一般的です (上位バイトはコマンド用、下位バイトはデータ用)。uint8_t データを使用して転送を 3 バイトに分割するのではなく、uint32_t データを使用して 24 ビットのフレーム サイズで送信し、先頭バイトを無視します。 さて、LPSPI と DMA の構成に移ります。 1.imxRT1060 SDK の API LPSPI_MasterInit 関数の lpspi_master_config_t 構造を使用すると、 bitsPerFrame を 24 に設定できます。DMA を使用せずに標準転送を行う場合、これは問題ではありません。 2. ただし、API の LPSPI_MasterTransferEDMA 関数で DMA を使用する場合、24 ビット フレーム サイズのケースは eDMA ハードウェアによって処理またはサポートされませんか?LPSPI_MasterTransferEDMALite では、DMA 転送幅は edma_transfer_config_t 構造体で設定されます。具体的には、srcTransferSize フィールドと destTransferSize フィールドは、SPI フレーム サイズ (bytesPerFrame) から導出される bytesEachRead 値と bytesLastWrite 値に基づいて構成されます。 /* LPSPI_MasterTransferPrepareEDMALite */ uint32_t bytesPerFrame = ((base->TCR & LPSPI_TCR_FRAMESZ_MASK) >> LPSPI_TCR_FRAMESZ_SHIFT) / 8U + 1U; if (bytesPerFrame <= 4U) { handle->bytesEachWrite = (uint8_t)bytesPerFrame; // for 24bit frames = 3 handle->bytesEachRead = (uint8_t)bytesPerFrame; // .... handle->bytesLastRead = (uint8_t)bytesPerFrame; // .... } /* now back in LPSPI_MasterTransferEDMALite */ switch (handle->bytesEachRead) //bytes each transfer { case (1U): transferConfigRx.srcTransferSize = kEDMA_TransferSize1Bytes; transferConfigRx.minorLoopBytes = 1; if (handle->isByteSwap) { addrOffset = 3; } break; case (2U): transferConfigRx.srcTransferSize = kEDMA_TransferSize2Bytes; transferConfigRx.minorLoopBytes = 2; if (handle->isByteSwap) { addrOffset = 2; } break; case (4U): transferConfigRx.srcTransferSize = kEDMA_TransferSize4Bytes; transferConfigRx.minorLoopBytes = 4; break; default: transferConfigRx.srcTransferSize = kEDMA_TransferSize1Bytes; transferConfigRx.minorLoopBytes = 1; assert(false); break; } デフォルトのケースが発生し、3 バイトのケースは処理されないためエラーが発生します。EDMAハードウェアは3バイト転送をサポートしていますか？基本的に、uint32_tのデータとフレームを3バイトとして扱い、最上位バイトを無視してDMA転送を行いたいのですが、可能ですか？ Re: i.MX RT1060 API's LPSPI_MasterTransferEDMA does not support 24bit framesize? こんにちは@azoneさん、 弊社の製品にご興味をお持ちいただき、またコミュニティをご利用いただき誠にありがとうございます。 次のリンクを確認してください。eDMA は 1、2、4、8、16、32、64 バイトの転送サイズをサポートしており、24 ビット (3 バイト) の転送サイズはサポートしていないことが説明されています。 MCUXpresso SDK APIリファレンスマニュアル: EDMA: 拡張ダイレクトメモリアクセス (eDMA) コントローラドライバ mayliu1_0-1768271744223.png よろしくお願いいたします。 メイリュー Re: i.MX RT1060 API's LPSPI_MasterTransferEDMA does not support 24bit framesize? わかりました。確認してくれてありがとう。これで、動作させるために時間を無駄にすることがなくなりました。したがって、唯一の方法は、すべてをuint8_tデータとしてkLPSPI_MasterPcsContinuousで3バイトとして送信することです。これは他のすべてのペリフェラルでも同じ方法で実行しているので問題ありませんが、16ビットDAC実装の場合は不要なオーバーヘッドが発生します。ありがとうございます。

S32K310 CAN Interrupt Receive S32K310のCANドライバモジュールをCANとCANIFを使って設定しました。CAN_Write()関数を呼び出してメッセージを送信できることは分かっていますが、以下の点について疑問があります。 1. メッセージを受信するにはどうすればよいですか？CanIf_RxIndication()関数を使ってメッセージを受信できるという記事をいくつか見ました。しかし、この関数のロジックは静的コード内で自動的に呼び出されるべきであり、外部メインプログラムで自分で記述するべきではありません。あるいは、この関数は割り込み発生後にデータを保存するので、どのようにデータを読み出せばいいのでしょうか？自分で作成したコールバック関数に置き換えることは可能でしょうか？（MCALルーチンの中に割り込みを使用するCANルーチンは見つかりませんでした。POLLINGモードのルーチンしかないようです。） CAN.png 2. CANの受信はCANIFを経由する必要があるのに、送信はCANドライバーから直接送信できるのはなぜですか？何か仕様上の制限があるのでしょうか？ 助けてくれてありがとう!! Re:S32K310 CAN割り込み受信 こんにちは@Embedded_novice、 1.FlexCANがドライバーとどのように連携するかについては、次のトレーニングをご覧ください:RTDおよび低レベルドライバーを使用したFLEXCAN。 割り込みモードでメッセージを受信するには、割り込みドライバー(IntCtrl)を設定し、FlexCANデータ情報構造体内でpolling = FALSEを選択し、「FlexCAN_Ip_Receive」を使用する必要があります。 この例は、コミュニティの投稿からガイダンスとして使用できます: TX/RX/EnhanceRXFIFO DMAテストの例S32K344 FlexCAN_Ip S32DS3.5 RTD400 - NXPコミュニティ。 2. CanIf_RxIndication APIのことを言っているのですね。前の回答で述べたように、代わりにFlexCAN_Ip_Receiveを使用できます。 Best regards, Julián

EB tresos 许可证到期 我的 EB Tresos 许可证有效期至 2025 年 12 月 31 日（即将到期）。 如何在过期前获得新的激活码？ Re: Expiration of EB tresos license 嗨，Joung、 请注意，在圣诞假期期间，我们的支持响应时间可能会比平时长。在某些情况下，您的请求可能会在新年后得到处理。感谢您的理解。 几天前，我给 [email protected] 发了电子邮件，提醒他们更新 EBTresos 激活码，但至今没有收到回复。 恐怕要到新年后才能更新。 很抱歉给您带来不便！ 祝好， Robin ------------------------------------------------------------------------------- 注： - 如果本帖回答了您的问题，请点击"ACCEPT AS SOLUTION" 按钮。谢谢！ - 我们会在最后一次发帖后的 7 周内跟踪主题，之后的回复将被忽略 如果您以后有相关问题，请另开新主题，并参考已关闭的主题。 -------------------------------------------------------------------------------

EIQ 時系列生成モデルは、PowerQuad DSP または Neutron N1-16 NPU を使用して高速化されます。 質問: PowerQuad DSP または Neutron N1-16 NPU を使用して EIQ 時系列生成モデルを高速化するにはどうすればよいですか? 図に示すように、別のライブラリ ファイルを追加する必要がありますか、それとも生成されたモデルの静的ライブラリにはすでに PowerQuad DSP または Neutron N1-16 NPU アクセラレーションが含まれていますか? 想定される回答：PowerQuad DSPまたはNeutron N1-16 NPUアクセラレーションを使用したドキュメントまたはプロジェクトをご提供ください。TSSで更新可能な関連プロジェクトはありますか？ xiaobai_226_0-1766832314400.png マクネン NPU|ML Re: eiq time series 生成模型使用PowerQuad DSP or Neutron N1-16 NPU加速 こんにちは@xiaobai_226 Harry_Zhang_0-1767064712071.png アクセラレータのサポート。  PowerQuad : NXP ハードウェア IP は、FFT 計算を高速化するのに役立ちます。選択したターゲットにこのハードウェア モジュールが含まれている場合は、デフォルトで表示され、有効になります。 Neutron NPU : NXP ハードウェア IP はディープラーニング モデルの予測を高速化するのに役立ちます。これは、選択したデバイスにこのハードウェア モジュールが含まれている場合にサポートされます。 BR ハリー Re: eiq time series 生成模型使用PowerQuad DSP or Neutron N1-16 NPU加速 こんにちは、ハリー TSS によって生成されたライブラリ ファイルには、すでに加速プロセッシングユニットが組み込まれているということをおっしゃっているのでしょうか?.lib 以降TSSによって生成されたファイルには、プロセッシングユニットが含まれているかどうかが明示的に示されておらず、SDKの例とTensorFlow for NPUの両方でNPUは.aの形式で提供されることを考えると、ファイルでは、TSS で生成されたファイルに加速ユニットが含まれているかどうかは不明のままです。テストに使用する評価ボードは MXCN947EVK です。

I.MX8MP Ethernet Camera Hello, Since the i.MX8MP does not support virtual channels, we would like to stream four Ethernet cameras simultaneously, as illustrated in the diagram below (which belongs to a different S32 processor); therefore, our question is whether the i.MX8MP is capable of decoding and streaming four 1080p @ 30 fps Ethernet camera streams at the same time, given that the Reference Manual indicates support for VLAN-tagged frames and AVB, but the VPU provides only a single hardware decoder.   Wobaffet_5-1766741211636.png Thanks, Best Regards.         Re: I.MX8MP Ethernet Camera Hello, Yes the iMX8MP could handle that, and the gstreamer is the tool that we use to decode all your streams. Regards

GUI Guider v1.7.2 オフライン テンプレートをダウンロードできません。 公式サイトからGUI Guider v1.7.2 オフライン テンプレートをダウンロードできません。ダウンロードしたバージョンは自動的に最新の 1.10.1 バージョンに更新されます。サーバーのリソース パスが正しいかどうかを確認してください。 Re: I can't download the GUI Guider v1.7.2 Offline Template. こんにちは@zzxx 、 この問題を報告していただきありがとうございます。試してみましたが、まさに説明どおりに動作しました。これを社内チームに報告し、修正が提供されるのを待ちます。 BR セレステ Re: I can't download the GUI Guider v1.7.2 Offline Template. こんにちは@zzxx 、 現時点ではこの問題に関してそれ以上の進展はありません。クリスマス休暇および EMEA と AMEC のタイム ゾーン全体の休日期間のため、プロセッシング時間は通常より長くなる場合がありますのでご了承ください。 皆様のご理解とご協力に心より感謝申し上げます。 楽しい一日をお過ごしください！ BR セレステ Re: I can't download the GUI Guider v1.7.2 Offline Template. こんにちは@zzxx 、 すべてが順調に進んでいることを祈っています。問題が解決したことをお知らせしたかったのです。   BR セレステ    

FreeMASTER を S32K3、Simulink MBDT、Segger JLink で使用すると問題が発生する こんにちは、 当社では、S32K311 を使用する独自設計のハードウェアを保有しています。 Segger JLink (Ver 7.98d) を使用して、Simulink 自体からターゲットをビルドしてフラッシュすることができました。 データ ストア メモリ変数を監視/変更するための FreeMASTER プロジェクトを作成しました。Segger JLink との通信ウィザードを設定し、接続が成功することを確認しました。 FreeMASTER で「GO」ボタンを押すと、ターゲットがフリーズ状態になるように見えます。たとえば、このモデルでは、Alive LED が点滅していますが、「GO」ボタンを押すと停止します。後で「STOP」を押しても何も変わりません。 電源をリセットすると、プログラムはデフォルトに戻り、変更した変数値も取得されませんでした。 FreeMASTER Config ブロックを使用する必要がありますか (接続タイプは Serial/CAN と記載されていますが)?モデル内で FreeMASTER Config ブロックを使用せずに変数を監視/変更することは可能ですか? schitta_0-1752164346161.png 何が足りないのか教えてください。 Re: Running into issues using FreeMASTER with S32K3, Simulink MBDT, Segger JLink こんにちは、 @beginner100さん FreeMASTERプロジェクトで変数を監視するには、 FreeMASTER Configブロックが必須です。現在の進捗状況についてお知らせいただけますか？また、可能であれば、FreeMASTERの設定に関する追加情報もご提供いただけますでしょうか？ 最新の S32K3 Toolbox バージョン1.8.0 (NXP Model-Based Design Toolbox for S32K3 バージョン 1.8.0 - 製品リリース発表) をインストールすることもお勧めします。 よろしくお願いいたします。 ドラゴス

フリートスK5ステータスに関する質問 こんにちはチーム フリートスのK5ステータスについてお聞きしてもよろしいでしょうか? 私はIDEs(DS3.6.4)にfreertosを追加しました。RTD0.8.0 CD3（K5用） しかし、私の側では機能していないようです。 以下のようにデモを呼び出しました。 ただし、以下のエラーは修正されませんでした... 「アップデート」後、freertos のフォルダが見つかりませんでした。 K5フリートステータスについてお尋ねしてもよろしいでしょうか? 私のアプローチが間違っている場合は、修正方法を教えてください。 ありがとう。 RTOS S32_CONFIG_TOOL 出典: 直接お客様 出典: NXP社内 Re: Question about freertos K5 status はい、debug_flash はコードが MRAM からロードされ実行されることを意味します。すべて正常に動作するはずですが、問題が発生した場合はお知らせください。 Re: Question about freertos K5 status はい、debug_flash はデフォルトで有効になっています。つまり、コードは MRAM からロードされ、実行されます。 すべて正常に動作するはずですが、何か問題が発生した場合はお知らせください。 Re: Question about freertos K5 status こんにちは@Nguyen_Duy_Dat ご返信ありがとうございます。 うまく動作しているようです。 そして、debug_flash と Clock 構成が正常に動作していることを確認しました。 これは正しいですか？ ありがとう。 Re: Question about freertos K5 status こんにちは@Luke_Chun 、 最新の freeRTOS 0.8.0 バージョンを使用しているようですが、これは RTD 0.8.0 CD3 とは 互換性がありません 。代わりに RTD 0.8.0 (2025 年 12 月リリース) をインストールしてください。 よろしくお願いいたします。 ダット

使用 jLink Segger 探针 RESET MIMXRT1176-EVKB 您好， 我正试图使用 Segger JLink 探头对评估套件（MIMXRT1176-EVKB，修订版"55139 REV C3" ）进行编程。 为此，我在 JP5 上添加了一个跳线，以断开嵌入式 MCU 链接，从而使探针能够对闪存编程。 尝试对二进制文件进行编程后，探测器似乎无法正确RESET CPU。编程完成后，CPU无法RESET，我必须手动RESET。 这让我觉得探头和 CPU 之间有问题，可能缺少了什么东西（跳线？其他？） 这是一个已知问题吗？我是否遗漏了文件中的某些内容？ 感谢您的帮助、 布伦丹 Re: Reset MIMXRT1176-EVKB with JLink Segger Probe 嗨，@BrendanLT、 您是否还短接了 JP4？正如 MIMXRT1170-EVKB 板硬件用户指南中所述： EdwinHz_0-1766163262721.png BR, Edwin.