xvassor

J'ai relié la masse de la console à la pin 2 du port LPC ainsi que le 3.3v à la pin 9 comme dit sur la photo 1 et ensuite j'ai pu en effet constater que la console démarrait bien sur la carte Aladdin. Quand la console est en veille la led rouge de la carte Aladdin ne s'allume pas donc il faut en conclure qu'il n'y pas de tension sur la pin 9 du port LPC. Donc mon problème de boot à mon avis venait du BT qui ne devait pas être relié correctement à la masse donc la carte Aladdin n'était jamais active. En conclusion cette xbox est bien une véritable v1.5, une perle rare

Hi Badablek, Merci pour ta réponse rapide ça fait plaisir Pour le BT j'avais fait comme sur ta 2eme photo (voir petit file jaune) . Concernant le 3.3v, je pense que d'avoir le 3.3v sur la pin 9 au moment du Power ON ne doit pas suffire pour faire fonctionner la carte Aladdin correctement. Je pense que la carte doit être relié au 3.3v en permanence donc pas uniquement au moment du démarrage de la console (donc même en mode veille celle ci doit être alimentée). Pour expliquer cela, je pense que pour driver le signal D0 à '0' au moment du boot donc pour forcer la xbox a booter sur le port LPC il faut que la carte Aladdin soit déjà en marche. Si j'ai la led de ma carte Aladdin qui s'allume après un "Power On" ca doit vouloir dire que le VCC et la masse arrive bien au port LPC mais sûrement trop tardivement. D’où le montage de la photo 1 pour forcer VCC et Ground a être présent en permanence mais pas uniquement après un démarrage de la console. Si quelqu'un pouvait me confirmer que quand la console est branchée au secteur, console en veille, la led rouge de sa carte Aladdin est effectivement allumée ca pourrait valider mon hypothèse. Dans tous les cas je vais cabler le VCC et la masse comme dit sur la photo 1. Je vous tiens au courant ... Merci à tous,

Bonjour, J'ai acheté récemment une XBOX dans un vide grenier. Quand je l'ai testé elle ne fonctionnait pas (elle n'affichait rien à l’écran, pas de message d'erreur). J'ai pensé qu'en branchant une carte de type Aladdin ca corrigerait peut êtrele problème. J'ai donc installé cette carte dans la console et j'ai changé la nappe IDE par une nappe IDE plus récente (qui supporte des débits plus élevé). Miracle la console c'est mise a fonctionner ! Mais je constate que je n'arrive pas a faire booter la console via l'eeprom du PCB Aladdin. Celle ci boot toujours en mode normal. Je n'utilise pas le bouton BT pour activer la carte j'ai opté pour la solution de toujours booter sur le bios de la carte aladdin et non celui de la XBOX en soudant la pine BT a la masse (comme dit dans la notice) via un file de 1-2 cm. Je pense pense que mon problème vient du choix de montage qui dépend de la version de la console et non des soudures. J'ai comme info: MFG DATE: 2003 03 19 SERIAL NO: 4053801 31205 PRODUCT ID: 441 4053801 31205 pour MFG DATE on me dit que 02/03/2003-26/07/2003 => v1.3 20/07/2003-10/04/2004 => v1.4 ou v1.5 Donc pour la date du 19/03/2003 ça donne une version 1.3 Le SERIAL NUMBER lui me donne aussi une version 1.3 SERIAL NUMBER = LNNNNNN YWWFF = 4053801 31205 L=4 numéro de la ligne de produit Y=3 année 2013 WW=12 FF=factory code=05=China NNNNNN=053801 numéro de la xbox produite durant la semaine LNNNNNN 31WFF => version 1.3 En revanche j'ai une chip VIDEO de type FOCUS FS454 donc ca doit être une version 1.4 ou 1.5 !!! La console n'a jamais été ouverte donc c'est bien son boîtier d'origine. Le lecteur DVD est de marque PHILIPS model VAD6035/21 => donc une version xbox v1.1 et + Le disque dur et de type SEAGATE ST310014ACE (LBA 20 005 650)(10 GO normalement) => version 1.1 et plus Pour le kernel et dashboard j'ai comme info K:1.00.5101.01 => Version 1.2-1.5 D:1.00.5960.01 Bref tout me dit que j'ai une console xbox v1.3 mais que son chip video lui ne correspond pas. J'ai testé la pin 2 du port LPC et je n'ai pas la masse dessus donc ça devrait être une version 1.5 mais j'ai bien la carte Aladdin qui s'allume (led rouge) quand j'allume la console via son bouton Power. donc j'en déduit que j'ai bien une masse et un vcc (3,3v je suppose) qui arrive à la carte aladdin Sur la pin 9 du port LPC j'ai bien du 3.3v qui arrive quand la console est ON mais 0V en veille. Question quand la console est en veille est ce que la carte aladdin doit avoir sa led rouge d'allumée ? je dis ca car j'ai vu que sur une video d'un montage 1.6 la led rouge était allumée quand la console était en veille. Sinon j'ai 5V sur le D0 de la carte mère quand la console boot. J'ai pris mon DO sur la face avant du PCB de la XBOX et non derrière comme indiqué dans la notice. Je pense pas que ça change grand chose car c'est ce point la que j'ai utilisé autrfaois pour une carte DUO X2. Mais pour forcer la console a booter sur le port LPC il faut que ce signal passe a '0' je pense que c'est la carte ALADDIN qui doit se charger de le rooter à la masse ? Les consoles 1.5 semblent très très très rare donc je doute que ça soit une version 1.5 ? Pour vous c'est une version 1.3 ou une version supérieur ? merci pour votre retour.

