S32K358 MCU 上的睡眠和唤醒驱动器配置 您好， 我一直在使用 S32K358，并参考了 S32K3XX 的低电源管理单元示例，该示例演示了使用 GPIO 的睡眠和唤醒功能。不过，我还没能让它按照预期运行。 我怀疑可能是我的配置或执行出现了问题。如果您能查看我的配置和源文件，并告诉我它们是否正确或是否需要修改，我将不胜感激。 经过多次尝试，我仍然无法达到预期效果，因此我希望得到您的指导。 现附上我的配置和源文件，供您审阅。 IDE：S32DS 3.5.14 SW 版本：4.0 HW: S32K358 致以最诚挚的问候， Karmegan C Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU 嗨，@karmegancjk、 当检测到唤醒且 S32K358 进入 RESET 序列时，RAM 内容是易失性还是非易失性？ 32KB 的 SRAM 内容是非易失性的，或者说，32KB 的 SRAM 在待机时保持供电：   如果 RAM 内容需要非易失性，如何创建备用 RAM 内存并将 RAM 数据复制到备用 RAM 内存？ 为了使用备用 RAM，必须修改链接器文件，分配单独的 32KB，放置备用部分，并调整链接器地址符号。如果之前的 RESET 是 POR，则还必须初始化待机 RAM 的 ECC。 我已经给你发了一条私信，里面有关于如何使用待机 RAM 和一般低功耗的演示。 待机模式是否类似于 S32K358 Cortex-M7 的睡眠模式或深度睡眠模式？ 是的，待机模式类似于深度睡眠： 致以最诚挚的问候， Julián Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU 你好，胡利安、 S32K358 通过 GPIO 实现休眠和唤醒功能。如上所述，当检测到上升沿时，控制器将按复位顺序进行 RESET。现在，我有一些疑问： 当检测到唤醒且 S32K358 进入 RESET 序列时，RAM 内容是易失性还是非易失性？ 如果 RAM 内容需要非易失性，如何创建备用 RAM 内存并将 RAM 数据复制到备用 RAM 内存？ 待机模式是否类似于 S32K358 Cortex-M7 的睡眠模式或深度睡眠模式？ Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU 嗨，@karmegancjk、 进入待机模式时，我使用的是唤醒通道 46 (PTC24)。我的理解是，如果在此引脚上检测到上升沿，则应触发唤醒中断。 外部唤醒信号支持上升或下降检测。 程序计数器是否从地址 0x00402000 开始恢复执行？ 还是需要完全 RESET 微控制器才能恢复执行？ 在以前的设备 (S32K1) 中，代码在 WFI 指令之后恢复执行，这意味着在 WFI 之后唤醒 ISR → 代码；S32K3 将在唤醒后始终执行 RESET 序列。这可能取决于配置的待机模式。 例如，正常待机退出执行 RESET 序列，然后初始化 sbaF 和 HSE 固件（如果已安装），然后在 reset_handler 恢复执行。 但是，快速待机退出可以跳过 sbaF 和 HSE 初始化，直接跳转到用户定义的启动地址。在此用户定义的启动地址之后，建议执行完全 RESET 以完全初始化设备（或者您可以再次返回待机状态，具体取决于应用程序的需求）： 至于项目配置，似乎一切正常。 致以最诚挚的问候， Julián Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU 您好， 我对 MCU 进入待机模式（睡眠或深度睡眠模式）时的行为有些疑问。在这种模式下，程序计数器是否会冻结，并在唤醒后从矢量地址 0x00402000 重新启动，还是从停止的位置继续执行？ 请检查我的电源和唤醒驱动程序配置（.cfg 文件中）是否正确。文件）是正确的吗？我附上了我的项目中的配置文件供你参考。 Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU 你好，朱利安， 我们使用的是基于 S32K358 MCU 的定制硬件。我有一个关于待机模式下唤醒功能的问题。 进入待机模式时，我使用的是唤醒通道 46 (PTC24)。我的理解是，如果在此引脚上检测到上升沿，则应触发唤醒中断。 不过，我不确定唤醒事件之后会发生什么。具体为： 程序计数器是否从地址 0x00402000 开始恢复执行？ 还是需要完全 RESET 微控制器才能恢复执行？ 另外，我没有使用任何中断控制 API 进行唤醒配置，所以我不确定唤醒中断是否得到正确处理或者是否需要 RESET。 请说明在这种情况下唤醒过程是如何进行的，以及预期的程序流程是怎样的？ ，感谢您的支持。 致以最诚挚的问候， Karmegan C Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU 嗨，@karmegancjk、 您使用的是 S32K3X8EVB 还是定制硬件？ 请记住，S32K358 在 PMIC 握手时增加了退出待机的步骤。 如果你不使用握手，请在 DCMRWF1： 已解决：S32K3： 请求唤醒和 RESET 行为支持——恩智浦社区中设置 PMIC_PGOOD_HNDSHK_BYP 位 。 另外，您配置的是哪个 GPIO？请使用 S32K3 参考手册所附的 S32K358_IOMUX.xlsx 文件交叉检查 WKPU 信号是否正确。 致以最诚挚的问候， Julián Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU 嘿@karmegancjk ， 我目前也在研究睡眠和唤醒序列，您能否分享一下您的工作代码供我参考？如果您能分享，那就太好了。

