S32DSライセンスの有効期限が切れました こんにちは、NXPサポートチームの皆さん、 私のS32DS v2.2ライセンスは2026年8月24日に期限切れとなりました。ライセンスの延長を手伝ってもらえますか? アクティベーションコード：563B-6314-7B07-7945 ご支援ありがとうございます。 Re: S32DS License Expired こんにちは、 お客様のS32DSライセンスが延長されました。以前のコードを使用して、S32DSを再度有効化してください。 Re: S32DS License Expired こんにちは： 私のARM 2018R1 IDE用のS32DSライセンスが期限切れです。確認して延長してもらえますか? 私のソフトウェアアクティベーションコードは09D2-DE37-6529-87FBです ありがとうございます。

RW610 PowerTableUtil.exe missing utility Hello, I'm looking for the PowerTableUtil.exe file referenced in the UM12154 document. I was able to find the sample power table spreadsheets but not the tool itself. Apparently it's supposed to be on the RW610 product page but I cannot find it there. Any help would be greatly appreciated Product: WiFi RW6XX Re: RW610 PowerTableUtil.exe missing utility Hello @allenandrew1357, You can find the PowerTableUtil.exe utility in the Secure Software section of the device's official product page: Could you please help us confirm that you have access to this section? You would need to request access through Secure Access Rights by following the instructions from this page: Secure Access Rights | NXP Semiconductors BR Habib Re: RW610 PowerTableUtil.exe missing utility I took a look at the secure section, seems like I have not requested access rights yet. I put in the request, I'll update once that goes through. Thanks!

HSE FW 2.40.0および2.55.0におけるGCM IV長サポートに関する質問 こんにちは、 S32K358のHSEにおけるGCMの動作について質問があります。 HSEサービスAPIリファレンスマニュアルのAEADサービス説明において、HSE FW 2.40.0および2.55.0の両方でGCMについて以下の事項が明記されています。 GCM: 1 <= ivLength <= 2^32-1。推奨サイズは12バイト以上です。 しかし、HSE FW 2.40.0のマニュアルには、HSE FW 2.55.0のマニュアルには記載されていない以下の注記が追加されています。 GCM操作においては、IV値として正確に12バイトを使用することを推奨します。12バイトを超える任意のIVサイズに対して、GCM暗号化操作によって生成される認証タグが正しくない場合があります。GCM復号操作では、認証チェックが失敗することがあります。 この点に関して、以下の点を明確にしたいと思います。 1. IV長が12バイトでない場合、HSE FW 2.40.0でGCM操作を通常使用できますか? 2. 12バイト以外のIV長を使用した場合、HSE FW 2.40.0と2.55.0の間でGCM操作に挙動的な違いはありますか? 3. IV長が12バイト以外の場合、HSE FW 2.40.0と2.55.0の間でGCM動作の信頼性に違いはありますか？ 私たちのテストでは、IV長が12バイトでなくてもGCM暗号化と復号が成功し、認証結果も正確でした。 したがって、HSE FW 2.40.0で12バイト以外のIV長の使用が完全にサポートされているかどうか、またこの場合のHSE FW 2.55.0使用と機能的に違いがあるのかを確認したいと思います。 ご説明いただきありがとうございます。 Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 こんにちは、 @wodudwo さん。 技術的には、ivLengthは異なる長さで設定可能ですが、しかし、その動作が信頼性を保証するわけではないため推奨されません。ご指摘の通り、ドキュメントにはGCM復号操作では、12バイト以外のIV長を使うと認証チェックが失敗する可能性があると記載されています。 異なる長さの点滴チューブを使用したテストに合格したとしても、手術が必ず成功するとは限りません。言い換えれば、特定のテストケースで成功した結果が、その構成が完全にサポートされている、あるいはすべてのシナリオで一貫して動作するという指標と解釈すべきではありません。 さらに、両方のファームウェアバージョンのリリースノートを確認すると、制限事項のリストに同じ推奨事項が記載されていることがわかります。それは、IV値を正確に12バイトにすることです。 この注記はHSE FW 2.55.0からHSEサービスAPIリファレンスマニュアルから削除されましたが、制限自体は変更されていません。 BR、VaneB Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 こんにちは。ご説明ありがとうございます。 12バイト以外のIV（初期化ベクトル）の使用に関して、もう一つ質問があります。 非12バイトのIVを使う場合、認証タグの生成や検証が信頼性に欠ける可能性があることは理解しています。 この場合、認証タグに関係なく暗号化/復号操作自体は信頼できると見なせるのでしょうか? 例えば、GCM暗号化に16バイトのIVが使われた場合、認証タグが信頼性がなくても、結果として得られる暗号文は正確かつ一貫性が保証されるのでしょうか? つまり、制限は認証タグの生成・検証に特有なのか、それとも12バイト以外のIVを使うことで、実際の暗号化・復号操作の信頼性や正確性にも影響が出るのでしょうか? よろしくお願いします。 Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 こんにちは、 @wodudwo さん。 HSEサービスAPIリファレンスマニュアルに記載されているように、推奨されるIV長は 1<= iv∧ の範囲内であり、推奨12バイト以上が推奨されます。 リファレンス実装はhse_crypto.cで入手できます。( S32K3汎用HSEデモ例)およびhse_sessionkeys_example.c(HSEデモアプリ)。

