Unable to update APP container software version for i.MX95 FlexSPI boot image Hello Experts, I'm working on the i.MX95 platform and enabling rollback protection using ROLLBACK_INDEX_IN_CONTAINER. I introduced the following variable in my local.conf: export ROLLBACK_INDEX_IN_CONTAINER = "1" This value is propagated through the build, and the build log confirms that mkimage_imx8 is invoked with "1" When building an eMMC boot image, parsing the generated image shows the container software version updated correctly.  if [ 1 ]; then \ ./../mkimage_imx8 -soc IMX9 -cntr_version 2 -sw_version 1 -c \ -ap bl31.bin a55 0x8A200000 \ -ap u-boot-hash.bin a55 0x90200000 \ -ap tee.bin a55 0x8C000000 \ -out u-boot-atf-container.img; \   However, when building the FlexSPI boot image (imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi), parsing the image still reports the default SW version ./mkimage_imx8 -soc IMX9 -parse imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi SOC: IMX9 Input container binary to be parsed: imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi ********************************* * * * APP CONTAINER 1 * * * ********************************* Length: 0X320 (800) Tag: 0X87 Version: 0X2 Flags: 0X10 Num images: 6 Fuse version: 0 SW version: 0X0 Sig blk offset: 0X310 I noticed an interesting thing in iMX95/soc.mak as there is no sw_version included during the build for flash_a55_flexspi flash_a55_flexspi: $(MKIMG) $(AHAB_IMG) $(MCU_IMG) $(SPL_A55_IMG) $(OEI_IMG_M33) fcb.bin u-boot-atf-container.img ./$(MKIMG) -soc IMX9 -cntr_version $(CTNR_VERSION) $(XSPI_FAST_HASH) -dev flexspi -append $(AHAB_IMG) -c $(OEI_OPT_M33) -msel $(MSEL) \ -m33 $(MCU_IMG) 0 $(MCU_TCM_ADDR) \ -ap $(SPL_A55_IMG) a55 $(SPL_LOAD_ADDR_M33_VIEW) $(V2X_DUMMY) -fcb fcb.bin $(FCB_LOAD_ADDR) -out flash.bin $(call append_container,u-boot-atf-container.img,1) $(call append_fcb) My questions are: Is ROLLBACK_INDEX_IN_CONTAINER expected to update the software version for FlexSPI boot images? Does the FlexSPI image follow a different container generation flow where the rollback index/software version must be configured separately? Is this a known limitation or issue in the i.MX95 imx-mkimage build flow? If anyone has successfully enabled ROLLBACK_INDEX_IN_CONTAINER for FlexSPI boot images on i.MX95, could you please share the expected flow or any additional configuration required? Thanks in advance! Best Regards, Arun Kumar Re: Unable to update APP container software version for i.MX95 FlexSPI boot image Hi @arun16598  The FlexSPI image is not another variant of the AHAB format, but it employs a combined process of first generating the boot container, then appending the U-Boot/ATF container. Your -sw_version 1 is set on u-boot-atf-container.img; however, the APP container containing SM/M33, OEI, SPL, and FCB—which flash_a55_flexspi creates first—does not pass the -sw_version option, so that container still displays SW version: 0. ROLLBACK_INDEX_IN_CONTAINER is used to generate the secondary U-Boot/ATF APP container, but it is not passed to the primary APP container created by flash_a55_flexspi. If the same software version is required for the first FlexSPI APP container, -sw_version $(ROLLBACK_INDEX_IN_CONTAINER) must also be added to the mkimage_imx8 invocation in flash_a55_flexspi. If the goal is true AHAB anti-rollback enforcement, the key settings to verify and configure are fuse_version and -fuse_version, not just sw_version. The SPSDK’s i.MX95 anti-rollback example clearly states that OEM anti-rollback uses the fuse_version specified in the AHAB container YAML, and the version is subsequently submitted via the ELE’s OEM_FW_FUSE commit process. Best Regards, Zhiming

FLEXCAN EDMA - CANメッセージのバースト受信時にACKエラーが発生する i.MXRT1176では、EDMAとFLEXCANを使用しています。(SDK 26.03) DMA転送完了時にコールバック関数が定義されています。 これが私たちの流れです。 1.転送を開始するには、`FLEXCAN_TransferReceiveFifoEDMA()` を呼び出してください。 2. DMA転送完了時にユーザー定義コールバックが呼び出されます。 3. データはDMAバッファからコピーされ、メッセージの受信を継続するために`FLEXCAN_TransferReceiveFifoEDMA()`が呼び出されます。 4. 手順2～4を繰り返す 別のノードから最小限のフレーム間隔でバースト的にメッセージを送信すると、ACKエラーの数が増加することがわかりました。つまり、iMXがメッセージをACKできないということです。 処理の流れを追っていくと、DMA転送完了コールバックが発生するたびに、FLEXCAN上でDMAが無効化されているようです。「FLEXCAN_TransferReceiveFifoEDMA()」が呼び出されると再び有効化されます。 これは「FLEXCAN_EnableRxFifoDMA()」を呼び出すことで行います。有効化/無効化DMAはFLEXCANのMCRレジスタ内のDMAビットを更新し、フリーズモードでのみ可能です。メッセージを一気に受信しているため、FLEXCANがフリーズモードに設定されている間に送信が進行中である可能性があります。そして、着信メッセージをACKで確認できません。   `FLEXCAN_EnableRxFifoDMA()` の呼び出しを削除することで、すべての ACK エラーが解消されることを確認しましたが、今度は一部のメッセージがドロップされるようになりました。また、メッセージの間隔を空けて送信してみたところ、ACKエラーも解消されました。これが実装上の問題なのか、それとも別の方法で再設計すべきか確認していただけますか? Re: FLEXCAN EDMA - ACK errors while receiving a burst of CAN messages こんにちは、@r-uv さん。 詳細な分析をありがとうございました。あなたの観察はSDKの実装と一致しています。 FLEXCAN_TransferReceiveFifoEDMA() は、有限長のトランザクション API です。DMA完了の後、ドライバーはRx FIFO DMA要求を無効化し、次の呼び出しで再び有効化します。MCR[DMA]を変更するにはフリーズモードが必要となるため、最小IFSトラフィックの次のフレームがFlexCANが通常モードに戻る前に到着する可能性があり、その結果ACKが欠落する可能性があります。 これは、繰り返し行われるDMAの有効化/無効化操作を削除するとACKエラーは解消されるものの、フレームのドロップが依然として発生する理由も説明しています。フリーズに関連するACKギャップは解消されますが、eDMA転送は継続的に再有効化されないためです。 連続的なバーストトラフィックについては、Rx FIFO DMA要求を有効にし、ハードウェアチェーンのピンポン/散乱集いTCDを使用して次のバッファが自動的に有効化されるようにすることを推奨します。これは、FLEXCAN_TransferReceiveFifoEDMA() を繰り返し再起動するのではなく、連続した DMA 受信パスを必要とします。 よろしくお願いします、 ギャビン Re: FLEXCAN EDMA - ACK errors while receiving a burst of CAN messages ご回答ありがとうございます。SDKにこのサポートを追加する計画はありますか?現在のトランザクションAPI実装だけでなく、継続的なDMAベースの実装はどうでしょうか？

