Support #545
Updated by Veronique bouzid over 8 years ago
Voici le scenario effectué dans le test SVS-0012 0- Reset de LFR 1- Synchronisation de LFR sur reception d'une TC_LFR_UPDATE_TIME + time code compatible (6bits of least bytes of coarse time 2- Send during 60s a time code valid --> Ce que l on observe 14:00:30.509906, TM_LFR_HK, TIME=0x8000000431ad, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_TIME_TIMECODE_CTR=0 14:00:31.461884, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x5447c6010000 14:00:31.509805, TM_LFR_HK, TIME=0x8000000531ad, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_TIME_TIMECODE_CTR=0 14:00:32.509786, TM_LFR_HK, TIME=0x5447c601bd68, *HK_LFR_DPU_SPW_TICK_OUT_CNT=1, HK_LFR_DPU_SPW_LAST_TIMC=1*, HK_LFR_TIME_TIMECODE_CTR=0 14:00:33.509884, TM_LFR_HK, TIME=0x5447c602ba29, *HK_LFR_DPU_SPW_TICK_OUT_CNT=2, HK_LFR_DPU_SPW_LAST_TIMC=2, HK_LFR_TIME_TIMECODE_CTR=1* Cette derniere ligne correspond à l'envoi de time-code sans la TC_LFR_UPDATE_TIME. On voit que le soft a positionné HK_LFR_TIME_TIMECODE_CTR à 1 car le temps demandé(CP_RPW_TIME) dans TC_LFR_UPDATE_TIME = 0x5447c6010000 ne correspond pas au time-code = 2. Il faut donc documenter ce point concernant le compteur HK_LFR_TIME_TIMECODE_CTR. Paul utilise le registre coarse_time_load qui contient la valeur du CP_RPW_TIME de la TC_LFR_UPDATE_TIME. HK_LFR_TIME_TIMECODE_CTR