Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Xtrend Support / GigaBlue Info. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

41

Montag, 19. Januar 2015, 20:30

...wenn es VF wäre, wäre es eine Diode und hätte ein anderes Gehäuse...

Murphy-09 ;)

42

Montag, 19. Januar 2015, 21:07

Ok vielen dank :)

43

Dienstag, 20. Januar 2015, 17:54

Hi Murphy-09,
habe noch mal an einen anderen Punkt gemessen sehe Resetsignal vom U3 zum Processor roter Pfeil und dort habe ich diese Signale aufgenommen sehe Bild Resetsignal(2 ) und 3,3V.
CH1 ist die 3,3V Spannung und CH2 ist der Reset roter Pfeil gemessen, ist der Reset zum Proz., dort kommt der Reset ca 250ms nach der 3,3V Spannung.
Was ich noch gemessen habe ict das am NOR das pin 26 CE dauernd Rechteck signale kommen, sehe Beitrag vom Freitag, 16. Januar 2015, 19:59 Bild CE#-Signal

Endschuldige für das Bild Resetsignal vom U3 zum Processor hatte ich deins benutzt, hatte keine Knipse zu Hand :whistling:


MfG:Resident0007
»Resident0007« hat folgende Dateien angehängt:

Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von »Resident0007« (20. Januar 2015, 18:27)


44

Dienstag, 20. Januar 2015, 19:54

Na, das sieht doch schon viel besser aus. Nachdem der Reset gut ist sollten die Zugriffe auf das NOR auch nach jedem Einschalten kommen. Das CE# ist auch LOW aktiv und sollte solange kommen, bis der Bootloader aus dem NOR ins DRAM kopiert wurde. Anhand des Datenblatts für das NOR kannst Du nun messen ob alle Adressen, beginnend von A0 als niedrigste Adresse aus, schalten, d.h. HIGH und LOW werden. Falls eine der Leitungen gar nicht schaltet ist das schon mal merkwürdig. Ein Zwischenpegel ist ebenso ein Hinweis, sofern der während der LOW-Zeit des CE# auftritt. Die Daten aus dem NOR sollten auch alle mal HIGH, mal LOW sein. Die Daten werden allerdings erst zum Schluss des Cycles, also kurz bevor das CE# von LOW auf HIGH geht stabil sein. Das es sich um ein 90ns Flash handelt müssen die Daten mindestens 90ns nach fallender Flanke des CE# gültig sein. Während dieser NOR-Lesezeit muss auch schon die erste Meldung auf der RS232-Konsole kommen. Falls hier nichts kommt und der Bootloader ewig im NOR läuft scheint hier ein defekt vor zu liegen. Dann wird es schwierig. Ich habe in so einem Fall das NOR ausgebaut und in einem Spezialboard ausgelesen, um fest zu stellen, ob nur der Inhalt oder der Baustein defekt ist. Die neben dem Bootloader enthaltenen Daten sind nämlich wichtig, z.B. IP-Adresse...Seriennummer...etc....
Na dann miss erst mal.......wir werden schon rauskriegen, was der Kiste fehlt.....

Murphy-09 ;)

45

Dienstag, 20. Januar 2015, 20:47

Hi, ist es richtig das das CE#- signal eine Pulsweite von 300ns high und 600ns low hat?
Da das CE#-signal ja bei mir ständig mit der genannten Pulsweite anliegt, nehme ich mal an das da der Hund begraben ist.

Ok werde mal alle Adressen schauen, getriggert auf CE#


MfG:Resident0007

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Resident0007« (20. Januar 2015, 20:55)


46

Mittwoch, 21. Januar 2015, 07:36

