Showing posts with label Electronics. Show all posts
Showing posts with label Electronics. Show all posts

Saturday, December 20, 2014

XSVF JTAG Programmer

Now I need to have a device that glitches my Xbox 360. For my pursuit of frugal fun, I chose to use a cheap Coolrunner (I bought off eBay for $8) instead of the Team Xecuter CR4 XL (which is currently $33 plus shipping, not to mention the QSB kit). But there is one more problem. The Coolrunner I bought comes blank (not programmed). The information to program the Coolrunner with (in XSVF file) comes with the JRunner software, and XSVF files are for being written to device through JTAG interface.

I have a Matrix NAND Programmer to read and write NAND from Xbox 360. That process seems to use an interface that is SPI (or very similar to it). On internet, I have seen people post connection diagram for connecting  Maxtrix NAND Programmer to the JTAG interface of the Coolrunner. Interestingly, the programmer does have six connection pads on the side, and the JTAG interface is pretty similar to SPI. Because of that, and also the fact that the other NAND programmers / software can also be used to program JTAG, I had assumed that I can do that same with Matrix NAND Programmer.

It turned out not working. As mentioned in my other post, the Matrix NAND Programmer is compatible to NAND-X with drivers from NandPro 2.0. But it turns out that NandPro 2.0 does not yet accept xsvf option (that programs JTAG using a XSVF file). That feature is added in NandPro 3.0, but the NAND-X driver with NandPro 3.0 would not work with Matrix NAND Programmer.

So I am stuck here. Basically, I would still need to buy a NAND-X or JR Programmer to program the device, or I will have to find some creative way to get it done cheap. I read about the JTAG spec, and it is just four lines which seems to be quite straight forward. Then I found some code about playing XSVF through Bus Pirate. Bus Pirate is a very useful tool I have always wanted. But it is another $28 even though it beats buying CR4 XL. There has to be a better way.