Accessing Micro Safety Manual Hi, On date 12/06/2026 i should have been enable to view secure resources for S32K3. I'm looking for the Safety Manual of S32K358 and i still can't find it at all. I tried in secure documentation here: https://www.nxp.com/products/S32K3#myDocument and in My NXP Account -> Secure Resources but i couldn't find it. Could someone help me? Thanks, Simon Re: Accessing Micro Safety Manual Hi @simon98  We have reviewed your account and our internal records and were unable to locate any previous request for the S32K3 Safety Manual. Could you please help us by requesting higher access permissions to obtain this document? BR, VaneB Re: Accessing Micro Safety Manual Hi @simon98  Please take a look at the NXP SECURE ACCESS RIGHTS FIRST-TIME USER REGISTRATION GUIDE, as you may find it useful.  Re: Accessing Micro Safety Manual hi @VaneB , Could you please tell me how could i request the access of S32K358 safety manual?  I thought having access to secure resourses (which was campleted in 12/06) i'd been able to acces it... BR, Simon Re: Accessing Micro Safety Manual Hi @VaneB  I've already got access to secure resources but i couldn't find the safety manual in secure resources section. I tried to apply a higher rights request specifying my needs. Is it correct? Thanks, Simon Re: Accessing Micro Safety Manual Hi @VaneB , I've checked the guide you mentioned above. I tried to request more higher rights for S32 Automotive Processing Platform but the page riminds me that it's still pending for all the items. I'd ask you if this is the right way to gain access to s32k358 safety manual or if there is other ways slipping off from me, missing something and wath else. Do i need to proivide something in order to gain access to it? Thanks, Simon

What Makes a Denver Mobile App Development Company a Good Choice for Businesses? A Mobile App Development Company in Denver can help businesses turn digital ideas into scalable iOS and Android applications with custom features, intuitive interfaces, secure integrations, and reliable backend systems. These services can support customer engagement, business automation, payments, real-time functionality, and other digital requirements. JPLOFT develops customized mobile applications aligned with business goals and user needs.

S32K2x8EVB-Q289 QSPI（S26KL512Sバリアントが誤っている） こんにちは、 現在、S32K3x8EVB-Q289ボードを使用しており、オンボードのS26KL512SDABHV030フラッシュとQSPIを連携させることを試みています。 徹底的なデバッグを行った結果、行き詰まってしまい、何が起こっているのか分からなくなってしまいました。そこで、解決したい点を見つけたので、ここに報告します。 EVBのユーザーガイドと回路図には、S26KL512SDABHV030が基板上にハンダ付けされていると記載されています。部品を検査した結果、刻印は以下のとおりであることが確認されました。 6KL512SDAHV03は03バリアント（DCARSバリアント）です。 S26K512Sのデータシートを読んだところ、DCARSはPSC信号を使用してRWDS（読み取りに必要な信号）を生成すると記載されていました。しかし、EVBの回路図では、PSCは（テストパッドTPAD21を除いて）どこにも配線されていません。PSC#は3VバリアントではRFUなので、必要ありません。 ロジックアナライザを見ると、レイテンシ期間(戻るデータを観察すべき時刻)後にRWDSが切り替える様子は見られず、転送は最終的にタイムアウトします。 フラッシュメモリが動作せず、EVBに誤ったバージョンのフラッシュメモリが搭載されているのではないかと考えています。 ご助言ありがとうございます。 ミハル Re: S32K2x8EVB-Q289 QSPI with wrong S26KL512S variant 中古ボードのリビジョンを具体的に教えてもらえますか?ボードユーザーマニュアルには以下の訂正が明記されています: Re: S32K2x8EVB-Q289 QSPI with wrong S26KL512S variant もう一つ最新情報をお伝えします。 PSCをSCKに接続した後、RWDS信号が得られました。 これは以下のことを裏付けています。 03（DCARS）バージョンでは、データが利用可能になったことを示すためにPSC信号が必要となります。現在、Rev C EVBにはコネクテッドされていません。 02（非DCARS）バリアントは、インストールされるべきICです。 PSC信号に遅延がないため、RWDSトグルはデータ変化エッジに非常に近い位置にあり、読み取り値にばらつきが生じます（現在はデバイスIDの読み取り値でテストしています）。 S32K358の内部DQSを利用すると、データの変更と正しく整合していない可能性があるため、データの読み取り方法が信頼できるとは言えません。 お知らせ下さい ミハル Re: S32K2x8EVB-Q289 QSPI with wrong S26KL512S variant 当社にはRev Cバージョンの基板があります。 したがって、その訂正は私たちのケースには適用されませんし、さらに、回路図上でPSCピンが入れ替わっていても、PSCピンは切断されたままになります(SCKピンだけが接続されているため)。 S26KL5152Sのデータシートを読むと、SCKピンをPSCに接続すればメモリが02(DCARS以外の)バリアントのように振る舞うと書かれています。基板を再設計してこの接続を追加し、それで問題が解決するかどうか確認してみます。 他に解決策があれば、ぜひお知らせください。 ミハル

