Bascom Bug melden

[kritias]

Bug Report:

Betrifft Bascom nach dem letzten Update auf 2.0.7.7
Hier liegt ein Fehler bei der Berechnung von Single-Variablen vor. Wenn man eine Variable nur oft genug mit 0.9 multipliziert, wird die wie erwartet 0. Wenn man weiter macht wird sie irgendwann NAN und dann irgendwann irgendwas ganz großes. Hier ein Beispielprogrämmchen mit dem der Fehler auf einem xmega nachvollzogen werden kann.

$regfile = "xm256a3def.dat"
$crystal = 32000000                                                                                                     '32MHz
$hwstack = 256
$swstack = 256
$framesize = 256
$lib "xmega.lib"
$external _xmegafix_clear
$external _xmegafix_rol_r1014

Config Portf.3 = Output
Config Portf.2 = Input

Dim A As Single
Dim Loopcount As Long

Config Osc = Enabled , 32mhzosc = Enabled
Config Sysclock = 32mhz , Prescalea = 1 , Prescalebc = 1_1
Config Com7 = 9600 , Mode = Asynchroneous , Parity = None , Stopbits = 1 , Databits = 8

Open "COM7:" For Binary As #1
A = 10
Wait 5
    Do
        Incr Loopcount
        A = A * 0.9
        Print #1 , Loopcount ; "    " ; A
    Loop

Der Fehler tritt nach 853 Durchgängen (NAN) und nach 1485 Durchgängen (3924871168.0) auf. Ändert man die Zeile A=A*0.9 in
A=A*9
A=A/10
funktioniert alles einwandfrei. Es scheint, daß der Fehler nur bei Multiplikationen von sehr kleinen Werten auftritt. Ob es noch andere Fälle gibt ist mir zumindest nicht bekannt. Bei Bascom 2.0.7.6 tritt der Fehler nicht auf.

[kritias]

Das ist kein Bug. Das war die NSA!
http://www.elektor.de/news/EmbedNet-Mikrocontroller/

[kritias]

Es gibt Neuigkeiten. Mark Alberts hat ein Update veröffentlicht. Einfach in Bascom auf Hilfe und Update. Der ganz normale Vorgang.

An dieser Stelle nochmal besonderen Dank an Mark Alberts für die extrem schnelle Reaktion.

[Searcher]

BASCOM-AVR Demo Version 2.0.7.5 auf ATTiny25

Es ist kein unmittelbarer Fehler, den ich in BASCOM-AVR Version 2.0.7.5 festgestellt habe, aber doch ein Verhalten, daß eine intensive Fehlersuche zur Folge hatte.

Zum schnellen Datenaustausch hatte ich eine Interruptserviceroutine in Assembler mit auch noch einem timingkritischen Abschnitt darin ohne Sichern der Prozessorregister (bzw manuellem Sichern, Stichwort: nosave) geschrieben.

Da es zu Problemen kam, nahm ich das Programm mittels Disassembler unter die Lupe und fand heraus, daß Bascom ohne Meldung Assemblerbefehle austauscht, anstatt eine Fehlermeldung oder zumindest eine Warnung zu erzeugen. Außerdem wird dabei ein Register benutzt, daß man in einer "nosave ISR" möglicherweise nicht gesichert hat. Siehe Kommentare im Code:

'### Verkürztes kompilierbares Demo zur Problembeschreibung
'### BASCOM-AVR Demo Version 2.0.7.5 (Compiler Version 2.0.7.5)
'
$regfile = "ATtiny25.DAT"
$framesize = 32
$swstack = 32
$hwstack = 34
$crystal = 16000000

Pcmsk = Bits(pcint3 , Pcint4)
On Pcint0 Isr_receive_data_compelled Nosave                 'keine Register sichern
Enable Pcint0
Enable Interrupts

Do
Loop

End                                                         'end program


Isr_receive_data_compelled:

  sbi gifr, pcif                                            'löschen Interrupt Flag

'### Mit Bascom assembliert und dann mit ReAVR von ja-tools zum Überprüfen
'### disassembliert zeigte, daß aus der SBI Zeile ohne Warnung Folgendes entstand
'### und dabei r23 verändert wurde.
'###
'###   lds        r23,(p3A+0x20)        ; io register
'###   ori        r23,k20
'###   sts        (p3A+0x20),r23        ; io register
'###
'### OK, SBI kann nicht auf das GIFR im ATTiny25 zugreifen, da das Register außerhalb
'### des Adressbereiches von SBI liegt.
'###
'### In einer ISR, die keine Register sichert kann die Änderung von r23 OHNE Warnung
'### aber fatal werden. Bei zeitkritischen Routinen können außerdem die zusätzlichen
'### Takte des Ersatzcodes noch graue Haare wachsen lassen wenn man von dem Austausch
'### zunächst nichts mitbekommt - Programm läuft ja eigentlich.

Return

