MFU NiosII Software Change Log

Refer to MFUSoftwareReleaseNotes for futher release infomation and possibly known issues.

007.00004 (10.07.2020)
  • Durch Änderungen in 007.00003 in der Funktion 'serial_flash_get_system_parameters()' konnte es passierte, dass am Ende einer Page nicht die nächste geladen wurde obwohl der USI-String ueber die Page-Grenze hinaus ging.
    Vielmehr wurde das Laden der Parameter abgebrochen, weil 'ascii_value <> ETX' war und page_index = 256.
  • Senden von Interlocktexten war nicht moeglich und wurde immer mit 'ERR_CHECKSUM_ERROR' beantwortet. Der Pruefsummentest war wegen einer Modifikation im FSP233 Funktionstext versehentlich geloescht.
  • War SVE eingeschaltet und wurde ICM gezogen (Status nicht mehr lesbar), wurde CPU_STATUS_PSU_IS_ON nicht geloescht. D.h. fuer z.B. PCA war der Geraetetstatus weiterhin: Eingschaltet.
  • Die Abschaltung der zyklischen Interlockabfrage ueber CPU-Status hat nicht richtig funktioniert.
  • Mit dem Kommandos '*initpar' wird nun zusaetzlich auch der Konfigurationsdateien-Sektor geleoscht.
  • Das FSP66 entfaellt zukuenftig. Daher ist das Uebertragen von Interlockinfos an die SCU/die IFK nun mittels RAM organisiert. Die Funktion 'menu_0111_interlocks_dyn()' entsprechend angepasst.
  • Geht ein Modul/eine gesamt USI verloren, sind bisher alle nachfolgenden Interlockbits in der Ausgabe ans Kontrollsystem nach vorne gerutsch. Das ist natuerlich nicht so schoen, da deren Bedeutung dann nicht mehr stimmt.
    Kuenftig werden Interlockbits verlorener Module mit '0' aufgefuellt. Fuer das Kontrollsystem stehendan dann ALLE Interlocks des Moduls an.
  • ISR Probleme in Massen:
    • Beim Empfang von Parametern (STATUS_CURRENTLY_RECEIVING_MFU_PARAMETERS_n = '0') darf in der zugehoerigen ISR das Setzen von WARNING_MODULE_VERFICATION_FAILED nicht ins Logbuch eingetragen werden. Andernfalls wuerde bei jedem Parametersenden faelschlich ein Fehler der Modulverfikation auftauchen.
    • Die Interruptquelle (weil ueberflüssig) STATUS_CHECKSUM_OK ist auf STATUS_CURRENTLY_RECEIVING_MFU_PARAMETERS_n reduziert.
    • Die Auswertung des 'EdgeCapture-Register' u.a. in der 'status_pio_isr()' war nicht richtig.
      Dieses Register erkennt fuer den STATUS_PIO prinzipiell eine fallende Flanke bei jedem Bit. Ist zusaetzlich fuer das betreffende BIT der IRQ zugelassen, wird bei fallender Flanke an diesem Bit die ISR aufgerufen. Da aber auch Flanken an anderen BITs, die KEINE IRQ Freigabe haben erkannt worden sein koennen, sind im 'EdgeCapture-Register' mitunter Bits gesetzt, die keinen Interrupt ausloesen.
      Beispiel:
      EdgeCapture 0011 0010 drei Flanken erkannt
      Interrupt 1100 0010 drei Interruptquellen aktiv
      EC & I 0000 0010 Bit[1] hat ausgeloest
      Wird nur das 'EdgeCapture-Register' in der ISR betrachtet, sind drei Bits gesetzt, dabei hat Bit[1] den Interrupt ausgeloest.
      Das notwendige UND hat bisher gefehlt. Dadurch wurden ggf. auch falsche 'if'-Zweige abgearbeitet.
    • Das int. Scope war immer aktiv (unabhängig von den Parametern), weil am Ende der ‚scope_init()‘ Funktion der Trigger aktiviert wurde. Das ist dahingehend fatal, als dass dadurch im Falle eines Triggerereignisses die 'status_pio_isr()' aufgerufen wurde. Das selbst ist noch nicht das Problem, in der ISR aber, wurden (durch das fehlerhaftes Bitmanagement) mitunter Bits "geserviced", die gar nicht als ISR-Quelle zugelassen waren. U.A. STATUS_CURRENTLY_RECEIVING_MFU_PARAMETERS_n*, was dafür sorgte, dass CPU_STATUS_MODULES_VERIFIED geloescht und WARNING_MODULE_VERFICATION_FAILED gesetzt wurde. Der Trigger ist daher nun per Standard deaktiviert, auch wenn das Problem in der ISR behoben ist.
  • Alle mUSIc_COM_BLOCK mit 'usi_number' und 'module_number' vorinitialisiert im Hinblick auf 'error_record_error()'. Dort wird nun, sofern 'usi_number >= USI_NMBR_UNDEFINED' und/oder 'module_number >=MOD_NMBR_UNDEFINED' sind der entsprechende Wert mit 0xF abgelegt. dadurch ist ersichtlich, dass die Variable ggf. (noch) nicht in Verwendung war. Dies soll Eintraege falscher USI/Modul Nummern aufgrund nicht initialisierter Variablen verhindern.
  • Logbuch zeigt undefinierte USI/Modul-Nummern nun als '-1'.
  • 'usi_auto_reconnect()' komplett ueberarbeitet. Das Wiederverbinden einzelner Module an USIs, die NICHT in HighSpeed sind, funktionierte nicht richtig.
  • Laden von Parametern von USB-Speichern ins MFU RAM hat nur 1x funktioniert, danach kam es zu einem Mem-Buf-Error. Ursache war: Der Pointer auf den reservierten RAM Speicher wurde veraendert, daher schlug 'free(pointer)' fehl.
  • CPU_STATUS_PERFORMING_USI_SCAN ist nun CPU_STATUS_MFU_CAN_NOT_TRANSFER_ANY_DATA_RIGHT_NOW und wird nicht mehr nur fuer den USI-Scan verwendet. Vielmehr wird der CPU-Status mit gesetztem CPU_STATUS_MFU_CAN_NOT_TRANSFER_ANY_DATA_RIGHT_NOW nun immer dann verschickt, wenn PCA gerade mal nicht irgendwelche Daten an die MFU schicken oder von dieser holen soll, weil diese zu beschaeftigt ist.
  • Das Umschalten von Bitraten einzelner Module/USI mittels FSP244 funktionierte nicht, wenn an einem USI mehr als ein Modul angeschlossen ist. Es muessen die Bitraten fuer ALLE Module geandert werden, nicht nur fuer das im 'p_usi_com_block'. Abhaengig vom neuen Parameter 'change_bit_rate_usi_mode_for_all_modules' in 'usi_config_bit_rate_usi_mode()' werden nun ggf. alle Module auf einmal umgeschaltet. Dabei wird darauf geachtet, dass die Bitrate des langsamsten Moduls nicht ueberschritten wird.
  • Neues internes FSP227 'internal_fsp_227()' fuer Bitmanipulationen in beliebigen FSPs. Verbesserte Version von int. FSP241.
  • Differenziertere Statusanzeige im Hinblick auf "Controller disabled".
  • Neues FSP067 in der MFU wird unterstuetzt im 'menu_0021_quick_oview_usi_modules()'. Dieses zeigt nun im Falle 'TFT_SHOW_USI_1ST_MODULE' ein rotes Sternchen (*) beim zugehoerigen Modul an, wenn dieses sich im HS-Modus befindet aber das zugehoerige Bit im FSP067 nicht gesetzt ist.
  • Int. FSP231 und FSP245 unterstuetzen nun auch das neue, auf vier Kanaele reduzierte Scope in der MFU.
  • Altera Remote Update fuer Cyclone V erfordert einen groesseren Adressbereich in FSP045. Daher nimmt 'update_update_module_firmware()' nun Ruecksicht auf die neue FSP-Tiefe von 7 anstelle 6 Byte.
  • Der Menuepunkt 145 zeigt nun den Mediendurchfluss bei vorhandenen Durchflusswaechtern.
  • Besitzt ein Modul KEINEN FSP004 und ist im Standard USI Modus konnte ohne FSP004 der Verlusst dieses Moduls am USI nicht erkannt werden. Daher wird nun in diesem Fall FSP012 gelesen. Dessen Inhalt aber verworfen. Ein FSP004 ist also zukuenftig fuer Module OHNE Interlockerfassung nicht mehr noetig.
  • 'menu_0062_..()' und 'mux_get_front_dac_..()' Funktionen an das neue 4 Kanal Scope und die Tatsache, dass es keinen seperaten FSP115 zur Scope-Quellenwahl mehr gibt angepasst. Die Scopequellen werden künftig ueber FSP110 fuer den DAC bestimmt. (02.04.20 - DS)
  • int. Scope auf dem TFT wurde nicht immer korrekt getriggert, da das Ein- bzw. Ausschalten der zugehoerigen ISR nicht richtig funktionierte (09.04.20 - DS)
  • Sind mehr als 2 ADCs angebunden, wird KEIN "ERR_MDS_3RD_ADC_FOUND" mehr erzeugt. Es sind beliebig viele ADCs möglich, aber der erste gefundene wird als ADC1 (Istwert-Strom) der naechste als ADC2 (Istwert-Feld) gewertet und auch entprechend auf dem TFT angezeigt. Für alle weiteren ADCs werden deren Messwerte NICHT auf dem TFT gezeigt. (27.05.20 - DS)
  • Neuer Menuepunkt "menu_0044_copy_compresse_configuration()" zum kopieren der gepackten Gerätekonfigurationdatei auf einen USB Speicher. (24.06.20 - DS)