s32ds 许可证已过期 你好， 代码：4F70-F0A3-101C-3C96 我谨此申请续订 S32DS 2018R1 许可证。 感谢您的支持。 顺祝商祺！

Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 Hello, I have a question regarding the GCM operation of the HSE on the S32K358. In the AEAD service description of the HSE Service API Reference Manual, both HSE FW 2.40.0 and 2.55.0 specify the following for GCM: GCM: 1 <= ivLength <= 2^32-1. Recommended 12 bytes or greater. However, the HSE FW 2.40.0 manual contains the following additional note, which is not present in the HSE FW 2.55.0 manual: In GCM operations, it is recommended to use IV values of exactly 12 bytes. For any IV size different from 12 bytes, the authentication tag generated by the GCM encryption operation might not be correct. In GCM decryption operations, the authentication check might fail. In this regard, I would like to clarify the following: 1. Can GCM operations be used normally in HSE FW 2.40.0 when the IV length is not 12 bytes? 2. Is there any behavioral difference in GCM operations between HSE FW 2.40.0 and 2.55.0 when using an IV length other than 12 bytes? 3. Is there any difference in the reliability of GCM operations between HSE FW 2.40.0 and 2.55.0 when using an IV length other than 12 bytes? In our tests, GCM encryption and decryption were performed successfully even when the IV length was not 12 bytes, and the authentication results were also correct. Therefore, I would like to confirm whether using an IV length other than 12 bytes is fully supported in HSE FW 2.40.0, and whether there is any functional difference compared to using HSE FW 2.55.0 in this case. Thank you for your clarification. Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 Hi @wodudwo  Technically, ivLength can be configured with a different length; however, doing so is not recommended because the behavior is not guaranteed to be reliable. As you correctly pointed out, the documentation states that for GCM decryption operations, the authentication check may fail when IV lengths other than 12 bytes are used. While your test may have passed using a different IV length, this does not guarantee that the operation will always succeed. In other words, a successful result in a particular test case should not be interpreted as an indication that the configuration is fully supported or will work consistently in all scenarios.  Additionally, if you review the release notes for both firmware versions, you will find that the List of Limitations includes the same recommendation: use IV values of exactly 12 bytes. Although the note was removed from the HSE Service API Reference Manual starting with HSE FW 2.55.0, the limitation itself remains unchanged.  BR, VaneB Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 Hi, Thank you for the clarification. I have one additional question regarding the use of an IV other than 12 bytes. I understand that the authentication tag generation/verification may not be reliable when a non-12-byte IV is used. In this case, can the encryption/decryption operation itself be considered reliable, regardless of the authentication tag? For example, if a 16-byte IV is used for GCM encryption, is the resulting ciphertext guaranteed to be correct and consistent, even though the authentication tag may not be reliable? In other words, is the limitation specific to the authentication tag generation/verification, or does using an IV other than 12 bytes also affect the reliability/correctness of the actual encryption/decryption operation? Thank you. Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 Hi @wodudwo  As stated in the HSE Service API Reference Manual, the recommended IV length is within the range 1<= ivLength <= 2∧32-1 with 12 bytes or greater recommended. Reference implementations are available in hse_crypto.c (S32K3 General Purpose HSE Demo Examples) and hse_sessionkeys_example.c (HSE DemoApp).

S32DS License Expired Hello NXP Support Team,   My S32DS v2.2 license expired on August 24, 2026. Could you please help extend the license? Activation Code: 563B-6314-7B07-7945   Thank you for your support. Re: S32DS License Expired Hi, your S32DS license has been extended. Please activate S32DS again with your old code.  Re: S32DS License Expired Hi: My license of S32DS for ARM 2018R1 IDE has expired. Could you help check and extend it for me?  My Software Activation Code is 09D2-DE37-6529-87FB Thanks.

KITPF09FRDMPGM – 是否包含错误的板？ 我订购了一台 KITPF09FRDMPGM。交付内容包括 KITPF09FRDMPGM 和一块单独的 FRDM-KL25Z 板。 但是，我认为这两个板不兼容，或者至少我看不出它们应该如何连接。例如，FRDM-KL25Z 上的 J21 接头在机械上会妨碍操作。 此外，将 KITPF09FRDMPGM 插入 FRDM-KL25Z 所需的针脚接头也缺失。 请问有人能确认一下套件里是否包含了正确的板吗？它看起来不应该和 KITPF7100FRDMPGM 附带的板相似吗？ i.MX 的 PMIC

