Configurer les modes basse consommation et mesurer le courant¶

Les guides basse consommation du SiFli-SDK couvrent plusieurs architectures SF32. Les SF32LB52x, SF32LB55x et SF32LB56x utilisent deux cœurs : le HCPU du HPSYS, jusqu'à 240 MHz, traite les tâches exigeantes ; le LCPU du LPSYS, jusqu'à 48 MHz, prend en charge le Bluetooth et les capteurs. Les SF32LB57x et SF32LB58x ajoutent un ACPU à l'architecture HCPU/LCPU ; sur le SF32LB58x, le LCPU basse consommation fonctionne jusqu'à 96 MHz. Le nombre de cœurs, les limites d'horloge et le comportement basse consommation varient selon la famille : référez-vous au guide SDK correspondant au composant visé.

Configurer l'infrastructure de gestion de l'énergie¶

Depuis le répertoire du projet, exécutez :

sdk.py menuconfig

Les paramètres menuconfig ci-dessous proviennent du guide source du SF32LB52x. Les noms de modes et les options disponibles peuvent varier selon la famille et la version du SDK ; vérifiez la documentation de la famille cible avant de les appliquer.

Le fichier rtconfig.h généré contient normalement RT_USING_PM, BSP_USING_PM, et le symbole du mode sélectionné. Partez de example/pm/classical comme référence fonctionnelle. Pour désactiver la fonctionnalité, inversez les mêmes sélections dans menuconfig.

Les figures ci-dessous proviennent du guide SiFli consacré au SF32LB52x et montrent les deux emplacements de menu clés. Pour le projet réel, référez-vous au menu SDK de la famille cible.

Sélectionner une source de réveil¶

Utilisez les fichiers pinmux.c/drv_io.c de la carte et les API de l'exemple SDK correspondant.

Pour Hibernate sur SF32LB52x, SF32LB56x, SF32LB57x et SF32LB58x, l'exemple ci-dessous associe un GPIO à la source de réveil PMU PIN0. Il ne s'applique pas au SF32LB55x, qui utilise la procédure distincte indiquée dans le tableau. Sur SF32LB57x, l'index des broches de réveil PMU va de 0 à 13. Vérifiez l'affectation choisie dans le manuel utilisateur du composant visé et dans le schéma de la carte.

HAL_PMU_SelectWakeupPin(0,
    HAL_HPAON_QueryWakeupPin(hwp_gpio1, BSP_KEY1_PIN));
HAL_PMU_EnablePinWakeup(0, AON_PIN_MODE_HIGH);
rt_kprintf("CR:0x%x, WER:0x%x\n", hwp_pmuc->CR, hwp_pmuc->WER);

Un réveil depuis Hibernate équivaut à un démarrage à froid et positionne PM_HIBERNATE_BOOT ; contrairement au réveil depuis Standby, l'exécution ne reprend pas au point d'interruption. Si une même broche doit réveiller le système depuis Standby et depuis Hibernate, configurez les deux chemins. Sur les 55x, les broches de réveil en Hibernate sont des entrées flottantes ; prévoyez une résistance de tirage externe lorsque la carte l'exige.

Comprendre les états de veille¶

Le guide SDK actuel sur la basse consommation cité ne fournit pas de données comparables de rétention SRAM et de temps de réveil pour le SF32LB57x. Ne transposez pas au SF32LB57x les capacités de rétention ni les durées d'une autre famille ; vérifiez-les dans la version du SDK et la documentation du composant cible.

Dans le tableau précédent, PM_SLEEP_MODE_LIGHT, PM_SLEEP_MODE_DEEP et PM_SLEEP_MODE_STANDBY correspondent respectivement aux modes Light Sleep, Deep Sleep et Standby.

Les valeurs par famille sont des références des guides SDK, et non des délais garantis sur la carte. Le guide du SF32LB52x indique qu'en présence de PSRAM, le HCPU y sauvegarde les données de la RAM qui sera mise hors tension, puis les restaure après le réveil ; sans PSRAM, la RAM Retention de 64 KB sert de destination de sauvegarde. Cette zone de sauvegarde est distincte de la capacité SRAM conservée indiquée par famille (par exemple, le mode Standby du SF32LB52x indique 384 KB de SRAM HPSYS conservés). Ne supposez pas que cette politique de sauvegarde ou cette capacité s'applique aux autres familles, sauf si leur guide SDK le confirme. Le courant réel dépend aussi des périphériques activés, des niveaux IO, de la mémoire externe et de la carte.

Contrôler les horloges à l'état éveillé¶

Si le thread IDLE ne peut pas entrer dans un état de veille, la réduction automatique de fréquence WFI peut abaisser le courant. Elle n'est sûre que lorsque l'EPIC, l'EZIP, le LCDC, l'USB et le SD sont inactifs. Si l'application n'utilise pas le mécanisme du SDK qui suit l'activité de LVGL et des périphériques, signalez le début et la fin de chaque activité avec rt_pm_hw_device_start() et rt_pm_hw_device_stop(). Configurez le diviseur avec HAL_RCC_HCPU_SetDeepWFIDiv() ; les traitements audio limitent normalement l'horloge réduite à 48 MHz, tandis que les autres peuvent utiliser 4 MHz. Réglez HPSYS_RCC_DBGR_FORCE_HP selon les consignes du guide SDK.

Pour le travail actif, utilisez rt_pm_run_enter() :

