LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

Suite à la livraison du logiciel 3.0.0.10, les champs sont maintenant renseignés
HK_LFR_RESET_CAUSE (pt #514)
HK_LFR_TIME_TIMECODE_CTR (pt #490)

Voici donc les champs HK non renseignés pour 3.0.0.10
le nom des champ utilisé est celui de l'ICD et dans l'ordre de description

*SY_LFR_WATCHDOG_ENABLED --> DISABLED
HK_LFR_CPU_LOAD_AVE --> 0

Les 6 champs de SOURCE_DATA/PARAMETERS/ANOMALY_STATISTICS
HK_LFR_LE_CNT --> 0
HK_LFR_ME_CNT --> 0
HK_LFR_HE_CNT --> 0
HK_LFR_LAST_ER_RID --> 0
HK_LFR_LAST_ER_CODE --> 0
HK_LFR_LAST_ER_TIME --> 0

Les 8 champs de SOURCE_DATA/PARAMETERS/HK_VHDL_BLK_STATUS
HK_LFR_VHDL_AA --> 0
HK_LFR_VHDL_SM --> 0
HK_LFR_VHDL_FFT --> 0
HK_LFR_VHDL_SR --> 0
HK_LFR_VHDL_CIC --> 0
HK_LFR_VHDL_HK --> 0
HK_LFR_VHDL_IR --> 0
HK_LFR_VHDL_CAL --> 0

Le champ de SOURCE_DATA/PARAMETERS/AHB_ERROR_STATISTICS
HK_LFR_LAST_FAIL_ADDR --> 0

Les champs suivants de SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/SPACEWIRE/LOW_SEVERITY
HK_LFR_DPU_SPW_RX_AHB --> 0
HK_LFR_DPU_SPW_TX_AHB --> 0

Les 3 champs de SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/TIMECODE
HK_LFR_TIMECODE_ERRONEOUS --> 0
HK_LFR_TIMECODE_MISSING --> 0
HK_LFR_TIMECODE_INVALID --> 0

Les 2 champs de SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/TIME
HK_LFR_TIME_TIMECODE_IT --> 0
HK_LFR_TIME_TIMECODE_NOT_SYNCHRO --> 0

Les 2 champs de SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/BUFFER
HK_LFR_BUFFER_DPU_TC_FIFO --> 0
HK_LFR_BUFFER_DPU_TM_FIFO --> 0

Les 2 champs de SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/AHB
HK_LFR_AHB_CORRECTABLE --> 0
HK_LFR_AHB_UNCORRECTABLE --> 0*

Mail envoyé le 08/01/2016

Salut !

Afin d'optimiser le temps de développement quand Paul sera là, je vous propose d'entamer par mail les discussions sur ce point évoqués lors de la QR et qui implique le FSW.

champs HK non renseignés :

Actuellement, les champs suivants ne sont pas remplis ou mis à jour par le FSW (bug redmine #491) et ce que j'en ai compris :

SY_LFR_WATCHDOG_ENABLED --> DISABLED
> c'est normal pour l'instant car pas de WD, si le WD est finalement implémenté : ce champs devra être renseigné correctement.

HK_LFR_CPU_LOAD_AVE --> 0
> le FSW ne remplit par ce champ, uniquement le CPU LOAD ponctuel

Les 6 champs de SOURCE_DATA/PARAMETERS/ANOMALY_STATISTICS :
HK_LFR_LE_CNT --> 0
HK_LFR_ME_CNT --> 0
HK_LFR_HE_CNT --> 0
> Paul a dit pendant la QR qu'il regarderait comment raffiner un minimum le tri selon le niveau critique des erreurs (LE, ME, HE)
HK_LFR_LAST_ER_RID --> 0
HK_LFR_LAST_ER_CODE --> 0
HK_LFR_LAST_ER_TIME --> 0
> Philippe avait l'air de tenir à ces champs ??

Les 8 champs de SOURCE_DATA/PARAMETERS/HK_VHDL_BLK_STATUS
HK_LFR_VHDL_AA --> 0
HK_LFR_VHDL_SM --> 0
HK_LFR_VHDL_FFT --> 0
HK_LFR_VHDL_SR --> 0
HK_LFR_VHDL_CIC --> 0
HK_LFR_VHDL_HK --> 0
HK_LFR_VHDL_IR --> 0
HK_LFR_VHDL_CAL --> 0
> Ces champs ont été demandés par LFR il y a longtemps mais ne seront jamais utilisés. Soit Philippe les passe en spare bits soit on laisse tel quel et le LFR Software User Manual signalera leur non-usage.

Le champ de SOURCE_DATA/PARAMETERS/AHB_ERROR_STATISTICS :
HK_LFR_LAST_FAIL_ADDR --> 0
> Possible à renseigner ?

Les champs suivants de SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/SPACEWIRE/LOW_SEVERITY
HK_LFR_DPU_SPW_RX_AHB --> 0
HK_LFR_DPU_SPW_TX_AHB --> 0
> Ces champs ne sont jamais mis à jour à priori.

Les 3 champs de SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/TIMECODE
HK_LFR_TIMECODE_ERRONEOUS --> 0
HK_LFR_TIMECODE_MISSING --> 0
HK_LFR_TIMECODE_INVALID --> 0
> Philippe avait l'air de tenir à ces champs ??

Les 2 champs de SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/TIME
HK_LFR_TIME_TIMECODE_IT --> 0
HK_LFR_TIME_TIMECODE_NOT_SYNCHRO --> 0
> Possible à renseigner ?

Les 2 champs de SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/BUFFER
HK_LFR_BUFFER_DPU_TC_FIFO --> 0
HK_LFR_BUFFER_DPU_TM_FIFO --> 0
> Possible à renseigner ?

Les 2 champs de SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/AHB
HK_LFR_AHB_CORRECTABLE --> 0
HK_LFR_AHB_UNCORRECTABLE --> 0*
==> Possible à renseigner ?
A méditer...

Bruno

Vu Paul le 28/01/2016, JIRA renseigné après ça + demande de validation à Philippe Plasson :
Bonjour Philippe, nous avons pas mal discuté avec Paul sur les champs HK de LFR non renseignés. En fonction de ces échanges, j'ai commenté la faisabilité de chacun dans :
https://jira-lesia.obspm.fr/browse/RPWSWR-612

Cela te convient-il? En particulier pourrais-tu nous faire un retour sur les HK_LFR_LAST_ER*.

En te remerciant par avance.

Bon week-end

Bruno

-----------------------------------------
JIRA :

After discussions with Paul, here is the current state of what can be done for 3.0.0.10 not implemented HK fields :

SY_LFR_WATCHDOG_ENABLED --> DISABLED

As a WD is implemented in FSW >= 3.0.0.14 : this will be set to ENABLED by default at fsw startup. No TC is currently existing to disable it.

HK_LFR_CPU_LOAD_AVE --> 0
> Planned to be unused. Ponctual load every second is filled in HK_LFR_CPU_LOAD. The easy implementation would have been to do average on the 1 second values but there is no added value with this way compared to what can be done on ground with the HK_LFR_CPU_LOAD values.

SOURCE_DATA/PARAMETERS/ANOMALY_STATISTICS :
HK_LFR_LE_CNT --> 0
HK_LFR_ME_CNT --> 0
HK_LFR_HE_CNT --> 0
> Those values are now filled (FSW >=3.0.0.14) and under validation. What they count will be detailed in SUM.

HK_LFR_LAST_ER_RID --> 0
HK_LFR_LAST_ER_CODE --> 0
HK_LFR_LAST_ER_TIME --> 0
> Those values are currently not filled because fsw gathers a block or error statistics from spacewire driver that cannot be dated so the relevancy of "LAST" cannot be complied. The only errors that can be dated by FSW are TIMECODES related errors. Philippe : is it relevant to fill those only with TIMECODE errors? if yes, of course SUM will mention this behaviour.

_ Echange Philippe/Bruno 01/02/2016: _

- The fileds HK_LFR_LAST_ER_RID, HK_LFR_LAST_ER_CODE, HK_LFR_LAST_ER_TIME shall also concern the SpaceWire errors. The time resolution for the Spacewire errors can be equal to the polling period of the error statistics from the SpaceWire driver: this is fully acceptable.
 - Ok for the time resolution.
Concerning the errors RID and CODE : spacewire driver throws a structure containing multiple error counters so in the case of multiple errors in the same structure what should be the choice strategy to select the one to be put in HK_LFR_LAST_ER_RID and HK_LFR_LAST_ER_CODE ? 
 - As you want, but document the choice in the SUM.

SOURCE_DATA/PARAMETERS/HK_VHDL_BLK_STATUS :
HK_LFR_VHDL_AA --> 0
HK_LFR_VHDL_SM --> 0
HK_LFR_VHDL_FFT --> 0
HK_LFR_VHDL_SR --> 0
HK_LFR_VHDL_CIC --> 0
HK_LFR_VHDL_HK --> 0
HK_LFR_VHDL_IR --> 0
HK_LFR_VHDL_CAL --> 0
> Those field that were queried long time ago by LFR are not planned to be used. They can be changed to spare bits or stay as-is and explained in SUM.

Le champ de SOURCE_DATA/PARAMETERS/AHB_ERROR_STATISTICS
HK_LFR_LAST_FAIL_ADDR --> 0
> It is not possible to update this field because the AHBSTAT IP (that provide the information) is not instanciated by FSW.

SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/SPACEWIRE/LOW_SEVERITY :
HK_LFR_DPU_SPW_RX_AHB --> 0
HK_LFR_DPU_SPW_TX_AHB --> 0
> Those errors are not raised in the structure given by spacewire driver so FSW is not able to fill those values.

SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/TIMECODE :
HK_LFR_TIMECODE_ERRONEOUS --> 0
HK_LFR_TIMECODE_MISSING --> 0
HK_LFR_TIMECODE_INVALID --> 0
> Those values are now filled (FSW >=3.0.0.14) and under validation.

SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/TIME :
HK_LFR_TIME_TIMECODE_IT --> 0
HK_LFR_TIME_TIMECODE_NOT_SYNCHRO --> 0
==> Those values are now filled (FSW >=3.0.0.14) and under validation.

SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/BUFFER :
HK_LFR_BUFFER_DPU_TC_FIFO --> 0
HK_LFR_BUFFER_DPU_TM_FIFO --> 0
> It is not possible to update this field because FIFO is handled by spacewire driver : FSW is not able to detect those errors.

SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/AHB :
HK_LFR_AHB_CORRECTABLE --> 0
HK_LFR_AHB_UNCORRECTABLE --> 0
> It is not possible to update this field because the AHBSTAT IP (that provide the information) is not instanciated by FSW.

Je propose une modification qui ajoute deux champs dans les HK. Voici le commentaire du commit correspondant des sources du logiciel de vol. Je recopie dans les champs HK housekeeping_packet.hk_lfr_vhdl_aa_sm et housekeeping_packet.hk_lfr_vhdl_iir_cal les valeurs des registres d'erreurs utilisés par Jean-Christophe dans le VHDL. On se sait jamais, ça pourrait servir.

<commit>

two fields added to the housekeeping parameters:
housekeeping_packet.hk_lfr_vhdl_aa_sm
housekeeping_packet.hk_lfr_vhdl_iir_cal

The contents are below

housekeeping_packet.hk_lfr_vhdl_aa_sm = (unsigned char) (statusReg & 0x7c0 >> 6);

housekeeping_packet.hk_lfr_vhdl_iir_cal = (unsigned char) ((waveform_picker_regs->status & 0xff00) >> 8);

</commit>

Concernant l'ajout des champs, tu fusionnes 4 champs existants en 2 nouveaux ?

HK_LFR_VHDL_AA et HK_LFR_VHDL_SM deviennent hk_lfr_vhdl_aa_sm ?

HK_LFR_VHDL_IR et HK_LFR_VHDL_CAL deviennent hk_lfr_vhdl_iir_cal ?

Si cela implique une modif de l'ICD, Philippe va être heureux encore...

Du coup : non ce n’est pas la peine de modifier l'ICD. J'expliquerai ça dans le SUM. Je reviendrai vers toi pour quelques explications car pas sûr d'avoir compris les bouts de code que tu as mis.

j'ai donc été vérifié les informations de Paul par rapport au document de Jean-Christophe (

les champs HK_LFR_VHDL_AA et HK_LFR_VHDL_SM sont remplis à partir du champ SPECTRAL_ MATRIX_STATUS du VHDL.
Lire la p25 du document RPW-MEB-LFR-SPC-00061-1-9_FPGA_Architecture_Design.pdf(joint)

Spectral matrices

Les champs recopiés dans les HK (byte hk_lfr_vhdl_aa_sm)

bit4 input_fifo_write(2)
    bit3 input_fifo_write(1)
    bit2 input_fifo_write(0)
    bit1 buffer_full
    bit0 bad_component_err  --> NOT USED

// STATUS REGISTER
// input_fifo_write(2) === input_fifo_write(1) === input_fifo_write(0)
// 10 9 8
// buffer_full not used f2_1 f2_0 f1_1 f1_0 f0_1 == f0_0
// 7 6 5 4 3 2 1 0

--> Il faut donc refaire la description des champs HK_LFR_VHDL_AA et HK_LFR_VHDL_SM.

Le script /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0003/loop_tm_lfr_tc_exe.py
montre que l'observe le champ HK_LFR_VHDL_SM positionné à 1, on peut donc en deduire ce bit n'est pas mis à zero suite au fait que le VHDL ne l'utilise pas.
Les fichiers de test se trouvent dans /home/validation/data/R3/3.0.0.19/1.1.89/SVS-0003.
Ici un extrait du fichier detail:

10:17:20.7944, TM_LFR_HK, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: HK_ROUTINE = 4, (PACKET_ID=0xcc4), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=25, (PACKET_SEQUENCE_CONTROL=0xc019), PACKET_LENGTH=129, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: HOUSEKEEPING_AND_DIAGNOSTIC_DATA_REPORTING = 3, SERVICE_SUBTYPE: HK_PARAMETER_REPORT = 25, DESTINATION_ID: GROUND = 0, TIME=0x8000001b48ba, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, HK_LFR_MODE: NORMAL = 1, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: RUN = 5, SPARE=0x0, HK_LFR_SC_POTENTIEL_FLAG: ON = 1, HK_LFR_MAG_FIELDS_FLAG: OFF = 0, SY_LFR_WATCHDOG_ENABLED: ENABLED = 1, HK_LFR_CALIB_ENABLED: DISABLED = 0, , HK_LFR_VHDL_AA=0, HK_LFR_VHDL_SM=1, HK_LFR_VHDL_FFT=0,

Contexte du test
----------------------
FSW 3.0.0.19
VHDL 1.1.89
EM sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee

OK, je fais la modification dans fsw >= 3.0.0.20
On aura donc dans hk_lfr_vhdl_aa_sm:
bit3 input_fifo_write(2)
bit2 input_fifo_write(1)
bit1 input_fifo_write(0)
bit0 buffer_full
Ca te va?

cela me va pour c'est toi qui a décidé de mettre ses valeurs et que je sais le vérifier.

Cette action est close?

On peut dire dans les docs que la fonction qui gère cela est dans fsw_processing.c

void spectral_matrix_isr_error_handler( int statusReg )
{
    // STATUS REGISTER
    // input_fifo_write(2) *** input_fifo_write(1) *** input_fifo_write(0)
    //           10                    9                       8
    // buffer_full ** [bad_component_err] ** f2_1 ** f2_0 ** f1_1 ** f1_0 ** f0_1 ** f0_0
    //      7                  6             5       4       3       2       1       0
    // [bad_component_err] not defined in the last version of the VHDL code

    rtems_status_code status_code;

    //***************************************************
    // the ASM status register is copied in the HK packet
    housekeeping_packet.hk_lfr_vhdl_aa_sm = (unsigned char) (statusReg & 0x780 >> 7);    // [0111 1000 0000]

    if (statusReg & 0x7c0)    // [0111 1100 0000]
    {
        status_code = rtems_event_send( Task_id[TASKID_DUMB], RTEMS_EVENT_8 );
    }

    spectral_matrix_regs->status = spectral_matrix_regs->status & 0x7c0;

}

rtems_isr waveforms_isr( rtems_vector_number vector )
{
    /** This is the interrupt sub routine called by the waveform picker core.
     *
     * This ISR launch different actions depending mainly on two pieces of information:
     * 1. the values read in the registers of the waveform picker.
     * 2. the current LFR mode.
     *
     */

    // STATUS
    // new error        error buffer full
    // 15 14 13 12      11 10 9  8
    // f3 f2 f1 f0      f3 f2 f1 f0
    //
    // ready buffer
    // 7    6    5    4    3    2    1    0
    // f3_1 f3_0 f2_1 f2_0 f1_1 f1_0 f0_1 f0_0

    rtems_status_code spare_status;

    waveforms_isr_f3();

    //*************************************************
    // copy the status bits in the housekeeping packets
    housekeeping_packet.hk_lfr_vhdl_iir_cal =
            (unsigned char) ((waveform_picker_regs->status & 0xff00) >> 8);