S32K2x8EVB-Q289 QSPI 芯片的 S26KL512S 型号错误 您好， 我们目前使用的是 S32K3x8EVB-Q289 板，我们正在尝试让 QSPI 与板载 S26KL512SDABHV030 闪存一起工作。 经过大量的调试，我们遇到了瓶颈，一直搞不清楚到底发生了什么，直到我们发现了一些我们想要澄清的事情。 EVB 用户指南和原理图中显示，S26KL512SDABHV030 焊接在板上。通过检查零件，我们也确认了标记内容： 6KL512SDAHV03 是 03 变体（DCARS 变体）。 阅读 S26K512S 数据手册后发现，DCARS 使用 PSC 信号生成 RWDS（读取所需）。然而，在 EVB 的原理图中，PSC 没有布线到任何地方（除了测试焊盘 TPAD21）。PSC# 在 3V 版本上是 RFU，所以我们不需要它。 从逻辑分析仪上看，我们始终看不到 RWDS 在延迟期后切换（此时我们应该观察到返回的数据），传输最终超时。 我们一直无法让闪光灯正常工作，我们怀疑EVB是否配错了闪光灯型号。 感谢您的帮助。 Michal Re: S32K2x8EVB-Q289 QSPI with wrong S26KL512S variant 以下是最新进展： 将 PSC 连接到 SCK 后，我们现在有了 RWDS 信号。 这证实了以下几点： 03 (DCARS) 变体确实需要 PSC 信号才能指示何时有数据可用。目前这在 Rev C EVB 上尚未连接。 02（非DCARS）型是应该安装的集成电路。 由于PSC信号没有延迟，RWDS切换非常接近数据变化边沿，导致读数不一致（目前我们正在使用设备ID读取进行测试）。 使用 S32K358 的内部 DQS 也无法提供可靠的数据读取方法，因为它可能无法与数据变化正确对齐。 请指教 Michal Re: S32K2x8EVB-Q289 QSPI with wrong S26KL512S variant 我们有一块 Rev C 板。 因此，该勘误不适用于我们的情况，而且，即使原理图将它们互换了，PSC 引脚仍然会断开，因为只有 SCK 引脚是连接的。 阅读 S26KL5152S 数据手册可知，我们可以将 SCK 引脚连接到 PSC，然后存储器将像 02（非 DCARS）变体一样工作。我们将重新设计板，添加此连接，看看是否能解决问题。 如果您有其他解决方案，请与我们联系。 Michal Re: S32K2x8EVB-Q289 QSPI with wrong S26KL512S variant 能否具体说明一下所用板的版本？板用户手册中列出了以下勘误：

s32ds license Expired Hello, Code: 4F70-F0A3-101C-3C96 I would like to kindly request the renewal of the S32DS 2018R1 license. Thank you for your support. Best regards.

マイクロセーフティマニュアルへのアクセス こんにちは、 2026年12月6日時点で、私はS32K3のセキュアなリソースを閲覧できる状態になっているはずです。 S32K358のセーフティマニュアルを探しているのですが、まだ全く見つかりません。 ここ https://www.nxp.com/products/S32K3#myDocument の安全なドキュメントやMy NXPアカウントの「Secure Resources」>で試しましたが、見つかりませんでした。 どなたか助けていただけますか? ありがとう、 サイモン Re: Accessing Micro Safety Manual こんにちは、 @simon98さん お客様のアカウントおよび内部記録を確認しましたが、S32K3セーフティマニュアルの過去のリクエストは見つかりませんでした。この文書を取得するために、より高いアクセス権限を申請する手助けをいただけますか? BR、VaneB Re: Accessing Micro Safety Manual こんにちは、 @VaneB さん。 セーフティマニュアルのアクセスをどう申請すればよいか教えていただけますかS32K358? 安全な資源(2006年12月にキャンプされたもの)にアクセスできると思っていましたが... BR、 サイモン Re: Accessing Micro Safety Manual こんにちは、 @simon98さん 役立つかもしれない「 NXPのセキュアアクセス権初回ユーザー登録ガイド」をご覧ください。 Re: Accessing Micro Safety Manual こんにちは、 @VaneBさん すでに安全なリソースへのアクセスはできていますが、セーフティマニュアルは安全なリソースのセクションで見つかりませんでした。 私は自分のニーズを具体的に明記した、より上位の権限要求を申請しようと試みました。それは正しいですか？ ありがとうございます サイモン Re: Accessing Micro Safety Manual こんにちは、 @VaneB さん。 上記で言及されていたガイドを確認しました。 S32自動車処理プラットフォームの権利をさらに高めて申請しようとしましたが、ページがすべてのアイテムについてまだ保留中であることを思い出させてくれました。 これがs32k358セーフティマニュアルにアクセスする正しい方法なのか、それとも他に見落としや見落としがあるのかをお聞きしたいです。アクセスするには何かをプロビッドする必要がありますか? ありがとうございます サイモン

访问微型功能安全手册 您好， 截至 2026 年 12 月 6 日，我应该能够查看 S32K3 的安全资源。 我正在寻找S32K358的功能安全手册，但我仍然找不到。 我尝试在以下安全文档中查找： https://www.nxp.com/products/S32K3#myDocument以及“我的 NXP 帐户”->“安全资源”，但都找不到。 请问有人能帮帮我吗？ 谢谢， 西蒙 Re: Accessing Micro Safety Manual 嗨@simon98 我们已查阅您的账户和我们的内部记录，但未能找到任何之前对 S32K3 功能安全手册的请求。请您帮忙申请更高的访问权限，以便我们获取这份文件？ BR，VaneB Re: Accessing Micro Safety Manual 嗨@simon98 请查阅《NXP 安全访问权限首次用户注册指南》 ，您可能会觉得它很有用。 Re: Accessing Micro Safety Manual 嗨@VaneB ， 请问如何申请获取S32K358功能安全手册？ 我以为有了安全资源访问权限（这项权限已于 12 月 6 日完成），我就能访问它了…… BR， 西蒙 Re: Accessing Micro Safety Manual 嗨@VaneB 我已经获得了访问安全资源的权限，但我在安全资源部分找不到功能安全手册。 我尝试申请更高的权限，并详细说明了我的需求。这样说对吗？ 谢谢！ 西蒙 Re: Accessing Micro Safety Manual 嗨@VaneB ， 我已查阅过您上面提到的指南。 我尝试申请更高的S32 汽车处理平台权限，但页面提示我所有项目的申请仍在审核中。 我想问一下，这是获取 s32k358 功能安全手册的正确方法吗？还是我遗漏了其他方法，或者还有其他什么原因？我需要提供什么才能获得访问权限？ 谢谢！ 西蒙