tu n'as pas besoin du CPLD pour tester si ta console reset toutes les 5-7 secondes Ca tu peux le faire a l'oreille en écoutant les ventillos start/stop .... le reset se fait via le signal CPU_RESET qui ets aussi cablé au CPLD donc mesure la tension de ce signale il doit passer de environs 1,8V a 0V un court instant s'il est tout le temps a 0V c'est que tu as un court circuit. sans CPLD il doit etre en haute impedance c'est a dire entre '0' et '1' logique environs soit 1V au repos et chuter a 0V lors d'un reset le glitch qui est fait via CPU_RESET est tellement rapide que tu ne pourra le mesurer (environs 100ns) toujours sans CPLD avec l'ECC present la console reboot a l'infini toutes les 5-7s sans led rouge bien sur sinon c'est que tu n'a pas le Xell de flasher mais le code d'origine. si pas de reset c'est que ton flash de l'ECC n'est pas bon car quand la console boot elle doit forcement echoué à son test de signature du mauvais code present en flash car tu n'a pas le glitch en place (par mauvais code je veux dire code non officiel M$) donc doit redemarrer suite a un reset complet provenant du bootloader et non du CPLD comme certains le pense.

Ca c'est normal car quand tu flash ton ECC ta console ne va plus booter sur le code original de M$ mais sur un custom firmware qui lui a son code SMC patché pour justement ne pas stoper les reset après n essaies infructueux. En mode normal, la console reboot naturellement toutes les 5s si celle ci rencontre un problème au boot et après n essaies et va en RROD et se bloque. Ton problème peut venir du GPU qui ne repond plus au firmware donc la console s’arrête. (Autotest qui failed !) Tu peux toujours essayer de faire booter un Xell et lancer des émulateurs pour voir si elle marche un peu mais sur Xenon vu que tu ne peux que récupérer ta clef CPU tu ne pourra rien lancer derrière. C'est ce qu'on dit, vu qu'il n'arrivait pas a restaurer la fréquence CPU en mode normal donc je pense que la console doit tourner au ralentit. Par contre avec le XELL tu va pouvoir vérifier si ton image NAND est bien alignée par rapport à tes efuses au niveau du LDV (en comptant les F ligne 7 je crois bien) peut être que ton problème vient de la ?