007.00003 (24.05.2019)
  • Bisher wurde auf 'USI_RxBufCounter < (USI_RXBUF_SIZE-1)' geprüft. Da 'USI_RxBufCounter' aber in der ISR inkrementiert und in 'usi_get_value()' dekrementiert wird, konnte es passieren, dass beide Zählungen "zeitgleich" erfolgen. Die ISR ist zwar verriegelt und kann nicht unterbrochen werden, 'usi_get_value()' hingegen von der ISR sehr wohl. Wie auch immer 'USI_RxBufCounter' ging manchmal falsch. Daher wird nun direkt auf die Pufferzeiger 'USI_RxBufIn' und 'USI_RxBufOut' getestet. 'USI_RxBufCounter' wird rein zu Debugzwecken noch mitgeführt.
  • Bei einem Module FW Update war es möglich Module zu adressieren, die in Wirklichkeit überhaupt nicht angeschlossen sind.
  • Das Gleiche galt für das Starten von "Reconf". Auch hier muss ein Modul nun physisch vorhanden sein.
* Bei der Interlockanzeige und zusätzlich bei deren Kommunikation ans Kontrollsystem wurde '.mem_interlocks' verwendet. Dies ist insofern nicht ganz OK, als dass ein Benutzer 'Memorized Interlocks' deaktivieren, resp. diese maskieren kann. Im Interlockfall wird dieses Bit dann nicht gesetzt, wurde also weder auf dem TFT angezeigt (sofern auch dessen HW-Anbindung an die Reißleine deaktiviert war), noch an das Kontrollsystem gemeldet. Nun werden '.mem_interlocks' und '.act_interlocks' miteinander UND Verknüpft und im neuen Speicherbereich '.mem_or_act_interlocks' abgelegt. Dieser neue Speicherbereich wird nun für die Anzeige und Meldung an das Kontrollsystem verwendet. Daraus folgt, solange das Interlockbit (ENTWEDER) in '.mem_interlocks' UND/ODER '.act_interlocks' gesetzt ist, wird es erkannt und gemeldet.
Für die Anzeige auf dem MFU TFT gilt:
Masken Interlock Rahmen/TFT Anzeige
"Pending Interlocks" "Memorized Interlocks" inaktiv aktiv wieder inaktiv bisher mit RL-Anbind. bisher OHNE RL-Anbind. jetzt MIT RL-Anbindung jetzt OHNE RL-Anbindung
zulässig zulässig X
-
-
grün/No interlocks grün/No interlocks grün/No interlocks grün/No interlocks
zulässig zulässig - X -
rot /*Interlock (RL) rot /*Interlock (RL) rot /*Interlock (RL) rot /*Interlock (RL)
zulässig zulässig - - X rot / Interlock (RL) rot / Interlock (RL rot / Interlock (RL) rot / Interlock (RL)
zulässig ausmaskiert X - - grün/No interlocks grün/No interlocks grün/No interlocks grün/No interlocks
zulässig ausmaskiert - X - gelb/No interlocks (RL) grün/No interlocks rot /*Interlock (RL) rot /*Interlock
zulässig ausmaskiert - - X gelb/No interlocks (RL) grün/No interlocks gelb/No interlocks (RL) grün/No interlocks
ausmaskiert zulässig X - - grün/No interlocks grün/No interlocks grün/No interlocks grün/No interlocks
ausmaskiert zulässig - X - rot / Interlock (RL) rot / Interlock (RL) rot / Interlock (RL) rot / Interlock (RL)
ausmaskiert zulässig - - X rot / Interlock (RL) rot / Interlock (RL) rot / Interlock (RL) rot / Interlock (RL)
ausmaskiert ausmaskiert X - - grün/No interlocks grün/No interlocks grün/No interlocks grün/No interlocks
ausmaskiert ausmaskiert - X - gelb/No interlocks (RL) grün/No interlocks gelb/No interlocks (RL) grün/No interlocks
ausmaskiert ausmaskiert - - X gelb/No interlocks (RL) grün/No interlocks gelb/No interlocks (RL) grün/No interlocks
(RL) sofern das Interlock modulseitig an die HW-RL angebunden ist, wird diese gezogen
Das Verhalten ändert sich also nur wenn "Memorized Interlocks" ausmaskiert ist.
  • Leider wird die RESET-Taste nicht per ISR erfasst, sondern nur gepolled. Daher kann das Löschen von Interlocks und ändern der Rahmenfarbe zurück auf Grün nicht direkt an die RESET-Taste geknüpft werden.
    Zeigte das TFT NICHT das 'menu_interlocks_dyn()' und es standen Interlocks an, wurde der Rahmen neuerdings nicht mehr grün, sofern sich diese erfolgreich löschen ließen. Der Rahmen wurde immer erst dann grün, wenn das Menu 'menu_interlocks_dyn()' aufgerufen wurde. Das 'menu_interlocks_dyn()' wurde bisher immer durchlaufen, beim
    - ersten Aufruf des Standardbildschirms
    - zyklischen Interlocktesten durch Aufruf in 'menu_idel_jobs' und dann durch -> testen von 'isr_timer_interlock_circular_check()' in 'menu_interlocks_dyn()'
    - wenn das Interlockmenü "111" angezeigt wird
    durch -> manuellen Aufruf durch den Benutzer
    -> automatischen Aufruf im Interlockfall
    Wurde der zyklische Test ausgesetzt, konnte der Rahmen nicht mehr grün werden, es sei denn, der Benutzer befand sich in 'menu_interlocks_dyn()'.
    Daher sind die Kriterien im 'menu_idle_jobs()' nun dahingehend geändert, dass 'menu_interlocks_dyn()' bei mindestens einer gezogener Reißleine und/oder bei mindestens einem anstehenden Interlock auch dann aufgerufen wird, wenn der zyklische Test eigentlich deaktiviert ist.
  • Bei einigen Funktionen im Menü
    - menu_0411_reload_flash_parameters(),
    - menu_4132_load_parameters_FROM_usb_flash_drive_TO_RAM()
    - menu_0422_0432_4131_load_data_FROM_usb_flash_drive()
    - menu_0412_0421_0431_save_data_TO_usb_flash_drive()
    wird der angezeigte Text und die Zulässigkeit zum Ausführen der Funktion durch den Benutzer nun abhängig vom Betriebszustand der SVE (Ein/Aus) oder USB Speicher verfügbar ist oder nicht umgeschaltet. Dadurch entfällt die Notwendigkeit zur Aktualisierung der Anzeige den Menüpunkt erneut aufzurufen. Problem war dabei, dass die Anzeige auf dem TFT mitunter nicht zur Zulässigkeit passte, sofern sich der Betriebszustand der SVE oder die Präsenz des USB Speichers änderte solange dieser Menüpunkt angezeigt wurde.
  • Die Anzeige der physikalischen Einheiten hat nicht wirklich funktioniert. Zum einen waren die FSP29 und FSP39 der physikalischen Eimheiten vertauscht, zum anderen wurden in der Funktion zur Ermittlung der Einheit immer das FSP29 anstelle des uebergeben benutzt.
  • Software FSP229 hinzugefuegt für das HighSpeed auslesen von Aufzeichungsdaten.
  • Software FSP237 ist nun synchronisierbar. Erfordert aber eine passende FW MFU_SE >= 7.4.0.
  • Werden die programmierten Interlocktexte über dem MFU FSP233 gelesen, wurde am Ende der Übertragung KEINE Prüfsumme geschickt. Lediglich das ETX.
  • Beim Programmieren von Interlocktexten mittels USB Speicher ist es möglich, dass eine Datei die nicht vollständig ist ins Flash programmiert wird.
    Z.B. weil die Datei selbst nicht vollständig ist. Es findet beim Programmieren keine Verifizierung statt, da es sich um eine Textdatei handelt deren Inhalt nicht überprüft wird.
    Beim Lesen von Interlocktexten zur Darstellung auf dem TFT kann es also passieren, dass in einem leeren Speicherbereich des seriellen Flashs versucht wird
    den eigentlichen Interlocktext auszulesen. In diesem Fall wurde bisher KEIN Fehler zurükgegeben. Dies sorgte dafuer, dass keine oder fehlerhafte Interlocktexte auf dem TFT zu sehen waren.
  • Leere Parameterdatei von USB Device ins RAM schreiben schlug fehl. Programm hing in 'vnc2_move_parameters_to_ram()'. Manche MFUs starteten sogar neu (wie RESET).
    Wird versucht eine leere Datei zu laden (Größe 0 Byte) wird dies nun verweigert und auf dem TFT gemeldet.
  • War ein USI Parameter String unvollständig, brach also mit (0xFF) ab, wurde dies nicht erkannt.
    Wird ein unvollständiger Parametersatz mit einem unvollstaendigen Parameter String (welcher z.B. nicht bis zum ETX reicht) geladen, wird dies nun sowohl in ‚serial_flash_get_system_parameters()‘ als auch ‚vnc2_move_parameters_to_ram()‘ bemerkt und als inkorrekter Parameterstring dokumentiert.
  • USB Device einstecken, Spannung MFU einschalten -> update.txt wird ausgeführt. Anschließend war USB Device nicht verfügbar, bzw. angeblich nicht angesteckt.
    Beim Starten der MFU wird ‚update_manage_update_from_usb_flash_drive()‘ aufgerufen. Darin wurde zwar getestet ob der VNC2 einen USB Speicher angesteckt hat, aber das zugehörige Flag ‚CPU_STATUS_USB_DEVICE_DETECTED‘ wurde nicht gesetzt, sofern dies der Fall ist. Lediglich ‚CPU_STATUS_USB_DEVICE_PERMITTED‘ wurde gesetzt oder nicht. Die Routinen des Menüs fragen aber zuerst ‚CPU_STATUS_USB_DEVICE_DETECTED‘ ab und erst wenn dieses gesetzt ist: ‚CPU_STATUS_USB_DEVICE_PERMITTED‘. Daher wurde immer angenommen, es ist kein USB Speicher angesteckt.
  • Auslesen der Scopedaten über FSP245 korrigiert im Hinblick darauf, dass die Indizierung der Messwerte von 1..500, der Trigger aber von 0..499 lief. Dies ist nun sowohl in PCA, in der FW (ab 7.4.1) der MFU, als auch in der Nios SW konsistent.

007.00002 (03.08.2018)
  • Die Anzeige "alter" FW-Versionen mit lediglich Major.Minor muss auf die neue FW-Version Major.MinorMSB.MinorLSB korrigiert angezeigt werden. Dies ist lediglich eine "Schönheitsreparatur" für den Benutzer.
  • Das MFU interne FSP 251 zum Speichern der Konfigurationsdatei funktioniert wieder nach dem alten Prinzip.
    1. senden der Dateilänge als vollständiger USI Stream
    2. senden der Konfigdatei als RBF ohne irgendwelche USI Zeichen
    Dies deshalb, weil das neue Verfahren, die Konfigdatei als vollständigen USI Stream zu schicken in PCA nicht richtig funktioniert.
    Die Datei ist komprimiert, d.h. deren Daten sind Symbole und werden vor dem senden mit PCA in einen String konvertiert.
    Dabei passiert etwas (was genau ist die Frage), dass dazu führt, dass sich die Datei nach dem lesen nicht wieder entpacken lässt.
  • Kurze Textanzeige vor der USI Schnellansicht mit der Bitte um etwas Geduld.
  • Die USI Schnellansicht zeigt nun das Image, die Bitrate und den USI Modus an.
  • Sind Modulbeschreibungen in der USI Schnellansicht zu lang, werden diese nun gekürzt und dies per ".." mitgeteilt

007.00001 (04.05.18)
  • Anzeige von Modul-FSP-Inhalten neu strukturiert.
  • MDS der MFU wird nun auch angezeigt.
  • Anzeigefehler bei mehrseitigen Interlocks behoben.
  • Lokaler Sollwert ist nun (richtig) 1/50 vom Nennstrom und nicht mehr 1/50 vom Nennstrom + 10%.
  • Einschaltzeit der SVE wurde falsch erfasst. Da der Status NICHT bitcodiert ist war hier die Verknüpfung nicht korrekt. Folglich wurde die Einschaltzeit auch irrtümlich beim Ausführen eines Kommandos erfasst.
  • Neuer Menüpunkt "Interlock Early Bird".
  • Speichern einer Datei im ext. seriellen Flash ist nun möglich. I.d.R. wird dies die Gerätekonfiguration sein.
  • Beim Erstellen des zugehörigen Software-FSP251 ist aufgefallen, dass im ext. seriellen Flash keine Sektoren > 7 adressiert werden konnten. Dies war beim alten kleinen Flash kein Problem, mit neuerdings 32 Sektoren sehr wohl.
  • Diverse kleine Fehler behoben, wie z.B. Update per USB Flash verhindern wenn SVE eingeschaltet ist oder ändern der Rahmenfarbe im Remotemodus beim Betätigen der RESET-Taste.

007.00000 (29.03.2017)
  • Viele, viele Dinge sind überabeitet. Insbesondere Dinge die mit 'Remote-Update' zu tun haben. Außerdem startet ab hier der Kompatibilitätscheck.
    Soll heißen: PCA und alle Modul-FW, -SW starten nun mit 7.x um klar zu definieren, dass hier etwas neues beginnt und alles andere davor war.

-- DerekSchupp - 2018-11-01
Topic revision: r13 - 2020-09-02, DerekSchupp
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding GSI Wiki? Send feedback
Imprint (in German)
Privacy Policy (in German)