SC16IS740：需要帮助配置自动RTS SC16IS740_750_760 我目前正在编写一个MicroPython库，以支持通过SPI接口使用SC16IS740。 我正在使用分线板测试与 MAX3237 连接的 SC16IS740。 所有基本功能均有效（包括 RX & TX FiFo），并通过物理 TX > RX 环回（以及我的示波器）进行了测试。 现在，我想测试/实现自动RTS功能。 为了验证这一点：我放置了一个示波器，通道 1 接 RX，通道 2 接 RTS。 我向接收缓冲区发送大量数据，期望示波器上的RTS信号变为高电平……但这种情况并没有发生。 以下是 Halt_trigger 和 resume_trigger 的值（以字符为单位）的 MicroPython 代码。代码主要读取和写入给定通道（“ch”参数）的寄存器。 数据手册里好像漏掉了什么，但我找不到原因。 备注：最后一条指令强制 RTS 为高电平，以便在瞄准镜上检查手动激活。然后它的值会降到很低，并且永远不会被自动RTS激活……可以肯定的是，RX FIFO已满。 def enable_rts( self, halt_trigger, resume_trigger ): assert 4<=halt_trigger<=60, "RTS trigger must be within 4-60 range" assert 4<=resume_trigger<=60, "RTS trigger must be within 4-60 range" assert (halt_trigger%4) + (resume_trigger%4) == 0, "Trigger level are step by 4!" assert halt_trigger > resume_trigger, "halt_trigger must be greater than resume_trigger!" _halt = halt_trigger//4 _resume = resume_trigger//4 # Set LCR=0xBF to access EFR register _old_lcr = self.owner.bus_wrapper.read_reg( REG_LCR, ch=self.ch ) # store transmission config (eg: 8n1) self.owner.bus_wrapper.write_reg( REG_LCR, 0xBF, ch=self.ch ) # activate enhanced feature _efr = self.owner.bus_wrapper.read_reg(REG_EFR, ch=self.ch) _efr = _efr | 0b00010000 self.owner.bus_wrapper.write_reg(REG_EFR, _efr, ch=self.ch) print( "EFR:" , bin(self.owner.bus_wrapper.read_reg(REG_EFR, ch=self.ch)) , 'Enhanced function activation') # Close access to EFR & restore transmission config (eg:8n1) self.owner.bus_wrapper.write_reg( REG_LCR, _old_lcr, ch=self.ch ) # Enable TCR & TLR register access _mcr = self.owner.bus_wrapper.read_reg(REG_MCR, ch=self.ch) _mcr = _mcr | 0b00000100 self.owner.bus_wrapper.write_reg(REG_MCR, _mcr, ch=self.ch) print( "MCR:" , bin(self.owner.bus_wrapper.read_reg(REG_MCR, ch=self.ch)), 'Enable TCR & TLR register') # Set TCR trigger values _tcr = self.owner.bus_wrapper.read_reg(REG_TCR, ch=self.ch) _tcr = _tcr | (_resume<<4) _tcr = _tcr | _halt self.owner.bus_wrapper.write_reg(REG_TCR, _tcr, ch=self.ch) print( "TCR:", bin(self.owner.bus_wrapper.read_reg(REG_TCR, ch=self.ch)), "Transmission Control register (resume & halt levels)") # TLR must be cleared (to use TCR) self.owner.bus_wrapper.write_reg(REG_TLR, 0x00, ch=self.ch) print( "TLR:", bin(self.owner.bus_wrapper.read_reg(REG_TLR, ch=self.ch)), "Disable TLR values (so use TCR)") # Disable TCR & TLR register access _mcr = self.owner.bus_wrapper.read_reg(REG_MCR, ch=self.ch) _mcr = _mcr & 0b11111011 self.owner.bus_wrapper.write_reg(REG_MCR, _mcr, ch=self.ch) print( "MCR:" , bin(self.owner.bus_wrapper.read_reg(REG_MCR, ch=self.ch)), 'Disable TCR & TLR register') self.owner.bus_wrapper.write_reg( REG_LCR, 0xBF, ch=self.ch ) # Enable auto RTS flow control _efr = _efr | 0b01000000 self.owner.bus_wrapper.write_reg(REG_EFR, _efr, ch=self.ch) print( "EFR:" , bin(self.owner.bus_wrapper.read_reg(REG_EFR, ch=self.ch)) , 'Enable auto RTS') # Close access to EFR & restore transmission config (eg:8n1) self.owner.bus_wrapper.write_reg( REG_LCR, _old_lcr, ch=self.ch ) # Initial State of RTS bit in Modem (MCR) _mcr = self.owner.bus_wrapper.read_reg( REG_MCR, ch=self.ch ) _mcr = _mcr | 0x02 self.owner.bus_wrapper.write_reg( REG_MCR, _mcr, ch=self.ch ) 非常欢迎提出建议和意见。 干杯， 多米尼克 Re: SC16IS740 : Need help to configure Auto-RTS 你好， 根据数据表，我建议检查以下几点： 请确认 EFCR[4] = 0。EFCR[4] 启用自动 RS-485 RTS 控制。当此位被设置时，发射器将控制 RTS 引脚，并且此功能优先于手动 RTS 控制和硬件流控制电路。因此，在使用 Auto-RTS 硬件流控制时，应清除 EFCR[4]。 TLR 未定义 Auto-RTS 停止/恢复阈值。对于 Auto-RTS，接收器 FIFO 触发电平取自 TCR，如果 TCR 位被清除，则取自 FCR。TLR 用于与中断生成相关的可编程发送和接收 FIFO 触发电平。因此，自动RTS操作不应要求清除TLR。 Re: SC16IS740 : Need help to configure Auto-RTS 嗨@ErikaC ， 谢谢你的留言。 虽然我检查了 EFCR[4]，但我注意到一切都按预期进行。 总之，感谢 EFCR[4]，这在未来会非常有用。 问：发生了什么变化？ 响应：完全重启电源。 推测：测试和尝试次数过多可能导致 SC16IS7xxx 配置损坏。 感谢您的帮助。 多米尼克

