Microkontroller - JTAG

[MatrixOne]

So erledigt.

zum einen hab ich nun andere kabel verwenet normale litzen kabel statt AWG32 und nun kann ich das ding mit 3 mal reset in den destroy recovery modus bringen.

aber wäre es net ne idee. das man das chip das direkt macht?

also so ne while schlife das der beim ersten start nen counter von 3 setzt und dann 3 mal vom chip aus resetet wird und bei jedem start einmal runter gerechnet wird. oder man ne abfage macht wobei ich nicht weiss in wie weit das möglich ist, das man den chip horchen läst nach den destroy recovery mode, das der solange resetet bis die meldung kommt. weil jedes mal die kiste beim einschalten 3 mal neustarten ist blöde.

[mce2222]

das sollte eigentlich nicht notwendig sein.

also bei mir wird der patch in 95% der Starts korrekt durchgeführt.

für die restlichen 5% hab ich einen kleinen Trick der dir wahrscheinlich auch helfen wird:

wenn keine NK.BIN Datei vorhanden ist, macht der bootloader sofort einen Reset.
daher die orginal NK.BIN löschen oder umbenennen, und die zu ladende NK.BIN in YA.BIN oder LX.BIN umbenennen.
Per Jumper oder besser noch per Schalter dann so einstellen das die passende Datei gebootet wird.

so gibt es nur 2 Möglichkeiten, entweder der patch klappt und die richtige Datei wird gebootet,
oder der Patch klappt nicht und die NK.BIN wird nicht gefunden -> Neustart... solange bis es klappt.

[MatrixOne]

THX das ist ne gute idee das blöde ist das ich jedes mal die blöde netzwerk leitung ziehen muss damit das teil keine neue NK.bin zieht.

dazu muss ich noch den jumper in funktion nehmen dazu muss man mal raus bekommen was LX udn wsa YX ist. aber das bekomme ich auch noch raus.

so nun mal schauen das ich mich durch die ganzen XML seiten wühle und mal sehen was sich da sonst noch so machen kann

und mir ne schöne ide platform beschaffen um ggf mal nen bissel was zu basteln.

[MatrixOne]

wasbeimir auffält ist , das nach dem einschaltenfürnicht ne sekunte startim display steht udn der direkt zum update fenster springt ohne irgrend was ich denke da leigt der hund begraben ansonsten muss ich den per power knopf so oft starten bis der die LX.bin bootet  nen reboot weil keine NKbin vorhanden ist machter bei der X301 nicht der bleibt solange im update fenster stehen bis irgend wannd ie meldung im display erschient keine verbindung.  in dem punkt unterscheitet sich die box von der 300. mal sehen wie man das im chip code anpassen kann. und wo der genaue zeitpunktist wo der patch ausgeführt wird.

[MatrixOne]

nach vielen versuchen finde ich immer noch nicht die antwort...

also ich hab den modchip von scheeleopard gebaut, der funktioniert ja auch. nur ich muss etliche male reseten vevor er überhaupt mal richitg patcht.

di ekabel sind max 5cm lang kürzer gehts net, kabel an reset ligt auch und funktioniert auch.

aber ich verzweifle echt das ich jedes mal 40  bis 50 resets durch führen muss bevor der chip patcht.

also ich denke mal nich das es an den kabels liegt da er ja gelegentlich nach unterschiedlichen intervallen ja greifft. einzigste ist der patchzeitpunkt. aber da mal den richitgen zeitpunkt erwichen das ist eine große frage.

egal wie ich die starte mit Nk.bin auf der plate ohne nk.bin nur mit ya oder Lx also nix 40-50 versuche.

vll hat schneeleopard ja ne idee, ich hab den letzten patch im einsatz den er auf sourceforce liegen hat.

[Schneeleopard]

Hallo,

compilierst du den Sourcecode selbst?

Wenn ja, der Patchzeitpunkt wird in ter x30xtmodchip.h Datei eingestellt.
Welche Bootloader Version hast du? evtl. wurde da ja seitens der Telekom etwas verändert was den Zeitpunkt zu dem gepatcht werden muss verschiebt.
Einfach mal versuchen den Patchzeitpunkt etwas höher oder niedriger zu setzen, so bis zu +-1 Sekunde.
Wenn das nicht hilft könnte es vielleicht auch helfen die JTAG-clocktime etwas zu erhöhen.