S32K364 无法捕获 eFlexPWM 输入信号——标志位已设置但 CAPTCOMPB 仍为零。 我正在使用 eFlexPWM 模块（实例）。 我正在使用 S32K364 微控制器上的 IP_EFLEXPWM_0 ) 通过输入捕获来测量外部信号的频率和周期。 子模块 2 （ SM[2] ）。我的配置如下： SM2_CAPTCTRLB->EDGB0 = 0x02; （上升沿捕获电路 0） SM2_CAPTCTRLB->EDGB1 = 0x02; （上升沿捕获电路 1） SM2_ARMB = 1; （Arm捕获电路） 运行代码后，我观察到以下情况： 在 SM2_CAPTCTRLB ，计数器状态位显示： CB0CNT = 0x4 CB1CNT = 0x4 在 SM2_STS ，两个标志位均已设置： CFB0 = 1 CFB1 = 1 然而，捕获的值（ SM2_CAPTCOMPB ）仍然存在。 0 对于这两个捕获电路——都没有数据被锁存。 造成这种情况的原因可能是什么？我是否遗漏了其他需要的配置（例如，时钟启用、输入多路复用或计数器设置）？这些标志表明检测到了捕获事件，但捕获的值没有更新。您的见解将不胜感激。 如有需要，请随时添加其他详细信息（例如引脚复用设置或计数器模式）。祝你好运！ Re: eFlexPWM input capture not capturing on S32K364 – flags set but CAPTCOMPB remains zero HI 首先，我检查了最新的 S32K3 RTD 7.0.x版本；但是， S32 配置工具尚不支持eFlexPWM E-Capture功能。 如果方便的话，能否分享一下您的项目，以便我可以在 S32K396 上进行测试？（可惜我没有 S32K364，只有S32K396-BGA-DC1评估板。） 其次，请查看 S32K396RM（修订版 4，2024 年 11 月） 中的“56.3.14 增强捕获（E-Capture）” 部分。请检查该部分中提到的寄存器，特别是图 254 中的寄存器。E-捕获 逻辑。您也可以与我分享eFlexPWM_0 寄存器的屏幕截图。 除了您在SM2_CAPTCTRLB [EDGB0]、[EDGB1]、[ARMB]中提到的位之外，您是如何配置SM2_CAPTCTRLB中的其他位的？   既然您观察到SM2_CAPTCTRLB[CB0CNT] = 0x4和[CB1CNT] = 0x4 ，您是否检查过SM2_CVAL4 、 SM2_CVAL4CYC 、 SM2_CVAL5和SM2_CVAL5CYC的相应寄存器值？   此外，如果您想读取SM2_CAPTCOMPB[EDGCNTB]的值，请先启用SM2_CAPTCTRLB[EDGCNTB_EN]和SM2_CAPTCOMPB[EDGCMPB] 。 我不明白你为什么要将SM2_CAPTCOMPB[EDGCMPB]设置为 0，因为这似乎会阻止图 254 中的比较器 E-Capture 逻辑正常工作。 此致敬礼， Robin Re: eFlexPWM input capture not capturing on S32K364 – flags set but CAPTCOMPB remains zero 子模块 2 的周期似乎太短了。请阅读“ 56.3.18.3 以低于子模块 0 的频率运行子模块”，并尝试为子模块 2 选择较低频率的时钟源，例如AUX_CLK或EXT_CLK 。 Re: eFlexPWM input capture not capturing on S32K364 – flags set but CAPTCOMPB remains zero 嗨@Robin_Shen ， 我通过正确配置 MCTRL 和 CAPTCTRLB 寄存器，成功实现了外部频率测量。然而，测试表明我能达到的最低可测量频率为 5 kHz，而我的要求是支持低至 1 Hz 的频率。 我尝试调整了预分频器和预分频器备用配置，但并未观察到任何改进。能否请您提供一些建议和故障排除方法？非常感谢您的支持。