关于 HSE FW 2.40.0 和 2.55.0 中 GCM IV 长度支撑的问题 你好， 我有一个关于 S32K358 上 HSE 的 GCM 操作的问题。 在 HSE 服务 API 参考手册的 AEAD 服务描述中，HSE FW 2.40.0 和 2.55.0 都对 GCM 进行了如下规定： GCM: 1 <= ivLength <= 2^32-1。建议大小为 12 字节或更大。 但是，HSE FW 2.40.0 手册包含以下附加说明，而 HSE FW 2.55.0 手册中没有此说明： 在 GCM 操作中，建议使用正好 12 字节的 IV 值。对于任何非 12 字节的 IV 大小，GCM 加密操作生成的认证标签可能不正确。在 GCM 解密操作中，身份验证检查可能会失败。 在此，我想澄清以下几点： 1. 当 IV 长度不是 12 字节时，HSE FW 2.40.0 中 GCM 操作能否正常使用？ 2. 当使用 12 字节以外的 IV 长度时，HSE FW 2.40.0 和 2.55.0 在 GCM 操作方面是否存在行为差异？ 3. 当使用 12 字节以外的 IV 长度时，HSE FW 2.40.0 和 2.55.0 的 GCM 操作可靠性是否存在差异？ 在我们的测试中，即使 IV 长度不是 12 字节，GCM 加密和解密也能成功执行，并且认证结果也正确。 因此，我想确认 HSE FW 2.40.0 是否完全支持使用 12 字节以外的 IV 长度，以及在这种情况下与使用 HSE FW 2.55.0 相比是否存在任何功能差异。 谢谢你的解释。 Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 嗨@wodudwo 从技术上讲，ivLength 可以配置为不同的长度；但是，不建议这样做，因为不能保证其行为可靠。正如您正确指出的那样，文档中说明，对于 GCM 解密操作，当使用 12 字节以外的 IV 长度时，身份验证检查可能会失败。 虽然使用不同长度的静脉输液管进行的测试可能通过了，但这并不能保证手术一定会成功。换句话说，某个测试用例的成功结果不应被解释为表明该配置完全受支持或在所有情况下都能稳定运行。 此外，如果您查看这两个固件版本的发行说明，您会发现限制列表包含相同的建议：使用正好为 12 字节的 IV 值。 虽然从 HSE 固件 2.55.0 版本开始，HSE 服务 API 参考手册中已删除该注释，但限制本身仍然存在。 BR，VaneB Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 嗨@wodudwo 如 HSE 服务 API 参考手册中所述，建议的 IV 长度在1<= ivLength <= 2∧32-1 的范围内，建议为 12 字节或更大。 参考实现可在 hse_crypto.c 文件中找到。（ S32K3 通用 HSE 演示示例）和 hse_sessionkeys_example.c（HSE 演示应用程序）。 Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 您好，谢谢您的澄清。 关于使用 12 字节以外的 IV，我还有一个问题。 我理解，当使用非 12 字节的 IV 时，身份验证标签的生成/验证可能不可靠。 在这种情况下，无论认证标签如何，加密/解密操作本身是否可以被认为是可靠的？ 例如，如果使用 16 字节的 IV 进行 GCM 加密，即使认证标签可能不可靠，能否保证生成的密文正确且一致？ 换句话说，这种限制是专门针对身份验证标签的生成/验证，还是使用 12 字节以外的 IV 也会影响实际加密/解密操作的可靠性/正确性？ 谢谢！

