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. 

[S32K388] SPD 1.0.6 Package Missing Complete Test Examples - Request for Register-Level Reference C Hi NXP Support Team,   I downloaded the "Safety Peripheral Drivers for S32K3 Version 1.0.6"    After installing and importing the SPD_example_S32K388_M7_0_0 project into S32 Design Studio, I found that the main.c is essentially empty   **My Environment:** - S32 Design Studio for S32 Platform 3.5 - SPD Version: 1.0.6 (SW32K3_SPD_1.0.6_D2512_DesignStudio_updatesite_updated.zip) - Target: S32K388 M7_0   **What I Expected** Please send complete register-level examples for: ECC on all memories (Flash, SRAM, TCM) - FCCU (Fault Collection and Control Unit) - STCU2 (Self-Test Control Unit 2 with LBIST/MBIST) - EIM (Error Injection Module) - ERM (Error Reporting Module) - CMU (Clock Monitor Unit) - Lockstep Core - SWT (Software Watchdog)   Send to [[email protected]] Or provide download link. Thank you.   Best regards, Re: [S32K388] SPD 1.0.6 Package Missing Complete Test Examples - Request for Register-Level Referenc Hi @xlele, Copilot said: The SPD provides a complete demo project, but it is available only for EB Tresos and not for the S32DS IDE. The demo is distributed in the standalone .exe version. Here is an unofficial SPD example for S32DS IDE.  https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K344-BIST-eMCEM-SPD106-v2-0-S32DS365-RTD700/ta-p/2373113 There is one bare-metal EIM, ERM example: https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K344-EIM-ERM-DTCM-SRAM-Baremetal-v3-0-S32DS36/ta-p/2193534 One CMU_FC example: https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K344-MCAL-MCU-ClockMonitor-v1-0-S32DS36-RTD600/ta-p/2179976 SWT example can be found by default in RTD. Best regards, Daniel

ホストからスイッチへのトレーラーは削除されていませんSJA1110 私はSJA1110上のホストプロセッサ(Cortex-M7)を通じてイーサネットフレームを送信しています。スイッチの特定のポートにルーティングするために、5.8.2の下UM11107に説明されているホスト-トゥスイッチヘッダー/トレーラーを使用しています。 フレームは正しい港に到着しているが、トレーラーは解体されていないか、部分的にしか解体されていない。参考までに、送信前にtxBufferに格納された同じフレームと、受信後に別のデバイスのrxBufferに格納された同じフレームを以下に示します。 01 80 c2 00 00 10 68 58 c5 00 11 02 8b 8c 88 39 88 b7 5a 46 00 01 02 06 68 58 c5 00 11 02 04 01 00 06 01 02 12 01 01 14 0e 01 02 11 00 c5 58 68 08 d8 26 c0 cb fd 18 00 00 00 00 ---- 00 04 00 00 00 ====== 01 80 C2 00 00 10 68 58 C5 00 11 02 88 B7 5A 46 00 01 02 06 68 58 C5 00 11 02 04 01 00 06 01 02 12 01 01 14 0E 01 02 11 00 C5 58 68 08 D8 26 C0 CB FD 18 00 00 00 00 ---- 00 04 00 00 00 ご覧の通り、ヘッダーは完全に削除されていますが、トレーラー(4本の線以降の部分)は削除されていません(イーサネットフレームが有効であるため、すべて0に設定されていることも含めて)です。 Re: host-to-switch trailer not removed on SJA1110 こんにちは、 @flxwly さん。 提供されたデータから判断すると、ホストからスイッチへのヘッダーは認識されているようで、4バイトのヘッダーは送信フレームから削除されています。しかし、受信フレームの末尾には依然としてトレーラーバイトが表示されます。 重要な点の一つは、ホストからスイッチへのヘッダーのTRAILER_POSフィールドです。あなたの例のヘッダーバイトは8b、8c、88、39です。 ホストからスイッチへのヘッダー形式で解釈すると、HEADER_TYPE = 0x8B8C、HOST_SWITCH = 1、TRAILER = 1、TRAILER_POS = 57となります。しかし、ダンプに示されている送信フレームでは、5バイトのトレーラーはMAC DAフィールドから0ベースのオフセットで59バイト目から始まっているようです。SFDに対する正確な位置カウントの慣例によっては期待値が1差になることがありますが、符号化された値57は実際のトレーラー位置と一致していないようです。 したがって、まずTRAILER_POSフィールドの計算方法を確認し、トレーラーの最初のバイトに対応する位置に設定してみてください。 もう一つ指摘しておきたい点があります。それは、提供されているテストフレームが非常に短いということです。5バイトトレーラーが剥がされると、得られるイーサネットフレームはFCSなしの最小イーサネットフレームサイズより短くなり、退出時に再度パディングを追加する必要があります。この曖昧さを避けるために、例えばホストトレーラーの前に16バイトや32バイトのダミーバイトを追加するなど、より長いペイロードでテストを繰り返していただけますか?これにより、トレーラーが本当に部品を抜き取られているかどうかが明らかになるだろう。 また、2番目のデバイスがフレームを受信する出力ポートが、通常のポートとして設定されていることを確認してください。UMによると、フレームが通常のポートから出力される際にはヘッダーとトレーラーは削除されますが、フレームがホストポートまたはカスケードポートから出力される際には制御情報は保持されます。 最後に、5バイトのトレーラー値「00 04 00 00 00」がどのように生成されるのか教えていただけますか?FRAMEID、PRIO、SWITCHID、DESTPORT のビットパッキングを、ユーザーマニュアルに示された形式と照らし合わせて検証することが有用でしょう。 よろしくお願いいたします。 パベル Re: host-to-switch trailer not removed on SJA1110 こんにちは、 @PavelL さん。 お返事ありがとうございます。トレーラーの位置は正しいのですが、ポストでフレームの「終わり」を間違ってマークしていました。実際には2バイト手前です（ご指摘のとおり、57バイト目です）。 したがって、予告編も異なり、今では意味が通じ、UMのシナリオに合致している。 また、トレーラーが64バイト以上過ぎてからしか表示されないフレームでは、トレーラーが正しく削除されていることも確認できます。つまり、これはトレーラーが追加される前の64バイト未満のフレームでのみ問題になります(確かIEEEの仕様ではトレーラーは存在しないはずです)。 よろしくお願いいたします。 ネポムク

如何在《MLB The Show 26》中解锁布莱斯·哈珀的循环里程碑系列 如果你最近一直在玩钻石王朝模式，你肯定已经知道社区正在热议新的 98 OVR 循环里程碑系列布莱斯·哈珀。这张卡片是为了纪念他在现实世界中完成完全打击的历史性表现而推出的，老实说，它的属性使其成为任何想要巩固外野或为阵容增添一些精英左打力量的人的必备之选。 有什么猫腻呢？他并不受制于一条简单的奖励机制。要获得这张 Harper 卡，你需要购买 Chase Pack 16。由于他是追逐包奖励，解锁他需要一些策略、运气或一大堆短截线。根据你拥有的时间或游戏内货币，以下是把他加入你的队伍的四种最佳方法。 1. 努力刷完第四局经验奖励路径轮盘 如果你正在组建一支严格的“零氪金”（NMS）队伍，那么这是你完全免费获得该卡牌的最佳主动刷图方法。完成第四局经验值计划的主要奖励后，真正的挑战并不会就此结束。超出程序主上限的额外经验值，每多获得一点，就能让你有机会转动一次可重复使用的奖励路径转盘。追逐包 16 就在这个转盘的奖池里，这意味着你可以不断刷经验值，并有机会抽取该卡包，而无需花费一根短截线。 2. 购买《The Show》50 合集 对于那些不想参与随机转盘抽奖，并且一直在攒钱购买游戏币的玩家来说，可以在礼包市场中采取更直接的方式。如果你购买标准的《The Show》50包组合包，游戏会额外赠送一个必定的追逐包16。虽然购买组合包总算有点投资，但知道你能 100% 获得包含哈珀的特定追逐包，这比购买单个卡包要安全得多。 3. 试试你的运气，购买标准版《The Show》卡包 你也可以顺其自然地玩游戏，然后祈祷运气之神眷顾你。你打开的每一个标准个人基础包都有很小的随机概率升级为追逐包 16。不花费游戏币就能最大化利用这种方法的最佳途径是囤积当前内容中的免费礼包。务必完成六月倒计时计划、六月焦点计划中的任务，并积极参与登月计划 II 活动。所有这些模式都会赠送大量免费基础礼包，让你获得大量免费彩票，用于兑换追逐礼包升级。 4. 直接从社区市场购买 如果你实在讨厌依赖卡包运气，只想现在就确保获得这张卡，那就直接前往社区市场的传奇与闪回卡牌专区吧。你可以用你积累的短截线直接从其他抽到Bryce Harper的玩家手中购买他。但你要做好支付高价的准备。根据市场波动和每日需求，他的价格一直徘徊在 364,000 至 404,000 Stubs 的范围内。虽然价格不菲，但如果你手头宽裕，它就能彻底消除猜测的成分。

