Project

General

Profile

Bug #491

Liste des champs contenus dans TM_LFR_HK non renseignés.

Added by Veronique bouzid almost 6 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
-
Start date:
09/09/2015
Due date:
% Done:

100%

Estimated time:
revision:
r0

Description

Tracé aussi dans : https://jira-lesia.obspm.fr/browse/RPWSWR-612

Voici la liste que j ai identifié. Paul devra validé cette liste.

le nom des champ utilisé est celui de l'ICD et dans l'ordre de description

SY_LFR_WATCHDOG_ENABLED --> DISABLED
HK_LFR_RESET_CAUSE --> UNKNOWN_CAUSE
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 3 champs de SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/TIME
HK_LFR_TIME_TIMECODE_IT --> 0
HK_LFR_TIME_TIMECODE_NOT_SYNCHRO --> 0
HK_LFR_TIME_TIMECODE_CTR --> 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


Related issues

Related to Bug #490: [JIRA] (RPWMEB-495) LFR doesn't detect the TIME_TIMECODE_CTR errorsClosed2015-09-09

History

#1 Updated by Veronique bouzid almost 6 years ago

  • Status changed from New to In Progress

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*

#2 Updated by bruno katra over 5 years ago

  • Description updated (diff)

#3 Updated by bruno katra over 5 years ago

  • % Done changed from 0 to 20

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

#4 Updated by bruno katra over 5 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 20 to 60

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.

#5 Updated by paul leroy over 5 years ago

  • Assignee changed from paul leroy to bruno katra

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>

#6 Updated by bruno katra over 5 years ago

Commentaires de Philippe Plasson ajoutés en edition du commentaire.

#7 Updated by bruno katra over 5 years ago

  • Assignee changed from bruno katra to paul leroy

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... :P

#8 Updated by bruno katra over 5 years ago

Je pense avoir compris : les champs HK sont codés sur 4 bits donc tu renseignes 2 champs d'un coup avec un unsigned char, c'est bien ça ?

#9 Updated by paul leroy over 5 years ago

On pourrait faire une mise à jour de l'ICD, mais on peut aussi documenter ça dans le user manual. Effectivement, il s'agit de deux unsigned char. Les champs sont les suivants:

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

Le registre complet (vérifier peut-être la conformité à la doc VHDL):

// 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

Waveform picker

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

  • bit7 new error f3
  • bit6 new error f2
  • bit5 new error f1
  • bit4 new error f0
  • bit3 error buffer full f3
  • bit2 error buffer full f2
  • bit1 error buffer full f1
  • bit0 error buffer full f0

Le registre complet (vérifier peut-être la conformité à la doc VHDL):

// 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

#10 Updated by paul leroy over 5 years ago

  • Assignee changed from paul leroy to bruno katra

#11 Updated by bruno katra over 5 years ago

  • Status changed from Feedback to In Progress
  • % Done changed from 60 to 70

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.

#12 Updated by Veronique bouzid over 5 years ago

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

#13 Updated by paul leroy over 5 years ago

  • Assignee changed from paul leroy to Veronique bouzid

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?

#14 Updated by Veronique bouzid over 5 years ago

  • Assignee changed from Veronique bouzid to paul leroy

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

#15 Updated by paul leroy about 5 years ago

  • Assignee changed from paul leroy to Veronique bouzid

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;

}

Et pout l'autre champ dans wf_handler.c
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);

#16 Updated by Veronique bouzid over 4 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 70 to 100

Also available in: Atom PDF