Bascom Bug melden

[Thomas E.]

Bekannt. Deine Schnittstellenparameter stimmen nicht! Prüfe, welche COM Schnittstelle eingestellt ist und wie die Einstellungen in der Systemsteuerung sind.

Ich habe COM3 eingestellt, worüber manchmal auch "reale" RS232-Kommunikation stattfindet.

[raidy]

Dann kann ich dir auch nicht helfen, bei mir gehts.

[jo_robot]

Bin mir nicht sicher ob das als Bug läuft, aber

Bascom Version 2.0.7.5.003 fehlt eine m324Adef.dat Der Chip mit der id: 0x1E9515 wird nicht erkannt.

[Dnerb]

Ich habe COM3 eingestellt, worüber manchmal auch "reale" RS232-Kommunikation stattfindet.

Wenn da reale Kommunikation läuft, dann kann natürlich Bascom in dem moment nicht darauf zugreifen. -> Problem

[Thomas E.]

Wenn da reale Kommunikation läuft, dann kann natürlich Bascom in dem moment nicht darauf zugreifen. -> Problem

Nein, die reale Kommunikation findet nicht in jenem Moment statt, in der ich den Simulator benutze (kein Terminalprogramm geöffnet). Trotzdem stürzt Bascom ab.

[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.