Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
S32K311 HSE_B ASB:为原始安全恢复应用程序生成 ADKP 派生的 GMAC 您好,NXP技术支持, 我们正在使用带有 HSE_B 的 S32K311。我们的主要启动引导加载程序使用高级安全启动 (ASB),具有 AES-CMAC 认证的安全内存区域和核心 RESET 条目。UID多样化的ADKPm已经完成编程,并且安全恢复功能已启用。 固件更新后,我们需要为替换的安全恢复应用程序重新生成身份验证数据,而无需更改现有的 ADKP 或将其派生的签名密钥保留在主机可访问的内存中。 恢复应用程序从 Cortex-M7 向量表开始。其布局如下: 区域地址 恢复 IVT 0x00480000 恢复应用程序向量表和代码起始于 0x00482000 恢复 IV,12 字节 0x0049FFE4–0x0049FFEF 恢复 GMAC,16 字节 0x0049FFF0–0x0049FFFF 单独签署IVT成功。然而,将原始恢复应用程序的向量表地址提交给 HSE_SRV_ID_BOOT_DATA_IMAGE_SIGN 会返回 HSE_SRV_RSP_INVALID_PARAM 错误。该请求使用 inTagLength = 28 和系统 SRAM 中的输出缓冲区。 在 S32K311 HSE_B 上,UID 多样化的 ADKPm 已编程并启用了安全恢复,主机如何为原始安全恢复应用程序生成 12 字节 IV 和 16 字节 GMAC?当 pInImage 指向 Cortex-M7 向量表时,HSE_SRV_ID_BOOT_DATA_IMAGE_SIGN 返回 HSE_SRV_RSP_INVALID_PARAM。 是否存在 HSE 服务,可以在不暴露该密钥的情况下,使用内部派生的 ADKP 生成安全恢复 GMAC?否则,GMAC 是否必须从外部生成? 此外,IVT 安全恢复长度是否包含 12 字节的 IV,以及具体验证哪些字节? 谢谢。 Re: S32K311 HSE_B ASB: Generating ADKP-derived GMAC for a raw Secure Recovery Application 嗨@sameer_chawla 之前手册中对安全恢复过程的描述有误(可能是在某个旧版本中,比如 2.3 版本,现在已经更新了)。从那时起,我还有以下补充笔记,总结了它的实施方式: 不要向安全恢复映像添加 AppBL 标头格式。 安全恢复映像的“第一个可执行字节”是指其向量表起始地址。镜像中不需要启动头/IVT。 不要使用 HSE_SRV_ID_BOOT_DATA_IMAGE_SIGN 服务生成安全恢复映像 GMAC IV 应由客户指定,GMAC 也应由客户生成(可通过 OpenSSL 等通用工具生成,或由 HSE 在单独的应用程序项目中生成)。 在客户计算 GMAC 之前,应将 12 字节的 IV 添加到镜像末尾,并且其长度(12 字节)也应计入镜像大小。 不要使用 AES-128 (ADKP) 进行 GMAC 计算。相反,使用 AES-256 (ADKP-Hash256) 计算 GMAC,如图 11 所示,参见 HSE 固件参考手册修订版。2.8. 手册现在在“2.6.1.3.1”中明确指出安全恢复模式”: 此致, Lukas Re: S32K311 HSE_B ASB: Generating ADKP-derived GMAC for a raw Secure Recovery Application 嗨@lukaszadrapa , 感谢您的快速回复。 此后,我们测试了一种使用高级安全启动的替代方案,因为我们想避免保留或单独配置 ADKP-Hash256 以生成恢复映像 GMAC。 我们的配置如下: CB(我们的主要引导加载程序)通过 SMR0 进行身份验证。 SRB(我们的恢复引导加载程序)通过 SMR1 使用 AES-CMAC 和 HSE 驻留密钥进行身份验证,遵循与 CB 相同的身份验证方法。 核心 RESET 条目选择 CB 作为主要目的地,SRB 作为备用目的地。如果 CB 认证失败,HSE 会在启动 SRB 之前对其进行认证。 据我们了解,这使用的是 ASB 的已验证备用启动路径,而不是专用的基于 ADKP 的安全恢复机制。ADKP 仍为其现有的 IVT 身份验证和安全调试目的配置。 在 S32K311 HSE_B 上,这是受支持和推荐的方法吗?对于经过身份验证的恢复引导加载程序来说,使用单独的 SMR 和 CR 备用启动目标是否是一种常见的设计?或者与专用的安全恢复机制相比,是否存在我们应该考虑的限制? 谢谢你, 萨米尔 Re: S32K311 HSE_B ASB: Generating ADKP-derived GMAC for a raw Secure Recovery Application 嗨@sameer_chawla 是的,这也是一种有效的方法。您可以使用备用启动目标,而不是专用的安全恢复机制。 选择主要取决于所需的备用保护级别。如果一个备用级别就足够了,那么使用单独的 SMR 作为 SRB 并将其配置为备用启动目标是一个合适的解决方案。如果需要额外的回退级别,例如备用启动映像的身份验证也失败,则安全恢复机制仍然可以用作另一个恢复级别。 所以,最终取决于应用需求。使用备用启动路径来实现此目的并没有什么固有的限制。事实上,它比相对简单的专用的安全恢复映像机制提供了更大的配置灵活性。 此致, Lukas
View full article
EB tresos Studio 32.1.4 哪里可以下载 EB tresos Studio 32.1.4?  S32K3 标准软件-> 汽车软件 - EB tresos Studio / AUTOSAR 配置工具,在该路径下只能找到 EB tresos Studio 30.0.0 最高版本。 Re: EB tresos Studio 32.1.4 你好,彼得, 我按照您的建议查看了如何申请安全访问权限,但这个过程相当复杂。 我无意访问高度机密的文件;我只想下载 EB Tresos Studio 32.x.x。有什么方法可以将 EB Tresos Studio 32.xx 添加到我的产品列表中吗? 谢谢! Re: EB tresos Studio 32.1.4 你好, 查看可用版本: 所以问题很可能与您的NXP软件帐户有关。 请参考常见问题解答以获取更多信息: https://www.nxp.com/support/support/secure-access-rights:SEC-ACCESS 顺祝商祺! Peter Re: EB tresos Studio 32.1.4 你好, 我的账户邮箱:[email protected] 谢谢! Re: EB tresos Studio 32.1.4 你好, 是的,如果管理员将其添加到您的帐户中,则有直接的方法。 请告诉我您用于此账户的邮箱地址。 顺祝商祺! Peter Re: EB tresos Studio 32.1.4 你好, 现在应该可以在您的SW账户中看到了。 顺祝商祺! Peter
View full article
lpx43xx usd0 ホスト HID キーボード こんにちは 私はLPX4357を使っていて、USB HIDを使ってキーボードインターフェースを無事に完了しましたが、バーコードスキャナーを接続するとスキャン後にハードフォールが発生します...読み取り・検出されたバイトは1バイトだけで、その後はハードフォールに入ります...なぜこうなるのか、何かアイデアを教えてもらえますか?何かアドバイスはありますか? ご協力ください! LPC43xx ペリフェラル USB Re: lpx43xx usb0 host HID keyboard こんにちは、 USBバーコードスキャナーとのインターフェースを試みています。私はLPCOpen Keyboard Hostのサンプルを使用しています。USBキーボードを接続すると、システムは入力されたデータを正しく受信します。しかし、バーコードスキャナの場合、スキャンされたバーコードデータは電源投入時に一度だけ受信されます。それは必ずしも起こるわけではなく、時々起こることだ。バーコードスキャナーからデータを受け取ったとき、次のスキャンでは必ず HID_Host_IsReportReceived falseフラグが表示されます。そのため、その後はバーコードからのデータが受信できません。ピピリンの問題はありますか?どうすれば解決できますか?  コントローラ LPC4337 バーコードメーカー、ゼブロニクス。 モデルBS2H1000 よろしくお願いします。 Re: lpx43xx usb0 host HID keyboard こんにちは、 USBバーコードスキャナーのインターフェースを試みています。LPCOpen Keyboard Host のサンプルを使用して、キーボードのキーを取得しています。しかし、バーコードスキャナーを接続すると、デバイスは認識されるものの、バーコードデータを読み取ることができません。バーコードデータを読み取るためにキーボードコードの例でどんな修正が必要か教えていただけませんか? コントローラ LPC4337 バーコードメーカー、ニューランド。 モデルNLS-HR11 敬具。 Re: lpx43xx usb0 host HID keyboard 問題は解決しました。ありがとうございました。 Re: lpx43xx usb0 host HID keyboard あなたのプロジェクトはlpcopenのデモをベースにしていますか?はいの場合、どれですか?修正はありますか? 実行時にエラーが発生する箇所を特定してください。そうですか きちんと列挙する? Re: lpx43xx usb0 host HID keyboard こんにちは、 @RDGC_member さん。 このThreadは5年前に作られました。LPCフォーラムに新しいThreadを作ることをお勧めします。NXPのサポートが助けてくれます。 https://community.nxp.com/t5/LPC-Microcontrollers/bd-p/lpc ありがとうございます ジャン・ジュン Re: lpx43xx usb0 host HID keyboard 私はLPCUSBLIBライブラリを使って、USBバーコードスキャナーとコントローラをインターフェースしていますLPC4337。パイプバッファをクリアする条件を知りたいです。時々、バーコード全体が正しく表示されることがあります。最初の文字の後に何も受信しないこともあり、USB回線も詰まってしまい、その後何度もバーコードスキャンを繰り返しても何も受信されません。
View full article
请求提供“AES_ACCEL子系统参考手册” 您好,恩智浦 我目前正在分析项目中的 AES_ACCEL(AES 加速器)模块。 文档中提到可以参考“AES_ACCEL 子系统参考手册” ,但我无法从产品页面找到或下载该手册。 请问您能否告知我在哪里可以获取这份手册,或者如何才能下载它? 顺祝商祺! Re: Request for "AES_ACCEL Subsystem Reference Manual" 该文件为安全文件。请按照此处所述的安全访问注册流程进行操作,除非您已完成该流程: NXP 安全访问权限注册 更多信息,请参阅: NXP 安全访问权限 由于该文件具有较高的保密级别,因此需要人工批准才能访问。如果您已经完成了注册,但文件仍然不可用,请联系您的 恩智浦代表或代理商,并要求他们为您申请所需的访问权限。
View full article
TAA3033AT – 400 V DCリンクプリチャージ適用の適性 こんにちは、NXPコミュニティの皆さん、 現在、DCリンクのプリチャージ用途向けにTAA3033ATアクティブプリチャージコントローラーを評価しています。 当システムの仕様は以下のとおりです。 直流入力電圧:24 Vから400 V 直流リンクの静電容量:1.5 mF 定格動作電流:25A プリチャージ後にDCリンクを接続するために使用されるメインコンタクタ このTAA3033ATがこのアプリケーションに適しているか、特に広い入力電圧範囲と電流制限に関して確認したいと思います。 いくつか質問があります。 TAA3033ATは24〜400Vの入力範囲全体で動作できますか? TAA3033DB1649評価ボードは、大幅な修正なしにこれらの条件を試験するのに適しているのでしょうか? コントローラは低電圧制御システムと高電圧電源回路の間に追加のガルバニック絶縁を必要としますか? ご協力ありがとうございました。 よろしくお願いいたします。 Re: TAA3033AT – Suitability for 400 V DC-Link Precharge Application こんにちは、 @sayf さん。 1.原則的には、そうです。TAA3033ATは調整電流コントローラとして動作し、サポートされる高電圧入力範囲は主に外部MOSFET、ダイオード、インダクタ、センス抵抗、そして設定可能なタイミングおよび電流センスパラメータによって決まります。しかし、24Vまでの動作については公開されたドキュメントでは明確に記述されていません。 2. TAA3033DB1649は出発点として使用できますが、400Vおよび800Vの動作に特化しています。したがって、24Vでのテストは構成や部品の変更が必要になることがあり、別途検証されるべきです。 3. TAA3033ATにはガルバニック絶縁が含まれていません。ローサイドトポロジーでは、その制御インターフェースはHVバッテリーの負極子を参照されます。低電圧コントローラがこの領域からガルバティックアイソレータを保つ必要がある場合、外部アイソレータが必要です。ハイサイドトポロジーでは、フローティング電源とレベルシフトが必要となる。 よろしくお願いいたします。 パベル
View full article
Clarification needed on Maximum number of Keyslots supported in NXP S32K388 micro Hello Team, We needed some clarification on the maximum supported keyslot number for S32K388 device. We integrated the following RTD 701 QLP04_D2608 and find that is limit of 5 SHE group( 1 group map to 10key) i.e. a total of 50 Key slots. Is this a limitation from HSE ? We have a requirement to enable 100 key slots, so in this case would like to understand if there a possibility to configure more key slots. Thanks! Nimsha Re: Clarification needed on Maximum number of Keyslots supported in NXP S32K388 micro Hi @Nimsha  This is a limitation defined by the HSE firmware itself, rather than by the RTD implementation. As stated in Sections 6.3.2 and 6.3.3 of the HSE-B Firmware Reference Manual, Rev. 2.8, SHE keys in the NVM key catalog can be mapped to Group 0, which contains 10 key slots. In addition, HSE allows the application to provision extra AES-128 SHE keys using the SHE key update protocol (referred to as extended SHE keys), which can be mapped to Groups 1 through 4, with 10 slots available in each group. This provides a total of 50 SHE key slots, as you noted. According to the reference manual, the NVM SHE Key Catalog configuration is as follows: Row 0: MASTER_ECU_KEY, BOOT_MAC_KEY, KEY_1 to KEY_10 Row 1: KEY_11 to KEY_20 Row 2: KEY_21 to KEY_30 Row 3: KEY_31 to KEY_40 Row 4: KEY_41 to KEY_50 hseKeyGroupCfgEntry_t NVM_key_catalog[] = { /* SHE keys */ { HSE_MU0_MASK, HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 12U, HSE_KEY128_BITS}, /* MASTER_ECU_KEY, BOOT_MAC_KEY, KEY_1 to KEY_10 */ { HSE_MU0_MASK, HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 10U, HSE_KEY128_BITS}, /* KEY_11 to KEY_20 */ { HSE_MU0_MASK, HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 10U, HSE_KEY128_BITS}, /* KEY_21 to KEY_30 */ { HSE_MU0_MASK, HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 10U, HSE_KEY128_BITS}, /* KEY_31 to KEY_40 */ { HSE_MU0_MASK, HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 10U, HSE_KEY128_BITS}, /* KEY_41 to KEY_50 */ { 0U, 0U, 0U, 0U, 0U } }; The reference manual also states that attempting to map SHE keys to Group 5 or higher will result in an error during the key catalog formatting operation.  BR, VaneB Re: Clarification needed on Maximum number of Keyslots supported in NXP S32K388 micro Hi @Nimsha  These specifications apply to the standard HSE Firmware. However, premium HSE Firmware variants (available as a paid licensed product) can be tailored to address specific customer requirements and use cases. I have sent you a private message with further details. Re: Clarification needed on Maximum number of Keyslots supported in NXP S32K388 micro Hi @VaneB  Thank you for the reply. We find that GM OEM has specific requirement to enable the 100 Keyslots. Is this limitation known to GM. Since you have mentioned that HSE FW is currently supporting only 50Key slots, could you please let me know any future Firmware version the 100 keyslots are supported. Thanks! Nimsha
View full article
EB tresos Studio 32.1.4 EB Tresos Studio 32.1.4はどこでダウンロードできますか?  S32K3標準ソフトウェア - > 自動車ソフトウェア - EB tresos Studio / AUTOSAR 設定ツールでは、ルート上で EB tresos Studio 30.0.0 しか最高位を見つけられません。 Re: EB tresos Studio 32.1.4 こんにちは、ピーター。 あなたのアドバイスに従い、セキュアアクセスの申請方法も確認しましたが、手続きはかなり複雑です。 私は極秘文書にアクセスするつもりはありません。私はEB Tresos Studio 32.x.xをダウンロードしたいだけです。EB Tresos Studio 32.x.xを製品リストに追加する方法はありますか? ありがとうございます! Re: EB tresos Studio 32.1.4 こんにちは、 利用可能なバージョンを見てみましょう。 つまり、問題はおそらくNXPのソフトウェアアカウントに関係しているのでしょう。 さらなるアクセスを得るにはFAQをご確認ください: https://www.nxp.com/support/support/secure-access-rights:SEC-ACCESS よろしくお願いいたします。 ピーター Re: EB tresos Studio 32.1.4 こんにちは、 はい、管理者があなたのアカウントに追加すれば、直接的な方法があります。 そのアカウントで使用しているメールアドレスを教えてください。 よろしくお願いいたします。 ピーター Re: EB tresos Studio 32.1.4 こんにちは、 私のアカウントのメールアドレス:[email protected] ありがとう! Re: EB tresos Studio 32.1.4 こんにちは、 現在、お客様のSWアカウントでご利用いただけるはずです。 よろしくお願いいたします。 ピーター
View full article
关于 CW 3.1 谁能提供可在 Windows XP 系统上运行的 CodeWarrior 3.1 的下载链接?文件名可能是Codewarrior-HC(S)08-v3.1.iso。非常感谢。 Re: About CW 3.1 对此给您带来的不便,我深感抱歉,但此软件版本的资料和文件已不再提供下载,我需要澄清一下,CodeWarrior 3.1 是一个过时的产品。搜索结果显示,某些特定设备的 CodeWarrior 版本已经多年未得到支持,NXP 也已停止维护某些旧版 CodeWarrior 实现。   您可以升级到更新的版本。用于操作 8 位设备的软件工具是CodeWarrior for MCUs (Eclipse IDE) v11.1,适用于 Windows 10/11;如果您感兴趣,可以使用此工具测试各种 8 位设备。 顺祝商祺!
View full article
lpx43xx usb0 host HID keyboard HI  i'm using lpx4357 and successfully completed keyboard interfacing using USB HID but when i connect a barcode scanner hard fault occurs after scanning .. only one byte read / detected and then it goes to hard fault.. can i get some ideas why this could be happen?? or any suggestions ? please help! LPC43xx Peripherals USB Re: lpx43xx usb0 host HID keyboard Hello, I am trying to interface the USB barcode scanner . I am using the LPCOpen Keyboard Host example. while connecting Usb key board ,system receives proper data what ever entered. but with barcode scanner, the barcode data scanned, is received only once at power on time . that is also happens sometimes not always. When ever i received data from barcode scanner , for the next scanning i  always receive HID_Host_IsReportReceived flag false. which causes no data receive from barcode after that.  Is there any pipiline issue? how can i resolve it?   Controller LPC4337 Barcode Make Zebronics. Model BS2H1000 Regards. Re: lpx43xx usb0 host HID keyboard Hi, I am trying to interface the USB barcode scanner. I am using the LPCOpen Keyboard Host example, I am getting the keyboard keys. But when I connect the barcode scanner, it shows device is enumerated, but now able to read the barcode data. Can you please let me know, what modification need to be done in the keyboard code example to read the barcode data.  Controller LPC4337 Barcode Make Newland. Model NLS-HR11 Warm regards. Re: lpx43xx usb0 host HID keyboard issue solved .. thank you.. Re: lpx43xx usb0 host HID keyboard Is your project based on lpcopen demo ? if yes which one? any revise ? Please track where runs to error? Does it enumerate well? Re: lpx43xx usb0 host HID keyboard Hi @RDGC_member  This thread was created 5 years ago. I suggest you to create a new thread in LPC forum. The NXP support will help you. https://community.nxp.com/t5/LPC-Microcontrollers/bd-p/lpc Thanks, Jun Zhang Re: lpx43xx usb0 host HID keyboard I am using LPCUSBLIB library for interfacing USB barcode scanner with LPC4337 controller. i wanted to know that which are the conditions cause to clear the  pipe buffer. some times i receive full barcode properly. some times after first character nothing is received also the usb line gets stuck so that after that nothing is received for several times barcode scanning. 
View full article
CW 3.1について Windows XPで動作するCodeWarrior 3.1のダウンロードリンクを提供できる人はいますか?ファイル名はCodewarrior-HC(S)08-v3.1.isoかもしれません。どうもありがとうございました。 Re: About CW 3.1 ご不便をおかけして申し訳ありませんが、このソフトウェアバージョンの情報やファイルはもはやダウンロードできません。CodeWarrior 3.1はレガシー製品であることを明確にしておきます。検索結果によると、特定のデバイス向けの一部のCodeWarriorバージョンは長年サポートされておらず、NXPは一部のレガシーCodeWarrior実装の維持から移行しています。   より新しいバージョンに移行することもできます。8ビットデバイスを使用するソフトウェアツールは、Windows 10/11向けに利用可能な CodeWarrior for MCUS (Eclipse IDE) v11.1 です。このツールで様々な8ビットデバイスでテストできます。 よろしくお願いいたします。
View full article
需要澄清NXP S32K388微型芯片支持的最大键槽数量。 各位团队成员,大家好! 我们需要了解一下 S32K388 设备支持的最大键槽数量。 我们集成了以下 RTD 701 QLP04_D2608,发现其限制为 5 个 SHE 组(1 组映射到 10 个密钥),即总共 50 个密钥槽。这是英国健康与安全执行局 (HSE) 的限制吗? 我们需要启用 100 个钥匙槽,因此想了解是否有可能配置更多钥匙槽。 谢谢您! 尼姆莎 Re: Clarification needed on Maximum number of Keyslots supported in NXP S32K388 micro 嗨@Nimsha 这是 HSE 固件本身的限制,而不是 RTD 实现的限制。 如 HSE-B 固件参考手册第 2.8 版第 6.3.2 节和第 6.3.3 节所述,NVM 密钥目录中的 SHE 密钥可以映射到第 0 组,该组包含 10 个密钥槽。此外,HSE 允许应用程序使用 SHE 密钥更新协议(称为扩展 SHE 密钥)配置额外的 AES-128 SHE 密钥,这些密钥可以映射到第 1 组到第 4 组,每组有 10 个可用槽位。正如您所指出的,这总共提供了 50 个 SHE 钥匙槽。 根据参考手册,NVM SHE 密钥目录配置如下: 第 0 行:MASTER_ECU_KEY、BOOT_MAC_KEY、KEY_1 至 KEY_10 第 1 行:KEY_11 至 KEY_20 第 2 行:KEY_21 至 KEY_30 第 3 行:KEY_31 至 KEY_40 第 4 行:KEY_41 至 KEY_50 hseKeyGroupCfgEntry_t NVM_key_catalog[] = { /* SHE keys */ { HSE_MU0_MASK, HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 12U, HSE_KEY128_BITS}, /* MASTER_ECU_KEY, BOOT_MAC_KEY, KEY_1 to KEY_10 */ { HSE_MU0_MASK, HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 10U, HSE_KEY128_BITS}, /* KEY_11 to KEY_20 */ { HSE_MU0_MASK, HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 10U, HSE_KEY128_BITS}, /* KEY_21 to KEY_30 */ { HSE_MU0_MASK, HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 10U, HSE_KEY128_BITS}, /* KEY_31 to KEY_40 */ { HSE_MU0_MASK, HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 10U, HSE_KEY128_BITS}, /* KEY_41 to KEY_50 */ { 0U, 0U, 0U, 0U, 0U } }; 参考手册还指出,尝试将 SHE 密钥映射到第 5 组或更高组会导致密钥目录格式化操作期间出错。 BR,VaneB Re: Clarification needed on Maximum number of Keyslots supported in NXP S32K388 micro 嗨@VaneB 感谢您的回复。 我们发现通用汽车OEM对启用100个钥匙槽有具体要求。通用汽车公司是否了解这一限制? 既然您提到 HSE 固件目前仅支持 50 个键槽,请问未来哪个固件版本会支持 100 个键槽? 谢谢您! 尼姆莎 Re: Clarification needed on Maximum number of Keyslots supported in NXP S32K388 micro 嗨@Nimsha 这些规范适用于标准 HSE 固件。然而,高级 HSE 固件版本(作为付费许可产品提供)可以根据客户的具体需求和使用案例进行定制。 我已私信您更多详情。
View full article
TAA3033AT – 适用于 400 V 直流链路预充电应用 NXP社区的各位朋友,大家好! 我目前正在评估 TAA3033AT 有源预充电控制器在直流链路预充电应用中的性能。 我们的系统具有以下规格: 直流输入电压:24V 至 400V 直流母线电容:1.5 mF 额定工作电流:25 A 主接触器用于预充电后连接直流链路。 我想确认一下 TAA3033AT 是否适合此应用,特别是关于其宽输入电压范围和电流限制方面。 我还有几个问题: TAA3033AT 能否在 24–400 V 的整个输入范围内工作? TAA3033DB1649 评估板是否适合在不进行重大修改的情况下测试这些条件? 控制器是否需要在低压控制系统和高压电源电路之间增加额外的电气隔离? 谢谢你的帮助。 顺祝商祺! Re: TAA3033AT – Suitability for 400 V DC-Link Precharge Application 你好@sayf , 1.原则上,是的。TAA3033AT 用作稳压电流控制器,其支持的高压输入范围主要由外部 MOSFET、二极管、电感器、检测电阻以及可配置的定时和电流检测参数决定。然而,已发布的文档中并未明确描述低至 24 V 的工作电压。 2. TAA3033DB1649 可用作起点,但其特性适用于 400 V 和 800 V 的工作电压。因此,在 24 V 电压下进行测试可能需要更改配置或元器件,并且应该单独进行验证。 3. TAA3033AT 不包含电气隔离。在低侧拓扑结构中,其控制接口以高压电池负极为参考。如果低压控制器必须与该功能域保持电气隔离,则需要外部隔离。在高侧拓扑结构中,需要浮空电源和电平转换。 顺祝商祺! 帕维尔
View full article
TAA3033AT – Suitability for 400 V DC-Link Precharge Application Hello NXP COMMUNITY , I am currently evaluating the TAA3033AT active precharge controller for a DC-link precharge application. Our system has the following specifications: DC input voltage: 24 V to 400 V DC-link capacitance: 1.5 mF Nominal operating current: 25 A Main contactors used to connect the DC link after precharge I would like to confirm whether the TAA3033AT is suitable for this application, particularly regarding the wide input voltage range and current limitation. I also have a few questions: Can the TAA3033AT operate across the full 24–400 V input range? Is the TAA3033DB1649 evaluation board suitable for testing these conditions without significant modifications? Does the controller require additional galvanic isolation between the low-voltage control system and the high-voltage power circuit? Thank you for your assistance. Best regards, Re: TAA3033AT – Suitability for 400 V DC-Link Precharge Application Hello @sayf , 1. In principle, yes. The TAA3033AT operates as a regulated current controller, while the supported HV input range is primarily determined by the external MOSFET, diode, inductor, sense resistor, and the configurable timing and current-sense parameters. However, operation down to 24 V is not explicitly characterized in the published documentation. 2. The TAA3033DB1649 can be used as a starting point, but it is characterized for 400 V and 800 V operation. Testing at 24 V may therefore require configuration or component changes and should be validated separately. 3. The TAA3033AT does not include galvanic isolation. In the low-side topology, its control interface is referenced to the HV battery negative terminal. If the low-voltage controller must remain galvanically isolated from this domain, external isolation is required. In the high-side topology, a floating supply and level shifting are required. Best regards, Pavel
View full article
S32K311 HSE_B ASB: Generating ADKP-derived GMAC for a raw Secure Recovery Application Hello NXP Support, We are using an S32K311 with HSE_B. Our primary bootloader uses Advanced Secure Boot (ASB) with an AES-CMAC-authenticated Secure Memory Region and a Core Reset entry. UID-diversified ADKPm has already been programmed, and Secure Recovery is enabled. We need to regenerate the authentication data for a replacement Secure Recovery Application after a firmware update, without changing the existing ADKP or retaining its derived signing key in host-accessible memory. The recovery application begins with the Cortex-M7 vector table. Its layout is: Region Address Recovery IVT 0x00480000 Recovery application vector table and code Starts at 0x00482000 Recovery IV, 12 bytes 0x0049FFE4–0x0049FFEF Recovery GMAC, 16 bytes 0x0049FFF0–0x0049FFFF Signing the IVT separately succeeds. However, submitting the raw recovery application's vector-table address to HSE_SRV_ID_BOOT_DATA_IMAGE_SIGN returns HSE_SRV_RSP_INVALID_PARAM. The request uses inTagLength = 28 and an output buffer in system SRAM. On S32K311 HSE_B, with UID-diversified ADKPm already programmed and Secure Recovery enabled, how can the host generate the 12-byte IV and 16-byte GMAC for a raw Secure Recovery Application? HSE_SRV_ID_BOOT_DATA_IMAGE_SIGN returns HSE_SRV_RSP_INVALID_PARAM when pInImage points to the Cortex-M7 vector table. Is there an HSE service that generates the Secure Recovery GMAC using the internally derived ADKP without exposing that key? If not, must the GMAC be generated externally? Additionally, does the IVT Secure Recovery length include the 12-byte IV, and what exact bytes are authenticated? Thank you. Re: S32K311 HSE_B ASB: Generating ADKP-derived GMAC for a raw Secure Recovery Application Hi @sameer_chawla  Some time ago, the secure recovery process was incorrectly described in the manual (in some old revision, probably 2.3, it is already updated). From that time, I have these additional notes, which summarize how it should be implemented:              Don’t add AppBL header format to Secure Recovery Image              The "First executable byte" of the Secure Recovery Image means its Vector Table start address. Boot header / IVT is not needed in the image.              Don't use HSE_SRV_ID_BOOT_DATA_IMAGE_SIGN service for Secure Recovery Image GMAC generation              The IV should be specified by customer and the GMAC should be generated by customer also (by some general tool like OpenSSL or in separate application project by HSE)              Before customer calculating the GMAC, the 12-byte IV should be added into the image end, and its length(12-byte) also should be added in the image size              Don’t use AES-128 (ADKP) for GMAC calculation. Instead of that, use AES-256 (ADKP-Hash256) to calculate the GMAC as shown in Figure 11 in HSE Firmware reference manual rev. 2.8. The manual now explicitly says in “2.6.1.3.1  Secure Recovery Mode”: Regards, Lukas Re: S32K311 HSE_B ASB: Generating ADKP-derived GMAC for a raw Secure Recovery Application Hi @lukaszadrapa,  Thank you for the quick reply.  We have since tested an alternative using Advanced Secure Boot, as we wanted to avoid retaining or separately provisioning ADKP-Hash256 for recovery-image GMAC generation. Our configuration is: CB (our primary bootloader) is authenticated through SMR0. SRB (our recovery bootloader) is authenticated through SMR1 using AES-CMAC and an HSE-resident key, following the same authentication approach as CB. The Core Reset entry selects CB as the primary destination and SRB as the alternate destination. If CB authentication fails, HSE authenticates SRB before starting it. Our understanding is that this uses ASB’s authenticated alternate boot path rather than the dedicated ADKP-based Secure Recovery mechanism. ADKP remains provisioned for its existing IVT authentication and secure-debug purposes. Is this a supported and recommended approach on S32K311 HSE_B? Is using a separate SMR and CR alternate boot destination a usual design for an authenticated recovery bootloader, or are there limitations compared with the dedicated Secure Recovery mechanism that we should consider? Thank you,  Sameer Re: S32K311 HSE_B ASB: Generating ADKP-derived GMAC for a raw Secure Recovery Application Hi @sameer_chawla  Yes, this is also a valid approach. You can use the alternate boot destination instead of the dedicated Secure Recovery mechanism. The choice mainly depends on the level of fallback protection required. If one fallback level is sufficient, using a separate SMR for SRB and configuring it as the alternate boot destination is an appropriate solution. If an additional fallback level is required, for example if authentication of the alternate boot image also fails, the Secure Recovery mechanism can still be used as another recovery level. So, it ultimately depends on the application requirements. There is no inherent limitation in using the alternate boot path for this purpose. In fact, it provides more configuration flexibility than the relatively simple dedicated Secure Recovery image mechanism. Regards, Lukas
View full article
lpx43xx usb0 主机 HID 键盘 你好 我正在使用LPX4357,并且已经成功完成了通过USB HID的键盘接口连接。但是当我连接条码扫描器时,扫描后出现硬故障……只读取/检测到一个字节,然后就出现硬故障……请问这是什么原因造成的?或者有什么建议吗? 请大家帮忙! LPC43xx 外设 USB Re: lpx43xx usb0 host HID keyboard 你好, 我正在尝试连接USB条形码扫描器。我正在使用 LPCOpen 键盘主机示例。连接USB键盘时,系统能够正确接收到输入的任何数据。但是使用条形码扫描器时,扫描的条形码数据仅在开机时接收一次。这种情况有时也会发生,但并非总是如此。每次我从条码扫描器接收到数据后,下次扫描时总是收到HID_Host_IsReportReceived 标志为 false 的情况,导致之后无法从条码扫描器接收到数据。这是管道问题吗?我该如何解决? 控制器 LPC4337 条形码制作 Zebronics。 型号 BS2H1000 此致问候 Re: lpx43xx usb0 host HID keyboard 您好, 我正在尝试连接USB条形码扫描器。我正在使用 LPCOpen 键盘主机示例,我已经获取到键盘按键了。但是当我连接条形码扫描器时,它显示设备已枚举,但无法读取条形码数据。请问需要对键盘代码示例进行哪些修改才能读取条形码数据? 控制器 LPC4337 条形码制造新大陆。 型号 NLS-HR11 温暖的问候。 Re: lpx43xx usb0 host HID keyboard 问题已解决,谢谢。 Re: lpx43xx usb0 host HID keyboard 您的项目是基于lpcopen示例吗?如果是,是哪一个?需要修改吗? 请追踪出错的运行环节?是吗? 列举清楚了吗? Re: lpx43xx usb0 host HID keyboard 我正在使用 LPCUSBLIB 库将 USB 条码扫描器与 LPC4337 控制器连接起来。我想知道清除管道缓冲器的条件是什么。有时候我能正确收到完整的条形码。有时扫描第一个字符后就收不到任何数据,而且USB线还会卡住,导致之后多次扫描条形码都收不到任何数据。 Re: lpx43xx usb0 host HID keyboard 您好@RDGC_member 这个帖子是5年前创建的。我建议你在LPC论坛创建一个新帖子。NXP技术支持会为您提供帮助。 https://community.nxp.com/t5/LPC-Microcontrollers/bd-p/lpc 谢谢! 张军
View full article
EB tresos Studio 32.1.4 Where could I download EB tresos Studio 32.1.4?  S32K3 Standard Software -> Automotive SW - EB tresos Studio / AUTOSAR Configuration Tool , on the path can only find EB tresos Studio 30.0.0 the highest. Re: EB tresos Studio 32.1.4 Hello Peter, I have followed your advice and checked how to apply for secure access, but the process is quite complicated. I don't intend to access highly classified documents; I only wish to download EB Tresos Studio 32.x.x. Is there a way to add EB Tresos Studio 32.x.x to my Product List? Thanks! Re: EB tresos Studio 32.1.4 Hello, Looking at the available versions: So the issue is most probably tied to your NXP SW account. Please follow the FAQ to gain further access: https://www.nxp.com/support/support/secure-access-rights:SEC-ACCESS Best regards, Peter Re: EB tresos Studio 32.1.4 Hello, My account email: [email protected] Thanks! Re: EB tresos Studio 32.1.4 Hello, Yes, there is a direct way if admin add it to your account. Please share with me account email you are using for it. Best regards, Peter Re: EB tresos Studio 32.1.4 Hello, It should be available at your SW account now. Best regards, Peter
View full article
FRDM-MCXN947 Ethernet port set up - PHY LAN8741A I am struggling to get the ethernet port to connect.  On debug, I keep getting the following below on frdm board.  [00:00:00.000,000] phy_mii: PHY (0) ID 7C121 [00:00:00.006,000] phy_mii: phy_mii_[00:00:00.000,000] phy_mii: PHY (0) ID 7C121 [00:00:00.006,000] phy_mii: phy_mii_cfg_link: PHY (0) Link already configured [00:00:00.015,000] eth_nxp_enet_qos_mac: Can't clear SWR [00:00:00.021,000] eth_nxp_enet_qos_mac: Link is down *** Booting Zephyr OS build v4.4.2 *** Starting application and checking MDIO bus... PHY Reg 0x01 (BMSR): 0x7809 PHY Reg 0x05 (Partner Ability): 0xCDE1 PHY Reg 0x1A (Symbol Errors): 51 [00:00:04.029,000] phy_mii: check_autonegotiation_completion: PHY (0) auto-negotiate timeout [00:00:14.042,000] phy_mii: update_link_state: PHY (0) Starting MII PHY auto-negotiate sequence [00:00:14.052,000] phy_mii: check_autonegotiation_completion: PHY (0) auto-negotiate sequence completed [00:00:14.062,000] phy_mii: PHY (0) Link speed 100 Mb, full duplex [00:00:14.069,000] eth_nxp_enet_qos_mac: Link is up [00:00:14.075,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Speed 100MBit or higher It seems like MDIO comms is working fine but link keeps resetting every 30ms.  Any clue as to what configuration needs to be to get LAN8741A to work properly on the FRDM-MCXN947 board?  Development Board 回复: FRDM-MCXN947 Ethernet port set up - PHY LAN8741A Hi @thisisdarlensonl  Thanks for the detailed information. To help us further investigate this issue, could you please provide the following information? Which Zephyr sample are you using? Your prj.conf, application overlay file, and build command. Have you made any changes to the FRDM-MCXN947 board DTS? Could you provide the complete log showing the link resetting every 30 ms? I want to reproduce this issue. BR Harry 回复: FRDM-MCXN947 Ethernet port set up - PHY LAN8741A Hi Harry,  Thanks for getting back to me. I have attached the prj.cong and app.overlay file. I started with a hello world sample and build on that. The current version of Zephyr is 4.4.2  As for full console messages. See below  [00:00:00.000,000] phy_mii: PHY (0) ID 7C121 [00:00:00.006,000] phy_mii: phy_mii_[00:00:00.000,000] phy_mii: PHY (0) ID 7C121 [00:00:00.006,000] phy_mii: phy_mii_cfg_link: PHY (0) Link already configured [00:00:00.015,000] eth_nxp_enet_qos_mac: Can't clear SWR [00:00:00.021,000] eth_nxp_enet_qos_mac: Link is down *** Booting Zephyr OS build v4.4.2 *** === FRDM-MCXN947 PM-Optimized Heartbeat Demo === Starting application and checking MDIO bus... PHY Reg 0x01 (BMSR): 0x7809 PHY Reg 0x05 (Partner Ability): 0xCDE1 PHY Reg 0x1A (Symbol Errors): 51 [00:00:04.029,000] phy_mii: check_autonegotiation_completion: PHY (0) auto-negotiate timeout [00:00:14.042,000] phy_mii: update_link_state: PHY (0) Starting MII PHY auto-negotiate sequence [00:00:14.052,000] phy_mii: check_autonegotiation_completion: PHY (0) auto-negotiate sequence completed [00:00:14.062,000] phy_mii: PHY (0) Link speed 100 Mb, full duplex [00:00:14.069,000] eth_nxp_enet_qos_mac: Link is up [00:00:14.075,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Speed 100MBit or higher [00:00:14.085,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Full Duplex [00:00:15.094,000] phy_mii: PHY (0) is down [00:00:15.098,000] eth_nxp_enet_qos_mac: Link is down [00:01:08.626,000] phy_mii: update_link_state: PHY (0) Starting MII PHY auto-negotiate sequence [00:01:08.636,000] phy_mii: check_autonegotiation_completion: PHY (0) auto-negotiate sequence completed [00:01:08.646,000] phy_mii: PHY (0) Link speed 100 Mb, full duplex [00:01:08.653,000] eth_nxp_enet_qos_mac: Link is up [00:01:08.659,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Speed 100MBit or higher [00:01:08.668,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Full Duplex [00:01:09.177,000] phy_mii: PHY (0) is down [00:01:09.182,000] eth_nxp_enet_qos_mac: Link is down [00:01:22.193,000] phy_mii: update_link_state: PHY (0) Starting MII PHY auto-negotiate sequence [00:01:22.203,000] phy_mii: check_autonegotiation_completion: PHY (0) auto-negotiate sequence completed [00:01:22.213,000] phy_mii: PHY (0) Link speed 100 Mb, full duplex [00:01:22.220,000] eth_nxp_enet_qos_mac: Link is up [00:01:22.226,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Speed 100MBit or higher [00:01:22.235,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Full Duplex [00:01:22.744,000] phy_mii: PHY (0) is down [00:01:22.749,000] eth_nxp_enet_qos_mac: Link is down [00:03:57.817,000] phy_mii: update_link_state: PHY (0) Starting MII PHY auto-negotiate sequence [00:03:57.827,000] phy_mii: check_autonegotiation_completion: PHY (0) auto-negotiate sequence completed [00:03:57.837,000] phy_mii: PHY (0) Link speed 100 Mb, full duplex [00:03:57.844,000] eth_nxp_enet_qos_mac: Link is up [00:03:57.850,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Speed 100MBit or higher [00:03:57.859,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Full Duplex [00:03:58.368,000] phy_mii: PHY (0) is down [00:03:58.373,000] eth_nxp_enet_qos_mac: Link is down [00:05:08.907,000] phy_mii: update_link_state: PHY (0) Starting MII PHY auto-negotiate sequence [00:05:08.917,000] phy_mii: check_autonegotiation_completion: PHY (0) auto-negotiate sequence completed [00:05:08.927,000] phy_mii: PHY (0) Link speed 100 Mb, full duplex [00:05:08.934,000] eth_nxp_enet_qos_mac: Link is up [00:05:08.940,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Speed 100MBit or higher [00:05:08.949,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Full Duplex [00:05:09.958,000] phy_mii: PHY (0) is down [00:05:09.963,000] eth_nxp_enet_qos_mac: Link is down [00:05:36.980,000] phy_mii: update_link_state: PHY (0) Starting MII PHY auto-negotiate sequence [00:05:36.990,000] phy_mii: check_autonegotiation_completion: PHY (0) auto-negotiate sequence completed [00:05:37.000,000] phy_mii: PHY (0) Link speed 100 Mb, full duplex [00:05:37.007,000] eth_nxp_enet_qos_mac: Link is up [00:05:37.013,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Speed 100MBit or higher [00:05:37.022,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Full Duplex [00:05:38.031,000] phy_mii: PHY (0) is down [00:05:38.036,000] eth_nxp_enet_qos_mac: Link is down [00:12:00.195,000] phy_mii: update_link_state: PHY (0) Starting MII PHY auto-negotiate sequence [00:12:00.205,000] phy_mii: check_autonegotiation_completion: PHY (0) auto-negotiate sequence completed [00:12:00.215,000] phy_mii: PHY (0) Link speed 100 Mb, full duplex [00:12:00.222,000] eth_nxp_enet_qos_mac: Link is up [00:12:00.228,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Speed 100MBit or higher [00:12:00.237,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Full Duplex [00:12:00.746,000] phy_mii: PHY (0) is down [00:12:00.751,000] eth_nxp_enet_qos_mac: Link is down [00:13:41.297,000] phy_mii: update_link_state: PHY (0) Starting MII PHY auto-negotiate sequence [00:13:41.307,000] phy_mii: check_autonegotiation_completion: PHY (0) auto-negotiate sequence completed [00:13:41.317,000] phy_mii: PHY (0) Link speed 100 Mb, full duplex [00:13:41.324,000] eth_nxp_enet_qos_mac: Link is up [00:13:41.330,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Speed 100MBit or higher [00:13:41.340,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Full Duplex [00:13:41.848,000] phy_mii: PHY (0) is down [00:13:41.853,000] eth_nxp_enet_qos_mac: Link is down [00:14:02.868,000] phy_mii: update_link_state: PHY (0) Starting MII PHY auto-negotiate sequence [00:14:02.877,000] phy_mii: check_autonegotiation_completion: PHY (0) auto-negotiate sequence completed [00:14:02.888,000] phy_mii: PHY (0) Link speed 100 Mb, full duplex [00:14:02.894,000] eth_nxp_enet_qos_mac: Link is up [00:14:02.900,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Speed 100MBit or higher [00:14:02.910,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Full Duplex [00:14:03.418,000] phy_mii: PHY (0) is down [00:14:03.423,000] eth_nxp_enet_qos_mac: Link is down [00:14:26.439,000] phy_mii: update_link_state: PHY (0) Starting MII PHY auto-negotiate sequence [00:14:26.448,000] phy_mii: check_autonegotiation_completion: PHY (0) auto-negotiate sequence completed [00:14:26.459,000] phy_mii: PHY (0) Link speed 100 Mb, full duplex [00:14:26.466,000] eth_nxp_enet_qos_mac: Link is up [00:14:26.471,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Speed 100MBit or higher [00:14:26.481,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Full Duplex [00:14:27.490,000] phy_mii: PHY (0) is down [00:14:27.495,000] eth_nxp_enet_qos_mac: Link is down [00:19:14.115,000] phy_mii: update_link_state: PHY (0) Starting MII PHY auto-negotiate sequence [00:19:14.125,000] phy_mii: check_autonegotiation_completion: PHY (0) auto-negotiate sequence completed [00:19:14.135,000] phy_mii: PHY (0) Link speed 100 Mb, full duplex [00:19:14.142,000] eth_nxp_enet_qos_mac: Link is up [00:19:14.148,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Speed 100MBit or higher [00:19:14.158,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Full Duplex [00:19:14.666,000] phy_mii: PHY (0) is down [00:19:14.671,000] eth_nxp_enet_qos_mac: Link is down [00:20:45.214,000] phy_mii: update_link_state: PHY (0) Starting MII PHY auto-negotiate sequence [00:20:45.223,000] phy_mii: check_autonegotiation_completion: PHY (0) auto-negotiate sequence completed [00:20:45.234,000] phy_mii: PHY (0) Link speed 100 Mb, full duplex [00:20:45.240,000] eth_nxp_enet_qos_mac: Link is up [00:20:45.246,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Speed 100MBit or higher [00:20:45.256,000] eth_nxp_enet_qos_mac: eth_nxp_enet_qos_phy_cb: Link Full Duplex [00:20:45.764,000] phy_mii: PHY (0) is down [00:20:45.769,000] eth_nxp_enet_qos_mac: Link is down [00:25:14.383,000] phy_mii: update_link_state: PHY (0) Starting MII PHY auto-negotiate sequence [ 回复: FRDM-MCXN947 Ethernet port set up - PHY LAN8741A Hi @thisisdarlensonl  Thank you for the additional information. For a quick verification, I tested the Zephyr DHCPv4 client sample using the following command: west build -b frdm_mcxn947/mcxn947/cpu0 zephyr/samples/net/dhcpv4_client -p always Initially, I observed a similar issue on my FRDM-MCXN947 board. After checking the board hardware, I found that SJ27 had been reworked. After restoring SJ27 to its default position, I ran the same DHCPv4 client example again and the issue no longer occurred. The PHY was detected correctly and the Ethernet link came up at 100 Mbps full duplex: [00:00:00.050,000] phy_mii: PHY (0) ID 7C121 *** Booting Zephyr OS build v4.4.0-17350-g1ee3b93134be *** [00:00:00.051,000] net_dhcpv4_client_sample: Run dhcpv4 client [00:00:00.051,000] net_dhcpv4_client_sample: Start on ethernet@40100000: index=1 [00:00:03.758,000] phy_mii: PHY (0) Link speed 100 Mb, full duplex Could you please check whether SJ27 or any other Ethernet-related solder jumpers on your FRDM-MCXN947 board have been reworked? If so, please restore them to the default Ethernet configuration and test again. BR Harry 回复: FRDM-MCXN947 Ethernet port set up - PHY LAN8741A Thanks @Harry_Zhang, massive help legend. I didn't realize that it was configured for display by default. Now I can move on. Thanks a lot for your help.  It is probably worthwhile noting this somewhere else. Also, the solder jumpers are painful 😉 Again massive thanks
View full article
HTRC11001T 的 EVM 您好, HTRC11001T是否有可用的EVM(评估模块)? Re: EVM of HTRC11001T NXP 没有为 HTRC110 提供专用的官方评估板。 不过,我们可以提供一些参考资料来帮助您进行设计和开发工作。 硬件设计参考:我们建议参考应用笔记AN98080_基于 HITAG 读写 IC 的读写设备。本文档详细介绍了基于HTRC110的读写器设计,包括: 125 kHz 天线设计 谐振和匹配网络设计 外围耦合电路 解调电路原理 时钟和电源相关设计 其他外部元器件选择建议 软件开发参考:NXP 可提供 HTRC110 的相关示例代码和参考文档,作为客户进行底层驱动程序和应用程序开发的起点。但是,申请这两项都需要签署保密协议。 对于评估硬件或现成的读卡器解决方案,我建议查看 NXP ®合作伙伴市场: https://www.nxp.com/design/design-center/partner-marketplace:PARTNER-MARKETPLACE Re: EVM of HTRC11001T 您好, 感谢您的快速回复。 其中一个查询,如 HTRC110 应用笔记中所述,仅针对 HITAG 系列标签进行了优化。那么,这是否意味着它不能与其他标签(例如 EM 系列 (EM4305) 标签)一起使用? Re: EVM of HTRC11001T 你好@Shanmukh 很抱歉,HTRC11001T 没有可用的 EVM(评估模块)! BR 凯莉
View full article
About CW 3.1 Who can provide a download link for CodeWarrior 3.1 that runs on Windows XP? The file  name may be Codewarrior-HC(S)08-v3.1.iso.  Thanks a lot. Re: About CW 3.1 I'm really sorry for the inconvenience this might cause you, but the information and files of this software version is no longer available for download, I need to clarify that CodeWarrior 3.1 is a legacy product. The search results indicate that some CodeWarrior versions for specific devices have not been supported in years, and NXP has transitioned away from maintaining certain legacy CodeWarrior implementations.   You could move to a more recent version, The software tool to use 8 bits devices is CodeWarrior for MCUs (Eclipse IDE) v11.1 available for windows 10/11; in this tool you can test with various 8-bit devices if you are interested. Best Regards
View full article
NXP S32K388マイクロコントローラでサポートされるキースロットの最大数について明確化が必要 こんにちは、チームの皆さん、 S32K388デバイスでサポートされる最大キースロット数について、いくつか確認が必要でした。 以下のRTD 701 QLP04_D2608を統合したところ、5つのSHEグループ(1グループが10キーにマッピング)まで、つまり合計50個のキースロットが制限されていることがわかりました。これはHSE(英国安全衛生庁)による制限ですか? 100個のキースロットを有効にする必要があるため、今回はさらに多くのキースロットを設定できるかどうか知りたいです。 よろしくお願いします! ニムシャ Re: Clarification needed on Maximum number of Keyslots supported in NXP S32K388 micro こんにちは、 @Nimshaさん これはRTDの実装による制限ではなく、HSEファームウェア自体によって規定された制限です。 HSE-BファームウェアリファレンスマニュアルRev. 2.8の6.3.2および6.3.3節に記載されているように、NVMキーカタログ内のSHEキーは、10個のキースロットを含むグループ0にマッピングできます。さらに、HSEはSEEキー更新プロトコル(拡張SEEキーと呼ばれる)を用いて追加のAES-128 SHE鍵をプロビジョニング可能にし、グループ1から4までにマッピングでき、各グループに10スロットがあります。ご指摘のとおり、これにより合計50個のSHEキースロットが提供されます。 リファレンス・マニュアルによると、NVM SHEキーカタログの設定は以下の通りです。 行0:MASTER_ECU_KEY、BOOT_MAC_KEY、KEY_1~KEY_10 1行目:KEY_11~KEY_20 2行目:KEY_21~KEY_30 3行目:KEY_31~KEY_40 4行目:KEY_41~KEY_50 hseKeyGroupCfgEntry_t NVM_key_catalog[] = { /* SHE keys */ { HSE_MU0_MASK, HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 12U, HSE_KEY128_BITS}, /* MASTER_ECU_KEY, BOOT_MAC_KEY, KEY_1 to KEY_10 */ { HSE_MU0_MASK, HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 10U, HSE_KEY128_BITS}, /* KEY_11 to KEY_20 */ { HSE_MU0_MASK, HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 10U, HSE_KEY128_BITS}, /* KEY_21 to KEY_30 */ { HSE_MU0_MASK, HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 10U, HSE_KEY128_BITS}, /* KEY_31 to KEY_40 */ { HSE_MU0_MASK, HSE_KEY_OWNER_ANY, HSE_KEY_TYPE_SHE, 10U, HSE_KEY128_BITS}, /* KEY_41 to KEY_50 */ { 0U, 0U, 0U, 0U, 0U } }; リファレンスマニュアルには、SHEキーをグループ5以上にマッピングしようとすると、キーカタログのフォーマット操作中にエラーが発生すると記載されています。 BR、VaneB Re: Clarification needed on Maximum number of Keyslots supported in NXP S32K388 micro こんにちは、 @Nimshaさん これらの仕様は、標準のHSEファームウェアに適用されます。しかし、プレミアムなHSEファームウェア(有料ライセンス製品として提供)は、特定のお客様要件やユースケースに合わせてカスタマイズ可能です。 詳しい内容を記載したプライベートメッセージをお送りしました。 Re: Clarification needed on Maximum number of Keyslots supported in NXP S32K388 micro こんにちは、 @VaneBさん ご返信ありがとうございます。 GM OEMは100個のキースロットを有効にするという特定の要件を持っていることがわかりました。この制限事項はGMに認識されているのでしょうか? HSE FWが現在50キースロットのみをサポートしているとおっしゃっていましたが、FUTURE 100キースロットをサポートするファームウェアバージョンがあれば教えていただけませんか? よろしくお願いします! ニムシャ
View full article