Bonjour Tout le Monde, Je constate qu'avec l'arrivée du RGH2, tous nos problèmes de stabilité du RGH reviennent au galop. Pour le RGH2 (donc que pour les PHAT) nous devons câbler nos CPLD à la sauce RGH1 version SLIM mais chose bizarre nous utilisons pas les mêmes composants externes (condo/resistance) lors du câblage. Je suis pas un expert en électronique mais il y a surement une raison, la CM des PHAT ne doit pas utiliser les mêmes valeurs de tension que celle des SLIM sinon je ne comprend pas le coup de la resitance de 10 ohms qui n'existe pas sur le montage SLIM RGH1. Pour revenir au hack RGH1 il y a un truc que je n'ai pas bien compris. - Pour SLIM on relie VCCIO1 sur VCCINT le tout relié au 1,8V fournie par le régulateur de 1,8V/150ma interne au CPLD (vu sur CoolRunner non TX) - Pour PHAT on doit utiliser une tension pour VCCIO1 < VCCINT pour que le FPGA arrive a bien décoder les infos (1 logique) qui arrive sur OUT_POST1 sinon il n'y arrive pas bien voir pas du tout. -> Certains utilise le 1,8V qui provient de la CM en directe pour VCCIO1 -> Certains utilise le 3.3V du CPLD - la tension de 3 diodes pour obtenir un 3,3V-3x0,7V=1,2V -> Certains utilise le 1.8V de VCCINT - la tension d'une diode soit 1,8V-0,7V=1,1V (note: La tension d'une diode peut varier de 0,6V a 0,7V donc ça peut varier de quelques 0,1V) Pourquoi car un niveau logique '1' vu sur POST_OUT doit etre égale a 70% de VCCINT (si je confond pas avec VCCIO1) soit 70% de 1,8V = 1,26V Corrigez moi si je me trompe De plus le signal CPU_RST que l'on va envoyer depuis le CPLD doit être de 1,1V pour être compatible avec le niveau logique donc des tensions des signaux de la CM donc il faut bien régler ce fameux VCCIO1 1ere question: Mais pourquoi sur PHAT et pas sur SLIM ? car les tensions de la carte SLIM sont plus élevés (> 1,1V) ? 2eme question: En modifiant nos CPLD RGH1 pour faire du RGH2 on câble bien le montage SLIM (utilisation de SDA & SCL mais plus de CPU_PLL_BYPASS) mais ne doit pas conserver le mechanisme de VCCIO1 < VCCINT sur nos CPLD aussi pour le RGH2 je pense que OUI c'est pourquoi nous avons pas beaucoup de retour positif ... car ce fameux VCCIO1 est surement mal réglé ! Certains vendeur de CPLD préconise de régler VCCIO1 a 1,65V pour avoir une temps de boot de 5s sur RGH2 (la reponse est peut être déjà donnée ?) La résistance de 10 ohms pour moi elle ne sert qu'a limiter la sortie du courant sortant de l'IO pour protéger la CM qui doit avoir un courant plus faible. donc avec ou sans cette résistance ça ne doit rien changer à la donne de plus cette valeur doit etre propre a la CoolRunner TX donc pas forcement bonne pour toutes les autres cartes a voir .... Merci pour vos lumieres ...

La coronna V1 a sa nand (ST) sur le dessus et la V2 sa nand (hynix) en dessous donc tu as une V2 donc pas encore modifiable ! Le RGH2 c'est juste une mise a jour du hack RGH v1.x pour les PHAT qui ont une mise a jour >= 14717 donc qui ont eu leur CB diviser en deux comme c'est déjà le cas pour les slims ou certains PHAT qui ont été réparé par M$ donc ne faite pas une mise a jour de votre PHAT dans le but d'installer le hack RGH2 car ça boot plus lentement car plus sensible aux perturbations ! J'ai fais une falcon avec une carte CoolRunner de chez TIAO, car marche mais moins bien que si c'etait un RGH v1.1 la console boot en moyenne en 4 voir 5 essais c'est a dire 20-30s au lieu d'un seul pour le RGH v1.1 ce qui est une bonne performance pour un RGH2 ! Le CPLD est configuré a la sauce SLIM c'est a dire que VCCINT est rebouclé sur VCCIO1 donc le tout alimenté par le regulateur interne de 1,8v/150ma du CPLD schema de cablage celon la doc de TX ECC fait avec J-Runner, CPLD programmé avec 360cProg v1.4 avec la version B du firmware de chez TX mais fournie par SH. puis installation du Freeboot généré par jrunner en version 14719 (le RGH2 de TX n'est compatible qu'avec les dashboard >= 14717) Bon fun !

s'il n'y a pas eu de mise à jour depuis le dump incrementer le LDV ne servira à rien sauf si le le firmware d'origine contient du code pour modifier son LDV en cas de tentative de bidouille donc s'auto killerait mais ca j'en ai jamais entendu parlé ... J'ai eu affaire a deux consoles qui n'ont jamais redémarrées suite a une restauration de l'image d'origine. Je pense que le hack a du cramer des résistances mais comment savoir lesquels ? S'il existe un schema/document qui explique quoi vérifier je suis preneur !

Pour mon test 1) J'ai fais un test avec l'émulateur nintendo64 avec une rom de jeu et ca a super bien marché ! Le son et l'image nickel (avec quelques imperfections d'affichage mais cela est du à la l'émulateur) Pour faire mes Freeboot j'utilise Multi-builder v0.921 de rogero cette version permet de faire un freeboot pour les kernels 14719/14699/13604 (Freeboot v0.08/XeBuild v1.01.421/Xell v0.991/Dashlaunch v2.32) Il est simple a utiliser. (mon orig.bin doit être a la base en 13604, LDV 14, CF/CG en patch1, PD=0xA0906B) J'opte pour le dernier dashbboard NXE et non METRO que je déteste donc je fais des images compatibles 13604. Pour mon test 2) (test fait à 50%) J'ai aussi essayé de déplacer les fichiers du filesystem de l'image (dash.xex) pour ne rien placer sur le block DD qui a mon sens pose problème. J'y est mis un fichier dummy donc qui est utilise par personne. Mais le boot n'a rien donné de mieux ! Je vais encore essayer pour le 2eme block qui pose aussi problème le 245 ...