Das CE# Signal, das Chip Select, besagt, dass der Baustein nun angesprochen wird. Während dieses Zugriffs müssen alle Adressen stabil sein und es muss ein gültige Schreib- (WE#) oder Lese- (OE#) Signal anliegen. Im Inter-Cycle, also wenn das CE# Signal HIGH ist, dürfen alle anderen Signale einen beliebigen Zustand haben. Dieser Wechsel CE# LOW, CE# high, ist völlig normal und dauert so lange, bis die CPU alles nötige aus dem NOR gelesen hat. Damit sie nicht immer das Gleiche liest, müssen sich die Adressen ändern. Wäre eines der Signale defekt, kann es sein, dass die CPU u.U. in eine Endlosschleife gerät, immer wieder von Vorne anfängt oder gänzlich abstürzt.
Kommt denn irgendwas am RS232 Port ? Bitte mit dem Scope am RS232-Port messen, denn es könnte auch eine andere Baudrate rauskommen !

Murphy-09 ;)

47

Sonntag, 25. Januar 2015, 11:13

Hi Murphy-09,
habe mal am NOR sie Adressen gemessen sehen wie folgt aus


A0-A2 Rechtecksignal 3,3V
A3-A5 Low
A6-A8 High
A9-A15 Low
A16-A17 Rechtecksignal 1,0V
A18-A21 Low
CE# Rechtecksignal 3,3V
OE# Rechtecksignal 3,3V mit unterschiedlichen Pulsweiten
WE# High
Reset# High
DQ0-DQ14 Low

und das sieht nicht gut aus. :(

MfG:Resident0007 :)

48

Sonntag, 25. Januar 2015, 12:21

....die Adressen A16-A17 mit dem 1V Signal sind interessant. Kann es sein, dass die beiden einen Kurzschluss haben ? Schick mal einen Scope-Dump. Geh' mal mit dem Multimeter an dem Baustein durch und schaue ob irgendein Signal niederohmig zu einem Anderen ist. 10-20Ohm reichen da schon. Ich denke entweder liegt irgendwo ein Zinnkrümel, der die Signale blockiert, oder ein Baustein hat einen Defekt. Dadurch dass die A16 und A17 keinen sinnvollen Pegel haben, startet die CPU falsch. Mit etwas Glück kann man das Problem aber schon finden.

Murphy-09 ;)

49

Sonntag, 25. Januar 2015, 15:04

ok werde ich Morgen mal machen.

Wünsche dir noch einen schönen Sonntag ^^


MfG:Resident0007 :)

50

Montag, 26. Januar 2015, 19:20

Hi Murphy-09,
also das Signal am NOR pin A16 u. A17 sieht wie folgt aus (Bild).
Einen Kurzschluss zu den Adressen unter ein ander habe ich nicht feststellen können, auch nicht zu GND.