In der gleichen "nosave ISR" verwendete ich folgendes Kommando:
Loadadr Flash_data(write_block_array_pointer) , X
Hier wird das Register r10 verändert. (Das X für r26, r27 steht, ist normalerweise bekannt)

Problem ist nicht weitergemeldet und vielleicht ist das ja auch irgendwo dokumentiert.

[kritias]

Ich gehe da immer so vor:
ich schließe zeitkritische Teile mit einer Menge NOP ein und kompiliere das ganze. Das Ergebnis sehe ich mir dann im AVR-Studio in Assembler an. Durch die vielen NOPs ist die Stelle auch leicht zu finden. Den Zeitkritischen Assembler-Teil optimiere ich dann. Also das unnötige wegspeichern der Register entfernen, so wenige wie möglich Register verwenden und was einem sonst so auffällt. Dann muss ich im Falle eines Interrups nur noch die verwendeten Register sichern. (Nosave!) Dabei hat Bascom noch nie etwas einfach so geändert.Die NOPs kommen nach getaner Arbeit weg. Verzählen darf man sich halt nicht wenn man den Stack von Hand beackert. Da hab ich schon meine bösen Überraschungen erlebt. War dann aber meine Dummheit und kein Fehler von Bascom.

[Searcher]

Ich gehe da immer so vor:
.
.

Ja, so oder so ähnlich werde ich das auch in Zukunft machen. Ich war halt total überrascht, daß ein Assemblerbefehl ausgetauscht wurde. Mit gutem und richtigen Grund, da ja auf einem ATTiny25 ein SBI GIFR,PCIF nicht möglich ist. Das sollte aber bei einem Assembler Befehl nicht ohne dicke rote Warnung geschehen. Der Compiler/Assembler hat ja erkannt, daß da etwas nicht paßt und könnte eben auch eine Meldung erzeugen. Vielleicht wurde auch in höheren Versionen da schon etwas vorgesehen.

Bei LOADADR mit einem indirekt adressierten Array als Argument würde mich ein Hinweis auf das zusätzlich verwendete Register zufrieden stellen

Ich hatte bisher in nosave ISRn immer nur die Register gesichert, die ich auch selbst in der ISR verwendet habe. Trotz der möglichen Verbesserungen finde ich den einfachen Gebrauch von Assembler innerhalb von Bascom Programmen genial.

Gruß
Searcher

[Searcher]

  sbi gifr, pcif                                            'löschen Interrupt Flag

'### Mit Bascom assembliert und dann mit ReAVR von ja-tools zum Überprüfen
'### disassembliert zeigte, daß aus der SBI Zeile ohne Warnung Folgendes entstand
'### und dabei r23 verändert wurde.
'###
'###   lds        r23,(p3A+0x20)        ; io register
'###   ori        r23,k20
'###   sts        (p3A+0x20),r23        ; io register
'###
'### OK, SBI kann nicht auf das GIFR im ATTiny25 zugreifen, da das Register außerhalb
'### des Adressbereiches von SBI liegt.
'###
'### In einer ISR, die keine Register sichert kann die Änderung von r23 OHNE Warnung
'### aber fatal werden. Bei zeitkritischen Routinen können außerdem die zusätzlichen
'### Takte des Ersatzcodes noch graue Haare wachsen lassen wenn man von dem Austausch
'### zunächst nichts mitbekommt - Programm läuft ja eigentlich.

Was mir gerade bewußt geworden ist. Diese Zeilen

lds        r23,(p3A+0x20)        ; io register
ori        r23,k20
sts        (p3A+0x20),r23        ; io register

die Bascom statt dem "sbi gifr, pcif" eingesetzt hat, löschen nicht nur das PCI-Flag, sondern alle Interrupt Flags im GIFR. Übel! Das "ori" ist gut um in anderen Registern Bits zu setzen aber gar nicht gut um ausgewählte Interrupt Flags zu löschen.

Gruß
Searcher

[Searcher]

Da es zu Problemen kam, nahm ich das Programm mittels Disassembler unter die Lupe und fand heraus, daß Bascom ohne Meldung Assemblerbefehle austauscht, anstatt eine Fehlermeldung oder zumindest eine Warnung zu erzeugen.

Ich hatte dieses Verhalten doch noch an mcs gemeldet, da ich beim Löschen eines Interrupt Flags dadurch echte Fehler bekam und habe auch Antwort bekommen.

Kurz: Das Verhalten ist kein Fehler, sondern ist so designed. Es gibt aber einen switch, mit dem man den Austausch der asm Befehle verhindern kann. Bei Verhindern des Austausches mit dem switch kommt es dann zu einer Fehlermeldung in meinem Beispiel. Tja, hätte ich die Doku doch vorher gründlicher, noch gründlicher gelesen

Der switch ist "$notransform on". Steht in der Doku zwar mit Doku-Fehlern, die aber von mcs noch behoben werden.

Der switch wird ab sofort bei mir in Verbindung mit asm intensiv genutzt werden!

Gruß
Searcher