After some more search, I found this library of writing XSVF files, called libxsvf. It is an open source project that programs XSVF files to an interface that you can provide. That is great. All I need is a bit-banging interface, and I can program the JTAG. I have thought about building a quick bit-banging interface with an AVR processor, or even an Arduino Pro Mini. But I happened do not have an 3.3V Pro Mini at hand, and my Coolrunner seems is marked 3.3V (but I don't have any data sheet on it). The next option is the well used FTDI USB-Serial interface, and I happened to have one of such (FT232R Breakout) which can be configured to either 5V or 3.3V.

Libxsvf comes with the main code compiled into a library and a couple of sample code that uses the library. One of the simple code is using simple GPIO in synchronous mode, the other one uses FT232H's MPSSE in asynchronous mode. My board is a FT232R, it can not use the later one. Oh well, I will just program the FT232R bit-bang as synchronous GPIO then.

Here come out my compiler and pretty soon I am writing to my Coolrunner. There are a few tricks to get it to run fast enough (mostly dealing with USB latency timers). It is possible to use the asynchronous mode to make it faster, but for the purpose of getting my Xbox 360 to work, that is enough. It takes a couple of minutes to program a 32KB xsvf file.

The source file of my program is xsvf_bang.c. It is based off xsvftool-gpio.c of libxsvf, and I hope I do get the license right. It needs to be linked to libxsvf (compiled as static library) and ftd2xx.lib (download driver from FTDI and extract).

 So after much trouble (all in the name of saving some $40 and having fun), my Coolrunner is ready to work with my Xbox 360.

Friday, December 12, 2014

Cheap programmer to read/write Xbox 360 NAND

In order to mod the Xbox 360, the first step is being able to read/write the NAND on Xbox 360. Apparent somebody has figured out the JTAG signals on the Xbox 360 board, and there are plenty of JTAG/NAND programmers out there.

The most common ones at this time is J-R Programmer v2 by Team Xecuter (at around $27 on Internet, plus shipping). There are also v1 version, and also an older programmer called NAND-X. As I always are, I am trying to find the solution to the problem at the lowest cost. On eBay, I found the Matrix NAND Programmer for around $8 shipped. So that's what I got. (I could go cheaper to build a parallel port adaptor, but that is 30 minutes for each NAND reading. A bit too long.)

It is now not that straight forward to use it (otherwise where is the fun of it). Here is the tricks that I have figured out to get it working.

Wiring to Xbox

The Matrix Programmer is an older device that was developed for use around 2011 (that's why it is cheap). The wiring connection is marked as J1D2.1, etc. The "J1D2" part of the mark refers to the connection headers on the Xbox motherboard, and ".1" part refers to pin 1 of the header. Apparently, that is for an older version of the Xbox. I have a Slim and the "J1D2" is now "J2C1", and "J2B1" is now "J2C3". And here is how it looks like connected to my Xbox Slim (Trinity).


Device Driver

One software that is commonly used is called NandPro by Team Xecuter (currently at v3.0). It is a command line tool that comes with a driver folder. However, none of these drivers work. So I searched up and down, and finally I read a post saying that the Matrix Programmer might be compatible with older versions of NandPro, such as 2.0c. The download can be found at this link. With the driver in that package, the device install well. And it appears as a "XECUTER NAND-X USB"!


Reading NAND

The NAND can be read by the NandPro on commandline. The Trinity has 16M NAND. So the command should be
nandpro usb: -r16 nand1.bin
But Team Xecuter has a better tool called JRunner. It has a graphic interface and makes everything a lot easier. Better yet, because the Matrix Programmer appears to be imitating NAND-X (as shown below in the red rectangle), it can be used directly with JRunner to read NAND.


Creating New ECC

With JRunner, creating becomes a simple operation of a click. No more need to install Python and the crypto pack as before.

Writing NAND

Just when I thought everything is sailing through, writing NAND in JRunner did not work. The operating It maybe because NAND-X has changed the interface. With the ECC generated, I just fall back to the commandline NandPro, and it worked well as intended.
nandpro usb: +w16 image_00000000.ecc


Now all we needed is a chip that glitches the CPU.



Monday, December 8, 2014

Run custom code on Xbox 360

I have a Xbox 360 slim for 3-4 years, and have played it occasionally. Recently I happened to check about running home brew code on Xbox and it turned out there are some amazing engineering done to enable that.

The best of that is a hack called "Reset Glitch". It is discovered by a French guy called Gligli. The whole process is nothing short of AMAZING. First a glitch was found that by asserting CPU_RST line on the processor the CPU will always return 0 for comparison commands (instead of a full CPU reset). So this way, one can assert the line at the "right moment" when the boot code is performing signature verifications so the verification always passes.

The keyword is "right moment". But the CPU is running code at hundreds of mega hertz. How do one find the right moment among the millions of instructions that are executed? It turns out there are ways to significantly slow down the CPU clocks, and different ways for different versions of Xboxes as well. For older Xboxes (called FHAT), the way is to assert CPU_PLL_BYPASS. For newer slim Xboxes, it is to change register value on a chip through I2C. I was thoroughly amazed by how people can probe and reverse-engineer all these from a complex black box system.

Apparently, this has been around for years (since 2011), and I have just learnt it today. I have decided to give it a try.

Saturday, August 9, 2014

Homemade CNC2 (Electronics - Part 2)

This blog is actually about a small disaster I have with my home made CNC. And I named it "Electronics - Part 2" because I believed that the problem seems to be with the electronics.

So I have GRBL controller on the CNC and everything works fine. The next thing I would do is to machine the end piece again for my Y-axis extension. This time I planned to machine it in aluminum. So I got some 5/16" aluminum, and go really slow with it (0.2mm per pass). It took a long time and I was watching the process, and got really bored. So I closed the enclosure and went on to do something else. When I got back to it after a while, I heard that something is wrong. I rushed in, and went for my panic button.

It was bad. The machine goes to some completely weird path. The end mill bits are broken. Not only the work piece is ruined, it gouged a deep mark onto my compound table. In additional, all the alignment of the machine is all thrown off.

I have been thinking about what went wrong. Eventually I came to a conclusion that this might be an isolation problem with the electronics. The step stick stepper motor driver I am using have both the logic and the driving power supply connected. The noise from the driving power side might get into the processer side and messed with the serial commands. That's just a guess based on logic deduction, and I have no prove for it. That give me an immediate next step work item, that is to build an isolation stage into my controlling electronics.

This really highlights another important aspect of working with machines and tools - the safety is a very important issue that can not be stressed enough. It was fortunate that I have an enclosure for the CNC, so whatever went wrong stays inside the cage. It is also a great practice to have a panic button that can stop all the machine operations right away. Because when you are at that moment, there is not much logic deduction going on. A pre-defined single safety action (such as pushing one button) would be a great feature to have for any machine.

For now, I will stay with machining plastic materials and stay watching it all the time during the process.

Tuesday, July 22, 2014

Homemade CNC2 (Electronics - Part 1)

I needed the electronics to run the CNC. When I started out (and with my last CNC build) I have been running it with Arduino Mega 2560 with a RAMPS shield. You can immediately recognize that this is a 3D printer electronics setup. Indeed, I have converted my last CNC into a 3D printer to learn the in and out of it. So with this CNC2 build, I have also started with the same setup, which I happened to have laying around.

For the firmware, I have been using Marlin. In order for it to run CNC, I have to modify the configuration file to disable temperature sensing otherwise it would not move (this is a safety feature for 3D printer to prevent extruding before the hot end is hot enough). For the host software, I have been using Printrun.

This setup works out fine for a while, but then I felt that I will need more. First of all, the Marlin firmware does not work with inch as unit. In this part of world where I am living, the English system is still commonly in use. It is a lot easier to go down to my local hardware store to buy stuff in English then mail order then on Internet and wait for them to arrive. The second thought is that I know there are CNC specific firmware out there, such as GRBL. If I can have a firmware that not wasting the processing power on checking the temperature, why not go for it? GRBL has been proven working by years of experience in the community and it has a few neat features from what I read (such as command to change steps per distance). The third things is that while using Marlin, I for a few times have the firmware paused in the middle of a long run. I somehow suspect there might be un-found bugs in the Marlin firmware, at the same time GRBL is simpler (thus less chance of bugs), better tested (it is there longer than any 3D printer firmware), and I especially like its soft reset that retains machine coordinate while resets the processor state. So I have set to move to GRBL.

GRBL is very simple and easy to use. It is small enough (I have always loved simpler solution) that fits into the 32K memory of ATmega328P. I happened to have a few Arduino Pro Mini 328 (which I bought for a few bucks on eBay thanks to China). So I pulled out my AVR compiler and build the GRBL. After some struggle with the Arduino bootloader, I am able to load GRBL onto my Arduino (which I essentially used as a ATmega328P breakout board).

Onto my breadboard in a spare box, I have built a test CNC controller running GRBL. And I have added the GRBL soft reset switch to the front panel, as I really needed that "Panic Switch". I will find out why soon.