ディープスリープを終了する際の遅延の周波数計算が正しくありませんか?

Tip / ログイン to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Translation_Bot
Community Manager
Community Manager
Community Manager

CM4で実行されている CY8C6137BZI-F14 に基づくカスタムBSPがあります(CM0では何もしていません)。 このプロジェクトでは、CLK_FASTは8MHzに初期化CLK_HF0 96MHzで、16MHzのECOから供給されるFLL(これも96MHz)から供給されます。 FAST クロックを 8 MHz / 24 MHz / 48 MHz の間で変更し、その際に Cy_SysLib_SetWaitStates() と SystemCoreClockUpdate() を適切に呼び出します。 私たちのプロジェクトはFreeRTOSを使用しており、vApplicationSleep()では、Cy_SysPm_CpuEnterDeepSleep(CY_SYSPM_WAIT_FOR_INTERRUPT)を介してディープスリープに入る前に、LVDを無効にします。 ディープスリープを終了すると、LVDを再度有効にします。 インフィニオンのPDLマニュアルおよびTRMによると、誤った割り込み(経験から学んだ)を回避するために、20uSの最小遅延が必要です。 私たちの開発では、20 uSでは不十分であるように思われたため、最終的に35 uSに増やしました。

ディープスリープから抜け出したときに再び偽のLVDトリップで問題が発生したので、これをもう一度掘り下げています。 この問題は、デバッガーがアタッチされていない場合にのみ発生します (通常、最適化レベルを -O1 に設定したカスタム構成を実行します)。 遅延を50uSに増やしましたが、それでもリセットされます。 その理由を理解しようとすると、Cy_SysLib_DelayUs(50)の前にGPIOトグルローを追加し、その後GPIOをハイに戻しました。 そして驚いたことに、遅延は24uSしかかかりません! 遅延を75 uSに増やしてみましたが、ロジックアナライザでは32.5 uSかかります。 マニュアルをもう一度掘り下げた後、私は何の推論も思いつかなかったので、PSoC SystemCoreClock変数を動作を変更せずに揮発性に設定してみました。 好奇心から、ディープスリープを終了するとすぐにSystemCoreClockUpdate()を呼び出したので、LVDが有効になり、Cy_SysLib_DelayUs()が呼び出される前に呼び出しました。 低くて見よ、遅延は今や想定どおりです!

 

私はコミュニティをいじくり回してきましたが、他の人が問題を抱えている直接的な例は見つかりませんでした。https://community.infineon.com/t5/PSoC-6/Frequency-Calculation-bug-when-using-ExtClk-but-ok-with-IMO... 似ているようですが、完全ではありません。 SystemCoreClockUpdate()はディープスリープを終了するときに呼び出されることになっているとどこかに記載されていますか? Cy_SysPm_CpuEnterDeepSleep()のマニュアルには、「この関数は、システムのディープスリープに入る直前に低速および高速クロック分周器を変更し、ウェイクアップ後にこれらの分周器を復元します」と記載されているため、クロックは期待どおりに戻りますが、システム遅延関数で使用される変数を再計算しないバグはありますか?

乾杯

0 件の賞賛
1 解決策
Translation_Bot
Community Manager
Community Manager
Community Manager

私は自分の問題を解決します、それは https://community.infineon.com/t5/PSoC-6/PSoC62-Wrong-delay-in-CM4-with-Cy-SysLib-Delay-if-ECO-used/... と同じです-まだModus 2.4を使用していますが、そのEcoSetFrequency()関数を手動で追加して呼び出した後、遅延は意図したとおりに機能しています。

元の投稿で解決策を見る

0 件の賞賛
2 返答(返信)
Translation_Bot
Community Manager
Community Manager
Community Manager

編集:もっと遊んだ後、SystemCoreClockUpdate()に呼び出しを追加した後、同じ「肯定的な」結果は表示されなくなりました。 私はそのルーチンを私たちのシステムで28uSを取るように計時しました。 SystemCoreClockUpdate()の後にトレース出力を使用し、LVD割り込みを有効にする前にCy_SysLib_DelayUs(75)を使用すると、予想される遅延時間の約半分、75uSであるはずのときに32.5uSが表示され、CLK_FASTは24MHzに設定されています。

8 MHz でペギングして動作するように CLK_FAST を変更すると、遅延には 92uS かかります。 48MHzでペッグして動作するようにCLK_FASTを変更すると、遅延には17uSかかります。

したがって、私の問題はまだ続いており、ディープスリープから戻った後にCy_SysLib_DelayUs(x)を呼び出すと、uSで想定されているものと一致しないシステム遅延が発生します。 デバッガーがアタッチされていると発生しません。 SystemCoreClock変数を揮発性に変更し、それを使用してDelayUs()関数に依存する代わりにサイクル数を計算しようとしましたが、遅延を呼び出す前にSystemCoreClockUpdate()を呼び出してみましたが、目的の50uSの代わりに19uSを取得しています。

SystemCoreClockUpdate()
Cy_LVD_Disable();
Cy_LVD_ClearInterruptMask();
Cy_LVD_SetThreshold(CY_LVD_THRESHOLD_2_7_V);
Cy_LVD_SetInterruptConfig(CY_LVD_INTR_FALLING);
Cy_LVD_Enable();

揮発性uint32_t遅延;
遅延 = システムコアクロック * .000050;
PortSetPinValue(TEST_WAKEUP_PORT, TEST_WAKEUP_PIN, pv_PORT_LOW);GPIO ピンをローに切り替えます。
Cy_SysLib_DelayCycles(遅延)
PortSetPinValue(TEST_WAKEUP_PORT, TEST_WAKEUP_PIN, pv_PORT_HIGH);GPIO ピンをハイに切り替えます。

ピンローからピンハイまでは、24MHzのコアクロックで19uSかかります。

0 件の賞賛
Translation_Bot
Community Manager
Community Manager
Community Manager

私は自分の問題を解決します、それは https://community.infineon.com/t5/PSoC-6/PSoC62-Wrong-delay-in-CM4-with-Cy-SysLib-Delay-if-ECO-used/... と同じです-まだModus 2.4を使用していますが、そのEcoSetFrequency()関数を手動で追加して呼び出した後、遅延は意図したとおりに機能しています。

0 件の賞賛