cerdopower escribió:marcosgue escribió:A pedido de BlakCat voy a iniciar este hilo para recopilar información y sobre errores y posibles soluciones de las corona malditas y así intentar tener más ordenado el foro ya que cada vez se llena más de problemas con coronas.
La idea es armar el Wiki entre todos por favor lean lo siguiente
En el Wiki solo agreguen los problemas a los que se encontró solución y en el post vamos posteando problemas hasta encontrar la solución, una vez encontrada lo añadimos completo al wiki.
Comienzo el post publicando las soluciones que encontré a algunas coronas malditas que pasaron por mi taller!
uds me disculpan pero es muy poco lo que se de wikis, asi que si peco por ignorancia me corrigen:
corona v4
modelo chip nand: Samsung
extracción normal de la nand y programación del chip con timmings que usaba normalmente en las demas corona: chip matrix con oscilador con capacitor de 470 pf y timming 1-3::: nada, quinto glitch y congelada
probe con timming 4-2 sugerencia de otro usuario y cables cortos: a veces rodaba y a veces 5 glitch congele...
probe con resistencia de 680 ohms en el punto que sugiere otro usuario: nada, ni arrancaba...
después de mirar vi un post de el usuario viraldoom y vi su instalación como siempre impecable, segui casi su mismo esquema con la única diferencia de tomar el punto cpu rst en la parte de encima de la consola, haciendo que el cable midiera como un máximo de 5 cms y voila!!! la consola nítida, sin errores recurrentes, de 15 encendidos solo una vez se fue con el quinto glitch y congelamiento,y hasta ahora a la persona que le instale el chip a su consola le ha ocurrido nada porque nunca mas lo volvi a ver , jajaja, de momento no tengo las fotos pero se las prometo para dentro de poco, saludos.
sgonzalez_betin escribió:Hola, muy buen aporte, te comento que tengo el mismo problema pero con chip Squirt (vino programado de la tienda con minusone_nr), he intentado de todo, diferentes medidas de cable, diferentes calibres, desde 24AWG hasta 30AWG, probe todos los puntos cpu_rst, puse la resistencia de 560 ohms en el punto sda, ya no se que mas hacer. Me podrias dar el link de donde tu te fijaste?, y ademas poner la foto de donde tomaste el punto rst?
Gracias de antemano.
fagar1 escribió:Estimados estoy haciendo una toshiba con el autogg, leo la nand sin problemas, creo el shell, sueldo el chip para sacar la key y la consola no responde, hace el pitido pero no enciende, le vuelvo a cargar la nand original y arranca sin problemas que podra ser? alguna ayuda por favor
marcosgue escribió:sgonzalez_betin escribió:Hola, muy buen aporte, te comento que tengo el mismo problema pero con chip Squirt (vino programado de la tienda con minusone_nr), he intentado de todo, diferentes medidas de cable, diferentes calibres, desde 24AWG hasta 30AWG, probe todos los puntos cpu_rst, puse la resistencia de 560 ohms en el punto sda, ya no se que mas hacer. Me podrias dar el link de donde tu te fijaste?, y ademas poner la foto de donde tomaste el punto rst?
Gracias de antemano.
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
GonzaloJavier escribió:Insisto.. porque pensar que el chip es el problema?, cuando funciona perfecto para el Xell y para el Xebuild (el primer booteo).
Me parece que el problema esta en otro lado y NO en el chip.
Por qué el "problema" desaparece cuando re-reprogramo la nand?
skyperen escribió: le puse la nand original anduvo bien. le puse la nand modificada y gigleaba rapido de nuevo
skyperen escribió:GonzaloJavier escribió:Insisto.. porque pensar que el chip es el problema?, cuando funciona perfecto para el Xell y para el Xebuild (el primer booteo).
Me parece que el problema esta en otro lado y NO en el chip.
Por qué el "problema" desaparece cuando re-reprogramo la nand?
a mi me paso con una que anduvo bien con cr3 lite a la semana volvio y gigleaba rapido le puse el xell gigleaba normal, le puse la nand original anduvo bien. le puse la nand modificada y gigleaba rapido de nuevo le puse el dgx y hasta ahora anda. pero ubieron otras que me dieron fallas. las que hice con cr3 pro anda de maravilla en el primer o segundo arranca.
marcosgue escribió:skyperen escribió:GonzaloJavier escribió:Insisto.. porque pensar que el chip es el problema?, cuando funciona perfecto para el Xell y para el Xebuild (el primer booteo).
Me parece que el problema esta en otro lado y NO en el chip.
Por qué el "problema" desaparece cuando re-reprogramo la nand?
a mi me paso con una que anduvo bien con cr3 lite a la semana volvio y gigleaba rapido le puse el xell gigleaba normal, le puse la nand original anduvo bien. le puse la nand modificada y gigleaba rapido de nuevo le puse el dgx y hasta ahora anda. pero ubieron otras que me dieron fallas. las que hice con cr3 pro anda de maravilla en el primer o segundo arranca.
Skyperen hoy empiezo a mirar con el Oscilador a ver si puedo llegar a alguna conclusión.
También creo que el problema no son los chip porque funcionan bien para Xell pero no para Xebuild, de todas formas sepan que no es lo mismo lanzar Xell que Xebuild, y es muy probable que el problema vaya por ahí.
Como digo esta noche voy a empezar a estudiar las señales a ver si puedo llegar a alguna conclusión.
Saludos!
skyperen escribió:pero que errores te dan los dgx. yo mire con un osciloscopio de 200 mhz y es puro ruido los que se ve en el cpu_rst. osea no se puede distinguir nada. los dgx anduvieron en la mayoria pero en algunas se colgaba o gigli infinito. avisa gracias
skyperen escribió:bueno hay algunas placas muy jodidas con nand toshiba que no hay forma que booteen. he probado de todo. me doy por vencido he invertido muchas horas en ellas. esperemos que alguien encuenre solucion
zte escribió:skyperen escribió:bueno hay algunas placas muy jodidas con nand toshiba que no hay forma que booteen. he probado de todo. me doy por vencido he invertido muchas horas en ellas. esperemos que alguien encuenre solucion
Hola saludos, hace mucho q me registre pero nunca había tenido necesidad de postear, estoy incurcionando en xbox y he seguido este hilo desde el comienzo, solo para dejarlo claro el CR3 PRO, si te funciono sin ningún problema?
marcosgue escribió:skyperen escribió:pero que errores te dan los dgx. yo mire con un osciloscopio de 200 mhz y es puro ruido los que se ve en el cpu_rst. osea no se puede distinguir nada. los dgx anduvieron en la mayoria pero en algunas se colgaba o gigli infinito. avisa gracias
No con los DGX van funcionando como a ti algunos no funcionan. pero otras si una lotería.
Sobre el funcionamiento del osciloscopio hay que medir el tiempo de la señal del CPURst y del PostOut. el primer RGH debía generar una señal de 100ns todavía no he tenido tiempo de ponerme a mirar las señales bien, pero por lo pronto se comporta correctamente, tengo que ponerme a medir bien todo y comparar voy a conectar 2 a la vez con mismas configuraciones una en cada canal y las encenderé al mismo tiempo y compararé señales. si son identicas y una funiona y otra no me comenzaré a volver loco jajaja. al igual que mediré el funcionamiento del CR3 en una consola cuando arranca y cuando se cuelga para ver si hay diferencias entre una señal y otra.
Saludos!
vamed15 escribió:con coolruner rev d no ? segun leiendo si jala
marcosgue escribió:vamed15 escribió:con coolruner rev d no ? segun leiendo si jala
CR3 Lite Original, CR3 Lite Chino, Squirt Original, Squirt Chino, Matrix con Cristal separado Original, Matrix con cristal incluido (chino) CR Rev D (Chino)
Todos dan problemas!
Saludos!
![[triston]](/images/smilies/nuevos/triste_ani2.gif "tristón")
. 
eh configurado el chip con solo el lk2 cerrado y los demas abierto. en S2 los swich 1 y 6 en on los demas cerrados y nada. cable cpu_rst con 15 cm y el de amarillo con 8 cm e igual nada ya estoy a punto de echarla a la basura.. si algien me puede ayudar les agradeceria porfavor.. skyperen escribió:bueno aporto que todas las toshiba que hice con dgx chinos salieron. 2 no anduvieron y las saque con cr3 pro.
el cpu_rst puede variar entre 10 y 15 cm y el post_out entre 68 y 73 cm. tengan en cuanta estas medidas por si no les funciona con 70 cm de una. tengan cuidad si alguna xbox no le arranca con ninguna medida de calbe porque me tocaron muchos dgx chinos malos. se dan cuanta porque el gigli es unas milesimas mas corto que lo normal.
espero que ayude con el aporte
blaKCat escribió:Hola señores, llevo ya unos dias atento a este hilo y hablando con el xebuild Team de este tema.
Parece un error bastante generalizado y eso atrae mi atencion.
Mas si cabe cuando despues de tantos dias no se da con la razon del error ni la solucion al mismo.
Yo os puedo asegurar que he hecho personalmente estas consolas y jamas me dio ningun problema, por eso sinceramente pense que eran malas instalaciones o chips chinorros de los cuales vengo avisando mucho tiempo de su fiabilidad a medio plazo por desgaste de los componentes de baja calidad que montan.
Si un Dgx ( un chip de mas calidad que cualquier otro ) funciona , descarta el error del Xebuild y asi me lo confirman en Team. No digamos si usan clones baratos.
Si les funciona Xell siempre es porque probablemente usen Autogg que hace un proceso diferente al xebuild ( cb_a rip) no me digan que porque funciona Xell y no el Xebuild es problema del Xebuild porque no es exactamente el mismo boot secuence,
Mis conclusiones son:
No es problema del Xebuild.
No es problema de la instalacion (en los casos que obtengan xell)
No es problema del chip ( si estan seguros que usan originales , chinorros es una loteria)
Si el Dgx funciona es simplemente por ese salte de calidad en sus componentes incluido el cristal con mejor precision.
Pero para mi lo mas interesante de todo es los glitchs cortos. Como desarrollador del codigo interno estoy seguro que esto se debe a las lineas Sda y Sdl responsables de frenar la Cpu en el intervalo que le señala el postout para hacerle el cpurst.
Recordar:
El punto postout debuguea el bit del puerto para saber en que momento del boot secuence se encuentra la maquina.
Una vez en el primer punto de control el chip (corona este caso) frena la cpu a traves de comandos spi por los puntos sda y sdl. Y enciende el Led
Una vez frenado espera un segundo punto de control por el postout a partir del cual hace una cuenta atras de unos ns concretos y ZAS le pega el viaje a modo de cpurst-
Espera un tercer punto de control para volver a acelerar el cpu por comandos spi (sda y sdl)
y apaga el Led.
Conclusion final:
Por algun motivo no esta frenando adecuadamente la CPU y ese proceso lo hace mas rapido (velocidad normal ?) por eso el Led esta muy poco tiempo encendido.
La causa pueden ser varias:
Chip chinorro (no le pidas una alta precision o que aguante mucho tiempo) Has probado bombillas de la tienda del chino ? Pues eso.
Interferencias en los cables sda y sdl de modo que el comando ( unos y ceros , 1101000101 ...) no llega correctamente y la consola no hace ni puto caso porque no se entera.
Yo probaria a estabilizar estas señales quitando ruido y probando modificar la tension.
No hay que descartar que el error este en el punto postout que confunda al chip en los punto de control .
Lo raro es que el Dgx 1.0 funcione y el Dgx 1.1 no. Seguramente harian algun cambio en este sentido.
Lo otro raro es que solo fallen las Toshiba , sera que llevan algo mas sensible a ruidos en spi?
Lo otro raro es que a muchos les funcione la primera vez y luego no. Alguna tension residual?
Los que esten en este caso que hagan el proceso , creen xebuild flasheen y guarden una copia. Arranquen la consola y si lo hace correctamente apagar y volver a probar, si falla lean la nand por si algo cambia. (no lo creo pero por descartar)
Y revisen que no quede nada en contacto con el cristal de la consola al quitar el mmc. (puente)
De lo que estoy seguro es que si tuviera una consola con toshiba problematica no creo que tardara mucho en tener un fix publicado.
Si eres de España y quieres enviarme una de estas contacta MP.
Suerte, saludos.
marcosgue escribió:blaKCat escribió:Hola señores, llevo ya unos dias atento a este hilo y hablando con el xebuild Team de este tema.
Parece un error bastante generalizado y eso atrae mi atencion.
Mas si cabe cuando despues de tantos dias no se da con la razon del error ni la solucion al mismo.
Yo os puedo asegurar que he hecho personalmente estas consolas y jamas me dio ningun problema, por eso sinceramente pense que eran malas instalaciones o chips chinorros de los cuales vengo avisando mucho tiempo de su fiabilidad a medio plazo por desgaste de los componentes de baja calidad que montan.
Si un Dgx ( un chip de mas calidad que cualquier otro ) funciona , descarta el error del Xebuild y asi me lo confirman en Team. No digamos si usan clones baratos.
Si les funciona Xell siempre es porque probablemente usen Autogg que hace un proceso diferente al xebuild ( cb_a rip) no me digan que porque funciona Xell y no el Xebuild es problema del Xebuild porque no es exactamente el mismo boot secuence,
Mis conclusiones son:
No es problema del Xebuild.
No es problema de la instalacion (en los casos que obtengan xell)
No es problema del chip ( si estan seguros que usan originales , chinorros es una loteria)
Si el Dgx funciona es simplemente por ese salte de calidad en sus componentes incluido el cristal con mejor precision.
Pero para mi lo mas interesante de todo es los glitchs cortos. Como desarrollador del codigo interno estoy seguro que esto se debe a las lineas Sda y Sdl responsables de frenar la Cpu en el intervalo que le señala el postout para hacerle el cpurst.
Recordar:
El punto postout debuguea el bit del puerto para saber en que momento del boot secuence se encuentra la maquina.
Una vez en el primer punto de control el chip (corona este caso) frena la cpu a traves de comandos spi por los puntos sda y sdl. Y enciende el Led
Una vez frenado espera un segundo punto de control por el postout a partir del cual hace una cuenta atras de unos ns concretos y ZAS le pega el viaje a modo de cpurst-
Espera un tercer punto de control para volver a acelerar el cpu por comandos spi (sda y sdl)
y apaga el Led.
Conclusion final:
Por algun motivo no esta frenando adecuadamente la CPU y ese proceso lo hace mas rapido (velocidad normal ?) por eso el Led esta muy poco tiempo encendido.
La causa pueden ser varias:
Chip chinorro (no le pidas una alta precision o que aguante mucho tiempo) Has probado bombillas de la tienda del chino ? Pues eso.
Interferencias en los cables sda y sdl de modo que el comando ( unos y ceros , 1101000101 ...) no llega correctamente y la consola no hace ni puto caso porque no se entera.
Yo probaria a estabilizar estas señales quitando ruido y probando modificar la tension.
No hay que descartar que el error este en el punto postout que confunda al chip en los punto de control .
Lo raro es que el Dgx 1.0 funcione y el Dgx 1.1 no. Seguramente harian algun cambio en este sentido.
Lo otro raro es que solo fallen las Toshiba , sera que llevan algo mas sensible a ruidos en spi?
Lo otro raro es que a muchos les funcione la primera vez y luego no. Alguna tension residual?
Los que esten en este caso que hagan el proceso , creen xebuild flasheen y guarden una copia. Arranquen la consola y si lo hace correctamente apagar y volver a probar, si falla lean la nand por si algo cambia. (no lo creo pero por descartar)
Y revisen que no quede nada en contacto con el cristal de la consola al quitar el mmc. (puente)
De lo que estoy seguro es que si tuviera una consola con toshiba problematica no creo que tardara mucho en tener un fix publicado.
Si eres de España y quieres enviarme una de estas contacta MP.
Suerte, saludos.
BlakCat gracias por tomarte el tiempo en presentar esto.
Sabes que hay algo más que extraño que está pasando, ayer me llego una toshiba PAL, traida especificamente de España, salio perfecta con CR3 Lite Original. Probé también los chinos CR3 Lite y los Rev. D. perfecto con todos!!! tiempos de arranque excelentes nunca superaba los 6 glitch.
luego de esto 6 más toshiba NTSC probé y nada... la verdad ya no se donde más mirar... he probado limpiar ruidos en SDA SCL fue una de las primeras cosas que intenté, de hecho en una de las consolas parecía una placa de ensayos miraba con el osciloscopio y las señales parecian un culito de bebe jaja... Nada... la misma falla...
Yo sinceramente me di por vencido... DGX y a la mierda... cada tantas consolas en alguna instalo un CR3 Original (comprado en XCONSOLES por eso se que son 100% originales) y nada siempre me encuentro con lo mismo.
A un cliente de hecho le entregué una consola que conseguí arranques en aprox 40 segundos, más de 10 arranques antes de devolverla al cliente todos perfectos
A los 3 días volvio que ya no le arrancaba más... cuando la miré por la rejilla de ventilación veo que el chip comienza a dar glitch rapidos permanente... dije... que raro se desoldaron los puentes en resistencias r2c6 y r2c7... pero no estaban perfectas... apenas llego... cambio a DGX y adios no tuve que cambiar nand ni reescribir nada!
Por el lado de leer la nand luego de que comienza a fallar. también lo he hecho y es identica no hay variaciones en ellas!
Saludos!
lecklerc escribió:No se si tendra algo que ver pero el tamaño de estas nands toshiba es mas grande que el resto
lo digo porque muestra mas megas cuando se ba a escribir con el J-Runner y este manda un mensaje de advertencia diciendo que el tamaño es distinto
blaKCat escribió:Hola señores, llevo ya unos dias atento a este hilo y hablando con el xebuild Team de este tema.
Parece un error bastante generalizado y eso atrae mi atencion.
Mas si cabe cuando despues de tantos dias no se da con la razon del error ni la solucion al mismo.
Yo os puedo asegurar que he hecho personalmente estas consolas y jamas me dio ningun problema, por eso sinceramente pense que eran malas instalaciones o chips chinorros de los cuales vengo avisando mucho tiempo de su fiabilidad a medio plazo por desgaste de los componentes de baja calidad que montan.
Si un Dgx ( un chip de mas calidad que cualquier otro ) funciona , descarta el error del Xebuild y asi me lo confirman en Team. No digamos si usan clones baratos.
Si les funciona Xell siempre es porque probablemente usen Autogg que hace un proceso diferente al xebuild ( cb_a rip) no me digan que porque funciona Xell y no el Xebuild es problema del Xebuild porque no es exactamente el mismo boot secuence,
Mis conclusiones son:
No es problema del Xebuild.
No es problema de la instalacion (en los casos que obtengan xell)
No es problema del chip ( si estan seguros que usan originales , chinorros es una loteria)
Si el Dgx funciona es simplemente por ese salte de calidad en sus componentes incluido el cristal con mejor precision.
Pero para mi lo mas interesante de todo es los glitchs cortos. Como desarrollador del codigo interno estoy seguro que esto se debe a las lineas Sda y Sdl responsables de frenar la Cpu en el intervalo que le señala el postout para hacerle el cpurst.
Recordar:
El punto postout debuguea el bit del puerto para saber en que momento del boot secuence se encuentra la maquina.
Una vez en el primer punto de control el chip (corona este caso) frena la cpu a traves de comandos spi por los puntos sda y sdl. Y enciende el Led
Una vez frenado espera un segundo punto de control por el postout a partir del cual hace una cuenta atras de unos ns concretos y ZAS le pega el viaje a modo de cpurst-
Espera un tercer punto de control para volver a acelerar el cpu por comandos spi (sda y sdl)
y apaga el Led.
Conclusion final:
Por algun motivo no esta frenando adecuadamente la CPU y ese proceso lo hace mas rapido (velocidad normal ?) por eso el Led esta muy poco tiempo encendido.
La causa pueden ser varias:
Chip chinorro (no le pidas una alta precision o que aguante mucho tiempo) Has probado bombillas de la tienda del chino ? Pues eso.
Interferencias en los cables sda y sdl de modo que el comando ( unos y ceros , 1101000101 ...) no llega correctamente y la consola no hace ni puto caso porque no se entera.
Yo probaria a estabilizar estas señales quitando ruido y probando modificar la tension.
No hay que descartar que el error este en el punto postout que confunda al chip en los punto de control .
Lo raro es que el Dgx 1.0 funcione y el Dgx 1.1 no. Seguramente harian algun cambio en este sentido.
Lo otro raro es que solo fallen las Toshiba , sera que llevan algo mas sensible a ruidos en spi?
Lo otro raro es que a muchos les funcione la primera vez y luego no. Alguna tension residual?
Los que esten en este caso que hagan el proceso , creen xebuild flasheen y guarden una copia. Arranquen la consola y si lo hace correctamente apagar y volver a probar, si falla lean la nand por si algo cambia. (no lo creo pero por descartar)
Y revisen que no quede nada en contacto con el cristal de la consola al quitar el mmc. (puente)
De lo que estoy seguro es que si tuviera una consola con toshiba problematica no creo que tardara mucho en tener un fix publicado.
Si eres de España y quieres enviarme una de estas contacta MP.
Suerte, saludos.