Falls beides nicht geht wird es schwer das ganze richtig zu debuggen ohne serielle Interfaces an den Receiver und den Chip zu bauen.
Evtl. mal als günstige Zwischenlösung die Debug LEDs anlöten, wenn noch nicht geschehen, um zumindest zu sehen ob das Patchen selbst korrekt funktioniert.

Die Patchzeitpunkterkennung ist leider noch ein ziemlicher Hack und der Grund warum der Code noch im pre-Beta Zustand ist.
Die einzige Information die der Modchip vor dem Patchen vom Receiver bekommt ist bisher das Reset-Signal und von da aus wartet er ein paar Sekunden und patcht dann.
Bisher kenne ich leider keine wirklich bessere Methode den richtigen Zeitpunkt zu bestimmen...

MfG

[Schneeleopard]

Ach ja, eine Sache noch, hast du bei deinem AVR auch die Fuse-Bits für den internen Taktgenerator geändert?

CKSEL3..0
   0100

Wenn nicht läuft der nur mit 1MHz statt den 8 auf die das Programm ausgelegt ist, dann stimmt entsprechend das gesamte Timing nicht mehr.

(Bei Fuses beachten -> Falls PonyProg verwendet wird entspricht eine 1 einem deselektierten Kästchen)

(http://www.mikrocontroller.net/articles/AVR_Fuses)

EDIT: Daran, dass du eine 301t hast sollte es nicht liegen, solange T-Home die nicht in den letzten Monaten wieder verändert hat, ich habe auch nur eine x301t.

Was auch noch sein kann: Ist deine Reset-Quelle in Ordnung?
Evtl. mal mit Multimeter messen ob das Reset-Signal auch low geht, wenn die Box resetted wird.

[MatrixOne]

da ponyprog selber komischwerweisse mien selbst gebauten chreiber net erkennt benötige ich den yaap damit kann ich problem los den avr proggen. müsste mal schauen wie ich da den fusebit setze könnte durch aus das problem erklären was ich habe scheinbar läuft er nämlich net mit 8mhz.

ich weiss auch net wieso ponyprog den avr net erkennen will benutze halt nen standart atmega8_isp wie im folgendem bild

[MatrixOne]

also mitlerweile reagiert er öfters beim reboot, aber i mmer noch unbefriedigent.

hier mal nen bild im anhang wegen des fusebit ob es vll doch daran liegt.


Edit oder sollte es so aussehen:

[X] CKSEL0
[X] CKSEL1
[_] CKSEL2
[X] CKSEL3
[X] SUT0
[_] SUT1
[_] BODEN
[_] BODLEVEL
[X] BOOTRST
[X] BOOTSZ0
[X] BOOTSZ1
[_] EESAVE
[_] CKOPT
[_] SPIEN
[X] WTDON
[_] RSTDISBL


weil wenn ich das bild unten richtig betrachte müsste der interne osc 1MHZ 6CK 64 ms haben das sollte dann entsprechent falsch sein bevor ich aber irgend was falsch einselle wäre ich dankbar für hilfe

[Hoernchen]

Hab gerade auch meinen ersten Modchip in Betrieb genommen. Hatte bisher immer einen alten fürchterlich lauten Server mit Parallelport als Patcher benutzt, daher war das "Basteln" eines Programmieradapter nurnoch ein umkonfigurieren des Pinouts in der avrdude-config, als GUI hab ich dann http://avr8-burn-o-mat.aaabbb.de/ benutzt, und es ging auf Anhieb mit dem beiliegenden Hexfile für den mega8.
Was die Fusebits angeht : Je nach Programmer/GUI den man Verwendet sind die Fusebits "aktiv 1" oder "aktiv 0", am einfachsten findet man raus wie es ist indem man erstmal die Fusebits ausliest, die im Auslieferungszustand des atmega8 auf 1mhz eingestellt sind (also CKSEL3,2,1 0 und CKSEL0 1), dann sieht man ja, wie sie Angezeigt werden.
Auf jeden Fall auch von mir ein grosses Dankeschön an Schneeleopard für die gute Arbeit

[mce2222]

allerdings könnte der Patch ansich noch etwas verbessert werden, denn es ist z.B. störend und unnötig, dass der bootloader den Videoausgang
abschaltet...
ausserdem wird irgendwo im bootloader scheinbar ein Schreibschutz für bestimmte Register gesetzt (wahrscheinlich der Grund warum die uCodes unter Linux nicht geladen werden können)

das wär also noch ein Aufgabenbereich für Assembler-Profis

[MatrixOne]

also ich für meinen teil muss sagen Jtag so geht microcontroler nur wenn er will.

resetleitung ist auch i ordnugn fuse bit hab ich nun auch richitg gesetzt denke ich mal von daher sollte der auf 8 Mhz laufen aber dennoch will er net was mich verrückt macht.

an der verkabelung kann es auch net liegen da ich die leitng so kurz wie möglich gehalten habe.

kann nru der microcontroler selber sein (ATmega8L-8PU) oder halt irgend was anderster.

ich weiss auch nimmer weiter hab schon etliche einstellugnen versucht.

da ich nicht so bewandert mit microcontroler bin kanns auch daran liegen bezweifle ich da dieanleitung recht simpel ist ud wenn man alle infos hat sollte es ja auch klappen.


da ich keinen hinweiss zur spannugns versorgung gefunde habe, weiss ich nciht ob das überhaupt der richitge ist.

[Hoernchen]

Mit meinem atmega8-16pu braucht das ding zwar 5v statt 3,3 (gibts am USBport), funktioniert aber ansonsten problemlos -korrektur: nun garnicht mehr ?! nach "CLEAR WARCHDOG" ist schluss. Hmm.
Weniger schön das ich heute 8h lang gefummelt hab bis endlich mal das rs232 mit MAX232N ging, ich hasse einfach Streifenraster, schnell gebaut, aber danach bin ich dann ewig und drei Tage lang auf der Suche nach irgend einem haarfeinen Kurzschluss der sich durch das wegdremeln der Streifen ergibt. Zusätzlich hab ich Schussel auchnoch das reset-Lötpad am minipci-Anschluss abgerissen und musste da mit Leitsilber pfuschen...


edit nr 3: ahaa ! da MÜSSEN Widerstände zwischen einen 5v-atmega und den JTAG-Port, genau wie beim Parallelport, sonst geht das Patchen nur halb oder garnicht. Hab nun überall 100 Ohm dazwischen ausser bei TDO, und nun geht der Patcher jedes Mal auf Anhieb.

[MatrixOne]

vlleicht sollte ich es auch malmit wiederständen versuchen

das ist im grunde das was ich auch habe,

anfang gings dann gings net und irgend wann doch
denke mal das es genau der gleiche effect bei mri ist werde ich auchmal versucen

[Schneeleopard]

Das mit den Widerständen kann gut sein, wenn der AVR mit einer höheren Spannung betrieben wird als der MediaReceiver, danke für den Hinweis.
Werd ich demnächst mal in den Schaltplan einfügen, schaden sollte es auch bei gleichen Spannungen nicht.

Ansonsten zum Problem von MatrixOne:
Wenn die FuseBits nun definitiv richtig gesetzt sind, die Spannungsversorgung stimmt (Für normalen ATmega USB port, ansonsten sollten auch 3.3V am JTAG port bereitstehen) und das Resetsignal in Ordnung sind dann gehen mir auch langsam die Ideen aus, vor allem weil es ja ob und an zu funktionieren scheint.

Ansonsten würde so spontan wohl nur noch helfen ein debug Interface (Wie RS232 oder zumindest die LEDs) zu haben, um zu sehen wo es hängt.
Aber vielleicht hat ja sonst noch jemand eine andere Idee.

Die Fuses bei YAAP müssten korrekt sein wenn folgende der CKSEL und SUT Kästchen gesetzt sind: CKSEL0, CKSEL1, CKSEL3 sowie SUT0 die Anderen davon ungesetzt.