Ist es normal das wenn ich von GND zu den einzelnen Spannungen messe die sehr niederohmig sind?
GND zu 3,3V 100ohm
GND zu 1,8V 30ohm
GND zu 1,2V 300ohm und GND zu den 1,2V beim Tuner 100ohm, alles gemessen ohne dem Netzteil nur das reine CPU-Board. ?(


MfG: Resident0007
»Resident0007« hat folgende Datei angehängt:

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Resident0007« (26. Januar 2015, 19:28)


51

Montag, 26. Januar 2015, 21:39

..die Spannungen dürfen sehr niederohmig sein, das ist o.k.
Dein Scope Dump zeigt leider nur einen Kanal. Die Adresse im Vergleich zum CE# wäre wichtig, den wenn die 1V während CE# high sind, ist das nicht unbedingt falsch. Wenn es während CE# low auftritt ist es sehr wohl ein Fehler. Dass die Daten allerdings immer low sind, ist schon merkwürdig. Die Einsprungadresse nach dem Powerup-Reset ist 0x1fc00000, wobei beim Flash die A0 als Word-Adresse gilt, also nicht von A0 bis A21 geht, sondern am Prozessor von A1 bis A22. Somit müsste die erste Adresse nach dem Reset binär von A32 bis A0 so aussehen: 0001 1111 11[00 0000 0000 0000 0000 000]0, wobei die Bits in den Klammern am Flash von A21 bis A0 anliegen müssten, d.h. der Bootloader startet im Flash selbst bei Offset 0. Die letzte 0 nach der Klammer ist die Byte-Adresse, die hier nicht wichtig ist, da das NOR immer wortweise ausgelesen wird. Beim Messen der Adressen ist also der CE# Pegel immer wichtig, sonst kann man leider nichts über die reale Adresse aussagen.
Hier sind die Einsprungdaten, die ab 0x0 im NOR stehen:
1fc00000% 0F 02 00 10 00 00 00 00 0F 03 00 10 00 00 00 00 ................
1fc00010% 3D 03 00 10 00 00 00 00 3B 03 00 10 00 00 00 00 =.......;.......
1fc00020% 39 03 00 10 00 00 00 00 37 03 00 10 00 00 00 00 9.......7.......
1fc00030% 35 03 00 10 00 00 00 00 33 03 00 10 00 00 00 00 5.......3.......
1fc00040% 31 03 00 10 00 00 00 00 2F 03 00 10 00 00 00 00 1......./.......
1fc00050% 2D 03 00 10 00 00 00 00 2B 03 00 10 00 00 00 00 -.......+.......
1fc00060% 29 03 00 10 00 00 00 00 27 03 00 10 00 00 00 00 ).......'.......
1fc00070% 25 03 00 10 00 00 00 00 23 03 00 10 00 00 00 00 %.......#.......

Murphy-09 ;)

52

Montag, 26. Januar 2015, 22:30

ok, man lernt immer noch was dazu. :)
Werde ich mal die Adresse A16 u. A17 in verbindung zu CE# messen, werde ich dann Morgen ein stellen.

MfG: Resident0007

53

Dienstag, 27. Januar 2015, 18:42

Hi Murphy-09,
hier der Scope-Dump A17 sieht gleich aus. Die anderen müsste ich noch überprüfen hatte heute nicht mehr Zeit dafür.

MfG:Resident0007
»Resident0007« hat folgende Datei angehängt:

54

Dienstag, 27. Januar 2015, 21:05

...die 1V Pegel sind also im Inter-Cycle und somit nicht unbedingt falsch. Dort können die Adresstreiber Tristate sein. Nun muss man mühsamerweise die ersten Zugriffe nach Reset von low auf high geht messen. Hier reichen CS#, A0 und der Reihe nach die Daten von D0 bis D15, um zu sehen, ob die ersten Daten richtig gelesen werden. Bei diesem ersten Zugriff müssen alle Adressen von A0 bis A21 während CS# auf low sein, also den Wert 00000 haben. Wenn dabei das erste Datum nicht 0F02 ist, wobei ich im Moment nicht sagen kann ob MSB nun die linke 0 oder die rechte 2 ist und die Adresse stimmt, ist das Flash defekt. Aber das würde man beim Messen schon sehen. Es muss also beim ersten Zugriff die Bit-Kombination 0001110000010 von D0 bis D15 oder von D15 bis D0 auftreten.

gut mess

Murphy-09 ;)

55

Dienstag, 27. Januar 2015, 21:21

Ok danke Murphy-09,
ich melde mich dann wenn ich die alle gemessen habe.
Mal eine frage 0F02 hex ist das in Bin nicht 0000111100000010 oder woher kommt Bit-Kombination 0001110000010


MfG: Resident0007

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »Resident0007« (27. Januar 2015, 21:43)


56

Mittwoch, 28. Januar 2015, 07:50

...sorry, aber da scheint beim Eintippen in jedem Nibble ein Bit verlorengegangen zu sein....
ist ja klar:

0b 0000 1111 0000 0010

es kann am Flash aber auch 020F anliegen, das hängt vom Indianer, little-endian/big-endian, ab.

Murphy-09 ;)

57