S32 デザインスタジオライセンス問題 こんにちは、 最近ノートPCを交換し、新しいマシンにS32 Design Studioを再インストールしました。 しかし、ライセンスアクティベーションのエラーが発生しています。ライセンスが以前のノートPCに紐づいているため、ソフトウェアがアクティベートできません。 NXPライセンスマネージャーを通じて免許証を返却しようとしましたが、免許返却が不可能であるというメッセージが出ました。 古いマシンのライセンスを解除・解放して、新しいノートPCで有効化できるように手伝ってもらえますか?(私のライセンスキーは81B8-B707-440D-FE7Cです。 ご協力ありがとうございました。 Re: S32 Design Studio License Problem こんにちは、 利用可能なライセンス数が増加しました。

i.MX8MP memory layout for Cortex M7 with DRAM 1GB We have a project where we use i.MX8MP with 1 GB DRAM. We adjusted Linker files for Cortex M7, Devicetree for RPMSG shared memory and DRAM reserved memory for Cortex M7. Starting rpmsg ping pong from U-Boot works, e.g. we are able to boot into linux, load the kernel module and see correct output. The memory map looks correct also for the m_data2 section which is in the configured space inside the 1GB DRAM Starting the same firmware (elf) from linux using remoteproc works but the demo hangs when waiting for rpmsg nameservice announce. Is there someting we miss when porting? Thank you Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB Add run prepare_mcore before booting Linux In U-Boot, before run bootcmd / run bsp_bootcmd, add: run prepare_mcore If they want this automatic, include it in the board boot command before Linux is launched. Keep unused clocks enabled during debug For bring-up, also add: setenv mmcargs "${mmcargs} clk_ignore_unused" saveenv Some downstream BSPs use a more specific workaround such as clk-imx8mp.mcore_booted=1; Toradex notes that this prevents Linux from disabling the Cortex-M7 root clock on i.MX8MP. Confirm the runtime DTB is the RPMsg-enabled DTB For EVK, NXP support responses commonly point to using imx8mp-evk-rpmsg.dtb for M7 remoteproc/RPMsg. In i.MX8MP M7 remoteproc failure – “carveout doesn't fit da request” with valid NXP RPMsg firmware, the NXP support answer says to make sure imx8mp-evk-rpmsg.dtb is used in Linux. [community.nxp.com] For a custom 1 GB board, the filenames will differ, but the important point is that the runtime DTB must include the imx8mp-cm7 remoteproc node, MU mailboxes, and all RPMsg reserved-memory nodes. Verify reserved-memory and resource table alignment For i.MX8MP, the common RPMsg layout uses regions such as: dts isn’t fully supported. Syntax highlighting is based on Plain Text. vdev0vring0: vdev0vring0@55000000 { reg = <0 0x55000000 0 0x8000>; no-map; }; vdev0vring1: vdev0vring1@55008000 { reg = <0 0x55008000 0 0x8000>; no-map; }; vdevbuffer: vdevbuffer@55400000 { compatible = "shared-dma-pool"; reg = <0 0x55400000 0 0x100000>; no-map; }; rsc_table: rsc_table@550ff000 { reg = <0 0x550ff000 0 0x1000>; no-map; }; A public Linux Remoteproc on i.MX8MP discussion shows this style of DT setup, including rsc-da = <0x55000000>, mboxes = <μ 0 1 μ 1 1 μ 3 1>, and memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>, .... [community.nxp.com] For your 1 GB DRAM case, make sure none of these regions are inside Linux normal memory, CMA, GPU, OP-TEE, or another reserved range. Also verify that the M7 firmware’s rsc_table.c and linker file use the same vring/resource addresses as Linux DT. For the 1 GB DRAM port, check the ELF program headers Because Linux remoteproc loads the ELF by program headers, not just by “where U-Boot copied it,” verify: readelf -l your_m7_firmware.elf readelf -S your_m7_firmware.elf | grep -E "resource|data|bss|text" Check that every loadable segment maps to an address Linux remoteproc can translate for i.MX8MP, and that your m_data2 region is inside the actual 1 GB DRAM range and matches the reserved-memory carveout. Clear stale resource table area during debug If testing repeated boot modes, clear the RPMsg resource table area before booting M7. The i.MX Linux User’s Guide says that for i.MX8M Plus LPDDR4 EVK, the resource table area can be cleared with: mw 0x550ff000 0 4 This is specifically documented for avoiding garbage resource table values Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB As I wrote, the devicetree and linker file were adjusted. The remoteproc elf loader will load the file and start it. The ported hello world demo from MXUXSDK runs fine when started from Linux. The RPMSG demo is loaded and starts (we have valid output on M7 debug console) but rpmsg itself does not work. I suspect, there is anything incompatible with the MPU initialisation code for the M7.  There are addresses above 1 GB in DRAM space for the 8MP EVK? Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB do you have an y error log to share？ it seems the rpmsg may not link with DRAM setting directly Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB Discussing with the AE team. Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB The binary file and elf file are generated on the same time, by the same code and linker file, oright?  "I suspect, there is anything incompatible with the MPU initialisation code for the M7. There are addresses above 1 GB in DRAM space for the 8MP EVK?"  - If everything on uboot is OK but linux rproc is not, then it seems not the issue of MPU. I may first suspend the differences between uboot and linux rproc boot M. Please suggest customer check below two things: 1) imx_rproc.c imx_rproc_att_imx8mn has been modified according to your new DRAM size? 2) Make sure the section .resource_table is in a suitable position? Because Uboot load this table by copyResourceTable, but Linux parse the .resource_table section from .elf file. Which demo they are using? can they provide all the patch of the modification, towards Linux and M7 SDK? And what isCan they share their log shows "The RPMSG demo is loaded and starts (we have valid output on M7 debug console) but rpmsg itself does not work"?

How do I build imx-optee-os from source and integrate it into the uboot FIT image? I am using the i.MX8MP SoC. I have cloned the imx-optee-ossource code from https://github.com/nxp-imx/imx-optee-os.gitand checked out the lf-6.6.36_2.1.0branch. How do I build imx-optee-osand package it into the flash.bin  image? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: How do I build imx-optee-os from source and integrate it into the uboot FIT image? Hello, I don't know exactly which BSP version you are using, but please have a look to the i.MX Linux User's Guide, section 4.5.13 How to build imx-boot image by using imx-mkimage, and look for i.MX 8M EVK section (i.MX8M is the family) Linux documentation: https://www.nxp.com/design/design-center/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX i.MX Linux User's Guide: https://www.nxp.com/docs/en/user-guide/UG10163.pdf Best regards/Saludos, Aldo.

《大学橄榄球27》：官方封面运动员预测及发售日程安排 等待即将结束。EA Sports College Football 27 已确定将于 2026 年 7 月 9 日星期四在全球范围内正式发布。 今年是该系列游戏的一个重要里程碑。该系列游戏有史以来第一次打破了主机平台独占的局面，通过 Steam、Epic Games Store 和 EA App 登陆 PC 平台。PC玩家终于可以和PlayStation 5和Xbox Series X|S用户一起在虚拟橄榄球场上驰骋了。 EA 已正式确定封面明星，并制定了分阶段的抢先体验计划。如果您想计划您的开球仪式，这里有一份完整的名单，包括谁在场、何时可以开始比赛以及费用是多少。 官方封面运动员 EA Sports 没有只突出一名球员，而是采用了星光熠熠、多名运动员参与的方式，在不同版本中庆祝现代大学橄榄球的辉煌时代。 标准版封面 标准版封面展示了上赛季表现出色的三位进攻型球员： 但丁·摩尔——带领俄勒冈鸭队的明星四分卫。 马拉奇·托尼——迈阿密队极具爆发力的外接手。 Kewan Lacy——这位爆发力十足的奥莱米斯大学跑卫。 豪华版封面 豪华版扩充了球队阵容，除了标准版的三位球星外，还加入了多名防守悍将和一位冠军教练： 杰登·马亚瓦（南加州大学四分卫） 科林·西蒙斯（德克萨斯大学线卫） 伦纳德·摩尔（圣母大学角卫） 科特·西格内蒂（印第安纳大学全国冠军队主教练） 官方发布时间表 根据您的预购等级或订阅状态，您有三个不同的时间段可以进入游戏。分阶段版本的安排可以让最专用的粉丝提前整整一周开始游戏。 日期 访问窗口 需求/版本 2026年7月2日 7天抢先体验/10小时试用 EA Sports MVP+ 会员资格或标准 EA Play 试用 2026年7月6日 提前3天进入 豪华版、MVP 捆绑包或 EA Play Pro（PC） 2026年7月9日 全球正式发布 标准版（所有平台） 定价及版本细分 目前已在EA Sports官方商店开启预购。选择合适的版本取决于你想多早开始玩以及你是否也玩 Madden 游戏。 标准版（69.99美元）：7 月 9 日发售当天即可获得基础游戏，以及标准的预购奖励，例如 Ultimate Team封面运动员物品和基本的王朝教练点数。 豪华版（99.99美元）：提前 3 天（7 月 6 日）解锁游戏，并包含 4,600 大学橄榄球积分，助您快速组建终极球队阵容。 MVP 套餐（149.99 美元）：专为足球纯粹主义者构建的软件包版本。它将《大学橄榄球 27》豪华版与即将推出的《麦登橄榄球 27》豪华版捆绑在一起，让您可以提前体验这两款游戏并获得高级货币。

How to Unlock Cycle Milestone Series Bryce Harper in MLB The Show 26 If you have been grinding Diamond Dynasty lately, you already know that the community is buzzing about the new 98 OVR Cycle Milestone Series Bryce Harper. This card was dropped to commemorate his historic real-world performance where he hit for the cycle, and honestly, the attributes make it an absolute must-have for anyone looking to anchor their outfield or add some elite left-handed power to their lineup. The catch? He isn't tied to a straightforward program reward path. To get your hands on this Harper card, you need to acquire Chase Pack 16. Because it is a Chase Pack reward, unlocking him takes a bit of strategy, luck, or a healthy stack of Stubs. Depending on how much time or in-game currency you have, here are the four best ways to add him to your squad. 1. Grind the 4th Inning XP Reward Path Wheel If you are running a strict "No Money Spent" (NMS) squad, this is your best active grind method to pull the card entirely for free. Once you finish up the main rewards in the 4th Inning XP Program, the grind does not actually stop. Every chunk of extra XP you accumulate beyond the program's main cap grants you a spin on the repeatable Reward Path Wheel. Chase Pack 16 is sitting right in that wheel’s prize pool, meaning you can keep farming XP and taking shots at pulling the pack without spending a single stub. 2. Buy the The Show 50-Pack Bundle For players who prefer to skip the random wheel spins and have been saving up their hard-earned stubs, you can take a more direct route in the Pack Market. If you purchase the standard The Show 50-Pack Bundle, the game throws in a guaranteed Chase Pack 16 as a bonus. While buying bundles is always a bit of an investment, knowing you are 100% getting the specific Chase Pack containing Harper makes this a much safer bet than buying individual packs. 3. Test Your Luck with Standard The Show Packs You can also just play the game naturally and hope the RNG gods smile on you. Every single standard individual base pack you open carries a small, random percentage chance to upgrade into a Chase Pack 16. The best way to maximize this method without spending currency is to hoard free packs from current content. Make sure to knock out your tasks in the June Countdown Program, the June Spotlight Program, and jump into the Moonshot II Event. All of these modes hand out a ton of free base packs, giving you plenty of free lottery tickets for that Chase Pack upgrade. 4. Buy Directly from the Community Marketplace If you absolutely hate relying on pack luck and just want the card guaranteed right now, head straight over to the Legends & Flashbacks section of the Community Marketplace. You can use your banked Stubs to buy Bryce Harper directly from other players who managed to pull him. Just be prepared to pay a premium. Depending on market fluctuations and daily demand, his price has been hovering heavily around the 364,000 to 404,000 Stubs range. It is a hefty price tag, but it completely removes the guesswork if you have the stubs to spare.

host-to-switch trailer not removed on SJA1110 I am sending ethernet frames via the host processor (Cortex-M7) on a SJA1110. To route them to the specific ports on the switch I am using the host-to-switch header/trailer described in UM11107 under 5.8.2. The frames are received on the correct port however the trailer is not stripped or only partily stripped. For reference here is the same frame once before sending stored in the txBuffer and once after receiving in the rxBuffer of another device: 01 80 c2 00 00 10 68 58 c5 00 11 02 8b 8c 88 39 88 b7 5a 46 00 01 02 06 68 58 c5 00 11 02 04 01 00 06 01 02 12 01 01 14 0e 01 02 11 00 c5 58 68 08 d8 26 c0 cb fd 18 00 00 00 00 ---- 00 04 00 00 00 ====== 01 80 C2 00 00 10 68 58 C5 00 11 02 88 B7 5A 46 00 01 02 06 68 58 C5 00 11 02 04 01 00 06 01 02 12 01 01 14 0E 01 02 11 00 C5 58 68 08 D8 26 C0 CB FD 18 00 00 00 00 ---- 00 04 00 00 00 As you can see the header is removed completly but the trailer (everything after the 4 dashed lines) is not removed (or set to all 0s because atleast 64 bytes are required for the ethernet frame to be valid). Re: host-to-switch trailer not removed on SJA1110 Hello @flxwly , From the provided data, the host-to-switch header seems to be recognized by the switch, because the 4-byte header is removed from the outgoing frame. However, the trailer bytes still appear at the end of the received frame. One important point to check is the TRAILER_POS field in the host-to-switch header. The header bytes in your example are 8b 8c 88 39 Interpreting this according to the host-to-switch header format gives HEADER_TYPE = 0x8B8C, HOST_SWITCH = 1, TRAILER = 1, and TRAILER_POS = 57. However, in the transmitted frame shown in your dump, the 5-byte trailer appears to start at byte offset 59 from the MAC DA field, zero-based. Depending on the exact position counting convention relative to SFD, the expected value may differ by one, but the encoded value 57 does not seem to match the actual trailer position. Therefore, please first check how the TRAILER_POS field is calculated and try setting it to the position corresponding to the actual first byte of the trailer. There is also a second point: the provided test frame is very short. If the 5-byte trailer were stripped, the resulting Ethernet frame would become shorter than the minimum Ethernet frame size without FCS, so padding would need to be added again on egress. To avoid this ambiguity, could you please repeat the test with a longer payload, for example by adding 16 or 32 dummy bytes before the host trailer? This will make it clear whether the trailer is really stripped or not. Please also confirm that the egress port where the second device receives the frame is configured as a normal port. According to the UM, the header and trailer are stripped when the frame egresses a normal port, while the control information is preserved when the frame egresses the host port or a cascaded port. Finally, could you please share how the 5-byte trailer value `00 04 00 00 00` is generated? It would be useful to verify the bit packing of FRAMEID, PRIO, SWITCHID, and DESTPORTS against the format shown in the user manual. Best regards, Pavel Re: host-to-switch trailer not removed on SJA1110 Hello @PavelL, thank you for your reply. The trailer position is correct because I marked the "end" of my frame in the post wrong. It is actually 2 bytes earlier (at byte 57 as you correctly states). Therefore the trailer is also different and now makes sense and corresponds to the sceme in the UM. I can also confirm that on frames where the trailer only comes after atleast 64 bytes the trailer is removed correctly. So this is only a problem for frames shorter than 64 bytes before the trailer is added (which should not exist according to IEEE spec if i remember correct).  Best regards Nepomuk

[S32K388]SPD 1.0.6 パッケージに完全なテスト例が欠けている - レジスタレベルの参照Cのリクエスト NXPサポートチームの皆さん、こんにちは。   「S32K3 バージョン1.0.6のセーフティ・ペリフェラル・ドライバ」をダウンロードしました。   SPD_example_S32K388_M7_0_0プロジェクトをインストールしてS32 Design Studioにインポートしたところ、main.cはほぼ空であることに気づきました   **私の環境:** - S32 Design Studio for S32 プラットフォーム 3.5 - SPD バージョン:1.0.6(SW32K3_SPD_1.0.6_D2512_DesignStudio_updatesite_updated.zip) - ターゲット:S32K388 M7_0   **私が期待していたこと** 以下のレジスタレベルの完全な例をお送りください。 すべてのメモリ（フラッシュ、SRAM、TCM）にECCを適用- FCCU（故障収集・制御装置） - STCU2 (LBIST/MBIST を備えたセルフテスト コントロール ユニット 2) - EIM（エラー注入モジュール） - ERM（エラー報告モジュール） - CMU（クロックモニタユニット） - ロックステップコア- SWT(ソフトウェア監視)   [[email protected]]宛てに送信してください。 または、ダウンロードリンクを提供してください。 よろしくお願いします。   よろしくお願いいたします。 Re: [S32K388] SPD 1.0.6 Package Missing Complete Test Examples - Request for Register-Level Referenc こんにちは、 @xlele さん。 Copilotさんによると:SPDは完全なデモプロジェクトを提供していますが、EB Tresosのみで利用可能で、S32DS IDEsには対応していません。 デモはスタンドアロンの.exeファイルとして配布されています。バージョン。 こちらはS32DS IDEの非公式SPD例です。 https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K344-BIST-eMCEM-SPD106-v2-0-S32DS365-RTD700/ta-p/2373113 ベアメタルEIM、ERMの例を1つ挙げます。 https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K344-EIM-ERM-DTCM-SRAM-Baremetal-v3-0-S32DS36/ta-p/2193534 CMU_FCの例を1つ挙げます。 https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K344-MCAL-MCU-ClockMonitor-v1-0-S32DS36-RTD600/ta-p/2179976 SWTの例はRTDでデフォルトで見つけることができます。 よろしくお願いいたします。 ダニエル

College Football 27: Official Cover Athlete Prediction and Launch Schedule Breakdown The wait is almost over. EA Sports College Football 27 is locked in for an official worldwide launch on Thursday, July 9, 2026. This year is a massive milestone for the franchise. For the first time ever, the series is breaking out of its console-only cage and landing on PC via Steam, the Epic Games Store, and the EA App. PC players can finally join PlayStation 5 and Xbox Series X|S users on the virtual gridiron. EA has officially finalized its cover stars and laid out a staggered early access schedule. If you want to plan your kickoff, here is a complete breakdown of who is on the box, when you can start playing, and what it will cost. Official Cover Athletes Instead of highlighting just one player, EA Sports went with a star-studded, multi-athlete approach to celebrate the modern era of college football across different editions. Standard Edition Cover The standard cover features a powerhouse trio of dominant offensive playmakers who lit up the previous season: Dante Moore – The star quarterback leading the Oregon Ducks. Malachi Toney – Miami’s electrifying wide receiver. Kewan Lacy – The explosive Ole Miss running back. Deluxe Edition Cover The Deluxe Edition expands the squad, grouping the three Standard Edition stars alongside major defensive standouts and a championship coach: Jayden Maiava (USC Quarterback) Colin Simmons (Texas Linebacker) Leonard Moore (Notre Dame Cornerback) Curt Cignetti (Indiana’s national championship-winning head coach) Official Launch Schedule Depending on your pre-order tier or subscription status, there are three distinct windows to jump into the game. The staggered release schedule lets the most dedicated fans get a full week of head-start playtime. Release Date Access Window Requirement / Edition July 2, 2026 7-Day Early Access / 10-Hour Trial EA Sports MVP+ Membership or standard EA Play Trial July 6, 2026 3-Day Early Access Deluxe Edition, MVP Bundle, or EA Play Pro (PC) July 9, 2026 Official Worldwide Launch Standard Edition (All Platforms) Pricing & Edition Breakdown Pre-orders are already live on the official EA Sports storefront. Choosing the right version comes down to how early you want to play and whether you also play Madden. Standard Edition ($69.99): Gives you the base game on the July 9 launch date, plus standard pre-order incentives like Ultimate Team cover athlete items and basic Dynasty coach points. Deluxe Edition ($99.99): Unlocks the game 3 days early on July 6 and includes 4,600 College Football Points to kickstart your Ultimate Team roster. MVP Bundle ($149.99): A massive package built for football purists. It bundles the Deluxe Edition of College Football 27 with the Deluxe Edition of the upcoming Madden NFL 27, giving you early access and premium currency for both titles.

如何从源代码构建 imx-optee-os 并将其集成到 uboot FIT 镜像中？ 我使用的是 i.MX8MP SoC。我从https://github.com/nxp-imx/imx-optee-os.git克隆了 imx-optee-os 源代码，并检出了 lf-6.6.36_2.1.0branch。如何版本 imx-optee-os 并将其软件包到 flash.bin 中图像？ i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: How do I build imx-optee-os from source and integrate it into the uboot FIT image? 你好， 我不太清楚您具体使用的是哪个 BSP 版本，但请参阅 i.MX Linux 用户指南的 4.5.13 节。如何使用 imx-mkimage 构建 imx-boot 镜像，并查找 i.MX 8M EVK 部分（i.MX8M 是系列名称） Linux 文档： https://www.nxp.com/design/design-center/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX i.MX Linux 用户指南： https://www.nxp.com/docs/en/user-guide/UG10163.pdf 此致敬礼/Saludos， 阿尔多。

Question Regarding Critical Section Protection for OTP and NVM Access Services Hi, We previously encountered an issue caused by a background process when modifying the OTP (Secure Debug Password) and Life Cycle (LC) in HSE_B. As a result, we were advised to protect the OTP and LC update operations by using a critical section. In addition, would it also be necessary to protect service requests that access the NVM area, rather than the OTP, such as ImportKey, FormatKeyCatalogs, SmrEntryInstall, and CrEntryInstall, by using a critical section? Re: Question Regarding Critical Section Protection for OTP and NVM Access Services Hi @lukaszadrapa, thank you for your reply. In that case, instead of entering a critical section, would it be sufficient to check the HSE_CONFIG_GPR3 register before accessing the flash to ensure that flash access is available? Re: Question Regarding Critical Section Protection for OTP and NVM Access Services Hi @wodudwo  To have full picture, I recommend to read description in HSE Firmware reference manual rev. 2.7 in section: “14.6.5  Synchronizing flash read/write access between HSE and application core”: https://www.nxp.com/webapp/sd/collateral/1765990353647716033651?version=2.7 There are tables 149, 150 and 151 where you can find details about typical scenarios. In short: if HSE firmware is executing, it’s not possible to program a flash block from which the firmware is running from. In case of S32K344 and FULL_MEM version (just an example) it’s block 3, in case of AB_SWAP it’s block 1. It’s necessary to wait until HSE is in idle state and then do not trigger other HSE services. If HSE is performing flash operation on SYS-IMG (like key catalog formatting, importing a key, writing NVM attribute…) then, in addition, it is not possible to access data flash memory. If HSE is writing OTP data (attribute, life cycle advancing, programming password etc.) it is not possible to access UTEST and also flash block 0 because UTEST and flash block 0 are in the same read partition. And this seems to be the key point if you have a problem with ADKP programming and with life cycle advancing. Please take a look at this post where I described what needs to be relocated from flash block 0: https://community.nxp.com/t5/S32K/S32K324-HSE-Setting-ADKP-Issue/m-p/2369325/highlight/true#M58774 And when talking about synchronization between flash and HSE, notice that the support for synchronization between FLS and CRYPTO modules in RTD was added in version 5.0.0 and higher. Here is a screenshot from 6.0.0: If you use older RTD version, it needs to be handled by users. Notice that this synchronization does not solve the problem with programming OTP attributes to UTEST. The code still needs to be relocated from flash block 0. Regards, Lukas Re: Question Regarding Critical Section Protection for OTP and NVM Access Services It depends on scenario. “In addition, would it also be necessary to protect service requests that access the NVM area, rather than the OTP, such as ImportKey, FormatKeyCatalogs, SmrEntryInstall, and CrEntryInstall, by using a critical section?” For this scenario – no. HSE_CONFIG_GPR3 informs users if read/execute or program/erase is blocked for application by HSE on some flash block. But this is not a protection similar to critical section in your code. Critical section will ensure that there will be no interrupt which could access data flash or which could somehow interfere with the operations. But this has nothing to do with status of HSE_CONFIG_GPR3. Anyway, mentioned services like ImportKey, FormatKeyCatalogs, SmrEntryInstall, and CrEntryInstall are crucial configuration services which should be executed sequentially in controlled environment. It makes sense to use critical section. If it is necessary to handle some important interrupts in the meantime, it’s necessary to ensure that used interrupt resources does not interfere with HSE and flash blocks used by HSE. Re: Question Regarding Critical Section Protection for OTP and NVM Access Services Hi, @lukaszadrapa  Thank you for your explanation. If I understand correctly, checking the HSE_CONFIG_GPR3 register alone is not sufficient, and protection using a critical section is still required. My understanding is that even if an interrupt occurs, checking the HSE_CONFIG_GPR3 register before accessing the flash should prevent the application core and the HSE core from accessing the same flash block simultaneously. If a critical section is not used, are there any other potential issues that could occur besides simultaneous flash access between the application core and the HSE core? Re: Question Regarding Critical Section Protection for OTP and NVM Access Services Conversely, is it also an issue if the application core performs a program/erase operation while HSE is already performing a program/erase operation? - Yes, it is an issue because no more flash operations can run at the same time.   If so, can this situation be prevented by checking not only bits 21:16 but also bits 29:24 of the HSE_CONFIG_GPR3 register before the application core starts the program/erase operation? - Yes. This would help in situation when HSE is already programming the flash and application core want to also start another flash operation.   If this approach is not sufficient to prevent such conflicts, would using a critical section be the recommended solution for protecting these service requests? - When HSE performs mentioned NVM operations (catalog format, key import…), application should not start other flash operations and should not access flash block which is being programmed by HSE. If anything like that is done by the interrupt handlers, yes, critical section would prevent this conflict.   Additionally, the tables do not explicitly describe the case where the application core is executing code from a code flash block while HSE is performing a program/erase operation on the same code flash block. Is this scenario considered safe without any synchronization, or does it also require some form of protection? - Code flash memory is being programmed by HSE only when HSE/SBAF installs/updates/recovers/erases HSE firmware. This is done either out of reset automatically or it is triggered by software. HSE firmware is located it the end of code flash (in FULL_MEM version) or at the end of active and passive block (AB_SWAP version). It is expected that the application starts from lower flash blocks and it also waits until initialization is done and until HSE finishes the initialization (and possible flash operations). So, there’s no risk in this case. If application triggers an update of HSE firmware, it’s up to user to ensure that corresponding flash block is not access during this operation. If protection is required for this scenario, what would be the recommended way to implement it? - As described above – after reset, do not access flash block which contains HSE firmware until initialization is completed. And do not access the flash block when your software initiates HSE firmware update.   Re: Question Regarding Critical Section Protection for OTP and NVM Access Services hi, @lukaszadrapa  Thank you for your explanation. Your answers have been very helpful.  Re: Question Regarding Critical Section Protection for OTP and NVM Access Services Hi, @lukaszadrapa  Thank you for your reply. According to Tables 149, 150, and 151 in the HSE Firmware Reference Manual, which describe synchronization requirements for concurrent flash program/erase operations, the following is stated: No synchronization steps to be followed. It is expected that the M7_0/1 core does not issue any command to HSE which involves program/erase operation when it is programming data flash. Conversely, is it also an issue if the application core performs a program/erase operation while HSE is already performing a program/erase operation? If so, can this situation be prevented by checking not only bits 21:16 but also bits 29:24 of the HSE_CONFIG_GPR3 register before the application core starts the program/erase operation? If this approach is not sufficient to prevent such conflicts, would using a critical section be the recommended solution for protecting these service requests? Additionally, the tables do not explicitly describe the case where the application core is executing code from a code flash block while HSE is performing a program/erase operation on the same code flash block. Is this scenario considered safe without any synchronization, or does it also require some form of protection? If protection is required for this scenario, what would be the recommended way to implement it? Re: Question Regarding Critical Section Protection for OTP and NVM Access Services We are getting back to tables 149, 150 and 151 from HSE firmware reference manual which I mentioned earlier. It's necessary to evaluate the program flow, compare it with scenarios described in the tables and decide if countermeasures are needed or not. Otherwise there could be a risk that HSE will disrupt application core(s) or vice versa.  Regards, Lukas

关于 OTP 和 NVM 访问服务的关键部分保护的问题 您好，我们之前在修改 HSE_B 中的 OTP（安全调试密码）和生命周期 (LC) 时，遇到了由后台进程引起的问题。 因此，我们被建议使用临界区来保护 OTP 和 LC 更新操作。 此外，是否也需要使用临界区来保护访问 NVM 区域（而不是 OTP）的服务请求，例如ImportKey 、 FormatKeyCatalogs 、 SmrEntryInstall和CrEntryInstall ？ Re: Question Regarding Critical Section Protection for OTP and NVM Access Services 嗨@lukaszadrapa ， 感谢您的回复。 在这种情况下，与其进入临界区，不如在访问闪存之前检查 HSE_CONFIG_GPR3 寄存器以确保闪存访问可用，这样是否就足够了？ Re: Question Regarding Critical Section Protection for OTP and NVM Access Services 嗨@wodudwo 为了获得完整的信息，我建议阅读 HSE 固件参考手册 rev. 中的描述。2.7 节： “14.6.5同步 HSE 和应用核心之间的闪存读/写访问： https://www.nxp.com/webapp/sd/collateral/1765990353647716033651?version=2.7 表 149、150 和 151 中提供了典型场景的详细信息。 简而言之：如果 HSE 固件正在执行，则无法对正在运行该固件的闪存块进行编程。以 S32K344 和 FULL_MEM 版本为例（仅举例），它是第 3 个块；以 AB_SWAP 为例，它是第 1 个块。必须等到 HSE 处于 IDLE状态后，才不要触发其他 HSE 服务。 如果 HSE 正在对 SYS-IMG 执行闪存操作（例如密钥目录格式化、导入密钥、写入 NVM 属性等），则此外，也无法访问数据闪存。 如果 HSE 正在写入 OTP 数据（属性、生命周期推进、编程密码等），则无法访问 UTEST 和闪存块 0，因为 UTEST 和闪存块 0 位于同一个读取分区中。如果你在使用 ADKP 编程和生命周期推进方面遇到问题，这似乎就是关键所在。请查看这篇帖子，其中我描述了需要从闪存块 0 迁移的内容： https://community.nxp.com/t5/S32K/S32K324-HSE-Setting-ADKP-Issue/mp/2369325/highlight/true#M58774 谈到闪存和 HSE 之间的同步时，请注意 RTD 中 FLS 和 CRYPTO 模块之间的同步支持是在 5.0.0 及更高版本中添加的。 以下是 6.0.0 版本的屏幕截图： 如果使用较旧的RTD版本，则需要用户自行处理。请注意，这种同步并不能解决将 OTP 属性编程到 UTEST 的问题。代码仍需从闪存块 0 迁移出来。 此致， Lukas Re: Question Regarding Critical Section Protection for OTP and NVM Access Services 这要视具体情况而定。 “此外，是否也需要使用临界区来保护访问 NVM 区域（而不是 OTP）的服务请求，例如ImportKey 、 FormatKeyCatalogs 、 SmrEntryInstall和CrEntryInstall ？” 就这种情况而言——不。HSE_CONFIG_GPR3 通知用户，如果 HSE 阻止了对某些闪存块的读取/执行或编程/擦除操作。但这并不类似于代码中的临界区保护机制。临界区将确保不会发生任何可能访问数据闪存或以任何方式干扰操作的中断。但这与 HSE_CONFIG_GPR3 的状态无关。 总之，提到的 ImportKey、FormatKeyCatalogs、SmrEntryInstall 和 CrEntryInstall 等服务都是至关重要的配置服务，应该在受控环境中按顺序执行。使用临界区是合理的。如果在此期间需要处理一些重要的中断，则必须确保所使用的中断资源不会干扰 HSE 和 HSE 使用的闪存块。 Re: Question Regarding Critical Section Protection for OTP and NVM Access Services 你好， @lukaszadrapa 谢谢你的解释。 如果我理解正确的话，仅仅检查 HSE_CONFIG_GPR3 寄存器是不够的，仍然需要使用临界区进行保护。 我的理解是，即使发生中断，在访问闪存之前检查 HSE_CONFIG_GPR3 寄存器也应该能够防止应用程序内核和 HSE 内核同时访问同一个闪存块。 如果不使用临界区，除了应用程序核心和 HSE 核心之间同时访问闪存之外，还会出现其他潜在问题吗？ Re: Question Regarding Critical Section Protection for OTP and NVM Access Services 反过来，如果应用程序核心在 HSE 已经执行编程/擦除操作的同时执行编程/擦除操作，这是否也是一个问题？ - 是的，这是一个问题，因为不能同时运行更多闪存操作。 如果是这样，是否可以通过在应用程序内核开始编程/擦除操作之前，不仅检查 HSE_CONFIG_GPR3 寄存器的第 21:16 位，而且检查第 29:24 位来防止这种情况发生？ - 是的。这有助于解决 HSE 已经对闪存进行编程，而应用程序核心也想启动另一个闪存操作的情况。 如果这种方法不足以防止此类冲突，那么使用临界区是否是保护这些服务请求的推荐解决方案？ - 当 HSE 执行上述 NVM 操作（目录格式、密钥导入等）时，应用程序不应启动其他闪存操作，也不应访问 HSE 正在编程的闪存块。如果中断处理程序执行了类似的操作，那么临界区可以防止这种冲突。 此外，表格没有明确描述应用程序核心正在执行代码闪存块中的代码，而 HSE 正在对同一个代码闪存块执行编程/擦除操作的情况。 在没有任何同步的情况下，这种方案是否安全？还是也需要某种形式的保护？ - 代码闪存仅在 HSE/SBAF 安装/更新/恢复/擦除 HSE 固件时由 HSE 进行编程。这是通过自动复位实现的，也是由软件触发的。 HSE 固件位于代码闪存的末尾（在 FULL_MEM 版本中）或主动和被动块的末尾（AB_SWAP 版本中）。预计应用程序将从较低的闪存块开始，并且会等待初始化完成，以及 HSE 完成初始化（以及可能的闪存操作）。所以，这种情况没有风险。如果应用程序触发 HSE 固件更新，则用户有责任确保在此操作期间不会访问相应的闪存块。 如果需要针对这种情况采取保护措施，建议采用哪种实施方法？ - 如上所述 - RESET后，在初始化完成之前，请勿访问包含 HSE 固件的闪存块。当您的软件启动 HSE 固件更新时，请勿访问闪存块。 Re: Question Regarding Critical Section Protection for OTP and NVM Access Services 我们现在要回到我之前提到的 HSE 固件参考手册中的表 149、150 和 151。有必要评估程序流程，将其与表格中描述的情况进行比较，并决定是否需要采取应对措施。否则，HSE可能会干扰应用程序核心，反之亦然。 此致， Lukas Re: Question Regarding Critical Section Protection for OTP and NVM Access Services 你好， @lukaszadrapa 感谢您的回复。 根据 HSE 固件参考手册中的表 149、150 和 151（其中描述了并发闪存编程/擦除操作的同步要求），规定如下： 无需遵循任何同步步骤。预计 M7_0/1 内核在对数据闪存进行编程时，不会向 HSE 发出任何涉及编程/擦除操作的命令。 反过来，如果应用程序核心在 HSE 已经执行编程/擦除操作的同时执行编程/擦除操作，这是否也是一个问题？ 如果是这样，是否可以通过在应用程序内核开始编程/擦除操作之前，不仅检查 HSE_CONFIG_GPR3 寄存器的第 21:16 位，而且检查第 29:24 位来防止这种情况发生？ 如果这种方法不足以防止此类冲突，那么使用临界区是否是保护这些服务请求的推荐解决方案？ 此外，表格没有明确描述应用程序核心正在执行代码闪存块中的代码，而 HSE 正在对同一个代码闪存块执行编程/擦除操作的情况。 在没有任何同步的情况下，这种方案是否安全？还是也需要某种形式的保护？ 如果需要针对这种情况采取保护措施，建议采用哪种实施方法？ Re: Question Regarding Critical Section Protection for OTP and NVM Access Services 嗨， @lukaszadrapa 谢谢你的解释。您的回答非常有帮助。

imx-optee-osをソースコードからビルドして、それをuboot FITイメージに統合するにはどうすればよいですか？ 私はi.MX8MP SoCを使用しています。私はhttps://github.com/nxp-imx/imx-optee-os.gitから imx-optee-os のソースコードをクローンし、lf-6.6.36_2.1.0 ブランチをチェックアウトしました。imx-optee-oをどのように構築して、それをflash.binにパッケージ化すればいいのでしょうか画像？ i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: How do I build imx-optee-os from source and integrate it into the uboot FIT image? こんにちは、 どのBSPバージョンを使っているのか正確にはわかりませんが、i.MX Linuxユーザーガイドのセクション4.5.13をぜひご覧くださいimx-mkimageを使ってimx-bootイメージを構築する方法と、i.MX 8M EVKセクション(i.MX8Mがファミリ)を探す Linuxのドキュメント: https://www.nxp.com/design/design-center/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX i.MX Linuxユーザーガイド: https://www.nxp.com/docs/en/user-guide/UG10163.pdf よろしくお願いいたします。 アルド。

OTPおよびNVMアクセスサービスのクリティカルセクション保護に関する質問 こんにちは。以前、HSE_B で OTP (セキュアデバッグパスワード) とライフサイクル (LC) を変更する際に、バックグラウンドプロセスが原因で問題が発生しました。 その結果、OTPおよびLCの更新処理を保護するためにクリティカルセクションを使用するよう助言を受けました。 さらに、 ImportKey、 FormatKeyCatalogs、 SmrEntryInstall、 CrEntryInstallなど、OTPではなくNVM領域にアクセスするサービスリクエストも、クリティカルセクションを使って保護する必要があるのでしょうか? Re: Question Regarding Critical Section Protection for OTP and NVM Access Services こんにちは、 @lukaszadrapa さん。 ご返信よろしくお願いします。 CASE、クリティカルセクションに入る代わりに、フラッシュにアクセスする前にHSE_CONFIG_GPR3レジスタを確認してフラッシュアクセス可能かどうかを確認するだけで十分でしょうか? Re: Question Regarding Critical Section Protection for OTP and NVM Access Services こんにちは、 @wodudwo さん。 全体像を把握するには、HSEファームウェアのリファレンスマニュアルの説明を読むことをお勧めします。2.7節： 「14.6.5HSEとアプリケーションコア間のフラッシュ読み書きアクセスの同期」: https://www.nxp.com/webapp/sd/collateral/1765990353647716033651?version=2.7 表149、150、151には典型的なシナリオの詳細が記載されています。 要するに、HSEファームウェアが実行されている場合、そのファームウェアが実行されているフラッシュブロックをプログラムすることはできません。S32K344 CASE や FULL_MEM CASE (あくまで例ですが) ではブロック3、AB_SWAP CASE ではブロック1です。HSEがアイドル状態になるまで待ち、その後他のHSEサービスを起動しないことが大切です。 HSEがSYS-IMGに対してフラッシュ操作(キーカタログのフォーマット、キーのインポート、NVM属性の書き込みなど)を行っている場合、さらにデータフラッシュメモリへのアクセスは不可能です。 HSEがOTPデータ(属性、ライフサイクル進行、パスワードのプログラミングなど)を書き込んでいる場合、UTESTとフラッシュブロック0の両方にアクセスすることはできません。なぜなら、UTESTとフラッシュブロック0が同じ読み取りパーティション内にあるからです。そして、ADKPプログラミングやライフサイクル進行に問題がある場合、これが重要なポイントとなるようです。フラッシュブロック0から移動する必要があるものについて説明したこちらの投稿をご覧ください。 https://community.nxp.com/t5/S32K/S32K324-HSE-Setting-ADKP-Issue/mp/2369325/highlight/true#M58774 また、フラッシュとHSEの同期について話す際、RTDのFLSとCRYPTOモジュール間の同期サポートがバージョン5.0.0以降に追加されたことに注目してください。 以下はバージョン6.0.0のスクリーンショットです。 古いRTDバージョンを使う場合は、ユーザーが対応する必要があります。この同期では、OTP属性をUTESTにプログラミングする際の問題は解決されないことに注意してください。コードはフラッシュブロック0から移動させる必要がある。 よろしくお願いいたします。 ルーカス Re: Question Regarding Critical Section Protection for OTP and NVM Access Services こんにちは、 @lukaszadrapa ご説明ありがとうございました。 私の理解が正しければ、HSE_CONFIG_GPR3レジスタのチェックだけでは不十分であり、クリティカルセクションを用いた保護が依然として必要となる。 私の理解では、割り込みが発生しても、フラッシュにアクセスする前にHSE_CONFIG_GPR3レジスタを確認することで、アプリケーションコアとHSEコアが同時に同じフラッシュブロックにアクセスするのを防ぐはずです。 クリティカルセクションが使われない場合、アプリケーションコアとHSEコア間の同時フラッシュアクセス以外に起こりうる問題はありますか? Re: Question Regarding Critical Section Protection for OTP and NVM Access Services 状況によります。 「さらに、 ImportKey、 FormatKeyCatalogs、 SmrEntryInstall、 CrEntryInstallなど、OTPではなくNVM領域にアクセスするサービスリクエストも、クリティカルセクションを使って保護する必要があるのでしょうか?」 このシナリオでは、答えはノーです。HSE_CONFIG_GPR3、HSEがフラッシュブロックで読み書き/実行やプログラム/消去をブロックした場合にユーザーに通知します。しかし、これはあなたのコードにおけるクリティカルセクションのような保護機能ではありません。クリティカルセクションは、データフラッシュにアクセスする割り込みや、操作に干渉する割り込みが起きないことを保証します。しかし、これはHSE_CONFIG_GPR3の状態とは何の関係もありません。 いずれにせよ、ImportKey、FormatKeyCatalogs、SmrEntryInstall、CrEntryInstallといったサービスは、管理された環境下で順番に実行する必要のある重要な構成サービスです。クリティカルセクションを使用するのは理にかなっている。その間に重要な割り込みを処理する必要がある場合には、使用される割り込みリソースがHSEおよびHSEで使用されるフラッシュブロックに干渉しないようにする必要があります。 Re: Question Regarding Critical Section Protection for OTP and NVM Access Services 先ほど述べたHSEファームウェアリファレンスマニュアルの表149、150、151に戻ります。プログラムの流れを評価し、表に記載されているシナリオと比較し、対策が必要かどうかを判断する必要があります。そうでなければ、HSEがアプリケーションコアを妨害したり、その逆を妨げるリスクがあります。 よろしくお願いいたします。 ルーカス Re: Question Regarding Critical Section Protection for OTP and NVM Access Services こんにちは、 @lukaszadrapa ご説明ありがとうございました。あなたの回答は大変参考になりました。 Re: Question Regarding Critical Section Protection for OTP and NVM Access Services こんにちは、 @lukaszadrapa ご返信よろしくお願いします。 HSEファームウェアリファレンスマニュアルの表149、150、151によると、同時フラッシュプログラム/消去操作の同期要件を説明しています。 同期手順は不要です。M7_0/1コアは、データフラッシュをプログラムしている際にHSEに対してプログラム/消去操作に関するコマンドを出さないことが期待されています。 逆に、アプリケーションコアがプログラム/消去操作を行っている間にHSEがすでにプログラム/消去操作を行っている場合も問題になるのでしょうか? もしそうなら、アプリケーションコアがプログラム/消去操作を開始する前に、HSE_CONFIG_GPR3レジスタの21:16だけでなく29:24ビットもチェックすることでこの状況を防げますか? この方法ではこのような競合を防ぐのに十分でない場合、これらのサービス要求を保護するための推奨される解決策はクリティカルセクションを使用することでしょうか？ さらに、表はアプリケーションコアがコードフラッシュブロックからコードを実行している間に、HSEが同じコードフラッシュブロックに対してプログラム/消去操作を行う場合を明示的に説明していません。 このシナリオは、同期処理なしでも安全だと考えられるのでしょうか、それとも何らかの保護対策が必要でしょうか？ このシナリオにおいて保護が必要な場合、推奨される実装方法はどのようなものでしょうか？ Re: Question Regarding Critical Section Protection for OTP and NVM Access Services 逆に、アプリケーションコアがプログラム/消去操作を行っている間にHSEがすでにプログラム/消去操作を行っている場合も問題になるのでしょうか? - はい、問題はあります。なぜなら、フラッシュ操作を同時に実行できなくなるからです。 もしそうなら、アプリケーションコアがプログラム/消去操作を開始する前に、HSE_CONFIG_GPR3レジスタの21:16だけでなく29:24ビットもチェックすることでこの状況を防げますか? - はい。これは、HSEがすでにフラッシュをプログラムしていて、アプリケーションコアが別のフラッシュ操作を始めたい場合に役立ちます。 この方法ではこのような競合を防ぐのに十分でない場合、これらのサービス要求を保護するための推奨される解決策はクリティカルセクションを使用することでしょうか？ - HSEが前述のNVM操作(カタログ形式、キーインポートなど)を行う際、アプリケーションは他のフラッシュ操作を開始しず、HSEがプログラムしているフラッシュブロックにもアクセスしてはいけません。割り込みハンドラによってそのような処理が行われる場合、クリティカルセクションによってこの競合は防止されます。 さらに、表はアプリケーションコアがコードフラッシュブロックからコードを実行している間に、HSEが同じコードフラッシュブロックに対してプログラム/消去操作を行う場合を明示的に説明していません。 このシナリオは、同期処理なしでも安全だと考えられるのでしょうか、それとも何らかの保護対策が必要でしょうか？ - コードフラッシュメモリは、HSE/SBAFがHSEファームウェアをインストール/更新/復旧/消去する場合にのみ、HSEによってプログラムされます。これはリセット後に自動的に行われるか、ソフトウェアによってトリガーされます。 HSEファームウェアは、コードフラッシュの末尾（FULL_MEMバージョン）またはアクティブブロックとパッシブブロックの末尾（AB_SWAPバージョン）に配置されます。アプリケーションは下位のフラッシュブロックから開始することが期待されており、初期化が完了し、HSEが初期化(および可能なフラッシュ操作)を完了するまで待ちます。ですので、このケースにはリスクはありません。アプリケーションがHSEファームウェアの更新をトリガーした場合、対応するフラッシュブロックがこの操作中にアクセスされないようにするのはユーザーが確認します。 このシナリオにおいて保護が必要な場合、推奨される実装方法はどのようなものでしょうか？ - 前述の通り – リセット後は、初期化が完了するまでHSEファームウェアを含むフラッシュブロックにアクセスしないでください。また、ソフトウェアがHSEファームウェアアップデートを開始する際にフラッシュブロックにアクセスしないでください。

カレッジフットボール27：公式カバーアスリート予想と発売スケジュール詳細 待ち時間はもうすぐ終わる。EA Sports College Football 27は、2026年7月9日（木）に全世界で正式に発売されることが決定しました。 今年はフランチャイズにとって大きな節目となる年だ。シリーズ史上初めて、コンソール専用という枠を超え、Steam、Epic Games Store、EAアプリを通じてPCにも登場する。PCプレイヤーはついにPlayStation 5やXbox Series X|Sユーザーとバーチャルグリッドアイアンに参加できるようになりました。 EAは正式に表紙スターを確定し、段階的な早期アクセススケジュールを発表しました。キックオフの計画を立てたい場合は、ボックスに誰がいるか、いつプレー開始できるか、そして費用がいくらかを詳細にまとめておきます。 公式カバーアスリート EA Sportsは、特定の選手だけをフィーチャーするのではなく、様々なエディションを通して、スター選手が多数登場する複数のアスリートをフィーチャーすることで、現代のカレッジフットボールを称えるというアプローチを採用した。 通常版カバー 通常版の表紙には、前シーズンに大活躍した、圧倒的な攻撃力を誇る3人のプレイメーカーがフィーチャーされている。 ダンテ・ムーア – オレゴン・ダックスを率いるスタークォーターバック。 マラキ・トニー – マイアミの電撃的なワイドレシーバー。 ケワン・レイシー – オレミス大学の爆発的なランニングバック。 デラックスエディションカバー デラックスエディションでは、スタンダードエディションのスター選手3名に加え、守備陣の主力選手や優勝経験のあるコーチが加わり、チーム構成がさらに充実します。 ジェイデン・マイアバ（南カリフォルニア大学クォーターバック） コリン・シモンズ（テキサス大学ラインバッカー） レナード・ムーア（ノートルダム大学コーナーバック） カート・シグネッティ（インディアナ大学の全米選手権優勝監督） 公式発売スケジュール 予約購入のティアやサブスクリプション状況に応じて、ゲームを開始できる期間は3つに分かれています。段階的な発売スケジュールにより、最も熱心なファンは1週間先行してプレイできる。 リリース日 アクセスウィンドウ 要件／エディション 2026年7月2日 7日間の早期アクセス/10時間トライアル EA Sports MVP+メンバーシップまたは標準のEA Playトライアル 2026年7月6日 3日間の早期アクセス デラックスエディション、MVPバンドル、またはEA Play Pro（PC版） 2026年7月9日 世界同時発売開始 スタンダードエディション(全プラットフォーム) 価格とエディションの内訳 EA Sportsの公式ストアでは、既に予約注文が開始されています。適切なバージョンを選ぶには、いつからプレイしたいか、そしてMaddenもプレイするかどうかが重要になります。 スタンダード版（69.99ドル）：7月9日の発売日に基本ゲームを入手できるほか、Ultimate Teamのカバーアスリートアイテムや基本的なDynastyコーチポイントといった、通常の予約特典も付いてきます。 デラックス版（99.99ドル）：7月6日にゲームを3日早くアンロックでき、Ultimate Teamのロスター作成に役立つ4,600カレッジフットボールポイントが含まれています。 MVPバンドル（149.99ドル）：サッカーの純粋主義者のために作られた巨大なパッケージです。このゲームは、College Football 27のデラックスエディションと、今後発売予定のMadden NFL 27のデラックスエディションをバンドルしており、両タイトルの早期アクセスとプレミアム通貨が提供されます。

Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. 1 Every great build starts with "Hello World" Every engineer remembers their first “Hello World” — that small, satisfying moment when an idea typed on a screen suddenly comes to life on a real machine. This series is a take on that same feeling, only this time the “machine” is a car. It’s a demonstrator that looks and behaves like a real vehicle, showcasing the combined use of tools from both the NXP and MathWorks ecosystems. This demo has been showcased at several events, including most recently at the MathWorks booth during Embedded World 2026 and MathWorks Automotive Conference, where the demo video that accompanies this series was filmed. Think of these articles as a guided tour through how the whole thing comes together, piece by piece. ▶ Watch the demo in action — presented at the MathWorks booth, Embedded World 2026 2 Table of Contents • Every great build starts with Hello World • From a model on a laptop to silicon on the bench • From the steering wheel to every node • And it grew up along the way • Built to be rebuilt — and learned from • A demonstrator, not a blueprint • The article series — one domain at a time 3 From a model on a laptop to silicon on the bench How does a car end up running on NXP silicon, starting from a model on a laptop? That’s where the NXP Model-Based Design Toolbox (MBDT) comes in. It acts as the bridge between the MathWorks ecosystem — Simulink and MATLAB — and NXP’s processors and embedded tools. An application is designed and modeled in Simulink, MBDT generates optimized code for the chosen NXP target, and that code is deployed straight onto the hardware. The main advantage of this approach is what it allows before any board is involved: an application can be validated and tuned in simulation first, and hardware that isn’t physically present can simply be simulated in its place. The results: early issue detection, shorter development cycles, and a faster time to market — backed by a toolchain that has been validated end to end. Figure 1. NXP Model-Based Design Toolbox One Pager 4 From the steering wheel to every node At the heart of the demo is a driver-in-the-loop setup: a physical steering wheel and a set of foot pedals feed signals directly into the simulation, where a virtual car is driven in simulation, into an environment developed through a RoadRunner simulated environment. From there, a clear hierarchy carries every input down to the hardware. The main node — an S32N processor — sits at the center: it communicates with the host PC running the simulation and makes the vehicle-level decisions. It then hands those decisions to a zonal node that acts as a gateway, fanning the signals out to the end nodes that handle each function — the front and rear lights, the front and rear parking sensors, the radar, and the steering rack, and, on the traction side, the battery management system and motor control. The effect is immediate and physical: steering and acceleration in the virtual world set the model on the table moving; shifting into reverse spins the motors up in the right direction; and when an obstacle appears behind the physical car, it stops on its own, with the rear lights turning red across every node — just like a production vehicle. Throughout, a live dashboard built with NXP’s FreeMASTER Lite shows the vehicle state as it happens, from the reverse camera to the parking sensors, blending signals from the virtual world with readings from the physical hardware. Figure 2. Demo architecture — main node (S32N), zonal gateway, and end nodes. 5 And it grew up along the way Behind all of these are the core functions of a real car — lighting, parking sensors, steering rack, motor control, and battery management — spread across roughly ten microcontrollers and processors and sixteen NXP evaluation boards and reference designs. There’s no need to unpack every component here, because each one earns its own dedicated article series later on. What’s worth knowing is how it all grew: this didn’t start as today’s car. It began as a battery management system (BMS), then gained cloud connectivity, then motor control — which evolved into a full traction inverter demo — and from there the remaining vehicle domains, from body and lighting to chassis and parking, were layered on one by one until it became a complete vehicle topology. In other words, existing MathWorks and model-based examples were assembled, domain by domain, into a car. 6 Built to be rebuilt — and learn from Why go to all this trouble? Mostly to document the work, share the thinking behind it, and show how to actually use MBDT. A big part of the appeal is that everything runs on NXP evaluation boards, which means the whole thing can be reproduced. There’s no need to redo a complex custom hardware design before starting; the same boards can be picked up to get going right away. That also makes the demo a hands-on learning platform: a place to explore the model-based workflow by doing one domain at a time. Note: A word on scope — this is a proof of concept that demonstrates the development workflow, not production firmware as it stands today. A great path forward is NXP’s CoreRide, which you can read more about on this page: Software-Defined Vehicle Development: NXP CoreRide Platform — but that part will not be covered in this series. Whether the field is automotive, electrification, industrial automation, or robotics — or simply an interest in model-based development — there should be something here worth taking away. 7 A demonstrator, not a blueprint One last note on how to read all of this. This car is a demonstrator, not a reference design. It was built with the hardware that happened to be on hand, so some of the boards and NXP solutions used aren’t necessarily the optimal fit for a given function — for a specific job, a different microcontroller might serve better. The point was never to say “use exactly these parts.” The point is the steps and the approach: the workflow itself, and how the pieces fit together. With that in mind, the articles below each take a part of this build and show how it’s done. Welcome to “Hello World” with the Model-Based Design Toolbox. 8 The article series — one domain at a time Each part of the demo car gets its own dedicated write-up, grouped into the twelve tracks below. As articles go live, the placeholders will be replaced with links. Bookmark this page — it will keep growing. NXP MBDT — How-To & Introduction What is Model-Based Design Toolbox? How to install Model-Based Design Toolbox? MBDT Setup and How-to run an application Develop an MBDT application workflow Create a new model and configure it for NXP Hardware Create a new configuration project using the S32CT How to MBDT Dio Port/Pins FreeMASTER & FreeMASTER Lite Introduction to FreeMASTER Using FreeMASTER block in Simulink Visualize and control variables in FreeMASTER Create web dashboard with FreeMASTER Lite Parking sensors Overview SW & HW Environment Logic Control (Main model overview) Lights Overview SW & HW Environment Logic Control (Main model overview) Motor Control Overview SW & HW Environment Logic Control Architecture (Main model overview) Battery Management Systems Overview SW & HW Environment Logic Control (Main model overview) Steering Overview SW & HW Environment Logic Control (Main model overview) Radar Overview SW & HW Environment Processing Chain - NXP Radar SDK Main Node Overview SW & HW Environment Logic Control (Main model overview) Zone Node Overview SW & HW Environment Logic Control (Main model overview) Software & Integration Creating virtual vehicle with MathWorks Overview SW & HW Environment Logic Control Creating Virtual Scenes & Scenarios with MathWorks (RoadRunner & Unreal Engine)  Processor-in-the-Loop (PIL) What is next? Export to & Debug generated code to S32 Design Studio IDE Other Guides Getting Started with FRDM-A-S32K312 using Model-Based Design  A1: Interacting with Digital Inputs Outputs on MR-CANHUBK344 A2: Sending data via UART and monitoring signals with FreeMASTER A3: Controlling LED intensity with ADC and PWM A4: Communicating over the CAN Bus   Note: This index is updated as new articles are published.

CLRC663 plus - LPCD Tip & Tricks Prerequisites:  CLRC663 plus Low Power Card Detection 1// Antenna Size  The stronger the coupling between reader and card, the better the detection range.  Ideally, the NFC reader antenna should have a size and form factor similar to that of the target NFC tag antenna. In practice, the reader antenna is typically designed to be slightly larger—by approximately 10% to 20%—to ensure reliable coupling and performance. 2// Antenna Q-factor  Higher Q-factor typically serves higher detection range. The Q-factor should be selected in accordance with the target communication bit rate.(e.g. Q≈30 for 106 kbit/s).  The antenna Q factor is mainly defined by the mechanical design of the antenna itself, as well as by external damping resistors. However, for LPCD-insensitive systems, a zero-ohm damping resistor can be used, and the system should then be evaluated through testing.  3// Target tuning  The CLRC663 should typically be used with the asymmetrical tuning as there is no internal power regulation implemented.  However, in some cases, symmetrical tuning may be beneficial, as it can improve detection range and sensitivity. Care must be taken to ensure that, under varying conditions—such as antenna loading by different NFC tags or the presence of nearby metal, the TVDD current does not exceed the specified maximum limits.   In CLRC663 LPCD operation, detection performance improves with higher TX power. However, this also increases current consumption, so an appropriate trade-off must be determined.   As a starting point, an antenna impedance of approximately Z≈ 50 Ω can be used.   4// Receiver setting (external Rx resistors) Based on the AN11019 (chapter 4.4.1), the peak voltage between RxN and GND (or RxP and GND) shall be in the range of 1.2Vp - 1.7Vp. Generally, higher Rx voltage levels improve detection range. To increase LPCD sensitivity and range, it can be advantageous to operate close to the upper limit of the allowed Rx voltage.   Please note that excessively high RX voltage may lead to immediate false wake-ups. 5//LPCD Settings As a starting point, we recommend using the following settings:   These settings provide robust immunity against false wake-ups and are highly efficient in terms of current consumption. The typical detection range for standard NFC tags is approximately 10 mm to 20 mm or even less in an application where the antenna is placed near a metal environment. Detection performance can be further improved by lowering the threshold settings +0 and -0. If this settings is used, we strongly advice using LPCD_FILTER feature as well. Alternatively, the user can use "high detection range option" + LPCD_FILTER. After using these settings, we recommend running "Endless LPCD" for a while and checking for any false wake-up rates. Note: The LPCD filter feature helps prevent false wake-ups. This is especially important when the threshold is set to +0 and -0. When using thresholds of +0 and −0 it is also recommended to set the "CWMAX" parameter (address 0x2A) to 1b. 5.1// LPCD RF ON time  If the RF on-time is shorter than approximately 20 µs - 30 µs , the primary detuning effect is dominated by the physical design of the NFC tag. For longer RF on-times, the NFC tag becomes energized, and its electrical parameters begin to contribute significantly to the overall detuning. Based on this understanding, a longer RF on-time can help increase LPCD detection range. However, this comes at the cost of higher current consumption. Therefore, it is recommended to compensate by adjusting the RF off-time. See an example below.   5.2// LPCD Charge pump  This function allows the TX power to be increased exclusively during the LPCD RF On time.   This can be beneficial if you want to avoid increasing the power in active mode (e.g., by reducing the tuning impedance) but only increase it during LPCD operation.   By activating the LPCD charge pump, detection performance can be improved, but at the cost of increased current consumption.   If this feature is enabled, it is recommended to verify the LPCD RF ping using an oscilloscope. It may be necessary to increase the RF On time to allow the amplitude to properly settle. Especially for TVDD= 3.3V or lower. 6// Summary Mode  Tuning function Target impedance Q-factor Receiver voltage LPCD Threshold LPCD Filter LPCD Charge -pump RF On time  Standard Asymmetrical  20 Ω - 80 Ω  10 - 30 1.5 Vp +1 and -1 disable disable 10 us High detection range  Asymmetrical /Symmetrical (1) 20 Ω - 50 Ω >25 (2) 1.7 Vp +0 and -0 enable enable/ disable (3)  20 us-100 us Note (1): Symmetrical tuning can only be applied if the TVDD current does not exceed the maximum allowable value after antenna loading caused by a card or metal object. Please ensure that this condition is met. Note (2): If high detection performance is required, the external antenna damping resistors are typically replaced with 0 Ω resistors, resulting in a higher antenna Q-factor. In this case, the user must verify that NFC communication continues to operate reliably. Due to the increased Q-factor, this configuration is typically limited to communication speeds of 106 kbit/s Note (3): Once the charge pump is enabled, the RF On time should be verified and adjusted if necessary. Please also note that the relationship between TX power and detection distance is not linear or unlimited. Beyond a certain point, enabling the charge pump provides only marginal improvements in detection distance.     Please note that the High Detection mode is generally more susceptible to false wake-ups and results in higher current consumption than the standard mode. NFC Frontend Solutions