pm_scenario_start()/pm_scenario_stop() fournissent la politique UI et Audio du SDK : si l'un ou l'autre scénario est actif, la vitesse élevée est sélectionnée ; si aucun n'est actif, la vitesse moyenne est sélectionnée. Mesurez l'énergie, pas seulement le courant instantané, car une horloge plus basse peut allonger le temps d'exécution.

Comprendre l'ordre de mise en veille des sous-systèmes¶

Après l'extinction de l'écran, le HPSYS peut entrer en veille. Sur les 55x/56x/58x, le LPSYS suit normalement le HPSYS ; la famille 52x est l'exception documentée et permet une veille indépendante du HCPU/LCPU. Les sources disponibles ne confirment pas que l'ACPU du 57x suit le même ordre ; vérifiez la politique de ses sous-systèmes dans la version SDK correspondante. Après le réveil, gui_resume démarre un nouveau cycle de décision d'extinction d'écran. Maintenez un cœur éveillé tant qu'un périphérique partagé ou une transaction IPC en a besoin.

Activez temporairement BSP_PM_DEBUG et recherchez dans les journaux :

Si la veille attendue ne se produit pas, vérifiez list_thread, pm_dump et list_timer. Le thread IDLE doit pouvoir s'exécuter et aucune demande rt_pm_request(PM_SLEEP_MODE_IDLE) ne doit rester active. La prochaine échéance d'un temporisateur du système d'exploitation doit dépasser le seuil fixé par la politique de gestion de l'énergie (généralement 100 ms pour le HCPU et 10 ms pour le LCPU). Les conditions de réveil doivent être inactives et les files IPC vides. Un délai périodique inférieur au seuil peut empêcher indéfiniment la veille.

Le guide SiFli schématise également le chemin « extinction de l'écran → IDLE → veille lorsque les conditions sont remplies » et le chemin « une touche réveille le LPSYS, puis le LCPU envoie l'évènement au HCPU via Mailbox et le système réveille automatiquement le HPSYS ». Ces schémas sont utiles pour vérifier l'ordre des journaux ; les libellés et le déroulement sont des exemples SF32LB52x et ne doivent pas servir à déduire les assignations de bits WSR d'une autre famille.

%%{init: {"flowchart": {"htmlLabels": true, "wrappingWidth": 260}}}%%
flowchart TD
    A["<div style='width:260px;text-align:center'>Délai de verrouillage d'écran dépassé,<br/>l'écran s'éteint</div>"] --> B["<div style='width:260px;text-align:center'>Tous les threads de travail sont inactifs ;<br/>le thread IDLE s'exécute</div>"]
    B --> C["<div style='width:260px;text-align:center'>Si toutes les conditions sont réunies,<br/>le système entre en veille</div>"]

%%{init: {"flowchart": {"htmlLabels": true, "wrappingWidth": 260}}}%%
flowchart TD
    A["<div style='width:260px;text-align:center'>Une touche réveille le LPSYS</div>"] --> B["<div style='width:260px;text-align:center'>Le LCPU envoie l'évènement de touche au HCPU via Mailbox,<br/>le système réveille automatiquement le HPSYS</div>"]
    B --> C["<div style='width:260px;text-align:center'>Le HCPU vérifie le type d'évènement de touche</div>"]
    C --> D["<div style='width:260px;text-align:center'>Le HCPU détermine qu'il s'agit d'un évènement de clic simple,<br/>puis allume l'écran</div>"]

Réduire les fuites au niveau carte¶

Mesurez d'abord le système minimal : déconnectez l'écran, le capteur, le chargeur et les autres charges amovibles, puis rajoutez-les une à une. Les sources de fuite courantes sont :

• un appareil externe qui reste alimenté ;
• une sortie maintenue à l'état haut vers un appareil mis hors tension ;
• une entrée flottante ou une configuration de tirage haut/bas inadaptée ;
• une PSRAM, une Flash NOR/NAND, une eMMC ou une interface SDIO qui n'a pas été mise dans son état basse consommation ;
• une configuration PA01 de l'USB des 55x qui entre en conflit avec sa résistance de tirage bas interne.

Implémentez les transitions spécifiques à la carte dans BSP_IO_Power_Down() et BSP_Power_Up(), et utilisez BSP_TP_PowerDown/Up et BSP_LCD_PowerDown/Up lorsque l'alimentation de l'écran ou du tactile doit changer immédiatement à l'extinction/allumage de l'écran. Si le code s'exécute en XIP depuis la Flash NOR, placez la routine de mise en veille/réveil de la Flash en RAM de rétention (HAL_RAM_RET_CODE_SECT).

Mesurer et consigner un résultat reproductible¶

Pour chaque mesure, consignez la famille et la révision du SDK, la révision de carte, la tension d'alimentation, le point de mesure et la bande passante de l'instrument, la configuration du firmware, les composants mémoire installés, les périphériques actifs, la source de réveil, le mode de veille et le journal de transition. Indiquez l'état et les conditions de test avec le courant mesuré ; ne comparez pas des valeurs isolées mesurées sur des cartes ou dans des modes différents.

Sources officielles par famille : SF32LB52x, SF32LB55x, SF32LB56x et SF32LB58x. La référence API PMU du SDK documente la plage d'index des broches de réveil Hibernate du SF32LB57x.

Dernière mise à jour: 2026-10-12