S32K2x8EVB-Q289 QSPI with wrong S26KL512S variant Hi, We currently have the S32K3x8EVB-Q289 board and  we are trying to make the QSPI work with the onboard S26KL512SDABHV030 flash. After extensive debugging, we have hit a wall and we couldn't figure out what was going on until we found something that we want to clear up. In the EVB user guide and schematics, it indicates that the S26KL512SDABHV030 is soldered on the board. By inspecting the part, we also confirmed that the markings are: 6KL512SDAHV03 which is the 03 variant (DCARS variant). After reading the S26K512S datasheet, it states that the DCARS uses the PSC signal to generate the RWDS (needed for reading). However, in the schematics of the EVB, the PSC is not routed anywhere (except to test pad TPAD21). PSC# is RFU on the 3V variant so we don't need it. Looking at the logic analyzer, we never see the RWDS toggling after the latency period (when we should observe the returned data) and the transfer eventually times out. We have not been able to get the flash working and we are wondering whether the EVB is shipped with the wrong flash variant. Thanks for your help. Michal Re: S32K2x8EVB-Q289 QSPI with wrong S26KL512S variant Here is another update: After connecting PSC to SCK, we now have have a RWDS signal. This confirms the following: The 03 (DCARS) variant does need a PSC signal to be able to indicate when data is available. This is currently not connected on the Rev C EVB. The 02 (non-DCARS) variant is the IC that should have been installed Since the PSC signal is not delayed, the RWDS toggle is very close to the data change edges giving us inconsistent readings (we are testing with the device ID reads for now).     Using the internal DQS of the S32K358 also does not provide a reliable method of reading the data as it may not be aligned correctly with data changes. Please advise Michal Re: S32K2x8EVB-Q289 QSPI with wrong S26KL512S variant We have a Rev C board. So that erratum does not apply to our case, and furthermore, that would still leave the PSC pin disconnected (even if the schematics had them swapped since only the SCK pin is connected). Reading the S26KL5152S datasheet, it says that we can connect the SCK pin to PSC and the memory would then behave like a 02 (non-DCARS) variant. We will re-work the board to add this connection and see if that fixes the issue. If you have another solution, please let us know. Michal Re: S32K2x8EVB-Q289 QSPI with wrong S26KL512S variant Could you specify used board revision? In the board user manual following erratum is specified:

RW610 PowerTableUtil.exe 实用程序缺失 您好，我正在寻找 UM12154 文档中提到的 PowerTableUtil.exe 文件。我找到了示例功率表电子表格，但没有找到工具本身。它应该在 RW610 产品页面上，但我找不到。非常感谢您的帮助！ 产品：WiFi RW6XX Re: RW610 PowerTableUtil.exe missing utility 你好@allenandrew1357 ， 您可以在设备官方产品页面的“安全软件”部分找到 PowerTableUtil.exe 实用程序： 请问您能否协助我们确认您是否拥有此部分的访问权限？ 您需要通过安全访问权限申请访问权限，请按照此页面上的说明进行操作：安全访问权限 | NXP 半导体 BR 哈比卜 Re: RW610 PowerTableUtil.exe missing utility 我查看了安全部分，似乎我还没有申请访问权限。我已经提交了申请，一旦获得批准，我会更新结果。谢谢！

