You are not logged in.

41

Monday, January 19th 2015, 8:30pm

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

Murphy-09 ;)

42

Monday, January 19th 2015, 9:07pm

Ok vielen dank :)

43

Tuesday, January 20th 2015, 5:54pm

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 has attached the following files:

This post has been edited 7 times, last edit by "Resident0007" (Jan 20th 2015, 6:27pm)


44

Tuesday, January 20th 2015, 7:54pm

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

Tuesday, January 20th 2015, 8:47pm

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

This post has been edited 1 times, last edit by "Resident0007" (Jan 20th 2015, 8:55pm)


46

Wednesday, January 21st 2015, 7:36am

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

Sunday, January 25th 2015, 11:13am

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

Sunday, January 25th 2015, 12:21pm

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

Sunday, January 25th 2015, 3:04pm

ok werde ich Morgen mal machen.

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


MfG:Resident0007 :)

50

Monday, January 26th 2015, 7:20pm

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 has attached the following file:

This post has been edited 1 times, last edit by "Resident0007" (Jan 26th 2015, 7:28pm)


51

Monday, January 26th 2015, 9:39pm

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

Monday, January 26th 2015, 10:30pm

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

Tuesday, January 27th 2015, 6:42pm

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 has attached the following file:

54

Tuesday, January 27th 2015, 9:05pm

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

Tuesday, January 27th 2015, 9:21pm

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

This post has been edited 3 times, last edit by "Resident0007" (Jan 27th 2015, 9:43pm)


56

Wednesday, January 28th 2015, 7:50am

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

Thursday, January 29th 2015, 7:47pm

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 has attached the following files:

This post has been edited 1 times, last edit by "Resident0007" (Jan 29th 2015, 7:52pm)


58

Friday, January 30th 2015, 6:48am

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

Monday, February 2nd 2015, 6:27pm

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

Monday, February 2nd 2015, 6:49pm

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 ;)