RT1176 PWMの起動に失敗しました 私はPWM + Fault + QTimerを使ってモーターパルス制御を実装していますが、PWM3サブモジュール0のPWM_Aチャネルが時々起動できず、最初のハイレベル以降は一定のままで、その後のパルスは現れません。検査の結果、PWMの「ラン」部分が正しく設定されていないことが判明しました。後からプログラムに起動時の処理を繰り返し追加したにもかかわらず、この異常は依然として発生した。 Re: RT1176 PWM startup failed こんにちは、 @liu626 さん。 カスタムボードを使用していますか、それともEVKを使用していますか？EVKを使用している場合、何か改造を加えましたか？ PWM3で使っている構成を教えてもらえますか? 何か例を参考にしていますか？もしそうなら、どの学校ですか? PWM3のみを含むプロジェクトを使用して問題を再現しようとした場合、問題は解消されますか？ これはPWM3サブモジュール0のPWM_Aチャネルだけに起こるのでしょうか?他のPWMモジュールやサブモジュールでも同様の現象が発生しましたか？ PWM3レジスタを操作し、ランビットに影響を与えたり上書きしたりする他のタスクや割り込みはありますか? よろしくお願いします、 パブロ Re: RT1176 PWM startup failed こんにちは、カスタム回路基板を使用しました。私は具体的な例を挙げませんでした。これは、プロジェクトの正式な開発過程で発見された問題だった。パルス制御用に6つのPWMチャネルを設定しました。このチャネルだけが問題を起こし、他のサブモジュールでは同様の問題はありませんでした。調べたところ、このチャネルだけがPWM3モジュールを使っていることがわかりました。他に干渉因子は検出されなかった。以下は私の設定です。 static axis_ctrl_t g_axes[AXIS_NUM] = ヤージュ ヤージュ .id= AXIS_X1、.name= "X1", .pwmBase= PWM1、.pwmModule= kPWM_Module_0、.pwmChannel= kPWM_PwmA、 .tmrBase= TMR3、.lowCh= kQTMR_Channel_2、.highCh= kQTMR_Channel_3、 .tmrInputsrc=kQTMR_ClockCounter2InputPin、.cascadePcs= 6U、 .faultNum= 0U、.hwExactSupported= true、.outTrigMask= kPWM_ValueRegisterMask_3、 }、 ヤージュ .id= AXIS_X2、.name= "X2", .pwmBase= PWM2、.pwmModule= kPWM_Module_0、.pwmChannel= kPWM_PwmA、 .tmrBase= TMR2、.lowCh= kQTMR_Channel_0、.highCh= kQTMR_Channel_1、 .tmrInputsrc=kQTMR_ClockCounter0InputPin、.cascadePcs= 4U、 .faultNum= 0U、.hwExactSupported= true、.outTrigMask= kPWM_ValueRegisterMask_3、 }、 ヤージュ .id= AXIS_Y、.name= "Y"、 .pwmBase= PWM3、.pwmModule= kPWM_Module_0、.pwmChannel= kPWM_PwmA、 .tmrBase= TMR3、.lowCh= kQTMR_Channel_0、.highCh= kQTMR_Channel_1、 .tmrInputsrc=kQTMR_ClockCounter0InputPin、.cascadePcs= 4U、 .faultNum= 0U、.hwExactSupported= true、.outTrigMask= kPWM_ValueRegisterMask_3、 }、 ヤージュ .id= AXIS_Z、.name= "Z"、 .pwmBase= PWM4、.pwmModule= kPWM_Module_0、.pwmChannel= kPWM_PwmA、 .tmrBase= TMR1、.lowCh= kQTMR_Channel_0、.highCh= kQTMR_Channel_1、 .tmrInputsrc=kQTMR_ClockCounter0InputPin、.cascadePcs= 4U、 .faultNum= 0U、.hwExactSupported= true、.outTrigMask= kPWM_ValueRegisterMask_3、 }、 ヤージュ .id= AXIS_EX1、.name= "EX1", .pwmBase= PWM1、.pwmModule= kPWM_Module_1、.pwmChannel= kPWM_PwmA、 .tmrBase= TMR1、.lowCh= kQTMR_Channel_2、.highCh= kQTMR_Channel_3、 .tmrInputsrc=kQTMR_ClockCounter2InputPin、.cascadePcs= 6U、 .faultNum= 1U、.hwExactSupported= true、.outTrigMask= kPWM_ValueRegisterMask_3、 }、 ヤージュ .id= AXIS_EX2、.name= "EX2", .pwmBase= PWM2、.pwmModule= kPWM_Module_1、.pwmChannel= kPWM_PwmA、 .tmrBase= TMR2、.lowCh= kQTMR_Channel_2、.highCh= kQTMR_Channel_3、 .tmrInputsrc=kQTMR_ClockCounter2InputPin、.cascadePcs= 6U、 .faultNum= 1U、.hwExactSupported= true、.outTrigMask= kPWM_ValueRegisterMask_3、 }、 };static void APP_Init_PWM_QTMR(void) ヤージュ pwm_config_t pwmConfig; pwm_fault_param_t faultConfig; qtmr_config_t qtmrConfig; PWM_GetDefaultConfig(&pwmConfig); pwmConfig.pairOperation= kPWM_Independent; pwmConfig.reloadLogic = kPWM_ReloadImmediate; PWM_FaultDefaultConfig(&faultConfig); faultConfig.faultLevel = true; faultConfig.enableCombinationalPath= 偽; faultConfig.faultClearingMode= kPWM_ManualSafety; faultConfig.recoverMode = kPWM_NoRecovery; QTMR_GetDefaultConfig(&qtmrConfig); CLOCK_EnableClock(kCLOCK_Qtimer1); CLOCK_EnableClock(kCLOCK_Qtimer2); CLOCK_EnableClock(kCLOCK_Qtimer3); PWM_StopTimer(PWM1, 0x0FU); PWM_StopTimer(PWM2, 0x0FU); PWM_StopTimer(PWM3, 0x0FU); PWM_StopTimer(PWM4, 0x0FU); pwm_fault_input_filter_param_t faultFilter; faultFilter.faultFilterPeriod= 255U; faultFilter.aultFilterCount= 7U; faultFilter.faultGlitchStretch= 偽; /* 记录每个 PWM 实例上已配置的 faultチャネル,避免重复设置 */ uint16_t pwm1FaultDone = 0U, pwm2FaultDone = 0U, pwm3FaultDone = 0U, pwm4FaultDone = 0U; for (uint8_t i = 0U; i < AXIS_NUM; i++) { axis_ctrl_t *ax = &g_axes[i]; PWM_Init(ax->pwmBase, ax->pwmModule, &pwmConfig); PWM_SetupFaults(ax->pwmBase, (pwm_fault_input_t)ax->faultNum, &faultConfig); /* 故障濾波(每個 PWM 实例的每个 faultチャネル 只设一次) */ { uint16_t *faultDone; if (ax->pwmBase == PWM1) faultDone = &pwm1FaultDone; else if (ax->pwmBase == PWM2) faultDone = &pwm2FaultDone; else if (ax->pwmBase == PWM3) faultDone = &pwm3FaultDone; else faultDone = &pwm4FaultDone; uint16_t faultBit = (uint16_t)(1U << ax->faultNum); if((*faultDone & faultBit) == 0U) { PWM_SetupFaultInputFilterExt(ax->pwmBase, (pwm_fault_channels_t)ax->faultNum, &faultFilter); *faultDone |= faultBit; } } /* 故障時輸出低電平 */ ax->pwmBase->SM[ax->pwmModule].OCTRL &= ~(PWM_OCTRL_PWMAFS_MASK |PWM_OCTRL_PWMBFS_MASK); APP_PWM_Unmap_Selected_Fault(ax); APP_PWM_ClearFault_Safe(ax); ax->pwmBase->SM[ax->pwmModule].INIT = 0U; ax->pwmBase->SM[ax->pwmModule].VAL0 = 0U; ax->pwmBase->SM[ax->pwmModule].VAL1 = 1U; ax->pwmBase->SM[ax->pwmModule].VAL2 = 0U; ax->pwmBase->SM[ax->pwmModule].VAL3 = 0U; ax->pwmBase->SM[ax->pwmModule].VAL4 = 0U; ax->pwmBase->SM[ax->pwmModule].VAL5 = 0U; ax->pwmBase->SM[ax->pwmModule].TCTRL = PWM_TCTRL_OUT_TRIG_EN(ax->outTrigMask); APP_PWM_Disable_Output(ax); if (ax->hwExactSupported) { qtmrConfig.primarySource= ax->tmrInputSrc; QTMR_Init(ax->tmrBase, ax->lowCh, &qtmrConfig); QTMR_Init(ax->tmrBase, ax->highCh, &qtmrConfig); ax->tmrBase->CHANNEL[ax->lowCh]。CTRL = TMR_CTRL_CM(kQTMR_PriSrcRiseEdge) |TMR_CTRL_PCS(ax->tmrInputSrc); ax->tmrBase->CHANNEL[ax->highCh]。CTRL = TMR_CTRL_CM(kQTMR_CascadeCount) |TMR_CTRL_PCS(ax->カスケードPcs); APP_QTMR_Disable_Low_OFLAG_Output(ax); QTMR_DisableInterrupts(ax->tmrBase, ax->lowCh, 0xFFU); QTMR_DisableInterrupts(ax->tmrBase, ax->highCh, 0xFFU); QTMR_ClearStatusFlags(ax->tmrBase, ax->lowCh, 0xFFU); QTMR_ClearStatusFlags(ax->tmrBase, ax->highCh, 0xFFU); } ax->位相 = kAxisIdle; ax->armed = false; ax->running=false; ax->done = 真; #if HARD_PWM_STATE_GUARD_ENABLE APP_StateGuard_Reset(斧); #endif } /* 使能 QTMR 中断 */ NVIC_SetPriority(TMR1_IRQn、2U); NVIC_SetPriority(TMR2_IRQn、2U); NVIC_SetPriority(TMR3_IRQn、2U); EnableIRQ(TMR1_IRQn); EnableIRQ(TMR2_IRQn); EnableIRQ(TMR3_IRQn); }静的ブールAPP_PWM_Config_Pulse(axis_ctrl_t *軸、 uint32_t highCnt400M、 uint32_t 低Cnt400M) { pwm_clock_prescale_tプリスケール; uint16_t期間ダックス; uint32_t totalCnt400M = highCnt400M + lowCnt400M; もし((軸 == NULL) ||(totalCnt400M == 0U))Return false; もし(!APP_PWM_SelectPrescaler_FromPeriodCnt400M(totalCnt400M、およびprescale、&periodTicks)) Return false; uint32_t highTicks32 = (uint32_t)((((uint64_t)periodTicks * (uint64_t)highCnt400M + ((uint64_t)totalCnt400M / 2ULL))/ (uint64_t)totalCnt400M); もし(highTicks32 == 0U) highTicks32 = 1U; もし(highTicks32 >= periodTicks) highTicks32 = (uint32_t)periodTicks - 1U; uint32_t riseTicks32 = 0U; uint32_t fallTicks32 = highTicks32; #if HARD_PWM_LOW_START_PHASE_ENABLE uint32_t lowTicks32 = (uint32_t)periodTicks - highTicks32; もし (lowTicks32 >= (2U * HARD_PWM_LOW_START_PHASE_MIN_TICKS)) { uint32_t LeadCnt400M = highCnt400M; uint32_t minLeadCnt400M = (uint32_t)HARD_PWM_LOW_START_PHASE_MIN_US * 400U; もし(desiredLeadCnt400M < minLeadCnt400M) desiredLeadCnt400M = minLeadCnt400M; uint32_t desiredLeadTicks32 = (uint32_t)(((uint64_t)periodTicks * (uint64_t)desiredLeadCnt400M + ((uint64_t)totalCnt400M / 2ULL))/ (uint64_t)totalCnt400M); if (desiredLeadTicks32 < HARD_PWM_LOW_START_PHASE_MIN_TICKS) desiredLeadTicks32 = HARD_PWM_LOW_START_PHASE_MIN_TICKS; uint32_t maxRiseByHalfTicks32 = lowTicks32 / 2U; uint32_t postGuardTicks32 = (uint32_t)(((uint64_t)periodTicks * (uint64_t)(HARD_PWM_VAL3_POST_LOW_GUARD_US * 400U) + ((uint64_t)totalCnt400M / 2ULL))/ (uint64_t)totalCnt400M); if(postGuardTicks32 < HARD_PWM_VAL3_POST_LOW_GUARD_MIN_TICKS) postGuardTicks32 = HARD_PWM_VAL3_POST_LOW_GUARD_MIN_TICKS; uint32_t maxRiseByPostGuardTicks32 = (lowTicks32 > postGuardTicks32) ? (lowTicks32 - postGuardTicks32) : 0U; uint32_t RiseTicks32; もし (maxRiseByHalfTicks32 >= desiredLeadTicks32) { selectedRiseTicks32 = desiredLeadTicks32; if(selectedRiseTicks32 > maxRiseByHalfTicks32) selectedRiseTicks32 = maxRiseByHalfTicks32; } そうでなければ(maxRiseByPostGuardTicks32 >= desiredLeadTicks32) { selectedRiseTicks32 = desiredLeadTicks32; if (selectedRiseTicks32 > maxRiseByPostGuardTicks32) selectedRiseTicks32 = maxRiseByPostGuardTicks32; } そうでなければ { selectedRiseTicks32 = maxRiseByPostGuardTicks32; } if (selectedRiseTicks32 >= HARD_PWM_LOW_START_PHASE_MIN_TICKS) { riseTicks32 = selectedRiseTicks32; fallTicks32 = riseTicks32 + highTicks32; } } #endif もし(fallTicks32 >= (uint32_t)periodTicks) fallTicks32 = (uint32_t)periodTicks - 1U; uint16_t riseTicks = (uint16_t)riseTicks32; uint16_t fallTicks = (uint16_t)fallTicks32; PWM_SetPwmLdok(axis->pwmBase, APP_PwmModuleMask(axis), false); uint16_t ctrl = axis->pwmBase->SM[axis->pwmModule]。CTRL; ctrl &=(uint16_t)(~PWM_CTRL_PRSC_MASK); ctrl |= PWM_CTRL_PRSC(プリスケール); axis->pwmBase->SM[axis->pwmModule]。CTRL = ctrl; axis->pwmBase->SM[axis->pwmModule]。INIT = 0U; axis->pwmBase->SM[axis->pwmModule]。VAL0 = 0U; axis->pwmBase->SM[axis->pwmModule]。VAL1 = ((uint16_t)(periodTicks - 1U); もし(軸>pwmチャンネル== kPWM_PwmA) { axis->pwmBase->SM[axis->pwmModule]。VAL2 = riseTicks; axis->pwmBase->SM[axis->pwmModule]。VAL3 = fallTicks; } そうでなければ (axis->pwmChannel == kPWM_PwmB) { axis->pwmBase->SM[axis->pwmModule]。VAL4 = riseTicks; axis->pwmBase->SM[axis->pwmModule]。VAL5 = fallTicks; } axis->pwmBase->SM[axis->pwmModule]。TCTRL = PWM_TCTRL_OUT_TRIG_EN(axis->outTrigMask); PWM_SetPwmLdok(軸>pwmBase、APP_PwmModuleMask(軸)、真); PWM_SetPwmLdok(軸>pwmBase、APP_PwmModuleMask(軸)、真); axis->pwmConfigValid = true; 軸>キャッシュドHighCnt400M = highCnt400M; axis->cachedLowCnt400M = lowCnt400M; 真を返す; } Re: RT1176 PWM startup failed こんにちは、 @liu626 さん。 設定を分離して、PWM3だけを初期化しても問題が続くかテストするのを手伝ってもらえますか? ご提供いただいた設定を確認し、その動作を再現するために、以下の質問があります。 axis_ctrl_t の定義は何ですか？ アプリケーションでHARD_PWM_LOW_START_PHASE_ENABLEとHARD_PWM_STATE_GUARD_ENABLEは有効になっていますか? 以下のアプリ機能はどのような働きをしますか？ APP_PWM_Unmap_Selected_Fault APP_PWM_ClearFault_Safe APP_PWM_出力無効化 APP_QTMR_Disable_Low_OFLAG_Output APP_StateGuard_Reset APP_PWM_SelectPrescaler_FromPeriodCnt400M APP_PwmModuleMask よろしくお願いします、 パブロ Re: RT1176 PWM startup failed お返事ありがとうございます。私が使用しているGPIOピンはrt1176のGPIO_EMC_B1_29です。「axis_ctrl_t」はモーターシャフトに関連する定義です。 * PWM出力パルス -> XBAR信号をトリガー -> パルスの立ち下がりエッジがQTMRの外部クロック入力を駆動 -> * QTMR 32ビットカスケードカウンタが1ずつ減少する -> 0に達すると、QTMR比較割り込みがトリガーされる -> 割り込みにより内部的にPWMがオフになる * 同時に、QTMR はハードウェア障害をトリガーし、PWM の物理出力ピンを直接プルダウンします。.id= AXIS_Y、 。名前= "Y", /* シリアルポートのログ記録またはブレークポイントデバッグでY軸を識別するために使用されます */ /* ================= PWM出力リソース割り当て ================= */ .pwmBase= PWM3、/* Y軸はFlexPWM3モジュールを使用します */ .pwmモジュール= kPWM_Module_0, /* PWM3 のサブモジュール 0 を使用します (各 PWM には 0 から 3 までの 4 つのサブモジュールがあります) */ .pwmChannel= kPWM_PwmA, /* サブモジュール0のフェーズAの出力ピンを使用します。これは物理ピンGPIO_EMC_B1_29に対応します。 */ /* ================= 32 ビット QTMR カスケード カウント リソース割り当て ================= */ .tmrBase= TMR3, /* Y軸はQTMR3ペリフェラル(IRQ割り込み番号TMR3_IRQnに対応します)を使用します */ .lowCh= kQTMR_Channel_0, /* 16ビットローカウンタ:TMR3のチャンネル0を使用します */ .highCh= kQTMR_Channel_1,/* 16ビットハイカウンタ:TMR3のチャンネル1を使用 */ /* 👉 .lowCh と .highChこれらはペアになっており、ハードウェアレベルでは自動的に32ビットカウンタに結合されます。 /* ================= ハードウェアカスケードクロックソースの構成 (コアクリティカル) ================= */ .tmrInputsrc=kQTMR_ClockCounter0InputPin, /* チャンネル0のクロックソース:「外部ピン入力0」に設定。 XBAR構成では、PWM3からのパルスの落ち降り縁がXBARを介してTMR3のチャネル0の入力ピンに接続されます。 したがって、PWMでパルスが出力されるたびに、チャンネル0(16ビット)は一度だけ減衰操作を行います。*/ .cascadePcs = 4U, /* 高16ビットチャネル(チャネル1)のクロックソース(PCS)の設定。 i.MX RTのQTMRレジスタにおけるPCS値は以下の通りに対応します。 0-3 = 外部ピン入力; 4 = チャネル0のオーバーフロー/終了イベント; 5 = チャネル1のオーバーフロー/終了イベント; 6 = チャネル2のオーバーフロー/終了イベント; 7 = チャネル3のオーバーフロー/終了イベント。 ここでは4Uとして構成されており、つまり「TMR3のチャネル1」が「TMR3のチャネル0のオーバーフローイベント」を監視することを意味します。 HARD_PWM_LOW_START_PHASE_ENABLE と HARD_PWM_STATE_GUARD_ENABLE が有効になっています。APP_PWM_Unmap_Selected_Fault 機能：現在の軸に対応する故障ピンマッピングを削除します。障害を無効にするには、基となる PWM_SetupFaultDisableMap 関数を呼び出します。その目的は、ハードウェア障害が不要な場合に、偶発的な外部干渉によってPWMがオフになるのを防ぎ、根本的なデバッグプロセスを容易にすることです。 APP_PWM_ClearFault（元のコード関数） 機能：PWMモジュールの障害状態フラグ（axis->pwmBase->FSTS）をクリアします。ハードウェア故障が発生した後は、PWMの再起動を許可する前にまずこのフラグをクリアしなければなりません。 APP_PWM_出力無効化 機能: PWMタイマーを即座に停止し、ピンの出力を強制的に低レベル（PWM_SetPwmForceOutputToZero）にし、出力を有効にします。この目的は、ピンがモーター起動前に浮かんだりデフォルト状態に置かれたりして高レベルを出力し、モーターが不規則に動くのを防ぐことです。 APP_QTMR_Disable_Low_OFLAG_Output 機能：QTMRのOFLAG（ステータスフラグ）出力を無効にし、OFLAGを低レベルに強制的に設定します。XBARハードウェアと連携して、その役割はQTMR出力からPWMフォルトピンへの経路を遮断し、起動前にフォルトが誤ってトリガーされるのを防ぐことです。 APP_StateGuard_Reset 機能：国家警備隊（番犬）のカウンターと旗をクリアします。この関数は、HARD_PWM_STATE_GUARD_ENABLEが有効になっている場合に、長時間パルス変化がない状態やデッドロックが発生した場合に、システムを停止または再起動する前にこれらの保護変数をリセットするために使用されます。 APP_PWM_SelectPrescaler_FromPeriodCnt400M 機能：これは周波数計算の非常に重要な基本機能です。これは、High + Lowの合計400MHzカウント値を受け取り、16ビットPWMレジスタに収まるように設定すべきプリスケーラ（PRSC）とPWM周期（PERIOD）の数を計算します。ご注意ください：計算された周期が65535を超え、かつ除算係数が範囲外の場合、この関数はfalseを返し、モーターの起動に失敗します。 APP_PwmModuleMask 機能：PWMサブモジュールのインデックス番号（例えば、値が0のkPWM_Module_0）を、Nビット左シフトしたビットマスクに変換します。NXPのPWMレジスタの多く（OUTEN、MCTRLなど）はビット単位で制御されます。この関数は、正しいバイナリマスクを生成する役割を担っています。 Re: RT1176 PWM startup failed 原因を突き止めました。これは、cm4コア内のPIT割り込みの内部負荷が大きすぎるため、cm7コアのPWM動作に影響を与えているためです。PIT割り込みの負荷を軽減したところ、PWM起動時の不具合が解消しました。

Help finding capacitor for PCF8563TS/5,118 I'm working with a PCF8563TS/5,118 IC, trying to get the external cap on OSCI pin right.  I'm working with a 50k ESR, 12.5pF 32.568KHz crystal, shortest possible traces, Schematic just like in the application diagram on the datasheet. I tried making the calculations by consulting both the datasheet and UM10301 to get an understanding on the device. I found it difficult to find out a clear way to calculate the value for the external cap because the datasheet mentions parallel and series on different pages of the same topic, OSCI and OSCO.  I see there is an internal 25pF cap in parallel with the external OSCI and OSCO pins. Table 30 on the datasheet indicates CL is calculated in parallel, but has a note that shows the calculation for series capacitors instead. I can't find an external cap that makes the device work. Getting no I2C response. I tried 25pF, 22.5pF, 20pF, 25pF, 10pF, 8.2pF, 6pF. All 0603 C0G/NP0 caps. I did get it to work on a different board by not placing a capacitor at all. Which doesn't make any sense after making the calculations. I would like to please get an example of how you calculate a value for these inputs (12.5pF 50k ESR crystal) because I haven't been able to make it work neither by calculating it nor by bruteforcing values. Re: Help finding capacitor for PCF8563TS/5,118 Yes that's the value of the integrated internal capacitor and I mentioned that in my own post. I have read that file. It would be way more helpful if you actually wrote what you intend to convey. Thanks for taking the time though Re: Help finding capacitor for PCF8563TS/5,118 UM10301 User Manual for PCF85x3, PCF85x63, PCA8565, PCF2123, and PCA21125 Re: Help finding capacitor for PCF8563TS/5,118 Dear David, db16122 correctly pointed you to the Table 3. in the UM10301. If your target load capacitance is 12.5pF, then you need to connect a trim capacitor on the OSCI pin with 25pF middle value.  This 25pF value can be calculated from the formula below the Table 30. in the PCF8563 datasheet.  Where CL is the target load capacitance, in your case 12.5pF.  Cosco is the known internal capacitance, the 25pF.  From the formula, the Ctrim can deduced: CL=Ctrim*Cosco/(Ctrim+Cosco) CL*Ctrim+CL*Cosco=Ctrim*Cosco CL*Cosco=Ctrim*Cosco-CL*Ctrim CL*Cosco=Ctrim*(Cosco-CL) CL*Cosco/(Cosco-CL)=Ctrim Ctrim=CL*Cosco/(Cosco-CL)=12.5*25/(25-12.5)=312.5/12.5 Ctrim=25pF The variable trim capacitor is required because there is margin for the internal Cosco capacitor. Cosco may vary from 15pF to 35pF.  With Best Regards, Jozef

IO Expansion for LEDs I am currently designing on a switch matrix board for custom measurement equipment. To route the signals I plan on using optical relays, the G3VM-61DR1 to be precise. So I need to control >250! LEDs (1,5-1,8V 6-8mA) somehow. Only <25 will be turned on at the same time Supply voltage will be 3.3V or lower, temperature should be around 40°C We just need to turn them on or off, no dimming or PWM I don't want to use an LED driver because of the noise it might/will introduce I can't use a classic matrix arrangement since it is unknown which switches will be on at the same time So the only option is to have a discrete output for each relay/LED, your IO Expanders look promising for this, eg. the PCAL6524. Because of the high channel count I want to reduce the components per channel as much as possible, so I have some questions: Can I rely on the 7,5mA current setting of the Agile IO devices and omit the LED series resistor? If this is ok, what are possible side effects? Since the devices start configured as Input some experience high currents when they are used to control LEDs(eg. PCA9535A  Datasheet page 14/15). The classic fix with a pullup for each channel is not cool for so many channels. Does this also affect the Agile IO devices? Can this be circumvented by supplying the LEDs with 3.3V and the expanders with 1.65V? Thank you in advance Otto Re: IO Expansion for LEDs PCAL6524 is well suited for driving a large number of optical relays and LEDs. However, the Agile I/O drive strength is not intended to replace the required series current-limiting resistors. To mitigate the risk of unintended current during power-up when the I/Os are still in their input state, options such as using a 3.3 V LED supply with a lower VDD(P), or implementing a global LED power switch, may be considered. Nevertheless, individual current-limiting resistors should always be retained for each LED channel.

射频功率放大器设计 - MRF13750H 你好！我正在使用 MRF13750H 设计一个 805 MHz 的射频功率放大器，我的设计基于数据手册中的 915 MHz 参考电路。但是，我只能使用 Usimmics 来模拟匹配网络；我无法使用 NXP 用来打开其设计文件的软件。 因此，为了设计匹配网络，我请求 NXP 提供 MRF13750H 915 MHz 参考电路的完整原理图，包括微带线尺寸，因为数据手册中没有提供此信息。如果可能的话，我还想请求提供 805 MHz 的大信号模型阻抗；否则，我将根据 915 MHz 提供的值进行设计。915MHz 参考电路和数据手册附在下方。 另一方面，如果有人知道在 805 MHz 频率下设计匹配网络的其他方法，我将不胜感激。

AUTOSAR MCAL MPC5744P Hello, is there any free compiler option to build the AUTOSAR MCAL applications for MPC5744P? Re: AUTOSAR MCAL MPC5744P Hello, For the legacy AUTOSAR MCAL package for MPC5744P (MPC574xP MCAL 4.x), the officially validated toolchains are typically: Wind River Diab Compiler (most commonly qualified) Green Hills Compiler (GHS) In practice, no officially supported free compiler is provided for MPC5744P AUTOSAR MCAL. Although the MPC5744P ecosystem supports GCC through S32 Design Studio for Power Architecture for general embedded development, the MCAL package itself was developed and validated primarily with Diab and GHS. The DEVKIT-MPC5744P information lists GCC (via S32DS), GHS, Cosmic, and other toolchains for MPC5744P development in general, but that does not mean the AUTOSAR MCAL release is qualified for GCC. List of validated compilers is always in release notes supplied with MCAL package. Best regards, Peter

KW47 扩展广告 您好， 我使用的 SDK 版本是 26.06。 该例程为 kw47loc_loc_reader_freertos。 #define gAppIsPeripheral_d                   1U   经查明，调用 BluetoothLEHost_StartExtAdvertising 的返回值为 4(gBleFeatureNotSupported_c) 我想使用扩展广告。请给予我支持。   谢谢您！   Re: KW47 extended advertising 你好， 希望你一切都好。 您对示例中做了哪些修改？要在应用程序中配置扩展广告，首先需要使用 Gap_SetExtAdvertisingParameters 设置扩展广告参数，然后调用 Gap_SetExtAdvertisingData 设置广告数据。 完整的设置步骤和参数详情，请参阅本指南：扩展广告 — MCUXpresso SDK 文档   希望这能帮到你！ 此致， 安娜·索菲亚。 Re: KW47 extended advertising 您好， 我使用的 SDK 版本是 26.06。导入的例程是 kw47loc_loc_reader_freertos。将该例程中 gAppIsPeripheral_d 的宏定义修改为 1，同时在 BluetoothLEHost_AppInit 函数中添加 BleApp_Start()；其他部分未做任何修改。 经查明，调用 BluetoothLEHost_StartExtAdvertising 的返回值为 4(gBleFeatureNotSupported_c)   谢谢您！ Re: KW47 extended advertising 你好@wjw2026 ， 请问您是否能够按照《扩展广告指南》中的步骤进行操作？扩展广告的外围设备配置涉及几个必要的步骤，验证这些设置可能有助于解决您观察到的问题。 此致， 安娜·索菲亚。

RFパワーアンプ設計 - MRF13750H こんにちは！私はこのMRF13750Hを使って805 MHzのRFパワーアンプを設計しており、その設計はデータシートにある915 MHzの基準回路に基づいています。しかし、私はUsimmicsしか対応できないネットワークのシミュレートに使えます。NXPがデザインファイルを開くために使っているソフトウェアにはアクセスできません。 したがって、マッチングネットワークの設計にあたり、データシートには記載されていないマイクロストリップライン寸法を含むMRF13750H 915 MHz参照回路の完全な回路図をNXPに依頼しています。可能であれば、805 MHzの大信号モデルのインピーダンスもお願いしたいです。それ以外の場合は、915 MHzの値に基づいて設計します。915MHzにおける基準回路とデータシートを以下に添付します。 一方で、805MHzでのマッチングネットワーク設計の別の方法を知っている方がいれば、ぜひご意見をいただけるとありがたいです。

補足説明が必要：QSPIフラッシュメモリの容量がデータシートと実際のハードウェアで一致しない NXPチームの皆様、こんにちは。 指定された部品番号のボードを購入しましたが、オンボードのQSPIフラッシュ容量に関して不一致があることに気づきました。 MCIMX6ULL-EVK データシートによると、このボードには256MBのQSPIフラッシュメモリが搭載されているとのことです。しかし、オペレーティングシステムからフラッシュメモリのサイズを確認すると、32MBとしか表示されません。 これを確認するために、デザインファイルをダウンロードし、BOMを確認しました。私も同じフラッシュデバイスの部品番号をDigiKeyとMouserで調べてみましたが、どちらも256Mbitのフラッシュメモリと記載されており、これは256MBではなく32MBに相当します。 Element14の代理店を通じてボードを購入しました。 以下の点について明確にしていただけますか: データシートに誤植があり、256 MBではなく256 Mbitと記載されるべきです。 データシートと実際のハードウェアでストレージの分類が異なるように見える理由について、他に何か説明があるのだろうか？ 私の調査によると、搭載されているフラッシュメモリは256MBではなく、256Mbit（32MB）のようです。 ご確認いただければ幸いです。 よろしくお願いします。 i.MX6UL Re: Clarification Required: QSPI Flash Capacity Mismatch Between Datasheet and Actual Hardware おっしゃる通りです。関係部署に報告します。256Mbitということは、32MBということですね。

PCF8563TS 生命周期状态和长期供货情况 你好呀.... 我们目前在我们的一款产品中使用了PCF8563TS RTC，并希望更好地了解其长期生命周期状况。 过去，我们的产品是基于PCF8563BS的，但该芯片最终已达到生命周期结束 (EOL)。因此，我们不得不进行完整的硬件重新设计，以迁移到另一个封装，这产生了额外的工程工作量、验证和制造成本。 鉴于以往的经验，我们想问： 是否有任何迹象表明PCF8563TS即将停产或处于 NRND 状态？ 这款设备是否有长期供货计划？ NXP能否分享一些关于其预期产品生命周期或路线图的信息？ 对于围绕 PCF8563TS 设计新产品的客户，有什么建议吗？ 我们理解未来的计划可能会有所改变，但任何关于该设备预期寿命的指导都将有助于我们做出明智的设计决策，并降低未来重新设计的风险。 感谢您的支持。 Re: PCF8563TS Lifecycle Status and Long-Term Availability 我做了一些调查，对于像 PCF8563TS $0.5 这样的芯片，由于存货很大，停止生产并不容易。 Re: PCF8563TS Lifecycle Status and Long-Term Availability 你好，维克多， 感谢您对恩智浦半导体产品的关注，也感谢您给我们提供支持的机会。 我们拥有长期供应计划下的产品，可确保未来 10-15 年的稳定供应。 长寿计划 然而， PCF8563TS 不属于产品延保计划，因此没有停产通知或最后购买日期。具体情况将取决于客户需求。 此致， 阿隆德拉 技术支援 恩智浦半导体

eFlexPWM入力キャプチャがS32K364でキャプチャされない - フラグは設定されているがCAPTCOMPBはゼロのまま 私はS32K364マイクロコントローラのeFlexPWMモジュール(インスタンス IP_EFLEXPWM_0)を使って、入力キャプチャを通じて外部信号の周波数と周期を測定しています。私は サブモジュール2 (SM[2])を使用しています。私の構成は以下の通りです: SM2_CAPTCTRLB->EDGB0 = 0x02; （キャプチャ回路0の場合、立ち上がりエッジでキャプチャ） SM2_CAPTCTRLB->EDGB1 = 0x02; （キャプチャ回路１の立ち上がりエッジでのキャプチャ） SM2_ARMB = 1; (キャプチャー回路をArm) コードを実行した後、以下のことが確認されました。 で SM2_CAPTCTRLBのカウンタステータスビットは以下を示します。 CB0CNT = 0x4 CB1CNT = 0x4 で SM2_STS 、両方のフラグビットがセットされています。 CFB0 = 1 CFB1 = 1 しかし、取得された値（ SM2_CAPTCOMPB ）は 0 どちらのキャプチャ回路においても、データはラッチされません。 これは何が原因でしょうか?他に何か必要な設定（例えば、クロックの有効化、入力多重化、カウンタの設定など）で、私が見落としているものはありますか？フラグはキャプチャイベントが検出されたことを示しますが、キャプチャされた値は更新されません。どんなご意見でも大変ありがたく思います。 必要に応じて、ピン多重化設定やカウンターモードなどの詳細情報を追加してください。幸運を！ Re: eFlexPWM input capture not capturing on S32K364 – flags set but CAPTCOMPB remains zero ハイ まず、最新のS32K3 RTD 7.0.xを確認しました。しかし、 S32設定ツール はまだ eFlexPWM E-Capture 機能をサポートしていません。 もしよければ、S32K396でテストしたいので、あなたのプロジェクトを共有してもらえますか?(残念ながら、私はS32K364を持っていません。私は S32K396-BGA-DC1 評価ボードしか持っていません。) 次に、 S32K396RM（Rev. 4、11/2024） の 「56.3.14 拡張キャプチャ（E-Capture）」の セクションを確認してください。そのセクションで言及されているレジスタ、特に図 254 のレジスタを確認してください。E-キャプチャ ロジック。eFlexPWM_0レジスターのスクリーンショットも共有しても構いません。 SM2_CAPTCTRLBの[EDGB0]、[EDGB1]、[ARMB]で言及されたビット以外に、 SM2_CAPTCTRLBの他のビットはどのように設定しましたか？   SM2_CAPTCTRLB[CB0CNT] = 0x4および[CB1CNT] = 0x4を確認されたとのことですので、対応するレジスタ値SM2_CVAL4 、 SM2_CVAL4CYC 、 SM2_CVAL5 、およびSM2_CVAL5CYCを確認されましたか？   さらに、 SM2_CAPTCOMPB[EDGCNTB]の値を読みたい場合は、まず SM2_CAPTCTRLB[EDGCNTB_EN] と SM2_CAPTCOMPB[EDGCMPB]を有効にしてください。 なぜ SM2_CAPTCOMPB[EDGCMPB] を0に設定しているのか分かりません。図254のコンパレータが使えなくなるように見える からです。E-キャプチャロジック が正しく機能しない。 よろしくお願いいたします ロビン Re: eFlexPWM input capture not capturing on S32K364 – flags set but CAPTCOMPB remains zero こんにちは、 @Robin_Shen さん。 MCTRLレジスタとCAPTCTRLBレジスタを適切に設定することで、外部周波数測定を正常に実装できました。しかし、テストの結果、私が達成できる最低周波数は5kHzであり、私の要求は1Hz程度の低周波数をサポートすることになっています。 プリスケーラーとプリスケーラー代替設定を調整してみましたが、改善は見られませんでした。何か提案やトラブルシューティングの方法を教えていただけますか?サポートありがとうございます。 Re: eFlexPWM input capture not capturing on S32K364 – flags set but CAPTCOMPB remains zero サブモジュール2の周期が短すぎるようです。「 56.3.18.3 サブモジュール0よりも低い周波数でサブモジュールを実行する」を読んで、サブモジュール2にAUX_CLKやEXT_CLKなどのより低い周波数のクロックソースを選択してみてください。

需要澄清：数据手册与实际硬件的 QSPI 闪存容量不匹配 您好，NXP团队， 我购买了一块符合指定零件编号的电路板，但我发现板载 QSPI 闪存容量存在差异。 MCIMX6ULL-EVK 数据手册显示，该电路板包含 256 MB QSPI 闪存。但是，当我从操作系统中检查闪存大小时，它只显示 32 MB。 为了验证这一点，我下载了设计文件并检查了物料清单。我还在 DigiKey 和 Mouser 上查找了相同的闪存设备部件号，两家都将其列为 256 Mbit 闪存，这相当于 32 MB，而不是 256 MB。 我通过 Element14 代理商购买了这块板。 请问您是否可以澄清以下事项： 数据手册中有一处拼写错误，应该写成 256 Mbit 而不是 256 MB？ 或者，数据手册和实际硬件似乎使用了不同的存储分类，还有其他解释吗？ 根据我的调查，安装的闪存设备似乎是 256 Mbit (32 MB) 而不是 256 MB。 希望您能确认一下。 谢谢！ i.MX6UL Re: Clarification Required: QSPI Flash Capacity Mismatch Between Datasheet and Actual Hardware 你说得对，我会向相关团队汇报，是 256Mbit，也就是 32MB。

PCF8563TS Lifecycle Status and Long-Term Availability Hello there.... We are currently using the PCF8563TS RTC in one of our products and would like to better understand its long-term lifecycle status. In the past, our product was based on the PCF8563BS, which eventually reached End of Life (EOL). As a consequence, we had to perform a complete hardware redesign to migrate to another package, generating additional engineering effort, validation, and manufacturing costs. Considering this previous experience, we would like to ask: Is there any indication that the PCF8563TS is approaching EOL or NRND status? Is there a long-term availability plan for this device? Can NXP share any information regarding its expected product lifecycle or roadmap? Are there any recommendations for customers designing new products around the PCF8563TS? We understand that future plans may be subject to change, but any guidance regarding the expected longevity of this device would help us make informed design decisions and reduce future redesign risks. Thank you for your support. Re: PCF8563TS Lifecycle Status and Long-Term Availability I did some research, and for chips like the PCF8563TS $0.5, which have a large inventory, it's not so easy to stop production. Re: PCF8563TS Lifecycle Status and Long-Term Availability Hello Victor,  Thank you for your interest in NXP Semiconductors products and for the opportunity to support you. We have products under longevity program which ensures a stable supply for the next 10-15 years.  Longevity program  However PCF8563TS is not part of the longevity program there is no discontinuation notice or last purchase date. Will depend on customer's demands Best regards, Alondra Technical Support NXP Semiconductors

i.MX95 FlexSPIブートイメージ用のAPPコンテナソフトウェアバージョンを更新できません こんにちは、専門家の皆様。 i.MX95プラットフォームの開発を進めており、ROLLBACK_INDEX_IN_CONTAINERを使ってロールバック保護を有効にしています。 local.confに以下の変数を追加しました。 export ROLLBACK_INDEX_IN_CONTAINER = "1" この値はビルドプロセス全体に伝播され、ビルドログにはmkimage_imx8が「1」で呼び出されたことが記録されています。 eMMCブートイメージを構築する際、生成されたイメージを解析するとコンテナソフトウェアのバージョンが正しく更新されていることが確認されます。  if [ 1 ]; then \ ./../mkimage_imx8 -soc IMX9 -cntr_version 2 -sw_version 1 -c \ -ap bl31.bin a55 0x8A200000 \ -ap u-boot-hash.bin a55 0x90200000 \ -ap tee.bin a55 0x8C000000 \ -out u-boot-atf-container.img; \   しかし、FlexSPIのブートイメージ(imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi)を構築する際には、画像を解析してもデフォルトのソフトウェアバージョンが報告されます ./mkimage_imx8 -soc IMX9 -parse imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi SOC: IMX9 Input container binary to be parsed: imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi ********************************* * * * APP CONTAINER 1 * * * ********************************* Length: 0X320 (800) Tag: 0X87 Version: 0X2 Flags: 0X10 Num images: 6 Fuse version: 0 SW version: 0X0 Sig blk offset: 0X310 iMX95/soc.mak で興味深い点に気づきました。flash_a55_flexspi のビルド時に sw_version が含まれていないのです。 flash_a55_flexspi: $(MKIMG) $(AHAB_IMG) $(MCU_IMG) $(SPL_A55_IMG) $(OEI_IMG_M33) fcb.bin u-boot-atf-container.img ./$(MKIMG) -soc IMX9 -cntr_version $(CTNR_VERSION) $(XSPI_FAST_HASH) -dev flexspi -append $(AHAB_IMG) -c $(OEI_OPT_M33) -msel $(MSEL) \ -m33 $(MCU_IMG) 0 $(MCU_TCM_ADDR) \ -ap $(SPL_A55_IMG) a55 $(SPL_LOAD_ADDR_M33_VIEW) $(V2X_DUMMY) -fcb fcb.bin $(FCB_LOAD_ADDR) -out flash.bin $(call append_container,u-boot-atf-container.img,1) $(call append_fcb) 私の質問は以下のとおりです。 FlexSPIのブートイメージのソフトウェアバージョンを更新するROLLBACK_INDEX_IN_CONTAINER期待されていますか? FlexSPIイメージは、ロールバックインデックスやソフトウェアバージョンを別々に設定する必要がある別のコンテナ生成フローに従っているのでしょうか? これは、i.MX95のimx-mkimageビルドフローにおける既知の制限事項または問題でしょうか？ もしi.MX95でFlexSPIブートイメージのROLLBACK_INDEX_IN_CONTAINERを成功裏に有効にした方がいれば、予想されるフローや追加設定について教えていただけますか? よろしくお願いいたします！ よろしくお願いいたします。 アルン・クマール Re: Unable to update APP container software version for i.MX95 FlexSPI boot image こんにちは、@arun16598さん FlexSPIイメージはAHABフォーマットの別のバリエーションではなく、まずブートコンテナを生成し、次にU-Boot/ATFコンテナを追加するという複合的なプロセスを採用しています。あなたの-sw_version 1はu-boot-atf-container.imgに設定されています。ただし、flash_a55_flexspiが最初に作成するSM/M33、OEI、SPL、FCBを含むAPPコンテナは-sw_versionオプションを通さないため、そのコンテナは依然としてSWバージョン0を表示します。ROLLBACK_INDEX_IN_CONTAINERはセカンダリのU-Boot/ATF APPコンテナを生成するために使われますが、flash_a55_flexspiが作成したプライマリAPPコンテナには渡されません。最初のFlexSPI APPコンテナに同じソフトウェアバージョンが必要な場合は、flash_a55_flexspiのmkimage_imx8呼び出しに-sw_version $(ROLLBACK_INDEX_IN_CONTAINER)を追加する必要があります。 真の AHAB アンチロールバックの強制が目的であれば、確認および設定すべき重要な設定はsw_versionだけでなくfuse_versionと-fuse_versionです。S PSDKのi.MX95アンチロールバックの例では、OEMアンチロールバックはAHABコンテナYAMLで指定されたfuse_versionを使用し、そのバージョンはその後ELEのOEM_FW_FUSEコミットプロセスを介して送信されることが明確に示されています。 よろしくお願いします、 志明

KW47拡張広告 こんにちは、 私が使っているSDKのバージョンは26.06です。 ルーチンは kw47loc_loc_reader_freertos です。 #define gAppIsPeripheral_d                   1U   BluetoothLEHost_StartExtAdvertising の呼び出しの戻り値は 4(gBleFeatureNotSupported_c) であることが判明しました。 拡張広告を利用したいです。どうかサポートしてください。   よろしくお願いします！   Re: KW47 extended advertising こんにちは、 あなたの調子が良いといいのですが。 サンプルコードにどのような変更を加えましたか？アプリケーション内で拡張広告を設定するには、最初のステップはGap_SetExtAdvertisingParametersで拡張広告パラメータを設定し、Gap_SetExtAdvertisingDataを呼び出して広告データを設定することです。 セットアップ手順とパラメータの詳細については、こちらのガイドをご覧ください: 拡張広告 — MCUXpresso SDKドキュメント   お役に立てば幸いです！ よろしくお願いします、 アナ・ソフィア。 Re: KW47 extended advertising こんにちは、 私が使っているSDKバージョンは26.06です。インポートされたルーティンはkw47loc_loc_reader_freertosです。 ルーチン内のgAppIsPeripheral_dのマクロ定義を1に修正し、同時にBluetoothLEHost_AppInit関数にBleApp_Start()を追加します。 他に何も変更されていません。 BluetoothLEHost_StartExtAdvertising の呼び出しの戻り値は 4(gBleFeatureNotSupported_c) であることが判明しました。   よろしくお願いします！ Re: KW47 extended advertising こんにちは、 @wjw2026 さん。 拡張広告ガイドの手順を踏めたかどうか確認していただけますか?拡張広告のペリフェラル設定にはいくつかの必要なステップがあり、それらの設定を確認することで、観察している動作のトラブルシューティングに役立つかもしれません。 よろしくお願いします、 アナ・ソフィア。

Clarification Required: QSPI Flash Capacity Mismatch Between Datasheet and Actual Hardware Hello NXP Team, I have purchased a board with the specified part number, and I noticed a discrepancy regarding the onboard QSPI flash capacity. MCIMX6ULL-EVK  The datasheet states that the board includes 256 MB QSPI flash. However, when I check the flash size from the operating system, it reports only 32 MB. To verify this, I downloaded the design files and checked the BOM. I also looked up the same flash device part number on DigiKey and Mouser, and both list it as 256 Mbit flash memory, which corresponds to 32 MB, not 256 MB. I purchased the board through the Element14 distributor. Could you please clarify whether: The datasheet contains a typo and should state 256 Mbit instead of 256 MB? Or is there another explanation for why the datasheet and the actual hardware appear to use different storage classifications? From my investigation, it appears that the installed flash device is 256 Mbit (32 MB) rather than 256 MB. I would appreciate your confirmation. Thank you. i.MX6UL Re: Clarification Required: QSPI Flash Capacity Mismatch Between Datasheet and Actual Hardware You are right, I will report it to related team, it is 256Mbit, that means 32MB.

PCF8563TSのライフサイクル状況と長期的な供給状況 こんにちは.... 現在、 PCF8563TS RTCを製品の一つに使用しており、その長期的なライフサイクル状況をよりよく理解したいと考えています。 過去には、私たちの製品は PCF8563BSをベースにしており、最終的にはエンド・オブ・ライフ(EOL)に達しました。その結果、別のパッケージへの移行のためにハードウェアの全面的な再設計を行い、追加のエンジニアリング作業、検証、製造コストが発生しました。 こうした過去の経験を踏まえ、私たちは以下の点について質問したいと思います。 PCF8563TSがEOL（販売終了）またはNRND（新製品化）に近づいている兆候はありますか？ このデバイスの長期的な供給計画はありますか？ NXPは今後の製品ライフサイクルやロードマップについて何かCAN情報を共有できますか? PCF8563TSで新製品をデザインするお客様におすすめはありますか? 今後の計画は変更される可能性があることは理解していますが、この装置の期待される寿命に関する指針があれば、デザイン上の判断を下し、将来の再設計リスクを減らすのに役立ちます。 再開まで今しばらくお待ちください。 Re: PCF8563TS Lifecycle Status and Long-Term Availability 調べてみたところ、PCF8563TS $0.5のように在庫が多いチップでは、生産を止めるのは簡単ではありません。 Re: PCF8563TS Lifecycle Status and Long-Term Availability こんにちは、ビクターさん。 NXPセミコンダクターズの製品にご関心をお寄せいただき、またサポートの機会をいただきありがとうございます。 今後10〜15年間安定した供給を保証する長寿命プログラムの製品もあります。 長寿プログラム しかしPCF8563TSは長寿プログラムには含まれておらず、販売終了の通知や最終購入日はありません。お客様の要望次第です 敬具 アロンドラ 技術サポート NXPセミコンダクターズ

DSP实现方式：微控制器或FPGA 大家好，我知道这个话题在这个子版块已经被反复讨论过了，但我只是想从这个领域的专家那里得到一些特定领域的建议。我想知道的是，如果我对通信领域的 DSP 应用感兴趣，并且想从事相关的实现工作，那么花时间学习微控制器编程是否值得？我是一名电子与计算机工程专业的本科生，所以我想知道我是否应该直接专注于FPGA，说实话，我对FPGA更感兴趣。我很困惑，因为我看到有人建议说，要使用现在越来越多地采用的片上系统 (SoC)，确实需要具备嵌入式软件编程技能。 如果这个问题很重复，我真的非常抱歉！我一直没能找到关于此事的合适答案，现在我可能需要稍微调整一下优先事项。非常感谢您的建议！ Re: DSP Implementation: Microcontrollers or FPGAs 你好@endros ， 如果您主要对通信领域的 DSP 感兴趣，那么专注于 FPGA 绝对是值得的，特别是对于高吞吐量或实时实现而言。也就是说，掌握基本的嵌入式 C 技能仍然很有用，因为许多 SoC/FPGA 平台都涉及软件控制、驱动程序和系统集成。我会优先学习 FPGA/DSP 基础知识，但也会花足够的时间学习 MCU 编程，以便熟悉嵌入式工作流程。你不需要成为一名纯粹的嵌入式软件工程师，但也不应该完全忽视它。 希望对您有所帮助。 BR 塞莱斯特