Pour moi ll peut y avoir deux sources de problèmes: 1) Un problème Hardware sur la partie Audio qui serait détecté par le dashboard qui ferait qu'il ne veulent pas démarrer - Avec l'image d'origine j’obtiens 3 leds rouge au bout d'un certain moment, l’équivalent de 5 essaies de démarrage il suffit d'ecouter le bruit des ventilateurs qui s’arrêtent et repartent. - Avec un freeboot sans lecteur DVD de connecté j'aila led verte qui clignote au centre indéfiniment. (avec le lecteur DVD je pense qu'elle ne clignote pas mais doit rester tout le temps allumée) => Pour voir si c'est vraiment l'audio qui est NOK, Il faudrait que je test d'autres homebrew qui utilise eux aussi la partie audio de la CM Mais si c'est la partie AUDIO qui est abimée et que le Xell ne l'utilise pas du tout c'est donc normal qu'il tourne sans problèmes. l'ideal serait d'avoir un homebrew qui fait l'autotest de la CM, la j'en serais plus .... Voila une bonne idée de développement car ce type d'application ne doit pas encore exister ? 2) Un problème sur la nand - J'ai deux bad blocs: le premier en 0xDD et le 2eme en 0x245 celui en DD est vraiment mal au point il me fait même une erreur 202 je crois bien quand je fais un erase du block via nandpro Mais si je fais la séquence: erase DD, write 0 en DD, read DD, compare read_DD avec write_DD => Tout est OK write original_DD en 3FF, read 3FF, compare read_3FF avec original_DD => Tout est OK normalement sur une flash pour ecrire il faut toujours faire une erase avant sinon l'ecriture ne marchera pas si on veut transformer un bit a 0 par un bit a 1 Je pense que nandpro fait toujours par défaut un erase du block avant de faire son write Ensuite comment la console va lire son bloc DD ca je ne sais pas ? peut être que le mechanisme de remapping qui ne marche pas si le bloc est vraiment naze ? Le block DD correspond a l'offset 0xDD * 0x4200 = 0x38FA00 (sur une flash non big bloc) dans l'image freeboot ca tombe sur le fichier dash.xex qui demarre sur le block 0x66 et qui fait 0x16E bloc consécutif (donc va jusqu'au bloc 0x1D3 compris) mais dans l'image originale ca ne tombe pas sur ce fichier (sur je ne sais pas trop quoi). => une piste, refaire un freeboot en faisant en sorte qu'il n'y ai rien sur le block DD, y mettre un fichier qui ne sert a rien. le coup de la donor nand j'ai deja testé, si j'ai bien fais celle ci: injection du kv et du config + changement du ldv a 14 (par contre j'ai gardé le PD de la donor nand, ai je bien fais ?), je suis même repartie de celle ci pour faire un freeboot mais ca n'a rien donné de mieux. Bon j'ai deux pistes a creuser ... A plus tard ...

Oui mais je vois pas bien ce que j'ai pu faire de mal pour en arriver la ... Normalement le jeux Quake ne doit pas accéder à la nand, enfin je l’espère ... sinon ca pourrait peut être expliquer le probleme du son qui ne marche pas si celui essayait d'aller recuperer la section config de la console qui est en flash ? le son sort par le southbridge mais je ne sais pas ou tester ca et comment ? d’ailleurs je n'ai même pas le schéma de la CM qui est une falcon.