S32 Design Studio for ARM 2.2 – ライセンスアクティベーションエラー (CLLReason errorNo=27: 再アクティベーションの最大数 こんにちは、 S32 Design Studio for Arm v2.2 のライセンス認証に問題があり、ツールを使用できなくなりました。 製品: Arm用S32 Design Studio バージョン: 2.2 OS: Windows 10 (64ビット) ライセンスの種類:ノードロック (アクティベーション コード) アクティベーションコード: 3668-673A-125A-5626 S32DS を起動すると、製品ライセンス ウィンドウに次の内容が表示されます。 ステータス: ライセンスがありません 「アクティベート」をクリックしてアクティベーション コードを入力すると、すぐに次のエラーが表示されます。 CLLReason [errorNo=27、errorString=リモート アクティベーション サーバーにリターン要求を送信し、応答をプロセッシングするときにエラーが発生しました。返品の最大数に達しました。サポートが必要な場合は、製品ベンダーにお問い合わせください。(FNPエラー 0)、flxActMajorErrNo=0、flxActMinorErrNo=0、flxActSysErrNo=0、flxCommErrNo=0] 私の理解では、これはこのアクティベーション コードの戻り/移動の最大数に達したことを意味します。 過去に S32DS や Windows を数回再インストールしたことがあるSO、ライセンスが何度も返却/アクティブ化されている可能性があります。 すでに試しました: S32DSを管理者として実行する インターネット接続とファイアウォール/プロキシ設定を確認する オンラインアクティベーションと「オフラインリクエストの生成」オプションの両方を使用する 問題は依然として同じであり、製品をアクティブ化できなくなりました。 現在の PC で S32 Design Studio for Arm 2.2 をアクティベートできるように、このアクティベーション コードの返却カウンターをリセットするか、新しいアクティベーション コードを発行していただけますか? 必要に応じて、追加情報（ログ ファイル、スクリーンショットなど）CAN提供します。 ご協力をよろしくお願いいたします。 よろしくお願いいたします。 ジョンヨブ・ベク。 Re: S32 Design Studio for ARM 2.2 – License activation error (CLLReason errorNo=27: maximum number o こんにちは、 古いコードを使用して S32DS を再度アクティブ化できるはずです。 Re: S32 Design Studio for ARM 2.2 – License activation error (CLLReason errorNo=27: maximum number o 私も同じ問題を抱えていて、どう直せばいいのか分かりません

S32K3の駆動力は高い S32K3XXのリファレンス・マニュアルには「ドライブ強度の有効化」ビットについて書かれていますが、その意味を明確に定義しているようには見えません。私が見つけた最も近い参考文献は、特定のピンがサポートする最大周波数と相関しているようです(S32K3XXRM/セクション4.4.1の42ページ)。 「drive-strength」を有効にすべきか否かを判断する上で、最大消費電流値やその他の注意点に関して、何か明確な規定はありますか？ Re: High Drive Strength on S32K3 GPIO規格：最大10MHzのスイッチングに対応。高駆動強度には対応していません。スルーレート制御はサポートされていません。 — GPIO-Standard plus:最大25 MHzへの切り替え 高い駆動強度をサポートします。スルーレート制御はサポートされていません。 — GPIO-Medium:最大50 MHzまでの切り替えで高いドライブ強度をサポートします。スルーレート制御をサポートします。 — GPIO-Fast:最大120 MHzへの切り替え 高いドライブ強度をサポートします。スルーレート制御をサポートします。 Re: High Drive Strength on S32K3 はい、それはまさに私が質問で引用した箇所の文章です。それではなぜ「ドライブ強度」を有効にするべきか、あるいは有効でないかはわかりません。単に一部のピンがそれをサポートしていること、そして一部の切り替え速度がそれに関連していることを示しているだけです。 もしこれでLEDを駆動する場合、より多くの電流を流すことができるでしょうか？どれくらい最新の情報ですか？ これは純粋にスルーレートの変更なのでしょうか？ ピンがサポートしているなら、有効にしない理由はありますか?それを有効にすると、チップの放熱量は増えますか？ Re: High Drive Strength on S32K3 S32K39x、S32K37x、S32K36xマイクロコントローラのハードウェア設計ガイドライン Re: High Drive Strength on S32K3 ハイ S32K3XXリファレンスマニュアル(S32K3XXRM)では、パッドタイプ「GPIO-Standard」は高駆動強度をサポートしない一方、「GPIO-Standard Plus」、「GPIO-Medium」、「GPIO-Fast」は高駆動力をサポートしていると記載されています。 GPIOパッドタイプについては、S32K3XXRMに付属のExcel添付ファイルS32K344_S32K324_S32K314_IOMUX.xlsxのS32K344_IO信号テーブル、特に列Hを参照してください。 よろしくお願いします、 ロビン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「解決策として承認」ボタンをクリックしてください。ありがとう！ - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: High Drive Strength on S32K3 前の投稿者にも言いましたが、どのピンが「高い駆動強度」をサポートしているかは分かっていますが、それが問題ではありません! しかし幸いなことに、背景には関連する情報が詰まっていました。S32K3xx.pdf には、表27。GPIOのDC電気仕様には、私が求めているものが含まれているようです。 これは、ピンの出力電流を2倍にして、「DSE = 0」と「DSE = 1」を切り替えるようにしているようです。

High Drive Strength on S32K3 The S32K3XX reference manual talks about the "drive-strength enable" bits, but doesn't appear to define what this means - the closest reference I can find is that it seems correlated with maximum frequency supported by certain pins (page 42 of the S32K3XXRM/Section 4.4.1) Is there something explicit in terms of maximum current draw or other things I should be aware of for why I should or should not enable "drive-strength"? Re: High Drive Strength on S32K3 GPIO-Standard: Switching up to 10 MHz High drive-strength not supported. Slew-rate control not supported. — GPIO-Standard plus: Switching up to 25 MHz  Supports high drive-strength. Slew-rate control not supported. — GPIO-Medium: Switching up to 50 MHz  Supports high drive-strength. Supports slew-rate control. — GPIO-Fast: Switching up to 120 MHz Supports high drive-strength. Supports slew-rate control. Re: High Drive Strength on S32K3 Yes, that is exactly the text of the section I cited in my question. That doesn't tell me why I should or shouldn't enable "drive strength" - it just tells me that some pins support it, and that some switching rates are related to it. If I were driving an LED with it, would it be capable of sinking more current? How much more current? Is it purely a slew-rate change? Is there a reason not to enable it, if the pin supports it? Will my chip dissipate more heat if I enable it? Re: High Drive Strength on S32K3 Hardware Design Guidelines for S32K39x, S32K37x and S32K36x Microcontrollers Re: High Drive Strength on S32K3 Hi The S32K3XX Reference Manual (S32K3XXRM) states that the Pad Type "GPIO-Standard" does not support high drive strength, whereas "GPIO-Standard Plus", "GPIO-Medium", and "GPIO-Fast" support high drive strength. For GPIO Pad Type, please refer to the S32K344_IO Signal Table, specifically column H, in the Excel attachment S32K344_S32K324_S32K314_IOMUX.xlsx provided with the S32K3XXRM. Best Regards, Robin ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "ACCEPT AS SOLUTION" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: High Drive Strength on S32K3 As I told the previous poster, I know which pins do and do not support "high drive strength," that is not the issue! But fortunately, in the background you had the relevant chunk of information: in S32K3xx.pdf, Table 27. GPIO DC electrical specifications, appears to have what I need. It looks like it doubles the output current of the pins to enable the "DSE = 0" vs "DSE = 1"  

S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hi We are working on Secure Debug authentication for the S32N55 platform and have successfully implemented FSS domain debug authorization using ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID) via SDC-600. We are now trying to extend this to the CRS domain (HSE_DEBUG_DOMAIN_APP = 0x1B) and have the following questions: --- [Q1] Is ADKP usable for CRS domain Secure Debug authentication? After provisioning ADKP via HSE_OTP_FOEM_ADKP_ATTR_ID, is it possible to use the same ADKP for CRS domain (APP) Secure Debug authentication via HSE_DEBUG_CMD_APP_CHALLENGE? --- [Q2] Does SetOwnerDebugKeyMap() need to be called separately per MU (FSS MU vs CRS MU)? Per the RM description of hseOwnerDebugKeyMapConfig_t: "This service is called for each installed device owner individually from an owning MU. HSE FW assumes the owner identity based on the MU this service request is sent to." Our current implementation calls SetOwnerDebugKeyMap() (HSE_SRV_ID_DEBUG_KEY_MAPPING) only through FSS MU (MU0), mapping aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP. - Is a separate SetOwnerDebugKeyMap() call required through the CRS MU for CRS domain authentication? - If so, which MU number should be used for the CRS domain on S32N55? --- [Q3] Does SetOwnerDebugKeyMap() need to be called on every boot? The RM states: "Only the numOfAuthorizationRefEntries and numOfAuthenticationRefEntries are logged, rest of the entries are ignored." This implies the key mapping is volatile and not stored in NVM. Does this mean SetOwnerDebugKeyMap() must be called on every boot (after SU rights are granted) for both FSS and CRS domains? --- [Q4] Correct keyRef value for APP_CHALLENGE In hseDebugAuthorizeStartCmd_t, the keyRef field references the index mapped via hseOwnerDebugKeyMapConfig_t. Since we map aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP, we send keyRef = 0x00 for CRS domain authentication. Is this correct? --- [Q5] Response size and packet structure for APP_CHALLENGE Per hseDebugAuthorizeProofProvCmd_t byte map, the packet structure is always 32 bytes (2 packets x 8 words). HSE_CR_APP_RESPONSE_SIZE = 16U vs HSE_CR_FSS_OR_HSE_RESPONSE_SIZE = 32U. For APP_CHALLENGE, should the host send: - 16 bytes of AES-encrypted response + 16 bytes of zero padding = 32 bytes total? - Or only 16 bytes? Currently, after sending FLAG_START + DebugSignalMap(4 bytes) + Response(16 bytes) + FLAG_END, HSE2 does not respond and T32 hangs waiting indefinitely. When we send 32 bytes (16-byte response + 16-byte zero padding), we observe the same hang. --- For reference: - Sherpa_Cdd_AllocateChannel() always allocates MU0 (FSS) - SetOwnerDebugKeyMap(): aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP (0x00000302), called with SU rights - crs_auth.cmm: DEBUG_TARGET=0x1B, OID=0xFF*16, keyRef=0x00 - AUTH_MODE_REQ passes successfully (HSE_DEBUG_WAITING_RESPONSE_TO_CHG received) - Challenge received: 32 bytes - After sending Response, no ACK (0x4A4A4A4A) received from HSE2 Please see the attached CMM script and log for reference. Thank you in advance. Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, Thank you for your suggestion. As requested, I have created a new post to track the CRS (APP domain) Secure Debug authentication issue: [S32N55 HSE2 — CRS (APP Domain) Secure Debug Authentication via hseDebugCardCmd_t] (Please search the title above in NXP Community) This issue is currently blocking our customer delivery schedule. Could you please review the new post at your earliest convenience? The CMM script (crs_auth.cmm) and log file are attached in the new post. Thank you very much for your urgent support. Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, Thank you for your response.  We have additional questions regarding hseDebugCardCmd_t implementation for CRS (APP) domain Secure Debug authentication on S32N55. --- [Q1] Is the Owner ID (ownerId) in hseDebugCardInfo_t the same value as provisioned via hseOwnerDebugKeyMapConfig_t? Our device is configured in single-owner scenario where Fss_Firmware_au8Oid[] = {0xFF * 16}. Should the ownerId field in hseDebugCardCmd_t also be set to 0xFF * 16? Or does it need to match a specific value provisioned during Device Owner installation? --- [Q2] Does hseDebugCardCmd_t need to be sent after APP_CHALLENGE, or instead of hseDebugAuthorizeProofProvCmd_t? Per RM: "For APP based options, debug signals are enabled and authorized only through the debug cards authentication (see hseDebugCardCmd_t)(field is ignored)." Our current flow: 1. AUTH_MODE_REQ (DEBUG_TARGET=0x1B) 2. rx_authmode → HSE_DEBUG_WAITING_RESPONSE_TO_CHG received 3. APP_CHALLENGE → rx_challenge (32 bytes received) 4. hseDebugCardCmd_t sent directly (skipping hseDebugAuthorizeProofProvCmd_t) 5. HSE2 stops responding (T32 hangs at FLAG_END of CARD_REQUEST) Should hseDebugAuthorizeProofProvCmd_t (appChallengeAuth = AES256-CMAC) be sent BEFORE hseDebugCardCmd_t? Or should hseDebugCardCmd_t be sent directly after rx_challenge without ProofProv? --- [Q3] What is the correct Authentication Tag (authTag) computation for hseDebugCardTag_t when using MAC scheme? We are using: authScheme.macScheme.macAlgo = HSE_MAC_ALGO_CMAC (0x11) authTag = AES256-CMAC(key=ADKP, data=Challenge[32 bytes]) authLen = 16 Is this the correct computation? Or should the CMAC input include additional fields (OID, domain map, etc.)? --- [Q4] What is the correct packet structure for hseDebugCardCmd_t? Based on the RM byte map, our current implementation: Packet 1 (32 bytes): KRI(4B) + CMD(4B=0x5DCDEB77) + OID(16B=0xFF*16) + AuthScheme(8B=CMAC) Packet 2 (32 bytes): enabledDebugDomainMap(bit27=0x08000000) + padding(28B) Packet 3: debugDomainMapping(4B) + numOfAllowedUids(2B) + reserved(2B) + authLen(2B) + reserved(2B) + authTag(256B) Is this structure correct? HSE2 stops responding after receiving the OID field (0xFF bytes). --- Could you please let me know your email?  I will send you cmm file for crs auth. BRs. Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, @EddiePark  Thanks for your post. Pleased to hear that the Secure Debug authentication for the S32N55 platform have successfully implemented FSS domain debug authorization using ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID) via SDC-600. I will continue to help check with the details for your new issues, sorry that I did not see the attached CMM script and log for reference, would you mind uploading them again to share with us? BR Chenyin Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, @EddiePark  Thanks for your reply. There are already 6 questions existed in this post, and may take a relative long time to investigate, in order for improving the efficiency,  for additional questions, I suggest creating a new post to track. And as you mentioned, there would be scripts/logs attached for checking, but I do not see in your post, may I know if they would be uploaded again? BR Chenyin Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, @EddiePark  Thanks for your reply. 1. As always, we will try our best to support your queries. 2. I understand it is a urgence issue, but as what I had mentioned in previous support, S32N55 is still in pre-production phase, it is not yet supported via the community channel, (during this period, we suggest directly contacting your FAE/Distributor to accelerate the efficiency)so it would take relative long time to reply, furthermore, the secure debug with LC advanced is usually at a relatively late stage of development, the document/samples are still limited in recent term. Sorry for your inconvenience. BR Chenyin Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, @EddiePark  Thanks for your patience, below are some initial comments for your reference [Q1] Is ADKP usable for CRS domain Secure Debug authentication? [Comments]: Yes, the used key for App domain secure debug authentication is selected from the hseOwnerDebugKeyMapConfig_t->pOwnerCardAuthenticationRef, it could includes the ADKP 's keyhandle. [Q2] Does SetOwnerDebugKeyMap() need to be called separately per MU (FSS MU vs CRS MU)? [Comments]: SetOwnerDebugKeyMap() should bound to the Device owner , not MU. The Device owner could includes multiple cohorts which has multiple MU instances. If FSS and CRS are included in the same device owner, it could be called by the CRS MU or FSS MU. [Q3] Does SetOwnerDebugKeyMap() need to be called on every boot? [Comments]:  It should not be called on every boot, the configuration should be saved in the SYS-IMG or fuse, otherwise the secure debug will fail after repowering the device, it does not meet the design expectation of secure debug. However not sure where to store this configuration from the current available resource. [Q4] Correct keyRef value for APP_CHALLENGE In hseDebugAuthorizeStartCmd_t, the keyRef field references the index mapped via hseOwnerDebugKeyMapConfig_t. Since we map aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP, we send keyRef = 0x00 for CRS domain authentication. Is this correct? [Comments]: Yes, if  ADKP handle is the first entry of OwnerCardAuthenticationRef and the user wants to use ADKP to authenticate CRD debug, the authKeyRef  should be 0(The index of ADKP handle entry) [Q5] Response size and packet structure for APP_CHALLENGE [Comments]: For App debug, besides the debug signal map and challenge response data fileds, the other unused data  in packet 1 can be filled with 0. Since the corresponding documents are not yet updated fully for this topic(the S32N55 is still at early stage), there is limited information we would provide. Sorry for your inconvenience. BR Chenyin  Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, Thank you again for your continued support. We fully understand that S32N55 is still in the pre-production phase and that documentation/resources for this topic are currently limited. We sincerely apologize for the additional questions, but as our customer delivery schedule is approaching and this is a critical blocker, we are compelled to ask for a bit more guidance. We have applied your previous comments (Q1-Q5): keyRef=0x00, ADKP in pOwnerCardAuthenticationRef, and Packet 1 filled to 32 bytes (debugSignalMap 4B + appChallengeAuth 16B + unused 12B = 0). However, we are still blocked at the ProofProv / CARD_REQUEST stage. Our current status: 1. AUTH_MODE_REQ (DEBUG_TARGET=0x1B) -> OK (HSE2 returns 0x4A4A4A4A) 2. APP_CHALLENGE -> OK (32-byte Challenge received) 3. ProofProv (hseDebugAuthorizeProofProvCmd_t): - Packet 1 = debugSignalMap(4B=0) + appChallengeAuth(16B AES256-CMAC) + unused(12B=0) - All 32 bytes transmitted successfully over SDC-600 - >>> HSE2 gives NO response after this <<< The SDC-600 TX appears to stall shortly after ~20 bytes and HSE2 never sends any response frame. Could you please clarify the following about the APP (CRS) domain authentication sequence: [Q1] After the host sends ProofProv (hseDebugAuthorizeProofProvCmd_t with appChallengeAuth) for APP_CHALLENGE, does HSE2 send an intermediate response frame back to the host? Or does HSE2 remain silent and wait for the next command? For reference, in the FSS domain, after ProofProv the HSE2 returns 0x4A4A4A4A. We observe NO such response in APP domain. Is this expected? [Q2] What is the correct ordering between ProofProv (hseDebugAuthorizeProofProvCmd_t) and CARD_REQUEST (hseDebugCardCmd_t) for APP_CHALLENGE? - Option A: APP_CHALLENGE -> ProofProv -> (HSE2 response?) -> CARD_REQUEST - Option B: APP_CHALLENGE -> CARD_REQUEST directly (ProofProv skipped for APP) - Option C: some other sequence Since RM states debugSignalMap is 'ignored' for APP and authorization happens 'only through the debug card authentication', should ProofProv be sent at all for APP domain, or should we go directly to CARD_REQUEST after the challenge? [Q3] Could you please provide the complete command sequence for APP (CRS) domain Secure Debug authentication from COMM_START to the final authorization response? We would like to confirm the exact order and which commands expect a response from HSE2, specifically: COMM_START -> AUTH_MODE_REQ -> APP_CHALLENGE -> [ProofProv?] -> [CARD_REQUEST?] -> [final response?] Any reference flow or example for the APP/CRS domain would be extremely helpful, as the current behavior (HSE2 silent after ProofProv) does not match the FSS domain flow. Thank you very much for your understanding and support. Best regards, Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello,   Thanks for your reply, I understand, and will always. try our best to support. 1. I have downloaded the cmm and auth files you shared from the other post S32N55 HSE2 CRS domain authentication does not complete, are they still the same one currently used? 2. For your questions listed later: [Q1] Is the Owner ID (ownerId) in hseDebugCardInfo_t the same value as provisioned via hseOwnerDebugKeyMapConfig_t? [Comments]: Yes, the OID of hseDebugCardInfo_t is just the ownerid of Device Owner installation service. [Q2] Does hseDebugCardCmd_t need to be sent after APP_CHALLENGE, or instead of hseDebugAuthorizeProofProvCmd_t? [Comments]: hseDebugAuthorizeProofProvCmd_t should be sent before sending CARD_REQUEST [Q3] What is the correct Authentication Tag (authTag) computation for hseDebugCardTag_t when using MAC scheme? [Comments]:  Sorry that no obvious description about this in API RM. But the authentication tag for App domain may not use the received challenge, the challenge is used for hseDebugAuthorizeProofProvCmd_t. For user's CRS domain debug, maybe it is authTag = AES256-CMAC(key=ADKP, data=hseDebugCardInfo_t). You may have a try. [Q4] What is the correct packet structure for hseDebugCardCmd_t? [Comments]:  The structure of hseDebugCardCmd_t could be referred to the comment in HSE FW API interface which is more clear than the description in HSE FW API RM. by checking your original script shared, we found some errors about hseDebugCardCmd_t structure, see the attached word. For any other files that you may not be conveniently shared within the post, you may send them to me via the private message BR Chenyin

适用于 ARM 2.2 的 S32 Design Studio — 许可证激活错误（cllReason errorNo=27：最大回复次数） 你好 我在使用适用于 ARM v2.2 的 S32 Design Studio 时遇到了许可证激活问题，我无法再使用这个工具了。 产品：适用于 ARM 的 S32 设计工作室 版本：2.2 操作系统：Windows 10（64 位） 许可证类型：节点锁定（激活码） 激活代码3668-673A-125A-5626 当我启动 S32DS 时，会显示 "产品许可证 "窗口： 状态：许可证丢失 如果我点击 "激活 "并输入激活代码，就会立即出现以下错误： CLLReason [errorNo=27, errorString=向远程激活服务器发送返回请求和处理响应时出错。退货数量已达到上限，如需帮助，请联系产品供应商。(FNP 错误 0），flxActMajorErrNo=0，flxActMinorErrNo=0，flxActSysErrNo=0，flxCommErrNo=0] （FNP 错误 0），flxActMajorErrNo=0，flxActMinorErrNo=0。 据我所知，这意味着已达到该激活码的最大返回/移动次数。 过去我曾多次重新安装 S32DS 和/或 Windows，因此许可证可能已被退回/激活多次。 我已经试过了： 以管理员身份运行 S32DS 检查我的互联网连接和防火墙/代理设置 同时使用在线激活和 "生成离线申请 "选项 问题依然存在，我无法再激活产品。 你能否 RESET 这个激活码的返回计数器或者发一个新的激活码，这样我就可以在我当前的电脑上激活适用于 Arm 2.2 的 S32 Design Studio 了？ 如有需要，我可以提供任何其他信息（日志文件、屏幕截图等）。 提前感谢您的帮助。 顺祝商祺！ jongyoub baik. Re: S32 Design Studio for ARM 2.2 – License activation error (CLLReason errorNo=27: maximum number o 你好、 您应该可以使用旧代码再次激活 S32DS。 Re: S32 Design Studio for ARM 2.2 – License activation error (CLLReason errorNo=27: maximum number o 我也遇到了同样的问题，但我一直找不到解决办法。

S32K358 MCUのスリープおよびウェイクアップドライバの構成 こんにちは、 私は S32K358 を使っており、GPIO を使用したスリープおよびウェイクアップ機能 を実証する S32K3XX 低パワーマネージメント の例を参照しました。しかし、期待通りに動作させることはできませんでした。 設定または実装に問題があるのではないかと考えています。私の設定とソース ファイルを確認して、正しいかどうか、または変更が必要かどうかをお知らせいただければ幸いです。 何度か試してみましたが、まだ希望通りの結果が得られませんでした、SOご指導をお願いしたいです。 ご検討のために、設定ファイルとソース ファイルを添付しましたのでご確認ください。 IDE: S32DS 3.5.14 ソフトウェアバージョン: 4.0 ハードウェア: S32K358 よろしくお願いします、 カルメガン C Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU こんにちは@karmegancjkさん、 ウェイクアップが検出され、S32K358 がリセット シーケンスに入ると、RAM の内容は揮発性ですか、それとも不揮発性ですか? 32KB の SRAM コンテンツは不揮発性です。つまり、スタンバイ時にも 32KB の SRAM に電力が供給されます。   RAM の内容を不揮発性にする必要がある場合、スタンバイ RAM メモリを作成し、RAM データをスタンバイ RAM メモリにコピーするにはどうすればよいでしょうか? スタンバイ RAM を使用するには、リンカー ファイルを変更し、個別の 32 KB を割り当て、スタンバイ セクションを配置し、リンカー アドレス シンボルを調整する必要があります。前回のリセットが POR だった場合は、スタンバイ RAM の ECC も初期化する必要があります。 スタンバイ RAM の使用方法と、一般的な低電力化に関するプレゼンテーションをプライベート メッセージで送信しました。 S32K358 Cortex-M7 のスタンバイ モードは、スリープ モードやディープ スリープ モードに似ていますか? はい、スタンバイ モードはディープ スリープに似ています。 よろしくお願いします、 ジュリアン Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU こんにちは、ジュリアン GPIO 経由の S32K358 スリープおよびウェイクアップ機能が動作しています。立ち上がりエッジが検出されると、コントローラは、前述のとおり、リセット シーケンスを使用してリセットします。さて、いくつか疑問があります。 ウェイクアップが検出され、S32K358 がリセット シーケンスに入ると、RAM の内容は揮発性ですか、それとも不揮発性ですか? RAM の内容を不揮発性にする必要がある場合、スタンバイ RAM メモリを作成し、RAM データをスタンバイ RAM メモリにコピーするにはどうすればよいでしょうか? S32K358 Cortex-M7 のスタンバイ モードは、スリープ モードやディープ スリープ モードに似ていますか? Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU こんにちは@karmegancjkさん、 STANDBY モードに入るときは、ウェイクアップ チャネル 46 (PTC24) を使用しています。私の理解では、このピンで立ち上がりエッジが検出されると、ウェイクアップ割り込みがトリガーされるはずです。 外部ウェイクアップ信号は、上昇検出と下降検出の両方をサポートします。 プログラム カウンターはアドレス 0x00402000 から実行を再開しますか? または、実行を再開するには完全な MCU リセットが必要ですか? 以前のデバイス (S32K1) では、WFI 命令の後にコード実行が再開され、 Wakeup ISR → WFI 後のコードを意味していましたが、 S32K3 ではウェイクアップ後に常にリセット シーケンスを実行します。これは、設定されたスタンバイ モードによって異なります。 たとえば、通常のスタンバイ終了ではリセット シーケンスが実行され、次に sBAF と HSE FW (インストールされている場合) が初期化され、次に reset_handler で実行が再開されます。 ただし、高速スタンバイ終了では、sBAF と HSE の初期化をスキップし、ユーザー定義のブート アドレスに直接ジャンプできます。このユーザー定義のブート アドレスの後、デバイスを完全に初期化するために完全なリセットを実行することをお勧めします (または、アプリケーションのニーズに応じて、再びスタンバイ状態に戻ることもできます)。 プロジェクトの構成に関しては、すべて問題ないようです。 よろしくお願いします、 ジュリアン Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU こんにちは、 スタンバイ モード (スリープ モードまたはディープ スリープ モード) に入るときの MCU の動作に関して疑問があります。このモード中、プログラム カウンターはフリーズし、ウェイクアップ後にベクター アドレス 0x00402000 から再開されますか、それとも中断したところから実行を再開しますか? 電源とウェイクアップドライバの設定（.cfgファイル内）を確認してください。ファイル）は正しいですか？参考までに、私のプロジェクトの設定ファイルを添付しました。 Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU こんにちは、ジュリアン S32K358 MCU をベースにしたカスタム ハードウェアを使用しています。スタンバイモードでのウェイクアップ機能に関して質問があります。 STANDBY モードに入るときは、ウェイクアップ チャネル 46 (PTC24) を使用しています。私の理解では、このピンで立ち上がりエッジが検出されると、ウェイクアップ割り込みがトリガーされるはずです。 しかし、ウェイクアップイベント情報後に何が起こるかはわかりません。具体的には： プログラム カウンターはアドレス 0x00402000 から実行を再開しますか? または、実行を再開するには完全な MCU リセットが必要ですか? また、ウェイクアップ構成に割り込み制御 API を使用しなかったSO、ウェイクアップ割り込みが適切に処理されるかどうか、またはリセットが必要かどうかはわかりません。 このCASEのウェイクアッププロセスがどのように機能するか、また予想されるプログラムフローはどのようなものかを明確にしていただけますか? どうぞよろしくお願いいたします。 よろしくお願いします、 カルメガン C Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU こんにちは@karmegancjkさん、 S32K3X8EVB を使用していますか、それともカスタム ハードウェアですか? S32K358 には、PMIC ハンドシェイクによるスタンバイ終了のための追加ステップがあることに留意してください。ハンドシェイクを使用しない場合は、DCMRWF1 の PMIC_PGOOD_HNDSHK_BYP ビットを設定します:解決済み: S32K3: ウェイクアップおよびリセット動作に関するサポートの要求 - NXP コミュニティ。 また、どの GPIO を設定していますか?S32K3 リファレンス マニュアルに添付されている S32K358_IOMUX.xlsx ファイルで WKPU 信号が正しいかどうかを確認してください。 よろしくお願いします、 ジュリアン Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU こんにちは 、@karmegancjk。 現在、睡眠と起床シーケンスの作業も行っています。参考にできる作業中のコードを教えてもらえますか?もし教えていただけると助かります。

S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections Hello, I am developing an application on the following platform: MCU: NXP S32K314 RTD 7.0.0 (AUTOSAR MCAL) FreeRTOS 7.0.0 S32 Design Studio 3.6.4 During development, I encountered a deadlock related to high-priority interrupts and would like to ask whether my understanding is correct and whether there is a recommended solution. Background FreeRTOS specifies that ISRs with a priority higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY must not call FreeRTOS APIs. However, I found that many RTD MCAL APIs internally execute FreeRTOS critical section APIs through the following call chain: MCAL API ↓ SchM_Enter_xxx() ↓ OsIf_SuspendAllInterrupts() ↓ SuspendAllInterrupts() ↓ OsIf_Interrupts_SuspendAllInterrupts() ↓ taskENTER_CRITICAL_FROM_ISR() and MCAL API ↓ SchM_Exit_xxx() ↓ OsIf_ResumeAllInterrupts() ↓ ResumeAllInterrupts() ↓ OsIf_Interrupts_ResumeAllInterrupts() ↓ taskEXIT_CRITICAL_FROM_ISR() This behavior exists even in APIs that only perform simple peripheral register accesses, such as DIO and GPT. Problem When a MCAL API is called from a high-priority ISR (priority higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY), the internal call to taskENTER_CRITICAL_FROM_ISR() causes the FreeRTOS interrupt masking state to become inconsistent. As a result, after taskEXIT_CRITICAL_FROM_ISR() returns, BASEPRI is not restored correctly, causing lower-priority interrupts such as SysTick and PendSV to remain masked. The scheduler eventually stops because xPortSysTickHandler() is no longer executed. I was able to reproduce this issue using APIs such as: Dio_FlipChannel() GPT (PIT) interrupt processing Other MCAL APIs that use SchM exclusive areas Current Workaround To avoid modifying RTD-generated source code directly, I used the GNU linker --wrap option to wrap the following functions: OsIf_Interrupts_SuspendAllInterrupts() OsIf_Interrupts_ResumeAllInterrupts() The wrapper checks the current interrupt priority. Please refer to the attached WrapperExample.c. If the current ISR priority is higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY, it skips the original function. Otherwise, it calls the original implementation. This workaround appears to resolve the deadlock while leaving the generated RTD source unchanged. Questions Is this behavior expected by design in the RTD MCAL? Is it recommended to call DIO, GPT, CAN, or other MCAL APIs from high-priority ISRs? Does NXP recommend implementing dedicated drivers (Complex Device Drivers) for high-priority real-time functions such as watchdog servicing or GPIO toggling? Is wrapping OsIf_Interrupts_SuspendAllInterrupts() and OsIf_Interrupts_ResumeAllInterrupts() using the GNU linker --wrap option an acceptable workaround? Is there an official or recommended solution for this problem that does not require modifying generated RTD source code? Any advice or recommendations would be greatly appreciated. Thank you. Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections Hello @tobara, The case is currently pending input from the RTD development team. BR, Daniel Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections Hi, please see below punctual answers to your question: Is this behavior expected by design in the RTD MCAL?Answer: yes, this happens because you are calling OS APIs from a CAT1 interrupt (aka interrupts with prio higher than MAX SYSCALL).  The purse of interrupts higher than MAX_SYSCALL is to do work with minimal latency also unhindered by the RTOS.If you need to avoid latency introduced by RTOS then you should not call APIs that in the end use the RTOS. Is it recommended to call DIO, GPT, CAN, or other MCAL APIs from high-priority ISRs? Answer:  no, not larger than MAX_SYSCAL, for the reason mentioned in first answer. Does NXP recommend implementing dedicated drivers (Complex Device Drivers) for high-priority real-time functions such as watchdog servicing or GPIO toggling? Answer: if you already can tolerate the latency introduced by the RTD SchM, OSIf APIs, RTOS then you can just use the existing drivers but just call them from the higher interrupt but lower than MAX_SYSCALL. You still get the priority boost but not the problems described in the ticket. Is wrapping OsIf_Interrupts_SuspendAllInterrupts() and OsIf_Interrupts_ResumeAllInterrupts() using the GNU linker --wrap option an acceptable workaround? Answer: No, a quick analysis points in the direction that this workaround protects in only one direction. It might avoid the deadlock but does not protect lower prio ISR that share registers / resources with higher prio ISR (> MAX_SYSCALL). This implementation can introduce race conditions on shared registers and global variables. Is there an official or recommended solution for this problem that does not require modifying generated RTD source code?Answer (but it needs to be confirmed by the RTD team): do not call RTD / RTOS APIs from IRQ > MAX_SYSCALL. If you can tolerate the current RTD->OSIF->RTOS latencies then just use a  higher prio IRQ but lower than MAX_SYSCALL. All answers need to be confirmed by the RTD team, I'm answering from a RTOS point of view. Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections Thank you very much for your detailed explanation. I now understand the following design constraints of the NXP RTD/MCAL: RTD/MCAL APIs must not be called from high-priority ISRs (interrupts with a priority higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY). Although using --wrap may prevent the deadlock, bypassing the RTD critical sections can introduce race conditions when resources or registers are shared between high- and low-priority contexts. I have a few additional questions. If an application requires processing in a high-priority ISR (AUTOSAR Category 1 ISR), what is the recommended software architecture? Should such functionality always be implemented as a Complex Device Driver (CDD) or a dedicated low-level driver? If a GPIO port or timer channel is exclusively owned by a single high-priority ISR and is never accessed from any other task or ISR, would the concerns about race conditions still apply to the --wrap workaround? Is it correct to understand that the current RTD/MCAL does not provide a supported way to use its APIs from high-priority ISRs, and therefore high real-time functions must be implemented using a CDD or a dedicated driver? From my experience with embedded software outside the automotive domain, hardware abstraction layers are often designed to be independent of the operating system. Therefore, I was surprised to find that simple GPIO and timer APIs internally invoke RTOS critical section APIs. As a reference, I have attached the GPT driver that I implemented to avoid this issue (CpuPit.h/c). I would appreciate any comments or suggestions from the RTD team. Thank you again for your support.

S32K314 RTD (MCAL) - 由 OsIf 临界区引起的高优先级 ISR 死锁 S32K314 RTD (MCAL) - 由 OsIf 临界区引起的高优先级 ISR 死锁 你好， 我正在以下平台上开发一个应用程序： MCU：NXP S32K314 RTD 7.0.0（AUTOSAR MCAL） FreeRTOS 7.0.0 S32 设计工作室 3.6.4 在开发过程中，我遇到了与高优先级中断相关的死锁，想请教一下我的理解是否正确，以及是否有推荐的解决方案。 背景信息 FreeRTOS 规定优先级高于 configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 的中断服务例程 (ISR) 不得调用 FreeRTOS API。 然而，我发现许多 RTD MCAL API 在内部通过以下调用链执行 FreeRTOS 临界区 API： MCAL API ↓ SchM_Enter_xxx() ↓ OsIf_SuspendAllInterrupts() ↓ SuspendAllInterrupts() ↓ OsIf_Interrupts_SuspendAllInterrupts() ↓ taskENTER_CRITICAL_FROM_ISR() 以及 MCAL API ↓ SchM_Exit_xxx() ↓ OsIf_ResumeAllInterrupts() ↓ ResumeAllInterrupts() ↓ OsIf_Interrupts_ResumeAllInterrupts() ↓ taskEXIT_CRITICAL_FROM_ISR() 即使在仅执行简单外设寄存器访问的 API（例如 DIO 和 GPT）中，也存在这种行为。 问题 当从高优先级 ISR（优先级高于 configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY）调用 MCAL API 时，对 taskENTER_CRITICAL_FROM_ISR() 的内部调用会导致 FreeRTOS 中断屏蔽状态变得不一致。 因此，在 taskEXIT_CRITICAL_FROM_ISR() 返回后，BASEPRI 无法正确恢复，导致 SysTick 和 PendSV 等低优先级中断保持屏蔽状态。 调度程序最终停止，因为 xPortSysTickHandler() 不再执行。 我使用以下 API 重现了这个问题： Dio_FlipChannel() GPT（PIT）中断处理 其他使用 SchM 专属区域的 MCAL API 当前解决方法 为了避免直接修改 RTD 生成的源代码，我使用了 GNU 链接器的 --wrap 选项来包装以下函数： OsIf_Interrupts_SuspendAllInterrupts() OsIf_Interrupts_ResumeAllInterrupts() 该包装器会检查当前的中断优先级。 请参考附件WrapperExample.c 。 如果当前 ISR 优先级高于 configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY，则跳过原始函数。 否则，它将调用原始实现。 这种变通方法似乎可以解决死锁问题，同时保持生成的 RTD 源不变。 问题 RTD MCAL 的这种行为是设计预期的吗？ 是否建议从高优先级 ISR 调用 DIO、GPT、CAN 或其他 MCAL API？ NXP 是否建议为看门狗服务或 GPIO 切换等高优先级实时功能实现专用驱动程序（复杂设备驱动程序）？ 使用 GNU 链接器的 --wrap 选项包装 OsIf_Interrupts_SuspendAllInterrupts() 和 OsIf_Interrupts_ResumeAllInterrupts() 是否是一种可接受的解决方法？ 是否有官方或推荐的解决方案来解决此问题，而无需修改生成的 RTD 源代码？ 任何建议或推荐都将不胜感激。 谢谢！ Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections 你好@tobara ， 目前该案件正在等待RTD开发团队的意见。 BR，丹尼尔 Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections 您好， 以下是对您问题的及时解答： RTD MCAL 的这种行为是预期行为吗？答：是的，这是因为您正在从 CAT1 中断（即优先级高于 MAX SYSCALL 的中断）调用操作系统 API。大于 MAX_SYSCALL 的中断次数是为了以最小的延迟完成工作，并且不受 RTOS 的干扰。如果您需要避免 RTOS 引入的延迟，则不应该调用最终会使用 RTOS 的 API。 是否建议从高优先级 ISR 调用 DIO、GPT、CAN 或其他 MCAL API？ 答：不，不能大于 MAX_SYSCAL，原因已在第一个答案中提及。 NXP 是否建议为看门狗服务或 GPIO 切换等高优先级实时功能实现专用驱动程序（复杂设备驱动程序）？ 回答： 如果您已经能够容忍 RTD SchM、OSIf API、RTOS 引入的延迟，那么您可以直接使用现有的驱动程序，但只需从高于 MAX_SYSCALL 的中断调用它们即可。您仍然可以获得优先级提升，但不会遇到工单中描述的问题。 使用 GNU 链接器的 --wrap 选项包装 OsIf_Interrupts_SuspendAllInterrupts() 和 OsIf_Interrupts_ResumeAllInterrupts() 是否是一种可接受的解决方法？ 答：不，简单的分析表明，这种变通方法只能在一个方向上起到保护作用。它或许可以避免死锁，但不能保护与优先级更高的 ISR (> MAX_SYSCALL) 共享寄存器/资源的优先级较低的 ISR。这种实现方式可能会在共享寄存器和全局变量上引入竞争条件。 是否有官方或推荐的解决方案来解决此问题，而无需修改生成的 RTD 源代码？答案（但需要 RTD 团队确认） ：不要从 IRQ > MAX_SYSCALL 调用 RTD / RTOS API。如果您可以容忍当前的 RTD->OSIF->RTOS 延迟，那么只需使用优先级更高的 IRQ，但低于 MAX_SYSCALL 即可。 所有答案都需要RTD团队确认，我是从RTOS的角度回答的。 Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections 非常感谢您的详细解释。 我现在理解了NXP RTD/MCAL的以下设计限制： 不得从高优先级 ISR（优先级高于configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY的中断）调用 RTD/MCAL API。 虽然使用--wrap可以防止死锁，但绕过 RTD 临界区可能会在高优先级和低优先级上下文之间共享资源或寄存器时引入竞争条件。 我还有几个问题。 如果应用程序需要在高优先级 ISR（AUTOSAR 1 类 ISR）中进行处理，推荐的软件架构是什么？此类功能是否应该始终以复杂设备驱动程序 (CDD) 或专用底层驱动程序的形式实现？ 如果一个 GPIO 端口或定时器通道被一个高优先级 ISR 独占，并且从未被任何其他任务或 ISR 访问，那么对于--wrap解决方法，竞争条件的问题是否仍然适用？ 目前的 RTD/MCAL 不支持从高优先级 ISR 中使用其 API，因此必须使用 CDD 或专用驱动程序来实现高实时性功能，这种理解是否正确？ 根据我在汽车领域之外的嵌入式软件开发经验，硬件抽象层通常被设计成独立于操作系统。因此，我惊讶地发现，简单的 GPIO 和定时器 API 在内部调用了 RTOS 临界区 API。 作为参考，我附上了我为避免此问题而实现的 GPT 驱动程序（CpuPit.h/c）。 我非常感谢RTD团队的任何意见或建议。 再次感谢您的支持。

S32 Design Studio for ARM 2.2 – License activation error (CLLReason errorNo=27: maximum number of re Hello, I am having a license activation problem with S32 Design Studio for ARM v2.2 and I can no longer use the tool. Product: S32 Design Studio for ARM Version: 2.2 OS: Windows 10 (64-bit) License type: Node-locked (activation code) Activation Code: 3668-673A-125A-5626  When I start S32DS, the Product Licenses window shows: Status: License missing If I click Activate and enter my activation code, I immediately get the following error: CLLReason [errorNo=27, errorString=Error sending an return request to a remote activation server and processing the response. The maximum number of returns is reached, contact your product vendor if you need help. (FNP error 0), flxActMajorErrNo=0, flxActMinorErrNo=0, flxActSysErrNo=0, flxCommErrNo=0] From what I understand, this means that the maximum number of returns/moves for this activation code has been reached. In the past I have reinstalled S32DS and/or Windows several times, so the license might have been returned/activated many times. I have already tried: Running S32DS as Administrator Checking my internet connection and firewall/proxy settings Using both online activation and the “Generate offline request” option The problem is still the same and I cannot activate the product anymore. Could you please reset the return counter for this activation code or issue a new activation code so that I can activate S32 Design Studio for ARM 2.2 on my current PC? I can provide any additional information (log files, screenshots, etc.) if needed. Thank you in advance for your help. Best regards, jongyoub baik. Re: S32 Design Studio for ARM 2.2 – License activation error (CLLReason errorNo=27: maximum number o Hi,  you should be able activate S32DS again with your old code.  Re: S32 Design Studio for ARM 2.2 – License activation error (CLLReason errorNo=27: maximum number o I'm having this same issue and I can't seem to figure out how to fix it

S32K314 RTD (MCAL) - OsIf クリティカルセクションが原因で発生した高優先度 ISR デッドロック S32K314 RTD (MCAL) - OsIf クリティカルセクションが原因で発生した高優先度 ISR デッドロック こんにちは、 私は以下のプラットフォームでアプリケーションを開発しています: MCU:NXP S32K314 RTD 7.0.0(AUTOSAR・マカル) FreeRTOS 7.0.0 S32 Design Studio 3.6.4 開発中に、優先度の高い割り込みに関連するデッドロックに遭遇しました。私の理解が正しいかどうか、また推奨される解決策があるかどうかをお伺いしたいと思います。 バックグランド FreeRTOSでは、configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITYよりも高い優先度を持つISRは、FreeRTOS APIを呼び出してはならないと規定されています。 しかし、多くのRTD MCAL APIは、内部的に以下の呼び出しチェーンを通じてFreeRTOSのクリティカルセクションAPIを実行していることがわかりました。 MCAL API ↓ SchM_Enter_xxx() ↓ OsIf_SuspendAllInterrupts() ↓ SuspendAllInterrupts() ↓ OsIf_Interrupts_SuspendAllInterrupts() ↓ taskENTER_CRITICAL_FROM_ISR() そして、 MCAL API ↓ SchM_Exit_xxx() ↓ OsIf_ResumeAllInterrupts() ↓ ResumeAllInterrupts() ↓ OsIf_Interrupts_ResumeAllInterrupts() ↓ taskEXIT_CRITICAL_FROM_ISR() この挙動は、DIOやGPTのような単純なペリフェラルレジスタアクセスのみを行うAPIでも存在します。 問題 MCAL API が高優先度 ISR (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY より高い優先度) から呼び出されると、taskENTER_CRITICAL_FROM_ISR() の内部呼び出しによって FreeRTOS の割り込みマスキング状態が不整合になります。 その結果、taskEXIT_CRITICAL_FROM_ISR() が戻った後、BASEPRI が正しく復元されず、SysTick や PendSV などの優先度の低い割り込みがマスクされたままになります。 xPortSysTickHandler() が実行されなくなるため、スケジューラは最終的に停止します。 以下のようなAPIを使用して、この問題を再現することができました。 Dio_FlipChannel() GPT(PIT)割り込みプロセッシング SchMの排他領域を使用するその他のMCAL API 現在の回避策 RTDで生成されたソースコードを直接変更することを避けるため、GNUリンカーの--wrapオプションを使用して以下の関数をラップしました。 OsIf_Interrupts_SuspendAllInterrupts() OsIf_Interrupts_ResumeAllInterrupts() ラッパーは現在の割り込み優先度をチェックします。 添付のWrapperExample.cを参照してください。 現在のISRの優先度がconfigLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITYよりも高い場合、元の関数はスキップされます。 そうでない場合は、元の実装を呼び出します。 この回避策は、生成されたRTDソースを変更せずにデッドロックを解消するようです。 質問 この挙動はRTD MCALのデザイン上当然のことですか? 高優先度のISRからDIO、GPT、CAN、または他のMCAL APIを呼び出すのは推奨されますか? NXPは、ウォッチドッグサービスやGPIOトグルなどの高優先度リアルタイム機能に対して専用ドライバ(複雑デバイスドライバ)の実装を推奨していますか? GNUリンカーの--wrapオプションを使用してOsIf_Interrupts_SuspendAllInterrupts()とOsIf_Interrupts_ResumeAllInterrupts()をラップすることは、許容できる回避策でしょうか？ 生成されたRTDソースコードを変更する必要のない、この問題に対する公式または推奨される解決策はありますか？ 何かアドバイスやご提案があれば、大変ありがたく思います。 よろしくお願いします。 Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections こんにちは、 @tobara さん、 このケースは現在、RTD開発チームからの意見提出を待っています。 BR、ダニエル Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections こんにちは、 ご質問に対する回答は以下のとおりです。 この挙動はRTD MCALの設計上当然のことですか?回答:はい、これはCAT1割り込み(つまり優先度がMAX SYSCALLより高い割り込み)からOSのAPIを呼び出すために起こります。MAX_SYSCALL以上の割り込みの手当は、RTOSの影響を受けずに最小限のレイテンシで作業を行うためです。RTOSによって生じるレイテンシを避けたいなら、最終的にRTOSを使うAPIを呼び出すべきではありません。 高優先度のISRからDIO、GPT、CAN、または他のMCAL APIを呼び出すのは推奨されますか? 回答：いいえ、最初の回答で述べた理由により、MAX_SYSCALより大きくすることはできません。 NXPは、ウォッチドッグサービスやGPIOトグルなどの高優先度リアルタイム機能に対して専用ドライバ(複雑デバイスドライバ)の実装を推奨していますか? 回答: RTD SchM、OSIf API、RTOSによる遅延に耐えられるなら、既存のドライバーを使い、MAX_SYSCALLより低い割り込みから呼び出しすればいいです。優先度アップの効果は引き続き得られますが、チケットに記載されている問題は解消されません。 GNUリンカーの--wrapオプションを使用してOsIf_Interrupts_SuspendAllInterrupts()とOsIf_Interrupts_ResumeAllInterrupts()をラップすることは、許容できる回避策でしょうか？ 回答：いいえ、簡単な分析によると、この回避策は一方向のみを保護するものです。デッドロックは回避できるかもしれないが、優先度の高いISR（> MAX_SYSCALL）とレジスタ/リソースを共有する優先度の低いISRを保護するものではない。この実装は共有レジスタやグローバル変数に競合条件を導入することができます。 生成された RTD ソース コードを変更する必要のない、この問題に対する公式または推奨される解決策はありますか?回答 (ただし、RTD チームによる確認が必要です) : IRQ > MAX_SYSCALL から RTD / RTOS API を呼び出さないでください。現在のRTD->OSIF->RTOSのレイテンシに耐えられるなら、優先度の高いIRQをMAX_SYSCALLより低く設定すればいいです。 すべての回答はRTDチームによる確認が必要です。私はRTOSの観点から回答しています。 Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections 詳細なご説明をありがとうございました。 私は今、NXP RTD/MCALの以下の設計制約を理解しました。 RTD/MCAL API は、優先度の高い ISR ( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITYよりも優先度の高い割り込み) から呼び出してはなりません。 --wrapを使う ことでデッドロックを防ぐことはできますが、RTDクリティカルセクションをバイパスすると、リソースやレジスタが高優先度コンテキストと低優先度コンテキスト間で共有される際に競合条件が発生する可能性があります。 いくつか追加の質問があります。 アプリケーションが高優先度のISR(AUTOSARカテゴリー1 ISR)でのプロセッシングを必要とする場合、推奨されるソフトウェアアーキテクチャは何ですか?このような機能は、常に複雑なデバイスドライバ(CDD)として実装されるべきでしょうか、それとも専用の低レベルドライバーとして実装されるべきでしょうか? もしGPIOポートやタイマーチャネルが単一の高優先度ISRのみで、他のタスクやISRからは一切アクセスされない場合、レースコンディションに関する懸念はラップ回避策にも適用されます か? 現在のRTD/MCALは、高優先度ISRからのAPI利用をサポートしておらず、したがって高リアルタイム機能はCDDまたは専用ドライバで実装しなければならないと理解してよいでしょうか? 自動車分野以外の組み込みソフトウェアの経験から言うと、ハードウェア抽象化層はしばしばオペレーティングシステムに依存しないように設計されています。そのため、単純なGPIOおよびタイマーAPIが内部的にRTOSのクリティカルセクションAPIを呼び出していることに気づいて驚きました。 参考までに、この問題を避けるために実装したGPTドライバー(CpuPit.h/c)を添付しました。 RTDチームからのご意見やご提案をいただければ幸いです。 改めてサポートありがとうございます。

S32K3 的高驱动强度 S32K3XX 参考手册提到了“驱动强度使能”位，但似乎没有定义其含义——我能找到的最接近的参考资料是，它似乎与某些引脚支持的最大频率相关（S32K3XXRM 第 42 页/第 4.4.1 节）。 关于最大电流消耗或其他方面，是否有明确的规定，让我了解是否应该启用或不应该启用“驱动强度”？ Re: High Drive Strength on S32K3 GPIO 标准：开关频率最高可达 10 MHz，不支持高驱动强度。不支持转换速率控制。 — GPIO 标准增强版：开关频率高达 25 MHz，支持高驱动强度。不支持转换速率控制。 — GPIO-中型：开关频率高达 50 MHz，支持高驱动强度。支持转换速率控制。 — GPIO-Fast：开关频率高达 120 MHz，支持高驱动强度。支持转换速率控制。 Re: High Drive Strength on S32K3 是的，这正是我在问题中引用的那部分内容的原文。这并没有告诉我是否应该启用“驱动强度”——它只是告诉我某些引脚支持它，并且某些开关速率与它有关。 如果我用它驱动一个LED，它能吸收更大的电流吗？电流还要高多少？ 仅仅是转换速率的变化吗？ 如果引脚支持，有什么理由不启用它呢？启用该功能后，我的芯片会散发更多热量吗？ Re: High Drive Strength on S32K3 S32K39x、S32K37x 和 S32K36x 微控制器的硬件设计指南 Re: High Drive Strength on S32K3 HI S32K3XX 参考手册 (S32K3XXRM) 指出，“GPIO-Standard” 焊盘类型 不支持高驱动强度，而“GPIO-Standard Plus”、“GPIO-Medium”和“GPIO-Fast” 焊盘类型 支持高驱动强度。 对于 GPIO焊盘类型，请参考S32K344_IO 信号表，特别是S32K344_S32K324_S32K314_IOMUX.xlsx随 S32K3XXRM 提供的 Excel 附件中的H 列。 此致， 罗宾 ------------------------------------------------------------------------------- 笔记： - 如果此帖解答了您的问题，请点击“接受为解决方案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 ------------------------------------------------------------------------------- Re: High Drive Strength on S32K3 正如我之前告诉过的帖子中所述，我知道哪些引脚支持“高驱动强度”，哪些不支持，这不是问题所在！ 但幸运的是，后台已经有了相关信息：在 S32K3xx.pdf 文件中，表27。GPIO直流电气规格，似乎符合我的需求。 看起来它将引脚的输出电流加倍，从而实现“DSE = 0”而不是“DSE = 1”。

Sleep and Wake-Up Driver Configuration on the S32K358 MCU Hi, I’ve been working with the S32K358 and have referred to the S32K3XX low-power management example, which demonstrates sleep and wake-up functionality using GPIO. However, I haven’t been able to get it working as expected. I suspect there may be issues with my configuration or implementation. I would greatly appreciate it if you could review my configuration and source files and let me know whether they are correct or if any changes are needed. After several attempts, I’m still unable to achieve the desired result, so I’m reaching out for your guidance. Please find my configuration and source files attached for your review. IDE: S32DS 3.5.14 SW Version: 4.0 HW: S32K358 Best regards, Karmegan C Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU Hi @karmegancjk, When wake-up is detected and the S32K358 enters the reset sequence, is the RAM content volatile or non-volatile? 32KB of SRAM content is non-volatile, or rather, 32KB of SRAM is kept powered while on standby:   If RAM content needs to be non-volatile, how can I create standby RAM memory and copy RAM data to standby RAM memory? In order to use standby RAM, you must modify the linker file, and assign the separate 32KB, place standby sections and adjust the linker address symbols. You must also initialize ECC of standby RAM if previous reset was POR. I've sent you a private message with a presentation on how to use standby RAM, and low power in general. Is standby mode similar to sleep mode or deep sleep mode in the S32K358 Cortex-M7? Yes, standby mode is similar to deep sleep: Best regards, Julián Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU Hi Julián, The S32K358 sleep and wake-up functionality through GPIO is working. When a rising edge is detected, the controller resets, as you mentioned, with a reset sequence. Now, I have a few doubts: When wake-up is detected and the S32K358 enters the reset sequence, is the RAM content volatile or non-volatile? If RAM content needs to be non-volatile, how can I create standby RAM memory and copy RAM data to standby RAM memory? Is standby mode similar to sleep mode or deep sleep mode in the S32K358 Cortex-M7? Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU Hi @karmegancjk, When entering STANDBY mode, I am using wake-up channel 46 (PTC24). My understanding is that if a rising edge is detected on this pin, a wake-up interrupt should be triggered. The external wake-up signals support both rising or falling detection. Does the program counter resume execution from address 0x00402000? Or is a full MCU reset required to resume execution? In previous devices (S32K1), code execution resumed after the WFI instruction, meaning Wakeup ISR → Code after WFI; S32K3 will always perform a reset sequence after waking up. This can depend on configured standby mode. For example, normal standby exit performs the reset sequence, then initializes sBAF and HSE FW (if installed), then resumes execution at reset_handler. However, fast standby exit can skip sBAF and HSE initialization and jump straight into a user defined boot address. After this user defined boot address, performing a full reset is recommended to fully initialize the device (or you can go back to standby again, depending on the application's needs): As for the project configuration, everything seems to be fine. Best regards, Julián Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU Hi, I have some doubts regarding the behavior of the MCU when entering STANDBY mode (sleep or deep sleep modes). Does the program counter freeze during this mode and restart from the vector address 0x00402000 after wake-up, or does it resume execution from where it left off? Could you please check whether my Power and Wake-Up driver configuration (in the .cfg file) is correct? I’ve attached the configuration file from my project for your reference. Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU Hi Julian, We are using custom hardware based on the S32K358 MCU. I have a question regarding the wake-up functionality in STANDBY mode. When entering STANDBY mode, I am using wake-up channel 46 (PTC24). My understanding is that if a rising edge is detected on this pin, a wake-up interrupt should be triggered. However, I’m unsure what happens after the wake-up event. Specifically: Does the program counter resume execution from address 0x00402000? Or is a full MCU reset required to resume execution? Also, I did not use any interrupt control APIs for the wake-up configuration, so I’m not sure whether the wake-up interrupt is handled properly or if a reset is necessary. Could you please clarify how the wake-up process works in this case and what the expected program flow should be? Thank you in advance for your support. Best regards, Karmegan C Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU Hi @karmegancjk, Are you using the S32K3X8EVB, or is this custom hardware? Keep in mind that S32K358 has an added step for standby exit with the PMIC handshake. If you don't use the handshake, set PMIC_PGOOD_HNDSHK_BYP bit in DCMRWF1: Solved: S32K3: Request for Support on Wakeup and Reset Behavior - NXP Community.  Also, which GPIO are you configuring? Please cross-check if the WKPU signal is correct with the S32K358_IOMUX.xlsx file attached to the S32K3 reference manual. Best regards, Julián Re: Sleep and Wake-Up Driver Configuration on the S32K358 MCU Hey @karmegancjk, I am also currently working on sleep and wakeup sequence , can you share your working code which i can use as reference , it would be helpful if you can share?

S32G274 ベアメタルコード S32G274の開発ボード上でベアメタルプログラムを使いたいと思っています。A53プロセッサの電源供給、LINFlexDシリアルポート、イーサネットなどのモジュール用のベアメタルドライバも含めて。箱から出してすぐに正常に動作させたいです。S32DSで生成されるドライバには、プロセッサの電源アップ機能のみが含まれています。 自分でLINFlexDシリアルポートの実装(ピンの有効化、クロックの有効化、シリアルインターフェースの初期化)を試みましたが、クロックの有効化の適切な扱い方がよくわかりません。 S32DSで直接コンパイルできる、すぐに使えるベアメタルプログラムを提供していただければ幸いです。 Re: S32G274 baremetal code こんにちは、 @Tatu_dd 投稿ありがとうございます。 1. NXPのソフトウェア支援S32G274A戦略では、A53コアは主にベアメタル開発ではなくLinux BSP運用に割り当てられています。A53コア向けのS32 Design Studio 3.6.8の例は、意図的に起動/起動コードに限定されており、意図された使用ケースはこれらのコア上で完全なLinuxディストリビューションを実行することが目的です。 2. ベアメタルA53開発に関しては、公開されているリファレンスコードはほとんどなく、デモは存在するものの、それはA53上の純粋なベアメタルコードではなく、異種実装である。 そのため、既存のLinuxドライバやRTDドライバを必要に応じて実装または移植する必要があるかもしれません。申し訳ありませんが、NXPによる直接的な例やソフトウェアリリースは提供されていません。 BR チェイン

在基于 MC9S12X256 16 位处理器的 SCI 系统上实现 I2C MC9S12XS256 微控制器没有专用的 I2C 端口，但是 SCI 子系统能否用于与 I2C 显示器或类似配件通信？ Re: implementing I2c on the sci system on an MC9S12X256 16 BIT I2C 无法与 SCI/LIN 直接通信，因为它们的硬件引脚定义不同。 如果必须使用 I2C 通信，则可能需要使用网关来传输协议（例如 MC9S12）。

VSCode DEBUG PROBES window not loading (white line scrolling right). This is on OS X, VSC ver: 26.6.57.  The DEBUG PROBES window is not detecting any probes (Segger at the moment).  This is for a freeform project which was functioning before I performed an upgrade.  I am looking for suggestions as to what to examine.  The probes are functioning outside of the VSCode extension.  I also have run MCUXpresso Installer as well (though the PEMicro server install always shows a spinning wheel, it did succeed in extracting the tar into ~/.mcuxpressotools/pemicrogdbserver - just an aside). Useful info would be what/how the extension is attempting to interact with the debug tools.  I have attempted to supply tool locations in the extension settings, etc.   Is the Debug Probes view controlled by the debug-tracker-vscode dependency? There is a message visible briefly when this loads, something about no provider found. Re: VSCode DEBUG PROBES window not loading (white line scrolling right). Hello @buff, When you mentioned, "This is for a freeform project which was functioning before I performed an upgrade," could you please clarify what was upgraded? In order to try a pinpoint if this solves the issue, could you perform the following tests? -In the Debug Probes window, click Clean-up Debug and then click the Refresh button. -Update the MCUXpresso Installer to the latest available version. You can follow the steps described in the Package and Component Status, Version, and Updates section. -Reinstall the SEGGER J-Link Software Pack from the MCUXpresso Installer. Also, could you please provide me which device are you currently using? Is one of our EVKs or is a custom board? BR Habib Re: VSCode DEBUG PROBES window not loading (white line scrolling right). MCUXpresso Installer is at v26.03.  I first noticed this after upgrading and running the install.  I see v26.06 is now current, I will install that and see what's what. * I installed v26.06.117 and upon launching it, I just see the spinning icons.  I will I relaunched Installer via /Applications/MCUXpressoInstaller.app/Contents/MacOS/MCUXpressoInstallerCLI to get more info.  Launching from MCUXpressoInstallerCLI from my default environment I see this spinning behavior.  When I relaunched from the GUI (OS X) a subsequent time the installer shows component status (installed, update available) with the exception of PEMicro.   -In the Debug Probes window, click Clean-up Debug and then click the Refresh button. In the VSCode DEBUG PROBES window there is nothing to click.  The message which popped up indicated that there is no 'provider' for the window.  This message shows up in all the windows when first launched then goes away as MCUXpresso finishes loading (with the exception of the DEBUG PROBES windows).  I guess I could blow away the MCUXpresso for VSCode extension and reinstall. MCUXpressoInstallerCLI output once had this, might be hint for PEMicro: verbose: Checking if MCUXpresso for VS Code is already installed... info: MCUXpresso for VS Code already installed. Version: 26.6.57 ^Cverbose: Checking if PEmicro is already installed... info: Executing "/Users/bruff/.mcuxpressotools/pemicrogdbserver/pegdbserver_console --version" info: zsh -c "source /Users/bruff/.zprofile && /Users/bruff/.mcuxpressotools/pemicrogdbserver/pegdbserver_console --version" error: Command /Users/bruff/.mcuxpressotools/pemicrogdbserver/pegdbserver_console exited with code 1. stdout: "P&E GDB Server for Arm(R) devices, Version 10.02.00.00 Copyright 2025, P&E Microcomputer Systems Inc, All rights reserved Loading library /Users/bruff/.mcuxpressotools/pemicrogdbserver/gdi/unit_ngs_arm_internal.so ... Done. Command line arguments: --version" stderr: "Exception EControlC in module libsystem_kernel.dylib at 00007FF80629B3CA. Control-C hit." info: PEmicro not found. Error occurred in handler for 'versionReport': Error: Could not get browser window handle at new o (/Applications/MCUXpressoInstaller.app/Contents/Resources/app.asar/main.js:2:312914) at o.getInstance (/Applications/MCUXpressoInstaller.app/Contents/Resources/app.asar/main.js:2:313215) at r (/Applications/MCUXpressoInstaller.app/Contents/Resources/app.asar/main.js:2:313676) at Rc (/Applications/MCUXpressoInstaller.app/Contents/Resources/app.asar/main.js:2:519204) at async Session. (node:electron/js2c/browser_init:2:114068) Re: VSCode DEBUG PROBES window not loading (white line scrolling right). I was able to use Installer to update the tools and components.  Restarting VSCode now shows the DEBUG PROBES window contents.  Note I did launch VSCoce from both spotlight and a shell, both worked.   Re: VSCode DEBUG PROBES window not loading (white line scrolling right). I deleted ~/.mcuxpressotools and MCUXpresso Installer at least isn't spinning checking for updates.  I will re-install the dependencies now.

Additional materials related to DRM099 application note Dear all, I'm an Electrical Engineering student and I'm using the document "Sensorless PMSM Vector Control with a Sliding Mode Observer for Compressors Using MC56F8013" (document number DRM099) to learn about the sliding mode observer for permanent magnet synchronous machines. So far this document has been very useful, and I'm really thankful that NXP made it available! In the document the authors mention some functions such as "PMSM_SL_DQSMOBemfSpedObservSclUniv32()", "EstimProcessing()", which would be very useful for me to look their code. In this way, I hope to better understand the concepts explained in DRM099, and hopefully tackle the challenge of implementing and tuning the SMO in the dq frame. Therefore, if it is not asking too much, I was wondering if I could have access to these additional files and materials, if possible. Anything you can share will be immensely appreciated and helpful. Thank you in advance for your time and consideration! I wish you a great day. Best regards, Rafael Re: Additional materials related to DRM099 application note Hello @Rafael1 , Thanks for your post. I think the information below is what you are looking for： RDDSCPMSMVCSMO: Sensorless PMSM Vector Control for Compressors Reference Design Using MC56F8013 https://www.nxp.com/search?keyword=pmsm_sensorlesscl&start=0  Download link: https://www.nxp.com/webapp/Download?colCode=PMSM_SENSORLESSCL_DQHREL&appType=license&location=null Hope it helps. BR Celeste Re: Additional materials related to DRM099 application note Thank you so much, @Celeste_Liu  After downloading and executing the .exe file, I was able to get the C code for the motor control with sliding mode observer. That was exactly what I was looking for. Thank you for your time and consideration! Have a nice day! Re: Additional materials related to DRM099 application note Glad to help! Any new questions, welcome to create a new post.

VSCode 调试探测窗口无法加载（白色线条向右滚动）。 这是在 OS X 系统上，VSC 版本：26.6.57。DEBUG PROBES 窗口未检测到任何探针（目前是 Segger）。这是一个自由格式项目，在我进行升级之前它运行正常。我想请教一下应该检查哪些方面。这些探针在 VSCode 扩展之外运行。我还运行了 MCUXpresso 安装程序（尽管 PEMicro 服务器安装一直显示旋转的圆圈，但它确实成功地将 tar 文件解压到了 ~/.mcuxpressotools/pemicrogdbserver）。（只是顺便提一下）。 有用的信息包括该扩展程序尝试与调试工具进行哪些交互/如何交互。我已尝试在扩展程序设置等中提供工具位置。 调试探针视图是否受 debug-tracker-vscode 依赖项控制？ 页面加载时会短暂显示一条消息，内容大概是找不到提供商。 Re: VSCode DEBUG PROBES window not loading (white line scrolling right). 你好@buff ， 您提到“这是一个自由格式项目，在我进行升级之前运行正常”，请问您能否具体说明升级了什么？ 为了确定这是否能解决问题，请您执行以下测试？ -在“调试探针”窗口中，单击“清理调试” ，然后单击“刷新”按钮。 -将 MCUXpresso 安装程序更新到最新版本。您可以按照“代码包，软件包和元器件状态、版本和更新”部分中描述的步骤进行操作。 -从 MCUXpresso 安装程序重新安装 SEGGER J-Link 软件包。 另外，请问您目前使用的是哪款设备？这是我们的EVK产品之一，还是定制的电路板？ BR 哈比卜 Re: VSCode DEBUG PROBES window not loading (white line scrolling right). 我使用安装程序更新了工具和元器件。重启 VSCode 后，现在可以显示“调试探针”窗口的内容。注意，我分别通过 Spotlight 和 shell 启动了 VSCoce，两种方式都成功了。 Re: VSCode DEBUG PROBES window not loading (white line scrolling right). 我删除了 ~/.mcuxpressotools 目录，MCUXpresso 安装程序至少不再循环检查更新了。我现在将重新安装依赖项。 Re: VSCode DEBUG PROBES window not loading (white line scrolling right). MCUXpresso 安装程序版本为 v26.03。我是在升级并运行安装程序后才注意到这个问题的。我看到最新版本是 v26.06，我会安装看看情况如何。 * 我安装了 v26.06.117 版本，启动后只看到旋转的图标。我会 我通过 /Applications/MCUXpressoInstaller.app/Contents/MacOS/MCUXpressoInstallerCLI 重新启动了安装程序 获取更多信息。从我的默认环境通过 MCUXpressoInstallerCLI 启动时，我看到了这种旋转现象。当我随后从 GUI（OS X）重新启动时，安装程序会显示元器件状态（已安装、有更新可用），但 PEMicro 除外。 -在“调试探针”窗口中，单击“清理调试” ，然后单击“刷新”按钮。 在 VSCode 的“调试探针”窗口中，没有任何可以点击的内容。弹出的消息表明该窗口没有“提供程序”。首次启动时，此消息会显示在所有窗口中，然后随着 MCUXpresso 加载完成而消失（调试探针窗口除外）。我想我可以把 MCUXpresso for VSCode 扩展卸载掉，然后重新安装。 MCUXpressoInstallerCLI 输出曾经出现过这个内容，这可能是 PEMicro 的一个线索： 详细信息：正在检查 MCUXpresso for VS Code 是否已安装…… 信息：MCUXpresso for VS Code 已安装。版本：26.6.57 ^详细：正在检查 PEmicro 是否已安装... 信息：正在执行“/Users/bruff/.mcuxpressotools/pemicrogdbserver/pegdbserver_console --version” 信息：zsh -c "source /Users/bruff/.zprofile && /Users/bruff/.mcuxpressotools/pemicrogdbserver/pegdbserver_console --version" 错误：命令 /Users/bruff/.mcuxpressotools/pemicrogdbserver/pegdbserver_console 退出，返回代码为 1。 标准输出：“适用于 Arm(R) 设备的 P&E GDB 服务器，版本 10.02.00.00 版权所有 © 2025 P&E 微型计算机系统公司，保留所有权利 正在加载库 /Users/bruff/.mcuxpressotools/pemicrogdbserver/gdi/unit_ngs_arm_internal.so ... 完成。 命令行参数：--version” stderr: "模块 libsystem_kernel.dylib 中出现异常 EControlC，地址为 00007FF80629B3CA。 Ctrl+C 按下。 信息：未找到 PEmicro。 'versionReport' 处理程序中发生错误：错误：无法获取浏览器窗口句柄 在 new o (/Applications/MCUXpressoInstaller.app/Contents/Resources/app.asar/main.js:2:312914) 在 o.getInstance (/Applications/MCUXpressoInstaller.app/Contents/Resources/app.asar/main.js:2:313215) 在 r (/Applications/MCUXpressoInstaller.app/Contents/Resources/app.asar/main.js:2:313676) 在 Rc (/Applications/MCUXpressoInstaller.app/Contents/Resources/app.asar/main.js:2:519204) 在异步会话. (node:electron/js2c/browser_init:2:114068)

Best IPTV usa Service 2026 Nigma TV is one of the best IPTV services to recommend in 2026 for users in the USA, Canada, UK, and worldwide — mainly because it’s built for stable streaming when it matters most. With 51,000+ live channels and 160,000+ movies and series on demand, Nigma TV gives users a massive entertainment library in one subscription. The service supports HD, Full HD, 4K, and UHD streaming, with strong performance on Smart TVs, Firestick, Android, iOS, PC, Mac, and popular IPTV player apps. What makes Nigma TV stand out is its focus on stability during peak hours and major live events. The platform is designed with anti-freeze technology, fast servers, and smooth playback to reduce buffering and keep streams running reliably. For anyone looking for a premium IPTV provider in 2026, Nigma TV is a strong option for live TV, sports, movies, series, and international channels. Official Site: www.nigma.tv Re: Best IPTV usa Service 2026 nigma tv official web site link is : NIGMA.TV Re: Best IPTV usa Service 2026 Looking for the best way to enjoy premium content without an immediate commitment? In 2026, the most effective way to find a high-quality provider is through a free IPTV trial. Why Start with a Free Test? A free trial allows you to verify several critical factors before subscribing: Stability: Ensure the service offers buffer-free streaming and high uptime (ideally 99% or more). Content Variety: Check for access to over 20,000+ live channels, including premium sports, news, and international networks. Quality: Verify support for HD, Full HD, and 4K streaming. Device Compatibility: Confirm it works on your preferred hardware, such as Amazon Firestick, Smart TVs, Android/iOS devices, or PCs. Top Recommendation for 2026 For a premium experience with a vast selection of channels and reliable performance, we recommend testing GoldCard TV. It is designed to provide a seamless entertainment solution with minimal downtime. 👉 Start your free trial now at: https://omeulink.com/GoldCardTv Re: Best IPTV usa Service 2026 Been testing a few streaming options lately for sports and live TV. Most of them had buffering issues during matches, especially at night, but this one has been surprisingly smooth so far. Picture quality looks good and it runs fine on Firestick, Smart TV, and phone without much setup. Still testing it, but the experience has been decent until now. nexusiptv Re: Best IPTV usa Service 2026 You don't need to look for a vast number of channels and movies to find a great server; what matters most is stability and a lack of interruptions during live match broadcasts, as well as good after-sales support—and that is exactly what I found on this site: nexusiptv. live Re: Best IPTV usa Service 2026 Nexus IPTV is an IPTV service that users may consider in 2026 for access to live TV, sports, movies, and series across multiple devices. The platform supports common IPTV applications and is compatible with Smart TVs, Android devices, Firestick, and other supported systems. click here to get free trial

2026 年美国最佳 IPTV 服务 Nigma TV 是2026年向美国、加拿大、英国和全球用户推荐的最佳IPTV服务之一——主要是因为它专为最重要的时候的稳定直播而打造。 Nigma TV拥有 51,000多个直播频道和16万多部电影和电视剧在线点播，一次订阅即可为用户提供庞大的娱乐库。该服务支持高清、全高清、4K 和 UHD 流媒体，在智能电视、Firestick、Android、iOS、PC、Mac 和流行的 IPTV 播放器应用程序上表现出色。 Nigma TV 脱颖而出的原因在于它注重高峰时段和重大直播活动期间的稳定性。该平台采用防冻技术、快速服务器和流畅播放设计，以减少缓冲并保持流媒体的可靠运行。 对于在 2026 年寻找优质 IPTV 提供商的人来说，Nigma TV是直播电视、体育、电影、连续剧和国际频道的有力选择。 官方网站： www.nigma.tv Re: Best IPTV usa Service 2026 NIGMA.TV 官方网站链接为 ：NIGMA.TV Re: Best IPTV usa Service 2026 您在寻找无需立即付费即可享受优质内容的最佳方式吗？2026 年，寻找优质供应商的最有效方式是免费试用 IPTV。 为什么要从免费测试开始？ 免费试用允许您在订购前验证几个关键因素： 稳定性：确保服务提供无缓冲流媒体和高正常运行时间（理想情况下为 99% 或更高）。 内容丰富：查看 20,000 多个直播频道，包括高级体育、新闻和国际网络。 质量：验证对高清、全高清和 4K 流媒体的支持。 设备兼容性：确认它可以在您的首选硬件上运行，例如亚马逊 Firestick、智能电视、安卓/iOS 设备或电脑。 2026 年的热门推荐 为了获得具有丰富频道选择和可靠性能的优质体验，我们建议您测试GoldCard TV。它旨在提供无缝娱乐解决方案，将停机时间降至最短。 👉 现在就开始免费试用： https://omeulink.com/GoldCardTv Re: Best IPTV usa Service 2026 最近我在测试一些体育和电视直播的流媒体选项。 其中大部分在比赛时都会出现缓冲问题，尤其是在晚上，但这一次到目前为止却出奇地流畅。 画质看起来不错，在 Firestick、智能电视和手机上都能正常运行，无需过多设置。 还在测试，但到目前为止体验还不错。 nexusiptv Re: Best IPTV usa Service 2026 你不需要寻找大量的频道和电影来找到一个好的服务器；最重要的是稳定性，以及在直播比赛期间不会中断，还有良好的售后支持——而这正是我在这个网站上找到的：nexusiptv。居住 Re: Best IPTV usa Service 2026 Nexus IPTV 是一项 IPTV 服务，用户在 2026 年可以考虑使用该服务在多个设备上访问直播电视、体育赛事、电影和剧集。该平台支持常见的 IPTV 应用，并兼容智能电视、安卓设备、Firestick 和其他支持的系统。 点击此处获取免费试用