Donnerstag, 29. Januar 2015, 19:47

Hi Murohy-09,

Signal 1 = jeweils = A0
Signal 2 = jeweils = CE
Signal 3 = jeweils = DQ

Signale nach dem Einschalten mit dem Netzschalter.

Beim zweiten Messen bei dem eingeschaltetem Gerät, komischerweise andere Endwerte. Messspitze vom Kontakt weg
und dann wieder ran.
Hier dann das andere Ergebnis: DQ0,7,10,15 = Low
DQ1,2,3,4,5,6,8,9,11,12,13,14 = High

Ich lese gerade das ich es in verbindung mit CS hätte machen sollen, müsste ich dann nochmal nach liefern :whistling:

MfG:Resident0007 ;)
»Resident0007« hat folgende Dateien angehängt:
  • DQ3,14.JPG (127,94 kB - 11 mal heruntergeladen - zuletzt: 6. Oktober 2017, 14:39)
  • DQ0,8,11,12.JPG (134,9 kB - 10 mal heruntergeladen - zuletzt: 6. Oktober 2017, 14:39)
  • DQ1,2,4,5,6,7,9,10,13,15.JPG (128,93 kB - 10 mal heruntergeladen - zuletzt: 6. Oktober 2017, 14:39)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Resident0007« (29. Januar 2015, 19:52)


58

Freitag, 30. Januar 2015, 06:48

...also so sollte das nicht ausschauen. So kann es nicht funktionieren.
Schauen wir mal was das NOR im ersten Zugriff nach Reset an den Pins haben soll.
Es müsste ein S29GL032N verbaut sein.
Das Datenblatt habe ich schon mal hochgeladen.

RESET# = low
CE# = high
alles andere egal, vermutlich high

RESET# geht auf high CE# geht auf low
Jetzt muss sein:
A0-A20 = low
WE# = high
WP# = high
RY/BY# = high
DQ0-DQ15 = 1.Datum, keinesfalls 0x00 oder 0xff
Das Datum wird erst zur steigenden Flanke von CE# gültig und von der CPU übernommen.

Du kannst dort, wo der Resetgenerator auf dem PCB ist und die frei stelle für den Schalter, das Reset Signal einfach auf Masse schalten, halten, messen, das Scope auf Single-Shot schalten, den Reset loslassen und so den ersten CE# Low Puls vermessen. Ich mache sowas mit einem Pulsgenerator, der den Reset erzeugt und mir das Scope triggert. Dann kann man alle Signale sehr schnell durchmessen, sieht welche Adresse im ersten, im zweiten...usw. Zugriff kommt und welches zugehörige Datum. Der Reset-Puls sollte nur als OC oder mittels einer Diode gegen Masse geschalten werden. Keinesfalls auf high treiben, da wir sowieso den Ausgang des UND-Gates übertreiben, was das Teil gegen GND aber ohne Probleme aushält, gegen eine Spannung aber keinesfalls.

Murphy-09 ;)

59

Montag, 2. Februar 2015, 18:27

Hi Murphy-09,

Bei RY/BY# ist immer low
der BYTE# ist immer high
WE# ist immer high u. auch der WP# ist immer high


MfG:Resident0007 :)

60

Montag, 2. Februar 2015, 18:49

Also BYTE# = high ist o.k.
WP# high ist auch o.k.
WE# high ist auch o.k.
aber RY/BY# heißt das Teil ist immer BUSY.
Dieser Pin ist ein open-drain und falls er von der CPU nicht genutzt wird (möglich) und keinen Pullup hat, liegt er einfach auf low.
Dieses Signal ist beim ersten Zugriff in keinem Fall ein Problem.
Wichtig wären die Daten beim ersten Zugriff und natürlich ob die Adresse dabei 0x0000 ist.
Wenn der allererste Zugriff in die Hose geht, kannst Du den Rest auch vergessen.

Murphy-09 ;)