http://digiex.net/downloads/download-cente...ebrew-port.html ou encore http://www.logic-sunrise.com/telecharger-3...bxenon-v10.html sinon j'ai refais le test avec le lecteur DVD de connecté et au miracle le jeu a démarrer ! mais sans le son !!! donc je pense que mon probleme viens de la mais je ne sais pas quoi verifier sur le CM ... Si quelqu'un sait quoi tester je suis preneur ! Merci

J'ai effectivement le Xell qui boot bien que javais testé avec un émulateur mais sans lancer une rom de jeu. La je viens de lancer Quake SDL. Normalement le jeux de démarre sur une démo ou tu vois un joueur aux commandes donc avec son et images qui bougent. Chez moi il s’arrête après l'affichage du message "init sample 32khz" un message du genre donc j'en déduit que la console a quelque chose de cassée .... Peut être une résistance qui a cramée ou deux files qui se touchent .... Je vais tout dessouder et re-flasher la nand d'origine en espérant que ça reparte ..... sauf si quelqu'un a une console hacké qui marche et qui a aussi quake sdl qui bloque au démarrage ?

Ok j'ai effacé les lignes vierges en trop, désolè, pb de copier coller HTML qui passe pas bien

Bonjour, Mon Problème est dans le titre ! J'ai réalisé le Hack RGL sur une Falcon (16MO). J'ai fais 3 dumps identiques qui ont chacun 2 bad blocks: Error Lecture NandPro - Block - remap to 25C DD 3FF 250 245 3FE J'ai Flashé le Xell J'arrive bien a booter sur le Xell via Eject en moins de 5 secondes. J'obtiens bien ma clef CPU: 6EF1A809FD5897C64798479561D97F71 Voici l'image de ma nand avec ses 2 bad Blocks: http://dl.free.fr/mXk5SnxnJ J'ai utilisé construit mon Freeboot 13604 (car je ne veut pas de la version METRO) via 360_Multi_Builder_v0.921 en utilisant ma nand d'origine avec ses Bad Blocks XeBuild detecte bien les Bad Blocks et les remap a la fin voir le log: ------ finalizing image ------ Fixing up empty FS block entries...done! Writing FS table to image...done! calculating ECD bytes and assembling raw image...done! remapping 2 blocks copying 0x4200 bytes of LBA 0xdd to block 0x3ff...zero fill origin...done! copying 0x4200 bytes of LBA 0x245 to block 0x3fe...zero fill origin...done! done! writing file 'nandflash.bin' to disk...done! nandflash.bin written OK J'ai flashe le tout via rawFlash V4 (qui lui sait aussi remapper) Mais quand je demarre via le bouton on/off J'ai bien les 4 leds de la manette filaire qui s'allume mais je n'ai que la led verte centrale qui clignote a l'infinie ... pas de demarrage du dashboard ! Vu que rawFlash fais du remapping je me suis dit que peut etre il cassait le remapping de XeBuild donc j'ai refais une nand origine sans bad block + refais mon freeboot + flash via rawflash v4 et toujours meme resultat ! la je seche .... j'ai remis ma nand d'origine coupé le 3.3v et le 1.8v du cpld en esperant que ca suffit pour desactiver le glitch et la ma nand d'origine ne boot plus, meme symptome, 1 led verte central qui clignote (peut etre qu'il faut tout dessouder pour ne pas parasiter un boot d'origine ?) j'ai dessouder 3.3V, 1.8V, POST_OUT1, GND reflashé la nand d'origin avec des 0 en DD et 245 (sur les 2 BB) et remappage de DD en 3FF et 245 en 3FE, je reboot et au bout qq secondes, 3 leds rouge ! j'ai relu le block DD qui et il est bien a 0 idem pour le 245 et 3FF et 3FE contiennent bien les blocks DD er 245 je part du principe que si le Xell boot bien c'est que la console est OK (j'arrive a lancer un emulateur donc ca marche bien) J'ai aussi fais le coup du: - LDV+1 (en gardant le meme PD) + freebot + flash => marche pas - refaire une nand retail a partir de ma nand clean + freeboot + flash => marche pas Bref je seche completement: pour le LDV qui est de 14 je pense qu'il est bon car j'ai bien 14 fois 'F' sur la fuseset 07 donc le coup du LDV+1 je ni crois pas. J'ai aussi essayer de faire mon freeboot via xeBuild-GUI v2.04 , mais pareille vace nand d'origine avec BB ou sans BB je n'arrive pas a faire booter le NXE J'ai lu aussi que ca pouvait venir du signal STBY_CLK (c3b2 moi j'utilise le point alternatif FT2R2) mais j'y crois pas trop non plus vu que je boot bien sur le Xell en moins de 5s ce qui est le plus rapide ... J'ai aussi pensé que ma nand etait corrompue donc j'ai essaye d'extraire les fichiers de la nand via 360 flash tool mais vu qu'il plante sur la partie des fichiers kernels sur des nand Ok ou NON je ne peux rien dire de plus. J'ai aussi injecte mon KV et Config dans une autre nand + mise a jour du LDV + build freeboot + rawflash => marche pas ! La je n'ai plus aucune piste ...... Merci pour votre aide

