atari-home.de - Foren
Hardware => Firebee => Thema gestartet von: Lukas Frank am Mi 17.06.2015, 09:24:48
-
Hatte die Firebee einige Monate nicht mehr in Benutzung und beim Einschalten kam das ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=12051.0;attach=8359;image)
... Ausschalten wieder einschalten, immer noch da, wieder aus und wieder einschalten und alles ist wieder in Ordnung.
Das ganze ging so einige Tage, jetzt aktuell trifft der Fehler nicht mehr auf und alles ist gut.
Was war das ? Probleme mit dem Flash ?
-
Ganz klar, da gibts zwei Möglichkeiten:
Entweder Deine Biene war extrem frustriert, weil sie die letzten Monate nicht genug Aufmerksamkeit und Liebe bekommen hat. Da ist sie dann die ersten paar Tage immer ein bissl zickig, um zu zeigen, daß sie auch nicht einfach so allzeit bereit ist. Es handelt sich dann quasi um einen teilweisen Streik. Nach ein paar Tagen, besonders wenn sie merkt daß man sich wieder umfassend mit ihr beschäftigt, wird das aber wieder.
Oder Du hast eine Winterschlafbiene erwischt. Eine Unterspezies der Ersten Generation braucht immer ein paar Tage um aus dem Winterschlaf wieder vollständig zu erwachen. Das ist vollkommen normal und wie Du siehst geht ja nach ein paar Tagen wieder Alles problemlos. Stell ihr in der Aufwachphase immer genug Strom hin, und schau daß sie genug Luft und Licht bekommt.
;-)
Ganz ehrlich, das ist absolut neu, und noch nie vorgekommen. Ich stells aber ins Entwicklerforum ob wer eine Idee hat.
-
So ein Bild kenne ich! >:( Aber aus einem etwas anderen Zusammenhang: Wenn mein Hacki den Monitor in den Energiesparmodus versetzt und man den Monitor dann wieder aufwachen lässt, bekomme ich auch oft einen solchen Streuselkuchen angezeigt. Erst dachte ich, dass liegt am OS X oder eben ist dem Umstand des Hackintoshes geschuldet, aber dem ist nicht ganz so. Irgendwas geht anscheinend schief beim Aufwachen des Monitors. Bekommt man diesen Streuselkuchen und stelle ich den Monitor ganz aus und schalte ihn dann wieder ein, ist alles wieder gut. Vor allem passiert es nur ab und zu. Ich habe auch noch keinen wirklichen Grund dafür ausmachen können. Als Monitor ist ein Samsung 24 Zöller dran, der wiederum per DVI an einer AMD Radeon HD 68x0 hängt. Müsste ich Zuhause nochmal genau nachschauen, wenn's von Intresse sein sollte.
-
Seitdem ich die Firebee wieder öfter einschalte und nutze tritt das Problem nicht mehr auf und der weisse Bootbildschirm kommt sofort ...
-
also doch - öfter einschalten :D
-
Gestern war es wieder da, musste die Firebee bestimmt zehn mal Reseten und Ein/Aus Schalten bis es dann irgendwann ging.
Beobachte das weiter und wenn es bleibt schicke ich das Teil vielleicht mal zu Medusa, mal schauen ...
-
Mir ist gerade aufgefallen das die HD Aktivitäts-LED arbeitet, also der Rechner bootet aber der kaputte Bildschirm bleibt ...
-
Hallo,
das Problem habe ich auch.
Bei mir ist aber auch noch eine sehr alte PIC-Version drauf.
Ich hab bisher niemand gefunden der mir meine Biene updaten könnte.
Allerdings habe ich auf der OFAM mitbekommen, dass es auch bei neueren Versionen diese
Probleme gibt.
Die Batterie habe ich auch schon getauscht, das hat aber nichts gebracht.
Viele Grüße
Maritn
-
Erinnert mich irgendwie an die Zeiten wos noch Sendeschluss im Fernsehn gab ;)
Also die einzige Theorie im Team bisher dazu war daß es eben schon was mit kaputten Akkus zu tun hat. Martin, ist es bei Dir irgendwie reproduzierbarer? EDIT: ach ja und mfros Idee mit den timings vom DDRAM controller im FPGA macht natürlcih auch Sinn. Siehe: http://atari-forum.com/viewtopic.php?p=276089#p276089 Da sind wir sehr hart am Limit was mögliche Timings in einem FPGA betrifft, damit kämpft Wolfgang auch schon seit einiger Zeit.
-
Zum Spaßen ist mir nicht zumute wenn ich sehe das, dass Teil nicht mehr Ordnungsgemäß funktioniert !
-
Zum Spaßen ist mir nicht zumute wenn ich sehe das, dass Teil nicht mehr Ordnungsgemäß funktioniert !
Ja, war nicht böse gemeint. Ich kenne das wenn man die Panik bekommt, weil irgendwas gar nicht mehr geht. Ich wollt ein bissl den Druck rausnehmen. Ich denke nicht, daß es sich um einen echten Hardwarefehler handelt.
Wenn Du mal die serielle Konsole angeschlossen hast und wir die Bootmeldungen sehen, und dann gegebenenfalls die FPGA-Config neu geflasht wurde, können wir das hoffentlich eingrenzen.
-
Habe ich schon versucht mit meinem Mac, ohne Erfolg mit so einem mini Null Modem Adapter, USB Seriell Adapter und Zterm auf dem Mac ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=12051.0;attach=8531;image)
Irgendwie mache ich was falsch, das Terminal empfängt nur Nullen ...
Habe mir jetzt mal ein Null Modem Kabel 25/9 beides Buchse für meinen Mega ST bestellt, weiss aber nicht wann das kommt, wir bekommen schon seit 14 Tagen keine Post mehr ...
-
Es klappte nicht weil mein Null Modem Kabel falsch war, keine Ahnung ...
Habe es jetzt hinbekommen mit einem anderen Kabel und meinem Atari Mega ST.
! Eý@ûòúUncompress PCI drivers from 0x00EA0008 (size 0x000380C7) to 0x01000000 (size 0x0007D3BC)
Init MMU
MMU OK
CF68K emulation startý
Scanning PCI devices...
-----------------------------------------------------------------------
Bus | Slot | Fctn | VendorID | DeviceID | Description
-----------------------------------------------------------------------
[0] | [0] | [0] | 0x1057 | 0x5806 | Bridge Controller
[0] | [1] | [0] | 0x1033 | 0x0035 | Serial Bus
[0] | [1] | [1] | 0x1033 | 0x0035 | Serial Bus
[0] | [1] | [2] | 0x1033 | 0x00E0 | Serial Bus
[0] | [1] | [3] | 0xFFFF | | no device
[0] | [2] | [0] | 0xFFFF | | no device
[0] | [3] | [0] | 0xFFFF | | no device
[0] | [4] | [0] | 0xFFFF | | no device
[0] | [5] | [0] | 0xFFFF | | no device
[0] | [6] | [0] | 0xFFFF | | no device
[0] | [7] | [0] | 0xFFFF | | no device
[0] | [8] | [0] | 0xFFFF | | no device
[0] | [9] | [0] | 0xFFFF | | no device
[0] | [10] | [0] | 0xFFFF | | no device
[0] | [11] | [0] | 0xFFFF | | no device
[0] | [12] | [0] | 0xFFFF | | no device
[0] | [13] | [0] | 0xFFFF | | no device
[0] | [14] | [0] | 0xFFFF | | no device
[0] | [15] | [0] | 0xFFFF | | no device
USB: EHCI usb-uPD720101, regs address 0xA0002000, PCI handle 0x20001
Scanning bus for devices... 1 USB Device(s) found
USB: OHCI usb-uPD720101-0, regs address 0xA0000000, PCI handle 0x1
Scanning bus for devices... 1 USB Device(s) found
USB: OHCI usb-uPD720101-1, regs address 0xA0001000, PCI handle 0x10001
Scanning bus for devices... 1 USB Device(s) found
init_videl TFP410 OK
Setscreen mode 0x003B 640x480-8@60
init_videl search in videl list 640x480x8@60Hz on DFP
init_videl PLL detected
init_videl found in modedb list 640x480x8 with clock 25MHz
init_videl 640x480x8@60Hz 25MHz HSYNC:LOW VSYNC:LOW
HHT:320 HBB:2B0 HBE:02F HDB:030 HDE:2AF HSS:2C0
VFT:20D VBB:201 VBE:020 VDB:021 VDE:200 VSS:20B
ADDR:60000000 VWRAP:0140 VCTRL:000 VCO:182
ACP_VIDEO_CONTROL:01078213 (01078213)
ERROR: OHCI usb-uPD720101-0 CTL:TIMEOUT
ERROR: OHCI usb-uPD720101-1 CTL:TIMEOUT
CODEC SYNC frequency: 48636 Hz
Pure C info at 0x110d240 to 0x1153f38 \AUTO\NVDI.PRG
Pure C info at 0x110f0b6: a000 0000 mac.w d0.l,d0.l,acc0
Pure C info at 0x110f6ae: 1e1f move.b (sp)+,d7
Pure C fix at 0x111a71c: 1f01 move.b d1,-(sp) -> 0xa911
Pure C fix at 0x111a8b8: 1f01 move.b d1,-(sp) -> 0xa911
Pure C fix at 0x111c56a: 1f00 move.b d0,-(sp) -> 0xa910
Pure C fix at 0x111c588: 1f00 move.b d0,-(sp) -> 0xa910
Pure C fix at 0x111d372: 1f00 move.b d0,-(sp) -> 0xa910
Pure C info at 0x1141146: a002 24a8 mac.w d2.l,d0.u>>,acc0
Pure C info at 0x1141162: a001 4fef msac.l d1,d0,acc0
Pure C info at 0x1141190: 1f00 move.b d0,-(sp)
Pure C info at 0x11411a0: 1f00 move.b d0,-(sp)
Pure C info at 0x11411b2: 1f02 move.b d2,-(sp)
Pure C fix at 0x1144c7a: 4c00 1c00 muls.l d0,d0:d1 -> 0xabc0
Pure C fix at 0x1144c7e: 4c42 1c00 divs.l d2,d0:d1 -> 0xafc2
Pure C fix at 0x1144cd6: 4c00 1c02 muls.l d0,d2:d1 -> 0xabc0
Pure C fix at 0x1144d5a: 4c40 2c01 divs.l d0,d1:d2 -> 0xafc0
Pure C info at 0x114535e: 1e1f move.b (sp)+,d7
Pure C info at 0x114545e: 1e1f move.b (sp)+,d7
Pure C fix at 0x114a102: 4c00 1c00 muls.l d0,d0:d1 -> 0xabc0
Pure C fix at 0x114a106: 4c42 1c00 divs.l d2,d0:d1 -> 0xafc2
Pure C info at 0x11513c6: a006 4e75 mac.l d6,d0,acc2
Pure C info at 0x11513d2: a007 2c5f mac.l d7,d0>>,acc2
Pure C info at 0x1151fe2: a000 7000 mac.w d0.l,d0.l,acc0
Line A opcode 0xA920 at 0x0110D28C
Line A opcode 0xA920 at 0x01175390
Zur Zeit funktioniert die Firebee. Habe mal einen anderen Monitor probiert und bei dem kommt bei dem Fehler nicht dieses bunte Bild sondern der Schirm bleibt einfach Schwarz, es kommt aber auch keine Meldung das kein Signal da wäre ...
-
Da steht nichts Auffällges. Die Kiste bootet normal, hat wohl bloß kein Bild.
Ich kann da nur raten.
Wie schon geschrieben, ist das FPGA-Timing in der Firebee ziemlich an der Grenze dessen, was der Chip kann. Das äußert sich beispielsweise dadurch, daß das Auslesen des VIDEO_PLL_CLK Registers nur bei jedem zweiten Zugriff gelingt.
Ich könnte mir vorstellen, daß eine leere oder "andere" Firebee-Batterie die Spannungspegel beeinflußt und die Kiste von "funktioniert gerade noch" nach "kein Bild mehr" bringt.
Ist aber nur eine Vermutung. Wie gesagt, ich hatte das Phänomen noch nie. Meine Firebee hängt aber fast ständig am Netz und die erste Batterie funktioniert immer noch zuverlässig.
-
Zur Zeit bootet die Firebee ja auch fehlerfrei. Ich muss mal abwarten bis der Fehler wieder auftrifft und dann einen Dump einstellen.
An meinem iiyama Monitor kommt dieses bunte Bild wenn der Fehler auftrifft und beim BenQ Monitor ist der Bildschirm einfach schwarz ...
-
... könnte mir vorstellen, daß eine leere oder "andere" Firebee-Batterie die Spannungspegel beeinflußt und die Kiste von "funktioniert gerade noch" nach "kein Bild mehr" bringt.
Ist aber nur eine Vermutung. Wie gesagt, ich hatte das Phänomen noch nie. Meine Firebee hängt aber fast ständig am Netz und die erste Batterie funktioniert immer noch zuverlässig.
Mein Akku war völlig platt, sprich kaputt, das ding hatte nur noch einige mV an Spannung ...
Habe jetzt den Akku von Reichelt drin ->
Sanyo (ENERPOWER) Li-Ion 18650 Zelle mit PCB
•Technologie:Lithium
•Ausführung:18650
•Spannung:3,6 V
•Kapazität:2600 mAh
•Anschluss:Flat-Top
•Typ:Industriezelle
•Gefahrgut / Sondervorschrift:UN3480/188
•Kategorie:Zelle
•Nennenergie:9,36 Wh
Ist ein baugleicher Akku allerdings mit einigen mA mehr Strom, das dürfte aber im Grunde ins ausmachen ...
Ich kann die Firebee natürlich auch problemlos nur über das Akku laufen lassen bis der leer ist, wird dann auch wieder aufgeladen sobald Netz da ist.
Joska sagte mal er nutze ein 19 Volt Netzteil und ich betreibe meine Firebee mit 12 Volt, mein Netzteil liefert maximal 5 Ampere an Strom. Hatte mal mit 15 Volt probiert aber immer noch mit dem gleichen Fehler. Die 12 Volt gefallen mir besser da die Spannungregler in der Firebee dann nicht so viel Verlust produzieren, keine Ahnung ...
Mein 12 Volt Netzteil lief ja auch Monate lang ohne Probleme, also kann es daran nicht liegen denke ich mal ...
-
Braucht denn die Firebee irgendwo 12V auf der Platine? Ich frage deshalb, weil wenn du einen Spannungsregler mit 12V versorgst, kannst du nicht erwarten, dass auf der anderen Seite noch 12V rauskommen. Wenn also die FV für irgendwas 12V braucht, dann muss die Eingangsspannung höher sein.
-
Braucht denn die Firebee irgendwo 12V auf der Platine?
Nicht daß ich wüsste.
-
Wenn der Fehler auftritt ist der Dump ->
Bildschirm Schwarz ->
R-lvu%UUU,LWUUUUçVUUUUVUUU:TZ-U§Sby$RÓT-þ*-ë} -AÁRH5-(-A(-(IÒÅ©II»ÄéU÷e5v
BUUU,[UUUU5+UUUU5eUUu-äúiº-wRH5-OR+vº- Õh5©åR8rUUU×-¾UUüR-U%JRUUõvUUU§çoåM¯µ
{Úíe]Ò×e
,fGÀ0J
Bildschirm mit Farbmuster ->
R-lvu%UUU,LWUUUUçVUUUUVUUU:TZ-U§Sby$RÓT-þ*-ë} -AÁRH5-(-A(-(IÒÅ©II»ÄéU÷e5v
BUUU,[UUUU5+UUUU5eUUu-äúiº-wRH5-OR+vº- Õh5©åR8rUUU×-¾UUüR-U%JRUUõvUUU§çoåM¯µ
{Úíe]Ò×e
,fGÀ0J
P)þÒÊEȨ@ùUU'WT
ºUmTëi¥»UmDM%dõU+¬S¬+¢ëYLUfEUÛM©u+%¬Õ+RUU§vZUµwLu)U;)"«+RUU
§ZUµwLS)·¥+¬+RUU§uZUµwV5jªSs×-@UÊ»ÕIV¯Éjä»ÕÝ,mÚC×µÜÚ§í[Ú·S
¨ PGyùòIëE
-
Das sieht mir wie eine falsch eingestellte Baudrate aus. Die Ausgaben der seriellen Schnittstelle sollten halbwegs lesbar sein...
-
Ich schaue noch mal ...
Ist aber auf 19200 Baud eingestellt und wenn die Firebee richtig bootet ist der Dump ja auch lesbar.
-
Kann sein das es nicht 19200 Baud waren. Komme hier ein wenig durcheinander da ich mehrere CF Karten habe.
Was gibt es denn z.B. für Windows 7 an Terminal Programmen für die serielle Schnittstelle wegen der höheren Baudraten ?
Zur Zeit läuft die Firebee wieder, ich muss warten bis der Fehler wieder auftritt ...
-
Nimm unter Windows einfach Putty. Das kann alles außer Hochdeutsch.
-
Sieht kompliziert aus, etwas einfacheres wäre mir lieber ...
-
Sieht kompliziert aus, etwas einfacheres wäre mir lieber ...
Falls dir TeraTerm besser gefällt: http://en.osdn.jp/projects/ttssh2/releases/63335
(keine Angst, japanisch ist nur die Website)
-
Tera Term ist wunderbar, recht vielen Dank.
Ich hatte Realterm, das war aber nichts ...
-
Putty ist total easy.
-
ssh und telnet client hat mich etwas abgeschreckt ...
-
Du kannst in Putty die Kommunikation auch auf COM-Port umstellen, guck mal genau hin.
-
So jetzt sollte alles richtig sein. Die Firebee funktionierte die ganze Zeit einwandfrei bis auf heute Abend ...
Das ist der Fehler ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=12051.0;attach=8359;image)
Der Dump über die serielle Schnittstelle ist aber normal so wie es aussieht ohne Fehler. Trotzdem bekomme ich das Fehlerbild mit diesem Farbmuster auf dem Bildschirm ...
SERIAL OK!
SLT OK!
FBCS OK!
DDRAM OK!
FPGA OK!
PLL SET!
DVI OK!
SD-Card SDHC SMI 1GB OK!
Uncompress PCI drivers from 0x00EA0008 (size 0x000380C7) to 0x01000000 (size 0x0007D3BC)
Init MMU
MMU OK
CF68K emulation started
Scanning PCI devices...
-----------------------------------------------------------------------
Bus | Slot | Fctn | VendorID | DeviceID | Description
-----------------------------------------------------------------------
[0] | [0] | [0] | 0x1057 | 0x5806 | Bridge Controller
[0] | [1] | [0] | 0x1033 | 0x0035 | Serial Bus
[0] | [1] | [1] | 0x1033 | 0x0035 | Serial Bus
[0] | [1] | [2] | 0x1033 | 0x00E0 | Serial Bus
[0] | [1] | [3] | 0xFFFF | | no device
[0] | [2] | [0] | 0xFFFF | | no device
[0] | [3] | [0] | 0xFFFF | | no device
[0] | [4] | [0] | 0xFFFF | | no device
[0] | [5] | [0] | 0xFFFF | | no device
[0] | [6] | [0] | 0xFFFF | | no device
[0] | [7] | [0] | 0xFFFF | | no device
[0] | [8] | [0] | 0xFFFF | | no device
[0] | [9] | [0] | 0xFFFF | | no device
[0] | [10] | [0] | 0xFFFF | | no device
[0] | [11] | [0] | 0xFFFF | | no device
[0] | [12] | [0] | 0xFFFF | | no device
[0] | [13] | [0] | 0xFFFF | | no device
[0] | [14] | [0] | 0xFFFF | | no device
[0] | [15] | [0] | 0xFFFF | | no device
USB: EHCI usb-uPD720101, regs address 0xA0002000, PCI handle 0x20001
Scanning bus for devices... 1 USB Device(s) found
USB: OHCI usb-uPD720101-0, regs address 0xA0000000, PCI handle 0x1
Scanning bus for devices... 1 USB Device(s) found
USB: OHCI usb-uPD720101-1, regs address 0xA0001000, PCI handle 0x10001
Scanning bus for devices... 1 USB Device(s) found
init_videl TFP410 OK
Setscreen mode 0x003B 640x480-8@60
init_videl search in videl list 640x480x8@60Hz on DFP
init_videl PLL detected
init_videl found in modedb list 640x480x8 with clock 25MHz
init_videl 640x480x8@60Hz 25MHz HSYNC:LOW VSYNC:LOW
HHT:320 HBB:2B0 HBE:02F HDB:030 HDE:2AF HSS:2C0
VFT:20D VBB:201 VBE:020 VDB:021 VDE:200 VSS:20B
ADDR:60000000 VWRAP:0140 VCTRL:000 VCO:182
ACP_VIDEO_CONTROL:01078213 (01078213)
ERROR: OHCI usb-uPD720101-0 CTL:TIMEOUT
ERROR: OHCI usb-uPD720101-1 CTL:TIMEOUT
CODEC SYNC frequency: 48493 Hz
filename from default: /home/firetos.hex
host IP from flash params: 192.168.2.1
Pure C info at 0x1938500 to 0x197f1f8 \AUTO\NVDI.PRG
Pure C info at 0x193a376: a000 0000 mac.w d0.l,d0.l,acc0
Pure C info at 0x193a96e: 1e1f move.b (sp)+,d7
Pure C fix at 0x19459dc: 1f01 move.b d1,-(sp) -> 0xa911
Pure C fix at 0x1945b78: 1f01 move.b d1,-(sp) -> 0xa911
Pure C fix at 0x194782a: 1f00 move.b d0,-(sp) -> 0xa910
Pure C fix at 0x1947848: 1f00 move.b d0,-(sp) -> 0xa910
Pure C fix at 0x1948632: 1f00 move.b d0,-(sp) -> 0xa910
Pure C info at 0x196c406: a002 24a8 mac.w d2.l,d0.u>>,acc0
Pure C info at 0x196c422: a001 4fef msac.l d1,d0,acc0
Pure C info at 0x196c450: 1f00 move.b d0,-(sp)
Pure C info at 0x196c460: 1f00 move.b d0,-(sp)
Pure C info at 0x196c472: 1f02 move.b d2,-(sp)
Pure C fix at 0x196ff3a: 4c00 1c00 muls.l d0,d0:d1 -> 0xabc0
Pure C fix at 0x196ff3e: 4c42 1c00 divs.l d2,d0:d1 -> 0xafc2
Pure C fix at 0x196ff96: 4c00 1c02 muls.l d0,d2:d1 -> 0xabc0
Pure C fix at 0x197001a: 4c40 2c01 divs.l d0,d1:d2 -> 0xafc0
Pure C info at 0x197061e: 1e1f move.b (sp)+,d7
Pure C info at 0x197071e: 1e1f move.b (sp)+,d7
Pure C info at 0x197151a: 1f12 move.b (a2),-(sp)
Pure C fix at 0x19753c2: 4c00 1c00 muls.l d0,d0:d1 -> 0xabc0
Pure C fix at 0x19753c6: 4c42 1c00 divs.l d2,d0:d1 -> 0xafc2
Pure C info at 0x197c686: a006 4e75 mac.l d6,d0,acc2
Pure C info at 0x197c692: a007 2c5f mac.l d7,d0>>,acc2
Pure C info at 0x197d2a2: a000 7000 mac.w d0.l,d0.l,acc0
Line A opcode 0xA920 at 0x0193854C
Line A opcode 0xA920 at 0x019A0650
Pure C info at 0x19d21f0 to 0x19d6e1c CT60TEMP.ACC
Pure C info at 0x19d53aa: a000 0000 mac.w d0.l,d0.l,acc0
Pure C info at 0x19d6454: a000 0000 mac.w d0.l,d0.l,acc0
Pure C info at 0x19d8810 to 0x19e122a COPS.ACC
Pure C info at 0x19de53e: a000 225f mac.w d0.u,d0.l<<,acc2
Pure C info at 0x19dfd70: 1e1f move.b (sp)+,d7
Setscreen mode 0x2E3B 1600x1200-8@60
init_videl search in videl list 1600x1200x8@60Hz on DFP
init_videl PLL detected
init_videl found in modedb list 1600x1200x8 with clock 162MHz
init_videl 1600x1200x8@60Hz 162MHz HSYNC:HIGH VSYNC:HIGH
HHT:870 HBB:770 HBE:12F HDB:130 HDE:76F HSS:7B0
VFT:4E2 VBB:4DE VBE:02D VDB:02E VDE:4DD VSS:4DF
ADDR:60000000 VWRAP:0320 VCTRL:000 VCO:1A2
ACP_VIDEO_CONTROL:01078213 (01078213)
[code]
-
Wenn der Fehler nicht auftritt und die Firebee bis zum Desktop unter FireTOS durchstartet der gleiche Dump ...
SERIAL OK!
SLT OK!
FBCS OK!
DDRAM OK!
FPGA OK!
PLL SET!
DVI OK!
SD-Card SDHC SMI 1GB OK!
Uncompress PCI drivers from 0x00EA0008 (size 0x000380C7) to 0x01000000 (size 0x0007D3BC)
Init MMU
MMU OK
CF68K emulation started
Scanning PCI devices...
-----------------------------------------------------------------------
Bus | Slot | Fctn | VendorID | DeviceID | Description
-----------------------------------------------------------------------
[0] | [0] | [0] | 0x1057 | 0x5806 | Bridge Controller
[0] | [1] | [0] | 0x1033 | 0x0035 | Serial Bus
[0] | [1] | [1] | 0x1033 | 0x0035 | Serial Bus
[0] | [1] | [2] | 0x1033 | 0x00E0 | Serial Bus
[0] | [1] | [3] | 0xFFFF | | no device
[0] | [2] | [0] | 0xFFFF | | no device
[0] | [3] | [0] | 0xFFFF | | no device
[0] | [4] | [0] | 0xFFFF | | no device
[0] | [5] | [0] | 0xFFFF | | no device
[0] | [6] | [0] | 0xFFFF | | no device
[0] | [7] | [0] | 0xFFFF | | no device
[0] | [8] | [0] | 0xFFFF | | no device
[0] | [9] | [0] | 0xFFFF | | no device
[0] | [10] | [0] | 0xFFFF | | no device
[0] | [11] | [0] | 0xFFFF | | no device
[0] | [12] | [0] | 0xFFFF | | no device
[0] | [13] | [0] | 0xFFFF | | no device
[0] | [14] | [0] | 0xFFFF | | no device
[0] | [15] | [0] | 0xFFFF | | no device
USB: EHCI usb-uPD720101, regs address 0xA0002000, PCI handle 0x20001
Scanning bus for devices... 1 USB Device(s) found
USB: OHCI usb-uPD720101-0, regs address 0xA0000000, PCI handle 0x1
Scanning bus for devices... 1 USB Device(s) found
USB: OHCI usb-uPD720101-1, regs address 0xA0001000, PCI handle 0x10001
Scanning bus for devices... 1 USB Device(s) found
init_videl TFP410 OK
Setscreen mode 0x003B 640x480-8@60
init_videl search in videl list 640x480x8@60Hz on DFP
init_videl PLL detected
init_videl found in modedb list 640x480x8 with clock 25MHz
init_videl 640x480x8@60Hz 25MHz HSYNC:LOW VSYNC:LOW
HHT:320 HBB:2B0 HBE:02F HDB:030 HDE:2AF HSS:2C0
VFT:20D VBB:201 VBE:020 VDB:021 VDE:200 VSS:20B
ADDR:60000000 VWRAP:0140 VCTRL:000 VCO:182
ACP_VIDEO_CONTROL:01078213 (01078213)
ERROR: OHCI usb-uPD720101-0 CTL:TIMEOUT
ERROR: OHCI usb-uPD720101-1 CTL:TIMEOUT
CODEC SYNC frequency: 48175 Hz
Pure C info at 0x1127490 to 0x116e188 \AUTO\NVDI.PRG
Pure C info at 0x1129306: a000 0000 mac.w d0.l,d0.l,acc0
Pure C info at 0x11298fe: 1e1f move.b (sp)+,d7
Pure C fix at 0x113496c: 1f01 move.b d1,-(sp) -> 0xa911
Pure C fix at 0x1134b08: 1f01 move.b d1,-(sp) -> 0xa911
Pure C fix at 0x11367ba: 1f00 move.b d0,-(sp) -> 0xa910
Pure C fix at 0x11367d8: 1f00 move.b d0,-(sp) -> 0xa910
Pure C fix at 0x11375c2: 1f00 move.b d0,-(sp) -> 0xa910
Pure C info at 0x115b396: a002 24a8 mac.w d2.l,d0.u>>,acc0
Pure C info at 0x115b3b2: a001 4fef msac.l d1,d0,acc0
Pure C info at 0x115b3e0: 1f00 move.b d0,-(sp)
Pure C info at 0x115b3f0: 1f00 move.b d0,-(sp)
Pure C info at 0x115b402: 1f02 move.b d2,-(sp)
Pure C fix at 0x115eeca: 4c00 1c00 muls.l d0,d0:d1 -> 0xabc0
Pure C fix at 0x115eece: 4c42 1c00 divs.l d2,d0:d1 -> 0xafc2
Pure C fix at 0x115ef26: 4c00 1c02 muls.l d0,d2:d1 -> 0xabc0
Pure C fix at 0x115efaa: 4c40 2c01 divs.l d0,d1:d2 -> 0xafc0
Pure C info at 0x115f5ae: 1e1f move.b (sp)+,d7
Pure C info at 0x115f6ae: 1e1f move.b (sp)+,d7
Pure C fix at 0x1164352: 4c00 1c00 muls.l d0,d0:d1 -> 0xabc0
Pure C fix at 0x1164356: 4c42 1c00 divs.l d2,d0:d1 -> 0xafc2
Pure C info at 0x116b616: a006 4e75 mac.l d6,d0,acc2
Pure C info at 0x116b622: a007 2c5f mac.l d7,d0>>,acc2
Pure C info at 0x116c232: a000 7000 mac.w d0.l,d0.l,acc0
Line A opcode 0xA920 at 0x011274DC
Line A opcode 0xA920 at 0x0118F5E0
Pure C info at 0x11c1180 to 0x11c5dac CT60TEMP.ACC
Pure C info at 0x11c433a: a000 0000 mac.w d0.l,d0.l,acc0
Pure C info at 0x11c53e4: a000 0000 mac.w d0.l,d0.l,acc0
Pure C info at 0x11c77a0 to 0x11d01ba COPS.ACC
Pure C info at 0x11cd4ce: a000 225f mac.w d0.u,d0.l<<,acc2
Pure C info at 0x11ced00: 1e1f move.b (sp)+,d7
Setscreen mode 0x2E3B 1600x1200-8@60
init_videl search in videl list 1600x1200x8@60Hz on DFP
init_videl PLL detected
init_videl found in modedb list 1600x1200x8 with clock 162MHz
init_videl 1600x1200x8@60Hz 162MHz HSYNC:HIGH VSYNC:HIGH
HHT:870 HBB:770 HBE:12F HDB:130 HDE:76F HSS:7B0
VFT:4E2 VBB:4DE VBE:02D VDB:02E VDE:4DD VSS:4DF
ADDR:60000000 VWRAP:0320 VCTRL:000 VCO:1A2
ACP_VIDEO_CONTROL:01078213 (01078213)
-
Dann ist es anscheinend so, wie ich dachte: die Kiste läuft völlig normal, Du siehst nur nix (ist natürlich nicht normal).
Deine Kiste schaltet beim Booten erst auf 640x480, dann auf 1600x1200. Du siehst - wenn der Fehler auftritt - kein Bild (auch nicht nur kurz)?
Der Bildschirmspeicher ist im SDRAM, das vom FPGA angesteuert wird. Die Bytes werden dann per TFP410 zum Bildschirm geschickt. Irgendwo bleibt da unterwegs auf der Strecke.
Es wäre interessant zu sehen, ob der Fehler mit EmuTOS (per Dip-Schalter) auch auftritt. Das faßt weder den TFP410 an, noch macht es an den Firebee-Auflösungen rum.
-
Du siehst - wenn der Fehler auftritt - kein Bild (auch nicht nur kurz)?
Nein zu keiner Zeit ein Bild, nur dieses Farbmuster welches sich auch nicht verändert. Ich meine manchmal bleibt der Bildschirm auch einfach Schwarz aber das ist sehr, sehr selten.
Die Firebee scheint bis auf den Bildschirm normal zu laufen, ich muss bei der Meldung FireTOS mit MiNT/EmuTOS/FireTOS entweder blind Return drücken oder mit den Cursortasten zweimal nach unten gehen, also alles ganz normal.
Das mit dem EmuTOS kann ich auch mal probieren, ist aber ein Geduldsspiel da die Maschine Tagelang einwandfrei läuft bis irgendwann mal dieser Fehler auftritt ...
-
Ich hab' mir gerade noch mal den Schaltplan angeschaut:
der Video-DAC ist eine der wenigen Komponenten in der FireBee, die eine 5V-Versorgung brauchen.
Ich könnte mir vorstellen, daß - wenn die nicht stabil bereit steht - es beim Einschalten zu einem Initialisierungsfehler kommen kann.
Da würd' ich wohl als erstes mal ein Oszi dranhängen...
-
Bei den SMD Aufbau werde ich da selber gar nichts machen. Garantie wird da keine mehr drauf sein und es ist halt ein blöder Fehler. Gerade wenn man danach schauen will ist er nicht da ...
-
Übrigens ist das nicht derselbe Dump - so wie's aussieht, hast Du einmal "FireTOS full" und einmal die andere Option gewählt. Ich glaube zwar nicht, daß das was mit deinem Problem zu tun hat, will's aber auch nicht ausschließen.
Warum sich die ermittelte AC97-Frequenz bei den beiden Dumps unterscheidet: momentan keine Idee. Könntest Du mal beobachten, ob das immer so ist.
-
Wegen der Sound Frequenz da habe ich ja keinen Einfluss drauf, oder ?
Kann sein das ich beim Booten einmal nur Return gedrückt und beim anderen erst zweimal mit den Cursortasten runter gegangen bin und dann Return gedrückt habe ...
Macht es denn einen Unterschied wegen des RamDAC ob ich VGA (DVI-VGA Adapter) oder DVI nutze ?
Do you have a VGA adapter so you can test VGA instead? Maybe there's a problem with the DVI chip.
Ich denke nicht, oder ?
Joska meinte ich könne über das Netzwerk schauen ob die Firebee einen Desktop anzeigt wenn dieser Fehler mit dem Farbmuster auftritt. Sowas wie VNC ...
Is FireTOS networking set up and working? If so, you can see your Firebee's desktop via it's web-server. It would be interesting to see if it display the same picture as on the monitor.
Ich habe keinerlei Ahnung wie ich das anstellen soll mit dem Netzwerk. Habe "Chicken of the VNC" und die Firebee Adresse 192.168.2.12 mal eingegeben aber es kommt keine Verbindung zustande ...
-
Was ich oben geschrieben habe, war übrigens verkehrt. Der ADV7125 Video DAC kann zwar 5V, braucht's aber nicht, da war ich auf dem Holzweg. Entsprechend hängt er in der FireBee an der 3,3V Versorgung.
Wegen der Sound Frequenz da habe ich ja keinen Einfluss drauf, oder ?
Nein, aber es ist mir aufgefallen. Ich habe grad' nicht parat, ob das FPGA den Takt für den AC97 erzeugt, wenn ja, könnte das ein Indikator sein, daß da was nicht ganz stimmt.
Macht es denn einen Unterschied wegen des RamDAC ob ich VGA (DVI-VGA Adapter) oder DVI nutze ?
Das sind zwei völlig voneinander getrennte Video-Schaltkreise. DVI benutzt den TFP410, VGA den ADV7125. Das Einzige, was die beiden gemeinsam haben, ist daß sie denselben Datenstrom des FPGA's als Input nutzen.
Deswegen macht der Test schon Sinn - wenn der Fehler an beiden Ausgängen auftaucht, steckt das Problem (wahrscheinlich) im FPGA, wenn nicht, in der jeweils anderen Komponente.
Joska meinte ich könne über das Netzwerk schauen ob die Firebee einen Desktop anzeigt wenn dieser Fehler mit dem Farbmuster auftritt. Sowas wie VNC ...
Das geht nur mit "FireTOS (full)" und über http (_kein_ VNC). Du kannst dich so mit der Firebee verbinden und den Bildschirminhalt angucken, die Taskliste vom FreeRTOS anzeigen und sonst noch ein paar Spielereien.
-
Erstmal vielen Dank für den Beistand ...
Also boote ich in FireTOS (letzter Eintrag der drei) und gebe einfach im Browser z.B. meines Macs der am selben Hub/Swtich hängt einfach die IP Adresse der Firebee ein welche im CPX Modul angegeben ist ...
Klappt nicht bei mir, was mache ich falsch ?
(http://didierm.pagesperso-orange.fr/jpg/cpx5_acp.jpg)
Unter IP steht bei mir - 192.168.2.12
Unter Server steht - 192.168.2.1
Dieses 192.168.2.1 ist meine Fritzbox der Router oder kommt da was anderes hin ?
Edit: Habe mal unter Server IP die 192.168.2.10 eingetragen, da tut sich aber auch nichts ...
-
Edit: Habe mal unter Server IP die 192.168.2.10 eingetragen, da tut sich aber auch nichts ...
Die Server-IP ist für dich nicht wichtig. Die spielt nur eine Rolle, wenn Du FireTOS über einen TFTP-Server laden willst (dessen Adresse muß dann da rein) statt aus dem Flash.
Geh' mal auf deine serielle Konsole, drück' Return (dann solltest Du einen ">"-Prompt bekommen) und gib'
ifconfig -a
ein.
-
> ifconfig -a
en1 flags=19 ( UP BROADCAST RUNNING ) mtu 1518
inet 192.168.2.12 netmask 255.255.255.0 gateway 0.0.0.0
ether 00:CF:54:01:02:03
lo0 flags=1 ( UP ) mtu 0
inet 127.0.0.1 netmask 0.0.0.0 gateway 0.0.0.0
>
Das Gateway kann ich doch unter Single TOS (FireTOS) nicht einstellen, oder doch ?
-
Nein, du sollst mit einem Webbrowser die Adresse 192.168.2.12 öffnen.
-
Habe jetzt mal die Firebee über einen DVI-VGA Adapter mit einem alten Eizo 15 Zoll TFT verbunden, mal schauen ob der Fehler dort auch auftritt. Ist halt ein wenig schwierig da es nur Sporadisch auftritt und das Teil wenn ich Pech habe Wochenlang ohne Probleme läuft ...
Nein, du sollst mit einem Webbrowser die Adresse 192.168.2.12 öffnen.
Das ist mir schon klar ...
Unter OSX mit Safari oder Firefox kommt "keine Verbindung mit Server möglich" oder ein Timeout.
-
Das Gateway brauchst Du nur, wenn Du aus deinem eigenen Netzsegment rauswillst. Willst Du ja nicht.
Das müsste so schon passen.
Guck' mal (mit "qt" auf der seriellen Konsole), ob die HTTPd-Task überhaupt läuft? Was sagt ein "ping" (auch auf der Konsole) zu deinem anderen Rechner (und andersrum)?
-
> qt
Name TID Prio Status Sys/User Stack #
------------------------------------------------------------
ROOT 1FE10008 0A Ready 3971/NU/4096 0
IDLE 1FE14170 00 Ready 4068/NU/4096 1
lwIP0 1FE1877C 1E Blocked 3983/NU/4096 2
lwIP1 1FE1C9C0 1E Suspend 4031/NU/4096 3
TOS 1FE1CB20 05 Ready 4072/NU/4096 4
DBUG 1FE1CC80 14 Ready 3959/NU/4096 5
USBHub 1FE1CF44 10 Suspend 3904/NU/4096 6
TELNETd 1FE1D0A4 0F Suspend 3979/NU/4096 7
TFTPd 1FE1D594 0A Suspend 3933/NU/4096 8
HTTPd 1FE1D6F4 0A Suspend 4011/NU/4096 9
HT01 1FE21CC0 09 Suspend 3906/NU/4096 10
HT02 1FE21E20 09 Suspend 3906/NU/4096 11
HT03 1FE21F80 09 Suspend 3906/NU/4096 12
HT04 1FE220E0 09 Suspend 3906/NU/4096 13
HT05 1FE22240 09 Suspend 3906/NU/4096 14
SDd 1FE226C0 06 Blocked 4037/NU/4096 15
> ping 192.168.2.12
Envoi d'une requete 'ping' sur 192.168.2.12 avec 32 octets de donnees :
board IP from flash params: 192.168.2.12
Reponse de 192.168.2.12: icmp=1 octets=32 temps<5 ms TTL=255
Reponse de 192.168.2.12: icmp=2 octets=32 temps<5 ms TTL=255
Reponse de 192.168.2.12: icmp=3 octets=32 temps<5 ms TTL=255
Reponse de 192.168.2.12: icmp=4 octets=32 temps<5 ms TTL=255
Statistiques Ping pour 192.168.2.12 :
Paquets : envoyes = 4, recus = 4, perdus = 0 (perte 0%),
Duree approximative des boucles en millisecondes :
minimum = 0ms, maximum = 0ms, moyenne = 0ms
>
... sieht doch alles gut aus, oder ?
Das Setup hier ist so das eine Fritzbox 7360 läuft mit drei 5port Switchboxen, eine für jede Etage. Alles mit DHCP mit Adressen über 100, also Fritzbox hat 192.168.2.1 eine Ausnahme sind meine Netusbee, die Firebee und ein MorphOS MacMini haben feste IPs unter 100 alles andere incl. WLAN über DHCP ...
Habe auch mal einen WIN7 PC direkt über ein LAN Kabel mit der Firebee verbunden, geht auch nicht.
Das ist die Firebee im Fritzbox Setup ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=12051.0;attach=8781;image)
-
Statistiques Ping pour 192.168.2.12 :
... daß die FireBee sich selber pingen kann, das hätt' ich fast erwartet - sorum sollst Du deinen Mac (oder wasauchimmer) anpingen und von dem aus andersrum ;).
-
War doof ...
> ping 192.168.2.145
Envoi d'une requete 'ping' sur 192.168.2.145 avec 32 octets de donnees :
board IP from flash params: 192.168.2.12
Reponse de 192.168.2.145: icmp=1 octets=12 temps<5 ms TTL=0
Reponse de 192.168.2.145: icmp=2 octets=12 temps<5 ms TTL=0
Reponse de 192.168.2.145: icmp=3 octets=12 temps<5 ms TTL=0
Reponse de 192.168.2.145: icmp=4 octets=12 temps<5 ms TTL=0
Statistiques Ping pour 192.168.2.145 :
Paquets : envoyes = 4, recus = 4, perdus = 0 (perte 0%),
Duree approximative des boucles en millisecondes :
minimum = 0ms, maximum = 0ms, moyenne = 0ms
> ping 173.194.112.183
Envoi d'une requete 'ping' sur 173.194.112.183 avec 32 octets de donnees :
board IP from flash params: 192.168.2.12
Delai d'attente de la demande depasse.
Delai d'attente de la demande depasse.
Delai d'attente de la demande depasse.
Delai d'attente de la demande depasse.
Statistiques Ping pour 173.194.112.183 :
Paquets : envoyes = 4, recus = 0, perdus = 4 (perte 100%),
Duree approximative des boucles en millisecondes :
minimum = 0ms, maximum = 0ms, moyenne = 0ms
> ping 192.168.2.1
Envoi d'une requete 'ping' sur 192.168.2.1 avec 32 octets de donnees :
board IP from flash params: 192.168.2.12
Reponse de 192.168.2.1: icmp=1 octets=12 temps=15 ms TTL=0
Reponse de 192.168.2.1: icmp=2 octets=12 temps<5 ms TTL=0
Reponse de 192.168.2.1: icmp=3 octets=12 temps<5 ms TTL=0
Reponse de 192.168.2.1: icmp=4 octets=12 temps<5 ms TTL=0
Statistiques Ping pour 192.168.2.1 :
Paquets : envoyes = 4, recus = 4, perdus = 0 (perte 0%),
Duree approximative des boucles en millisecondes :
minimum = 0ms, maximum = 15ms, moyenne = 3ms
>
145 ist mein Apple Rechner und die 1 ist die Fritzbox, geht also, nur raus ins Netz geht natürlich nicht ...
-
Hmmm. Dann bin ich jetzt fast ein bißchen überfragt, bei mir geht's so.
Hast Du einen Rechner mit einer nmap-Installation? Gibt's für Mac und Linux, Windows weiß ich nicht. Damit kann man nachschauen, welche Ports offen sind:
nmap -P0 <firebee-ip>
Die Firebee muß dafür natürlich laufen...
-
Job done ...
gerhard@hp-compaq-dc7100:~$ nmap -P0 192.168.2.12
Starting Nmap 6.47 ( http://nmap.org ) at 2015-08-11 21:23 CEST
Nmap scan report for 192.168.2.12
Host is up (0.67s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
23/tcp open telnet
8080/tcp open http-proxy
Nmap done: 1 IP address (1 host up) scanned in 1.20 seconds
gerhard@hp-compaq-dc7100:~$ nmap -P0 192.168.2.145
Starting Nmap 6.47 ( http://nmap.org ) at 2015-08-11 21:23 CEST
Nmap scan report for Franks-Mac-Pro.fritz.box (192.168.2.145)
Host is up (0.00095s latency).
Not shown: 500 closed ports, 492 filtered ports
PORT STATE SERVICE
88/tcp open kerberos-sec
111/tcp open rpcbind
445/tcp open microsoft-ds
548/tcp open afp
999/tcp open garcon
1021/tcp open exp1
1023/tcp open netvenuechat
2049/tcp open nfs
Nmap done: 1 IP address (1 host up) scanned in 2.52 seconds
gerhard@hp-compaq-dc7100:~$
Das erste ist die Firebee und als Vergleich mal der Apple Rechner ...
-
gerhard@hp-compaq-dc7100:~$ nmap -P0 192.168.2.12
8080/tcp open http-proxy
Tja, da steht's ja. Dein http Server auf der Firebee läuft auf Port 8080. Warum auch immer...
Mit http://192.168.2.12:8080 (http://192.168.2.12:8080) solltest Du dann auch dran kommen...
-
Super, Danke ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=12051.0;attach=8801;image)
Auf welchem Port liegt denn der HTTP Server sonst normalerweise ?
Dachte jetzt man hätte den Desktop der Firebee da ?
Vielleicht sollte ich die Firebee doch mal neu flashen, keine Ahnung ?
-
Betreibe jetzt die Firebee seit einigen Tagen über einen DVI auf VGA Adapter und bis jetzt ist alles in Ordnung.
Vielleicht stimmt ja etwas mit meinem DVI Ausgang Hardware mäßig nicht ...
Aber man soll den Tag ja nicht vor dem Abend loben !
Bei den Debug Ausgaben über die Serielle Schnittstelle ist ja auch kein Fehler ersichtlich, vermute den Fehler in der Hardware kurz bevor es an den DVI Ausgang nach draussen geht, keine Ahnung !?!
Stellt sich jetzt auch die Frage ob ich die Firebee an Medusa schicken soll, ich befürchte aber das der Fehler weil nur sporadisch, die Kiste bei Medusa einwandfrei läuft, so was ist immer schwierig ...
-
Mir ist was zu dem Fehlerbild eingefallen. Eine DVI-Grafikkarte/gerät und ein DVI-Monitor/Fernseher müssen miteinander erstmal das Protokoll aushandeln, wenn ein Bild dargestellt werden soll. (Bei DVI ist das noch ein Schritt komplexer, wie ich mal gelesen habe. HDMI ist mit DVI eng verwandt.) Genau das Fehlerbild mit dem bunten Ameisenfußball hatte ich auch mal zwischen SAT-Reciever und Fernseher per HDMI. Dort trat dieser Fehler auch nur sporadisch auf, und mit einem anderen Fernseher garnicht. Geholfen hat letztendlich ein Firmware-Update am SAT-Reciever. Denkbar ist aber aiuch, dass es mit einem anderen Monitor nicht auftritt.
Dass es jetzt im VGA-Modus funktioniert, spricht sehr für diese Variante.
-
Das Fehlerbild tritt auf einem 2560Pix BenQ 27 Zöller und auf einem iiyama 27 Zöller auf, über DVI angeschlossen mit einem hochwertigen DVI (glaube sogar Duallink Kabeln) auf.
Die Monitore machen je Probleme an der Firebee, habe noch einen 19 Zoll BenQ mit 1280x1024 aber keinen Platz mehr auf dem Tisch ...
-
Ich hatte bei meiner Firebee 3x das Problem des "schwarzen Bildschirms". Die Biene ist da auch ganz normal gestartet, allerdings ohne Bild.
Bei mir trat es nur auf, wenn der Akku völlig leer war.
Da musste ich die Firebee direkt über DVI mit einem (DVI-)Monitor verbinden und ich hatte wieder Bild. Danach klappt es auch wieder mit DVI auf VGA Adapter.
Ähnliches machte der Falcon auch, wenn der Dallas platt war. Dann hat man einen SM124 dran anschließen müssen und hernach lief er wieder.
Wieso das so ist, weiß ich nicht, aber am letzten OFAM hab ich meine Firebee, die versehentlich ohne Netzteil über Nacht eingeschaltet blieb, am nächsten Tag wiederbelebt.
LG,
Chris
-
Eine Frage.
Was hat der Akku mit dem Fehlerbild zu tun wenn das Netzteil dran ist ?
Spannung/Strom 12Volt/5AH , das müsste doch für ein Board dieser Ausmaße übermäßig Optimal sein.
FPGA/PIC usw? Ansonsten könnte man ja im Winter die Heizung ausschalten und mit dem Firebee spielen und die Wohnung heißen?
Wenn ich die obigen Werte lesen , wird sogar 15 Volt genommen, ist das nicht zuviel ?
Gruss
-
Eingeschaltet ohne Netzteil dran leert den nvram-Akku? Das sollte überarbeitet werden, das ist schlecht...
-
Aber wenn der Firebee am Netzteil betrieben wird , wozu den Akku als Notbetrieb , er ist doch kein Notebookersatz mit seinem Externen Monitor usw.
Der Akku bleibt immer eine Fehlerquelle mit der unsicheren Spannung.
Ein Uhrenakku kann ich verstehen, so wie es im PC ist.
Gruss
-
Der Akku ist auch nicht viel mehr als der Uhrenakku, insofern passt das schon. Du hast eben den Bonus, dass die Firebee kurzzeitig auch ohne Strom weiterläuft. Kann schon praktisch sein und theoretisch kann man ja auch einen Laptop draus bauen... dann würde ich aber einen größeren Akku nehmen ;)
-
Eingeschaltet ohne Netzteil dran leert den nvram-Akku? Das sollte überarbeitet werden, das ist schlecht...
Natürlich schaltet die FireBee nur mit Akku seit jeher zwischen 3,05 und 3,19 Volt automatisch ab. Das reicht üblicherweise zumindest für 4 Monate NVRAM.
-
Das reicht üblicherweise zumindest für 4 Monate NVRAM.
Werden die NVRAM-Einstellungen bei der Firebee nicht wie beim Milan auch fest im EPROM gespeichert, so dass sie gar nicht verloren gehen können?
-
Eingeschaltet ohne Netzteil dran leert den nvram-Akku? Das sollte überarbeitet werden, das ist schlecht...
Natürlich schaltet die FireBee nur mit Akku seit jeher zwischen 3,05 und 3,19 Volt automatisch ab. Das reicht üblicherweise zumindest für 4 Monate NVRAM.
Das sollte vielleicht so sein, ich denke aber, dass mein Akku jeweils richtig leer war, als dieses Phänomen auftrat... Werd ich das nächste Mal messen. Also hoffentlich nie ;)