INSTRU: Issues
https://hephaistos.lpp.polytechnique.fr/redmine/
https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?1508097601
2018-10-03T15:24:43Z
Redmine
Redmine
LFR-FSW - Bug #3121 (Closed): Analyse Logiscope LFR_3.2.0.21 : LFR_basic-parameters : Tr_OperCond...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/3121
2018-10-03T15:24:43Z
William Recart
william.recart@lpp.polytechnique.fr
<p>Rappel de la règle :<br />Tr_OperCond<br />Definition:<br />-----------<br />The conditional operator ? ... : ... must not be used.</p>
<p>La règle n'est pas respectée dans 2 cas d'après Logiscope:<br />basic_parameters.h : line 363 : tmp_uint8 = (e_cross_b_im > e_cross_b_re) ? 0x40 : 0x00;<br />basic_parameters.h : line 479 : tmp_uint8 = (n_cross_e_scal_b_im > n_cross_e_scal_b_re) ? 0x40 : 0x00;</p>
LFR-FSW - Bug #1744 (Closed): Corrections QA pour relivraison DATAPACK R3++ updated
https://hephaistos.lpp.polytechnique.fr/redmine/issues/1744
2017-07-07T14:11:40Z
bruno katra
<p>Ci-dessous l'ensemble des bugs QA à corriger pour DP R3++ updated attendu pour fin Aout 2017:</p>
<p>- <a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-574">https://jira-lesia.obspm.fr/browse/RPWSWR-574</a> : pas compris ce qu'il fallait faire...</p>
<p>- <a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-712">https://jira-lesia.obspm.fr/browse/RPWSWR-712</a></p>
<p>- <a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-713">https://jira-lesia.obspm.fr/browse/RPWSWR-713</a></p>
<p>- <a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-710">https://jira-lesia.obspm.fr/browse/RPWSWR-710</a></p>
<p>- <a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-706">https://jira-lesia.obspm.fr/browse/RPWSWR-706</a> : Mise à jour des tailles de l'exe.</p>
<p>- <del><a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-625">https://jira-lesia.obspm.fr/browse/RPWSWR-625</a> * ==> RFW à faire avec Bruno + document fourni à Milan (en pj dans JIRA)*</del> REASSIGNé à BRUNO</p>
<p>- <a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-627">https://jira-lesia.obspm.fr/browse/RPWSWR-627</a> : mettre à jour le texte de la RFW</p>
<p>- <a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-633">https://jira-lesia.obspm.fr/browse/RPWSWR-633</a> : documents à signer par les concernés</p>
LFR-FSW - Bug #897 (Closed): Analyse Logiscope LFR_3.1.0.4 modifiée tag 322 (c0603702c8c8) : Do...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/897
2017-01-13T16:00:08Z
William Recart
william.recart@lpp.polytechnique.fr
<p>Rappel de la règle :<br />Don_ArtVariables</p>
<p>Definition:<br />-----------<br />The key-word union is not allowed.</p>
<p>La règle n'est pas respectée dans 2 cas :<br />ccsds_types.h : lignes 803, 833 (code ajouté das cette version)</p>
LFR-FSW - Bug #814 (Closed): Analyse Logiscope LFR_3.1.0.4 : metric Number of direct calls
https://hephaistos.lpp.polytechnique.fr/redmine/issues/814
2016-10-19T13:39:17Z
William Recart
william.recart@lpp.polytechnique.fr
<p>La métriqueNumber of direct calls doit etre inférieure à 20.</p>
<p>Le métrique est non respectée dans 0.79% des cas :<br />Init (rtems_task_argument) => 38<br />actn_task (rtems_task_argument) => 21</p>
LFR-FSW - Bug #813 (Closed): Analyse Logiscope LFR_3.1.0.4 : metric Cyclomatic number
https://hephaistos.lpp.polytechnique.fr/redmine/issues/813
2016-10-19T13:36:39Z
William Recart
william.recart@lpp.polytechnique.fr
<p>La métrique Cyclomatic number doit etre inférieure à 20.</p>
<p>Le métrique est non respectée dans 1.19% des cas :<br />start_all_tasks (void) => 34<br />actn_task (rtems_task_argument) => 21<br />tc_check_length (unsignedchar, unsignedint) => 33</p>
LFR-FSW - Bug #812 (Closed): Analyse Logiscope LFR_3.1.0.4 : metric Maximum nesting level
https://hephaistos.lpp.polytechnique.fr/redmine/issues/812
2016-10-19T13:30:46Z
William Recart
william.recart@lpp.polytechnique.fr
<p>La métrique Maximum nesting level doit etre inférieure à 4.</p>
<p>Le métrique est non respectée dans 1.58% des cas :<br />cwf2_task (rtems_task_argument) => 5<br />lfr_rtems_cpu_usage_report (void) => 6<br />recv_task (rtems_task_argument) => 6<br />send_task (rtems_task_argument) => 10</p>
LFR-FSW - Bug #809 (Closed): Analyse Logiscope LFR_3.1.0.4 : Tr_Parenthèses Severity is Medium
https://hephaistos.lpp.polytechnique.fr/redmine/issues/809
2016-10-19T12:42:41Z
William Recart
william.recart@lpp.polytechnique.fr
<p>Rappel de la règle :<br />Tr_Parenthèses<br />Definition:<br />-----------<br />In expressions, every binary and ternary operator has to be put in parenthesis, <br />so that the evaluation priorities are not ambiguous.<br />Use the partpar option to allow the following rules: when the right operand of <br />a + or * operator uses the same operator, you can omit parenthesis for it. <br />In the same way, you can omit parenthesis in the case of the right operand of an <br />assignment operator. Moreover, you can omit parenthesis at the first level of <br />the expression.</p>
<p>Parameters:<br />----------<br />The character string "partpar", which, if used, allows programmers not to put <br />systematically parenthesis, according to the rule above.</p>
<p>Justification:<br />--------------<br />Removes ambiguity about the evaluation priorities.</p>
<p>Example:<br />--------</p>
<p>// do not write<br />result = fact / 100 + rem;</p>
<p>// write<br />result = ((fact / 100) + rem);</p>
<p>// or write, with the partpar option<br />result = (fact / 100) + rem;</p>
<p>// with the partpar option, write<br />result = (fact * ind * 100) + rem + 10 + (coeff ** c);</p>
<p>// instead of <br />result = ((fact * (ind * 100)) + (rem + (10 + (coeff ** c))));</p>
<p>La règle n'est pas respectée dans 75 cas d'après Logiscope:<br />Fichier avf0_prc0.c : ligne 378<br />Fichier avf1_prc1.c : ligne 370<br />Fichier avf2_prc2.c : ligne 256<br />Fichier fsw_misc.c : lignes 374, 705, 706, 707<br />Fichier fsw_processing.c : lignes 236, 549, 556, 584, 585, 587, 651, 654, 658, 664, 668, 702, 782, 783<br />Fichier fsw_processing.h : lignes 280, 283, 286, 306, 309<br />Fichier fsw_spacewire.c : lignes 162, 167, 267, 1586<br />Fichier tc_acceptance.c : lignes 223, 274<br />Fichier tc_handler.c : lignes 279, 365, 382, 970, 1037, 1407, 1413, 1416, 1519, 1549<br />Fichier tc_load_dump_parameters.c : lignes 403, 408, 417, 422, 431, 436, 462, 467, 551, 555, 559, 867, 885, 999, 1000, 1353, 1365, 1367, 1514<br />Fichier tm_lfr_tc_exe.c : ligne 380<br />Fichier wf_handler.c : lignes 113, 843, 905, 906, 1170, 1184, 1185, 1208, 1209, 1231, 1233, 1266, 1277</p>
LFR-FSW - Bug #807 (Closed): Analyse Logiscope LFR_3.1.0.4 : Don_Enumeration Severity is Medium
https://hephaistos.lpp.polytechnique.fr/redmine/issues/807
2016-10-19T12:36:33Z
William Recart
william.recart@lpp.polytechnique.fr
<p>Rappel de la règle :<br />Don_Enumeration<br />Definition:<br />-----------<br />Numbers, characters and strings have to be declared as constants instead of being <br />used as literals inside a program. The user can list the allowed literal <br />constants.</p>
<p>Parameters:<br />-----------<br />A list of character strings representing the allowed literal constants.</p>
<p>Note: In the case of constants used in initializing lists <br />(concerning array and struct structures), only the first five violations are shown.</p>
<p>Justification:<br />--------------<br />Makes maintenance easier by avoiding the scattering of constants among the code, <br />often with the same value.</p>
<p>Example:<br />--------</p>
<p>// do not write</p>
<p>char tab<sup><a href="#fn100">100</a></sup>;<br />int i;</p>
<p>La règle n'est pas respectée dans 1435 cas d'après Logiscope:<br />Fichier avf0_prc0.c : lignes 27, 46, 83, 90, 172, 376, 377, 378, 378, 379, 380, 381, 382, 383, 384<br />Fichier avf1_prc1.c : lignes 28, 84, 91, 173, 368, 369, 370, 370, 371, 372, 373, 374<br />Fichier avf2_prc2.c : lignes 26, 72, 76, 123, 256, 269, 282<br />Fichier ccsds_types.h : lignes 303, 304, 305, 311, 313, 314, 323, 324, 325, 331, 333, 334, 335, 348, 349, 350, 356, 358, 359, 360, 363, 372, 373, 374, 380, 382, 383, 384, 395, 396, 397, 403, 405, 406, 407, 418, 419, 420, 426, 428, 429, 430, 433, 434, 435, 436, 444, 445, 446, 452, 460, 461, 469, 470, 471, 477, 483, 484, 492, 493, 494, 500, 508, 509, 517, 518, 519, 525, 531, 533, 541, 542, 543, 549, 555, 556, 564, 565, 566, 572, 580, 581, 582, 587, 592, 593, 594, 610, 611, 612, 613, 614, 615, 616, 617, 618, 619, 620, 621, 623, 624, 625, 626, 628, 635, 636, 640, 642, 643, 644, 646, 647, 648, 687, 688, 689, 695, 705, 706, 707, 729, 730, 731, 732, 734, 735, 736, 737, 739, 740, 741, 742, 748, 750, 751, 754, 755, 756, 757, 758, 759, 760, 761, 762, 763, 764, 765, 776, 777, 778, 784, 792<br />Fichier fsw_config.c : lignes 7, 7, 8, 8, 9, 9<br />Fichier fsw_globals.c : lignes 26, 27, 28, 98<br />Fichier fsw_init.c : lignes 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 322, 323, 325, 326, 327, 332, 345, 345, 345, 345, 346, 346, 346, 346, 347, 347, 347, 347, 348, 348, 348, 348, 349, 349, 349, 349, 350, 350, 350, 350, 351, 351, 351, 351, 352, 352, 352, 352, 353, 353, 353, 353, 354, 354, 354, 354, 355, 355, 355, 355, 356, 356, 356, 356, 357, 357, 357, 357, 358, 358, 358, 358, 359, 359, 359, 359, 360, 360, 360, 360, 361, 361, 361, 361, 362, 362, 362, 362, 363, 363, 363, 363, 366, 366, 366, 366, 368, 368, 368, 368, 369, 369, 369, 369, 370, 370, 370, 370, 371, 371, 371, 371, 372, 372, 372, 372, 374, 374, 374, 374, 406, 449, 465, 481, 831, 831, 831, 831, 843, 843, 843, 843, 855, 855, 855, 855, 867, 867, 867, 867, 879, 879, 879, 879, 916, 917, 918, 919<br />Fichier fsw_init.h : lignes 19, 20<br />Fichier fsw_misc.c : lignes 28, 48, 49, 50, 51, 52, 64, 65, 66, 130, 144, 145, 146, 147, 193, 193, 193, 193, 213, 220, 264, 264, 272, 287, 291, 292, 293, 293, 294, 295, 295, 296, 354, 354, 355, 356, 357, 358, 380, 382, 386, 390, 394, 422, 429, 433, 447, 448, 452, 453, 453, 473, 474, 494, 495, 496, 496, 497, 498, 498, 499, 509, 509, 526, 530, 536, 537, 538, 538, 539, 540, 540, 541, 545, 546, 550, 551, 553, 555, 556, 556, 560, 562, 586, 587, 588, 588, 589, 589, 590, 590, 591, 591, 604, 605, 606, 606, 607, 607, 608, 608, 609, 609, 628, 640, 644, 652, 656, 664, 668, 676, 680, 686, 689, 705, 706, 707, 740, 740, 741, 743, 743, 744, 746, 746, 747, 757, 757, 811<br />Fichier fsw_params.h : lignes 276, 277, 278<br />Fichier fsw_processing.c : lignes 51, 70, 76, 78, 98, 100, 117, 128, 128, 134, 136, 156, 158, 175, 185, 185, 191, 193, 202, 208, 214, 236, 236, 238, 243, 273, 273, 279, 279, 285, 285, 360, 362, 365, 366, 369, 373, 374, 375, 375, 376, 376, 377, 377, 378, 378, 381, 382, 383, 384, 385, 386, 386, 387, 387, 388, 388, 389, 389, 390, 400, 402, 405, 406, 409, 415, 416, 417, 418, 419, 420, 421, 422, 423, 424, 425, 480, 514, 521, 521, 522, 522, 523, 523, 524, 524, 530, 531, 531, 532, 533, 533, 534, 534, 535, 535, 536, 584, 585, 605, 606, 607, 608, 609, 610, 611, 612, 613, 616, 617, 618, 619, 669, 669, 692, 699, 700, 702, 719, 723, 728, 731, 732, 733, 782, 783<br />Fichier fsw_processing.h : lignes 27, 28, 29, 35, 41, 42, 44, 53, 54, 55, 61, 67, 69, 71, 102, 103, 176, 184, 204, 205, 206, 206, 206, 207, 207, 207, 208, 208, 208, 209, 209, 209, 210, 210, 210, 211, 211, 211, 287, 287, 344<br />Fichier fsw_processing_globals.c : ligne 46<br />Fichier fsw_spacewire.c : lignes 60, 67, 125, 126, 162, 163, 194, 263, 263, 264, 264, 349, 351, 479, 539, 542, 561, 565, 768, 768, 769, 773, 773, 774, 774, 775, 775, 776, 776, 783, 785, 810, 810, 812, 820, 851, 1010, 1011, 1017, 1018, 1019, 1020, 1021, 1022, 1024, 1026, 1027, 1036, 1040, 1047, 1048, 1049, 1050, 1051, 1052, 1054, 1057, 1058, 1068, 1072, 1073, 1079, 1080, 1081, 1082, 1083, 1084, 1086, 1087, 1088, 1089, 1090, 1091, 1128, 1132, 1153, 1153, 1154, 1154, 1155, 1155, 1156, 1156, 1161, 1166, 1216, 1225, 1228, 1230, 1236, 1238, 1247, 1247, 1248, 1248, 1249, 1249, 1250, 1250, 1302, 1306, 1329, 1329, 1330, 1330, 1331, 1331, 1332, 1332, 1335, 1368, 1378, 1389, 1399, 1402, 1406, 1407, 1408, 1408, 1409, 1410, 1410, 1411, 1415, 1415, 1416, 1416, 1417, 1417, 1418, 1418, 1448, 1458, 1469, 1479, 1482, 1486, 1487, 1488, 1488, 1489, 1490, 1490, 1491, 1495, 1495, 1496, 1496, 1497, 1497, 1498, 1498, 1528, 1537, 1546, 1549, 1553, 1554, 1555, 1555, 1556, 1557, 1557, 1558, 1562, 1562, 1563, 1563, 1564, 1564, 1565, 1565, 1586, 1598<br />Fichier lfr_cpu_usage_report.c : lignes 95, 103, 104, 110<br />Fichier tc_acceptance.c : lignes 13, 28, 28, 28, 28, 42, 46, 48, 49, 51, 52, 54, 55, 57, 58, 60, 61, 63, 64, 66, 67, 87, 91, 92, 128, 128, 128, 128, 129, 130, 458, 460<br />Fichier tc_handler.c : lignes 35, 180, 265, 269, 269, 274, 279, 282, 293, 295, 360, 361, 362, 362, 363, 365, 368, 489, 502, 905, 922, 923, 928, 929, 934, 935, 940, 941, 946, 947, 952, 953, 958, 959, 964, 965, 971, 971, 972, 972, 973, 973, 974, 974, 996, 1013, 1014, 1019, 1020, 1025, 1026, 1031, 1032, 1038, 1038, 1039, 1039, 1322, 1326, 1334, 1338, 1367, 1368, 1369, 1370, 1371, 1371, 1373, 1376, 1378, 1379, 1380, 1381, 1392, 1395, 1396, 1397, 1398, 1400, 1403, 1405, 1406, 1407, 1407, 1411, 1413, 1413, 1414, 1414, 1415, 1415, 1416, 1416, 1417, 1417, 1425, 1429, 1438, 1442, 1451, 1455, 1482, 1488, 1508, 1510, 1514, 1514, 1515, 1515, 1516, 1516, 1517, 1517, 1519, 1521, 1538, 1540, 1544, 1544, 1545, 1545, 1546, 1546, 1547, 1547, 1549, 1551, 1618, 1618, 1626, 1630<br />Fichier tc_load_dump_parameters.c : lignes 108, 117, 130, 175, 184, 192, 192, 195, 240, 249, 262, 334, 334, 335, 335, 339, 339, 340, 340, 343, 343, 344, 344, 350, 408, 422, 428, 436, 441, 442, 443, 443, 444, 445, 445, 446, 460, 462, 463, 467, 472, 473, 474, 474, 475, 476, 476, 477, 511, 512, 513, 513, 514, 515, 515, 516, 551, 555, 559, 570, 572, 578, 580, 589, 598, 608, 617, 627, 988, 996, 999, 1000, 1023, 1028, 1033, 1034, 1045, 1053, 1056, 1059, 1063, 1064, 1065, 1065, 1073, 1081, 1087, 1091, 1093, 1095, 1101, 1103, 1107, 1107, 1110, 1110, 1113, 1113, 1116, 1116, 1119, 1119, 1122, 1122, 1125, 1128, 1133, 1144, 1167, 1215, 1216, 1217, 1222, 1247, 1247, 1249, 1255, 1255, 1258, 1258, 1266, 1268, 1275, 1275, 1278, 1278, 1317, 1364, 1365, 1383, 1383, 1384, 1384, 1394, 1395, 1413, 1417, 1424, 1425, 1426, 1426, 1427, 1428, 1428, 1429, 1439, 1441, 1443, 1468, 1472, 1473, 1483, 1489, 1490, 1490, 1495, 1496, 1498, 1503, 1504, 1506, 1514, 1514, 1520, 1524, 1531, 1532, 1533, 1533, 1534, 1534, 1535, 1535, 1536, 1536, 1539, 1546, 1548, 1611, 1612, 1616<br />Fichier tm_lfr_tc_exe.c : lignes 44, 47, 54, 55, 56, 56, 57, 58, 58, 59, 109, 112, 119, 120, 121, 121, 122, 123, 123, 124, 126, 177, 180, 187, 188, 189, 189, 190, 191, 191, 192, 194, 245, 248, 255, 256, 257, 257, 258, 259, 259, 260, 262, 311, 314, 321, 322, 323, 323, 324, 325, 325, 326, 328, 379, 380, 388, 391, 398, 399, 400, 400, 401, 402, 402, 403, 405, 497, 498, 502<br />Fichier wf_handler.c : lignes 64, 67, 89, 118, 118, 121, 121, 125, 127, 127, 131, 145, 145, 160, 162, 172, 185, 185, 191, 191, 197, 199, 199, 204, 212, 212, 216, 216, 221, 223, 223, 228, 236, 236, 241, 241, 246, 248, 248, 253, 286, 286, 288, 288, 400, 401, 405, 416, 417, 417, 455, 470, 490, 578, 679, 679, 680, 680, 681, 681, 682, 682, 698, 701, 703, 704, 705, 705, 706, 707, 707, 708, 710, 711, 712, 712, 713, 713, 714, 714, 715, 720, 720, 724, 724, 728, 728, 732, 732, 736, 736, 740, 740, 744, 744, 748, 748, 753, 759, 760, 761, 761, 762, 762, 763, 763, 764, 791, 792, 793, 794, 807, 808, 810, 813, 814, 818, 819, 838, 850, 850, 850, 851, 851, 851, 854, 855, 856, 856, 856, 857, 857, 857, 861, 898, 899, 900, 905, 905, 906, 906, 914, 914, 919, 919, 931, 933, 933, 939, 944, 944, 950, 967, 1018, 1029, 1094, 1095, 1096, 1100, 1120, 1120, 1121, 1121, 1122, 1123, 1124, 1124, 1125, 1125, 1144, 1145, 1148, 1149, 1152, 1170, 1173, 1184, 1185, 1185, 1185, 1185, 1185, 1185, 1188, 1208, 1209, 1209, 1209, 1209, 1209, 1209, 1231, 1233, 1292, 1293, 1297<br />Fichier wf_handler.h : ligne 33</p>
LFR-FSW - Bug #801 (Closed): Analyse Logiscope LFR_3.1.0.4 : Don_Initialisation_P2 Severity is High
https://hephaistos.lpp.polytechnique.fr/redmine/issues/801
2016-10-19T12:13:09Z
William Recart
william.recart@lpp.polytechnique.fr
<p>Rappel de la règle :<br />Don_Initialisation_P2 :<br />Definition:<br />-----------<br />All variables must be initialized before they are used, without aking into account<br />on the default value attributed by the compiler.<br />Global variables, parameters of a function in the function body, and data fields <br />of a class in its methods are considered to be initialized.</p>
<p>Justification:<br />--------------<br />Not all compilers give the same default values. Unexpected behaviour can be <br />avoided with better control over variable values.</p>
<p>Limitations:<br />------------<br />This rule is not violated in the following cases: <br />If an array, a struct or a class are used, they will be consided initialized as <br />soon as a part of them has been initialized.<br />For example: <br /> int a<sup><a href="#fn2">2</a></sup>;<br /> int b<sup><a href="#fn2">2</a></sup> = {6, 7};<br /> int h;</p>
<pre><code>a[0] = b[0]; // ok<br /> h = a[1]; // ok</code></pre>
<pre><code>struct
{<br /> int i;<br /> int j;<br /> } e, f;</code></pre>
<pre><code>e.i = 0;<br /> g = e; // ok</code></pre>
<p>This rule is violated in the following cases where initialization is uncertain:</p>
<p>Using a variable in a function call is considered as "being used": if it is not <br />initialized, the rule will be violated. <br />This will occur whatever the use of the function, even initializing the variable.</p>
<p>In cases including a conditional initialization, the rule is violated even though <br />the variable may well be initialized. </p>
<pre><code>int i, j, k;<br /> j = func();<br /> if (j)<br /> i = 0;<br /> k = i; // violation</code></pre>
<p>This applies even when there is an else branch, for example in<br /> int i, j, k;<br /> j = func();<br /> if (j)<br /> i = 0;<br /> else <br /> i = 5;<br /> k = i; // violation <br />where initialization is certain.</p>
<p>In the case of a loop, for example<br />int j, k;<br />for (int i=0; i<glob; i++)
{<br /> j=func(i);<br /> }<br />k = j; // violation <br />where glob is a global variable, depending on the value of glob, j will have been <br />initialized or not: the rule is violated, even if the loop condition occurs or not.</p>
<p>La règle n'est pas respectée dans 352 cas d'après Logiscope:<br />Fichier avf0_prc0.c : lignes 70, 77, 174, 207, 210, 218, 221, 227, 230, 236, 239, 248, 253, 262, 262, 287, 289, 290, 293, 300, 302, 303, 306, 325, 327, 328, 331, 337, 339, 340, 343, 357, 360, 366<br />Fichier avf1_prc1.c : lignes 71, 78, 175, 208, 211, 219, 222, 228, 231, 240, 245, 254, 254, 279, 281, 282, 285, 292, 294, 295, 298, 317, 319, 320, 323, 329, 331, 332, 335, 349, 352, 358<br />Fichier avf2_prc2.c : lignes 59, 66, 125, 156, 159, 163, 168, 177, 177, 202, 204, 205, 208, 216, 218, 219, 222, 238, 244<br />Fichier fsw_init.c : lignes 274, 278, 743, 752, 761, 770, 779, 805, 891, 893<br />Fichier fsw_misc.c : lignes 30, 195, 210, 235, 260, 262, 270, 323, 378, 379, 565, 567, 802, 802, 803, 803, 805, 806, 807, 808<br />Fichier fsw_processing.c : ligne 574<br />Fichier fsw_spacewire.c : lignes 45, 59, 60, 66, 67, 136, 142, 152, 166, 173, 173, 175, 175, 184, 186, 186, 188, 193, 193, 199, 240, 250, 250, 259, 314, 329, 346, 348, 349, 352, 406, 522, 588, 611, 613, 615, 617, 619, 621, 623, 625, 627, 629, 631, 649, 674, 674, 681, 681, 688, 688, 695, 695, 702, 702, 709, 709, 716, 716, 723, 723, 730, 730, 737, 737, 744, 744, 754, 754, 757, 1122, 1124, 1125, 1208, 1209, 1211, 1296, 1298, 1299, 1360, 1362, 1363, 1440, 1442, 1443, 1520, 1522, 1523, 1586, 1586<br />Fichier lfr_cpu_usage_report.c : ligne 110<br />Fichier tc_acceptance.c : lignes 130, 130, 204, 287, 470<br />Fichier tc_handler.c : lignes 39, 45, 58, 58, 58, 67, 71, 71, 72, 72, 75, 76, 76, 79, 79, 80, 80, 83, 83, 84, 84, 87, 87, 88, 88, 91, 91, 92, 92, 95, 95, 96, 96, 99, 99, 100, 100, 103, 103, 104, 104, 107, 107, 108, 108, 111, 111, 112, 112, 115, 115, 116, 116, 119, 119, 120, 120, 123, 123, 124, 124, 127, 127, 128, 128, 131, 132, 132, 393<br />Fichier tc_load_dump_parameters.c : lignes 878, 897, 914, 1021, 1043, 1044, 1045<br />Fichier tm_lfr_tc_exe.c : lignes 379, 379<br />Fichier wf_handler.c : lignes 145, 185, 191, 197, 197, 199, 204, 204, 212, 216, 221, 221, 223, 228, 228, 236, 241, 246, 246, 248, 253, 253, 343, 354, 356, 362, 363, 364, 366, 390, 412, 421, 426, 457, 469, 471, 473, 475, 482, 523, 534, 542, 585, 586, 838, 843, 924, 953, 1183, 1207, 1230, 1264, 1290, 1293, 1293, 1295, 1301, 1303, 1303, 1307, 1313, 1313<br />Fichier : lignes</p>
Solar Orbiter LFR - Bug #240 (Resolved): Liste de problèmes observés sur le LFR FGSE
https://hephaistos.lpp.polytechnique.fr/redmine/issues/240
2014-09-18T07:57:45Z
Vincent Leray
<p>Lors de l'utilisation du FGSE LFR au CNES quelques dysfontionnements ou incompréhensions dans l'utilisation sont remontés:</p>
<p>Extrait mail CNES (Cf PJ):<br />Le foreign LFR plante 9 fois sur 10 lors du lancement<br />Les courbes LFR ASM ou SWF s’affichent en superposées lors de leur sélection.<br />Nous n’arrivons pas à faire fonctionner la fonction FFT, mode d’emploi ?</p>
<p>A cela 2 Ncs ont été ouvertes:<br />NC 93 concernant l'enregistrement des ASM à F1 et F2 sur le FGSE<br />NC 102 concernant les labels des colonnes des ASMs lors d'un export.</p>
<p>Existe t il des mises à jours du FGSE prévues pour corriger ces points?</p>
LFR-FSW - Bug #166 (Closed): PACKET LENGTH erroné pour TM_LFR_SCIENCE_BURST_BP1_F1 et TM_LFR_SCIE...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/166
2014-06-10T06:15:20Z
Veronique bouzid
<p>EN analysant le fichier 2014_06_05-12_11_54-Detail.txt correspondant au test<br />SVS-0090/generate_science_all_modes.py<br />2 pbs sur le parametre PACKET LENGTH, la longueur du packet de telemetry ne correspond pas au champ contenu dans PACKET_LENGTH</p>
<p>- 16:42:38.053034, TM_LFR_SCIENCE_BURST_BP1_F0, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=3, (PACKET_SEQUENCE_CONTROL=0xc003), PACKET_LENGTH=217, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x80000025ac28, PA_LFR_SID_PKT: SC_B_BP1_F0 = 17, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, PA_BIA_ON_OFF: OFF = 0, PA_LFR_ACQUISITION_TIME=0x80000025ac28, PA_LFR_B_BP1_BLK_NR_F0=22<br />16:42:38.064438, TM_LFR_SCIENCE_BURST_BP1_F1, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=4, (PACKET_SEQUENCE_CONTROL=0xc004), <strong>/!\PACKET_LENGTH=217(exp=(Number of bytes in Packet Data Field)-1=253)</strong>.....</p>
<p>- 16:42:38.053034, TM_LFR_SCIENCE_BURST_BP1_F0, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=3, (PACKET_SEQUENCE_CONTROL=0xc003), PACKET_LENGTH=217, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x80000025ac28, PA_LFR_SID_PKT: SC_B_BP1_F0 = 17, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, PA_BIA_ON_OFF: OFF = 0, PA_LFR_ACQUISITION_TIME=0x80000025ac28, PA_LFR_B_BP1_BLK_NR_F0=22<br />16:42:38.064438, TM_LFR_SCIENCE_BURST_BP1_F1, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=4, (PACKET_SEQUENCE_CONTROL=0xc004), <strong>/!\PACKET_LENGTH=217(exp=(Number of bytes in Packet Data Field)-1=253)</strong>,</p>
<p>Ce probleme est présent sur d'autres tests (vu egalement sur 1.0.0.6)</p>
<p>Contexte<br />LPPMON Version = 0.2.2, Branch = default, Changeset = 835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série 5<br />Vhdl: 0.0.16<br />Soft: 1.0.0.7 (variante sur carte finale)</p>
<p>Brique Star-Dundee S/N <strong>XX</strong>.</p>
LFR-FSW - Bug #152 (Closed): TM_LFR_SCIENCE_NORMAL_BP1 (F0,F1): Champ SPARE et PA_LFR_N_BP1_NR_F(...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/152
2014-05-13T07:04:08Z
Veronique bouzid
<p>Suite à l'execution du test SVS-0090, l'analyse des paquets TM_LFR_SCIENCE_NORMAL_BP1_F0 et TM_LFR_SCIENCE_NORMAL_BP1_F1 a mis en évidence que<br />- le champ SPARE (octet 24) n'est pas initialisé à 0x0.<br />- le champ nommé "number of blocks in the packet" (octet 25) n'est pas correct (pas renseigné au vu des valeurs aleatoires observées).<br /> Ce champ se nomme respectivement PA_LFR_N_BP1_BLK_NR_F0 et PA_LFR_N_BP1_BLK_NR_F1.</p>
<p>Tous les autres packets de type BP1 ou BP2 sont bien renseignés, ils n ont pas d octet SPARE et le champ "number of blocks in the packet" est sur l octet 24 et 25 et correct.</p>
<p>Ici le tableau récapitulatif<br />----------------------------<br />TM_LFR_SCIENCE_NORMAL_BP1_F0<br />- le champ SPARE octet 24 (0x0)<br />- le champ PA_LFR_N_BP1_BLK_NR_F0 octet 25 source = OBSW number of blocks in the packet [1,11]</p>
<p>TM_LFR_SCIENCE_NORMAL_BP1_F1<br />- le champ SPARE octet 24 (0x0)<br />- le champ PA_LFR_N_BP1_BLK_NR_F1 octet 25 source = OBSW number of blocks in the packet [1,13]</p>
<p>Ici un exemple:<br />Fichier analysé est 2014_05_06-19_36_11-Detail.txt<br />17:31:21.183587, TM_LFR_SCIENCE_NORMAL_BP1_F0, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=119, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x800000049901, PA_LFR_SID_PKT: SC_N_BP1_F0 = 14, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, PA_BIA_ON_OFF: OFF = 0, PA_LFR_ACQUISITION_TIME=0x000099014f40, <strong>/!\SPARE=0x48, /!\PA_LFR_N_BP1_BLK_NR_F0=1280/!\Failure format</strong></p>
<p>--------------------------------<br />Contexte:<br />LPPMON Version=0.2.2 - Branch=default - Changeset=835955994d5f</p>
<p>Carte mini-LFR: LFR-172200 dev V1.0; No série 5<br />Vhdl: 0.0.16<br />Soft: 1.0.0.6 (variante sur carte finale)</p>
<p>Brique Star-Dundee S/N <strong>XX</strong>.</p>
<p>Scripts utilisés : <br />SVS-0090/generate_science_all_modes.py (BKA)</p>
LFR-FSW - Bug #111 (Closed): Pb de timing dans le traitement de TC_LFR_UPDATE_TIME
https://hephaistos.lpp.polytechnique.fr/redmine/issues/111
2014-04-02T10:37:53Z
Gerald Saule
<p>Le changement de temps interne (au LFR) doit se faire sur réception du time code.<br />Par le code Python, on envoie TC_LFR_UPDATE_TIME, puis le time code 300ms après.</p>
<p>On a les traces:</p>
<blockquote>
<p>11:27:26.425912, TM_LFR_HK, ..., TIME=0x000000044139, ..., HK_LFR_MODE: SBM2 = 4, ..., SY_LFR_SW_VERSION_N1=1, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=4, SY_LFR_FPGA_VERSION_N1=0, SY_LFR_FPGA_VERSION_N2=2, SY_LFR_FPGA_VERSION_N3=255, ..., HK_LFR_UPDATE_TIME_TC_CNT=3, ...<br />11:27:27.193676, TC_LFR_UPDATE_TIME, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=8658, (PACKET_SEQUENCE_CONTROL=0xe1d2), PACKET_LENGTH=11, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: TIME_MANAGEMENT = 9, SERVICE_SUBTYPE: UPDATE_TIME = 129, SOURCE_ID: MISSION_TIMELINE = 110, CP_RPW_TIME=0x000000000000, CRC = 0x4428<br />11:27:27.42591, TM_LFR_HK, ..., TIME=0x00000005413a, ..., HK_LFR_UPDATE_TIME_TC_CNT=4, ...<br />11:27:28.425916, TM_LFR_HK, ..., TIME=0x00000006413c, ...<br />11:27:29.425921, TM_LFR_HK, ..., TIME=0x00000000ee13, ...</p>
</blockquote>
<p>D'après le HK recu à 11:27:27.42591, LFR a reçu le TC_LFR_UPDATE_TIME à TIME=0x00000005413a.<br />Dans le pire cas (où il faut encore attendre les 300ms pour recevoir le time code, avant la remise à 0 du temps interne), le temps interne ne pourra donc pas dépasser 0x000000058E07 (au format CUC).</p>
<p>Malheureusement, il s'écoule plus d'un seconde avant la prise en compte de la valeur de CP_RPW_TIME.<br />C'est clairement incompatible avec la cadence possible des TC_LFR_UPDATE_TIME (1Hz).</p>
<p>Contexte:<br />LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.2.255<br />Brique Star-Dundee S/N <illisible>.<br />Soft:1.0.0.4 (variante sur carte finale)</p>
<p>TEST CASE = SVS-0011<br />Req = SSS-CP-FS-360</p>
<p>RPW-SYS-IDB-00067-LES_Issue2_Rev2<br />RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2</p>
LFR-FSW - Bug #88 (Closed): CP_LFR_ENTER_MODE_TIME de TC_LFR_ENTER_MODE ignoré
https://hephaistos.lpp.polytechnique.fr/redmine/issues/88
2014-03-12T17:15:35Z
Gerald Saule
<p>Le champ CP_LFR_ENTER_MODE_TIME de TC_LFR_ENTER_MODE est toujours ignoré.<br />La transition vue semble immédiate.</p>
<blockquote>
<p>17:58:32.947046, TM_LFR_HK, TIME=0x00000010cbe9, HK_LFR_MODE: NORMAL = 1, SY_LFR_SW_VERSION_N1=1, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=2, SY_LFR_FPGA_VERSION_N1=0, SY_LFR_FPGA_VERSION_N2=0, SY_LFR_FPGA_VERSION_N3=15</p>
<p>17:58:33.58306, TC_LFR_ENTER_MODE, <strong>CP_LFR_MODE: STANDBY = 0, CP_LFR_ENTER_MODE_TIME=0x000000120000</strong><br />17:58:33.600928, TM_LFR_TC_EXE_SUCCESS</p>
<p>17:58:33.947034, TM_LFR_HK, <strong>TIME=0x00000011cbe9, HK_LFR_MODE: STANDBY = 0</strong></p>
</blockquote>
<p>Contexte:<br />LPPMON Version=0.2.2 - Branch=default - Changeset=835955994d5f</p>
<p>Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.0.0.15<br />Soft: 1.0.0.2 (variante sur carte finale) = r104</p>
<p>Brique Brique Star-Dundee S/N 46120065.</p>
<p>TEST CASE associé(s) = SVS-0034.</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p>
LFR-FSW - Bug #54 (Closed): TM_LFR_PARAMETER_DUMP: affectation de SY_LFR_S1_BP_P0 par défaut
https://hephaistos.lpp.polytechnique.fr/redmine/issues/54
2014-02-18T15:20:17Z
Gerald Saule
<p>Cette issue est associée à l'issue Bug#53 ('TM_LFR_PARAMETER_DUMP incohérent avec l'ICD').</p>
<p>Dans un 'TM_LFR_PARAMETER_DUMP', le champ SY_LFR_S1_BP_P0 par défaut (/SOURCE_DATA/LFR_SBM1_PARAMETERS) est affecté à 1.<br />Le LSB étant de 0.25, on en déduit la valeur 0.25s.</p>
<p>La valeur spécifiée par défaut est 1s.</p>
<p>Contexte:</p>
<p>LPPMON: Version=0.2.2 - Branch=default (Changeset=835955994d5f)</p>
<p>Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.0.0.15<br />LFR FSW: 1.0.0.1 (variante sur carte finale)</p>
<p>Brique Star-Dundee S/N 46120065.</p>
<p>TEST CASE = SVS_0001</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p>