si tu arrives a booter sur le Xell au moins une fois c'est que oui ton CPLD est bien configuré avec le bon jed et que ton montage est bien soudé. Ensuite si tu boot dificilement dessus (1 fois sur 20 par exemple) c'est que la position de tes fils est mauvaise et/ou que tu n'utilises pas les bonnes CAPA. Sur slim c'est surtout la position de tes fils qui pose problème, regarde les photos des montages qui marchent et fait de même. Par contre si tu boot bien sur le Xell, c'est la piste du mauvais build de ton dashboard qu'il faut creuser ... bien verifier si tu as des bad sectors lors du dump initial que tu dois retrouver aussi lors du flash final forcement ...

En effet je n'ai pas été très clair dans mon explication, je fais ma synthèse sur ce que j'ai lu ici et ailleurs, désolé ! Je ne parle pas du tôt de reussite au boot qui semble pas terrible mais bien de l'après glitch une fois qu'on a passé le test de comparaison ! Je crois en l'avenir mais attention aux annonces incomplètes ... Mon opinion du moment c'est que sur Xenon ca n'irra pas plus loin que l'affichage de la clé DVD ! D'ailleurs avez vous une video d'une Xenon RGL qui boot sur un kenel hacké puis qui lance un homebrew ensuite ?

Sur PHAT savez vous pourquoi on va chercher du 1.8V sur la CM alors que sur la CoolRunner nous avons un regulateur qui le fait deja ? Question de patate ? pas assez d’ampérage (limitation a 150ma) ? Ou Tout le monde à zaper ?

Pour les Xenons ce je que j'ai compris c'est qu'ils n'arrivaient pas passer du mode lent (une fois la frequence reduite) au mode normal ca plantait ensuite. Cela permet bien de continuer à booter sur le Xell donc de récupérer sa clé CPU et DVD mais ça ne pourrait en aucun cas faire tourner le Dashboard et les jeux ensuite qui eux demande du 200MHz donc cela servirait juste a récupérer sa clé DVD ... Donc OUI ils arrivent bien a glitcher toutes les versions de XBOX type PHAT mais toutes ne sont pas totalement utilisable ... L'annonce est correcte il faut juste la lire jusqu'au bout .... (C'est ce que j'ai compris donc espérons que ça va évoluer ....)

Merci beaucoup ! J'avais vu aussi dans le log qu'il utilisait les numéros de série des disques comme référence pour identifier ses disques donc je me suis dis qu'il avait surement sauvé cette info dans la DB mais j'ai pas poussé l'investigation jusqu'a aller comparer les deux DBs via un utilitaire SQLite. Bravo et encore merci pour l'info !

A priori les valeurs des CAPA sont bonnes car il faut juste respecté une valeur mini qui est loin d’être celle la. donc j'ai refais un test avec une nouvelle carte de chez Mr 007 avec juste comme modif un pont sur R2 et ca marche bien, elle boot en moins de 10s ... donc je vais mettre ca sur le compte de la fabrication du CPLD qui ne sont pas testés correctement en production ... Je pense a un probleme de fiabilite du FPGA

ici tu as le schema du connecteur avec les 3 sources de 3.3v http://free60.org/images/d/d5/J2B1_SCON.png tu peux utiliser souder la ou il ya le file orange