SC16IS740:Auto-RTSの設定について助けが必要です SC16IS740_750_760 現在、SPIを使ったこのSC16IS740をサポートするMicroPythonライブラリを書いています。 私はブレークアウトボードを使って、MAX3237に接続されたSC16IS740のテストを行っています。 すべての基本機能（RX & TX FiFoを含む）は正常に動作し、物理的なTX->RXループバック（および私のオシロスコープ）でテスト済みです。 今、Auto-RTS機能をテスト・実装したいと思っています。 確認するために、ch1をRXに、ch2をRTSに接続してオシロスコープを設置しました。 RXバッファをフラッディングして、RTS信号がスコープでHighに切り替わると思っていますが、実際には起こりません。 以下に、halt_trigger と resume_trigger の値 (文字単位) を含む MicroPython コードを示します。コードは主に特定のチャネル(「ch」パラメータ)に対してレジスタの読み書きを行います。 データシートに何か見落としがあるのですが、それが何なのか分かりません。 注記：最後の命令は、オシロスコープでの手動アクティベーションを確認するために、RTSをハイレベルに強制します。その後、その数値が低くなり、オートRTSで一度も起動されません......確かに、RXのFIFOは満タンになります。 def enable_rts( self, halt_trigger, resume_trigger ): assert 4<=halt_trigger<=60, "RTS trigger must be within 4-60 range" assert 4<=resume_trigger<=60, "RTS trigger must be within 4-60 range" assert (halt_trigger%4) + (resume_trigger%4) == 0, "Trigger level are step by 4!" assert halt_trigger > resume_trigger, "halt_trigger must be greater than resume_trigger!" _halt = halt_trigger//4 _resume = resume_trigger//4 # Set LCR=0xBF to access EFR register _old_lcr = self.owner.bus_wrapper.read_reg( REG_LCR, ch=self.ch ) # store transmission config (eg: 8n1) self.owner.bus_wrapper.write_reg( REG_LCR, 0xBF, ch=self.ch ) # activate enhanced feature _efr = self.owner.bus_wrapper.read_reg(REG_EFR, ch=self.ch) _efr = _efr | 0b00010000 self.owner.bus_wrapper.write_reg(REG_EFR, _efr, ch=self.ch) print( "EFR:" , bin(self.owner.bus_wrapper.read_reg(REG_EFR, ch=self.ch)) , 'Enhanced function activation') # Close access to EFR & restore transmission config (eg:8n1) self.owner.bus_wrapper.write_reg( REG_LCR, _old_lcr, ch=self.ch ) # Enable TCR & TLR register access _mcr = self.owner.bus_wrapper.read_reg(REG_MCR, ch=self.ch) _mcr = _mcr | 0b00000100 self.owner.bus_wrapper.write_reg(REG_MCR, _mcr, ch=self.ch) print( "MCR:" , bin(self.owner.bus_wrapper.read_reg(REG_MCR, ch=self.ch)), 'Enable TCR & TLR register') # Set TCR trigger values _tcr = self.owner.bus_wrapper.read_reg(REG_TCR, ch=self.ch) _tcr = _tcr | (_resume<<4) _tcr = _tcr | _halt self.owner.bus_wrapper.write_reg(REG_TCR, _tcr, ch=self.ch) print( "TCR:", bin(self.owner.bus_wrapper.read_reg(REG_TCR, ch=self.ch)), "Transmission Control register (resume & halt levels)") # TLR must be cleared (to use TCR) self.owner.bus_wrapper.write_reg(REG_TLR, 0x00, ch=self.ch) print( "TLR:", bin(self.owner.bus_wrapper.read_reg(REG_TLR, ch=self.ch)), "Disable TLR values (so use TCR)") # Disable TCR & TLR register access _mcr = self.owner.bus_wrapper.read_reg(REG_MCR, ch=self.ch) _mcr = _mcr & 0b11111011 self.owner.bus_wrapper.write_reg(REG_MCR, _mcr, ch=self.ch) print( "MCR:" , bin(self.owner.bus_wrapper.read_reg(REG_MCR, ch=self.ch)), 'Disable TCR & TLR register') self.owner.bus_wrapper.write_reg( REG_LCR, 0xBF, ch=self.ch ) # Enable auto RTS flow control _efr = _efr | 0b01000000 self.owner.bus_wrapper.write_reg(REG_EFR, _efr, ch=self.ch) print( "EFR:" , bin(self.owner.bus_wrapper.read_reg(REG_EFR, ch=self.ch)) , 'Enable auto RTS') # Close access to EFR & restore transmission config (eg:8n1) self.owner.bus_wrapper.write_reg( REG_LCR, _old_lcr, ch=self.ch ) # Initial State of RTS bit in Modem (MCR) _mcr = self.owner.bus_wrapper.read_reg( REG_MCR, ch=self.ch ) _mcr = _mcr | 0x02 self.owner.bus_wrapper.write_reg( REG_MCR, _mcr, ch=self.ch ) ご意見やご提案を心よりお待ちしております。 乾杯、 ドミニク Re: SC16IS740 : Need help to configure Auto-RTS こんにちは、 データシートに基づき、以下の点を確認することをお勧めします。 EFCR[4] = 0 であることを必ず確認してください。EFCR[4] は Auto RS-485 RTS コントロールを有効にします。このビットが設定されると、**トランスミッタ**はRTSピンの制御を行い、この機能は手動RTS制御およびハードウェアフロー制御回路の両方よりも優先されます。したがって、Auto-RTSハードウェアフロー制御を使用する場合はEFCR[4]をクリアする必要があります。 TLRはAuto-RTSの停止/再開閾値を定義していません。Auto-RTSでは、**レシーバ**のFIFOトリガーレベルはTCRから、またはTCRビットがクリアされている場合はFCRから取られます。TLRは、割り込み生成に関連する、プログラム可能な送信および受信FIFOトリガーレベルに使用されます。したがって、オートRTS動作にTLRのクリアリングは必須ではありません。 Re: SC16IS740 : Need help to configure Auto-RTS こんにちは、 @ErikaC さん。 ご連絡ありがとうございます。 EFCR[4]を確認したところ、すべてが予想通りに進んでいることがわかりました。 ともあれ、EFCR[4]ありがとうございます。FUTURE的に役立つでしょう。 質問：何が変わったのですか？ 応答：完全な電源サイクル。 推測：テストと試行錯誤が多すぎたために、SC16IS7xxxの設定が壊れてしまった可能性が高い。 ご協力いただきありがとうございます。 ドミニク

KITPF09FRDMPGM – 間違った基板が同梱されていますか？ KITPF09FRDMPGMを注文しました。納品物には、KITPF09FRDMPGM本体と、別売りのFRDM-KL25Z基板が含まれていました。 しかし、両基板は互換性がないと思いますし、少なくともどう接続すべきかはわかりません。例えば、FRDM-KL25ZのJ21ヘッダーは機械的に邪魔になる。 さらに、KITPF09FRDMPGMをFRDM-KL25Zに接続するために必要なピンヘッダーが欠品しています。 どなたか、キットに正しい基板が付属しているか確認していただけませんか?KITPF7100FRDMPGMに付属の基板と似たような外観であるべきではないでしょうか？ i.MX用PMIC