Bonjour à tous, Je me suis procuré un CPLD provenant de chine sur le fameux site de vente au enchère. Il existe différentes version du CPLD utilisant le fameux Xilinx XC2C64A. comme Le CoolRunner II qui existe en plusieurs version chez différents fabriquants. J'ai testé le C-MOD de Digilent qui marche bien Le CoolRunner II version ngzhang Rev B qui marche très bien ! Existe en Rev A et Rev B. et le catastrophique CoolRunner II de zhangjiqi007 .... Le CoolRunner II de ngzhang a part le nom qui a été pompé à refais son propre design, regulateur, oscillateur, capa etc ... mais Mr zhangjiqi007 lui a rien inventé sauf réduire les couts de fabrication et de controle quallité a la bonne sauce de chez radin.com ... il a tout pompé sur ngzhang meme jusqu'au nom des composants mais a utiliser des composants de m....e ! J'ai fais mon cablage avec la version de Mr 007 et ca boot sur le Xell une fois sur 20 .... J'ai desoudé le CPL puis mis la version de ngzhang et la ca boot en 5s tout le temps (ce qui prouve que mes soudures sur la CM sont OK) Conclusion les deux CPLD ne sont pas égaux en terme de fiabilité ! Si on regarde de plus prêt la version de Mr 007 on peut voir que certains composant comme la capa C7 sont présent sur centaines cartes mais pas sur toutes ... Ca je deteste, car ca veut bien dire qu'il n'y a aucun process qualité ... Bref j'aimerai savoir si certains ont réussie à utiliser ce CPLD avec un bon tot de reussite au boot, si OUI que faut il modifier sur la carte pour que ce la marche bien ? Pour PHAT J'ai fait un pont sur R2 et sur R5 car j'avais rien sur R5, R1 etant pas present pas besoin de la dessouder. note: le pont sur R5 ne sert a rien car l'entree 35 du CPLD n'est pas utilisé, j'ai juste reproduit ce qui etait present sur la version de ngzhang. La capa C5 est 3 fois plus petite en taille sur la version 007 que sur la version de ngzhang, je le soupsonne fortement d'avoir mis autre chose car ça coutait moins cher ou que son stock était vide donc qu'un autre composant fera l'affaire qu'il sait dit ... Je pense remplacer C5 par une capa plus grosse, une de 22uf (qui est la bonne valeur) Pour connaitre la valeur de C5 sur la carte de 007 il faudrait la dessouder puis la tester en charge mais comme je n'ai pas le matos pour tester donc je vais supposer qu'elle n'est pas bonne ! sinon j'espere que le regulateur 1.8V de 150ma est bien le même ... A propos de ce régulateur sur les coolrunner il est utilisé pour l'entree VCC du FPGA (15), VAUX lui étant en 3.3V. Question pour quoi prendre le 1.8V de la CM alors que nous l'avons déjà sur le CPLD ? car ça ferait un file de moins à souder ? Pour une console PHAT, on a pour l'instant pour les entrées du FPGA: VCC en 15 => 1.8V depuis le régulateur du CPLD (150ma maxi) VAUX en 35 => 3.3V depuis la CM (VCC du CPLD) VCCIO1 en 7 => 1.8V depuis le régulateur de la CM VCCIO2 en 26 => 3.3V depuis la CM merci pour votre aide note: schema du CPLD http://www.divshare.com/direct/16435109-692.zip

le 3.3v tu peux le prendre a deux endroit different. Tu as le 3.3V qui est présent uniquement quand la console est ON et le 3.3V qui est présent tout le temps quand l'alim est connecte a la CM (J2B1.7). Les Tutoriels parlent de celui qui est présent tout le temps (celui dont tu as arraché la pastille, tres fort d'ailleur car tu peux souder dessus ou dessous la CM) prend l'autre qui celons certains est bien meilleur car il ferait mieux booter le CPLD il se trouve juste en face sur le même connecteur en J2B1.8

Les points alternatif marchent très bien, j'utilise toujours FT2R2 et ca boot en 5s chrono. Je rappel qu'un point Alternatif est un point qui a une résistance de 0 ohm entre le point original et celui ci donc ces deux points se touchent et sont donc forcement relié entre eux par une piste. Ce qui peut changer c'est la longueur de la piste (source vers destination) qui doit varier et son voisinage qui peut être plus ou moins source de parasite. Je confirme donc que FT2R2 est bien meilleur que le point original car plus facile a souder et sous le CM donc moins parasité !