USB SPI Flasher with PIC18F2455 - now with source and binaries

[Kdawg]

Im using mKonKing's hex atm, seems to work now. It goes into bootloader mode, and memory access shows in normal mode.
Is his hex version the correct on or should I reprogram it with a later xpicflash version?

Cheers!

**And Yes, I did ground pin 17 when inserting into the PC.

Hi Illness (Respect for work on PS3 scene, that was epic)

Im using a PICkIT3 and MPLAB to flash the PIC. I loaded the bootloader successfully(Bootloader always enabled, pin 17 grounded or not), and when I reprogramming it using the PICDEM USB FS Tool it programs flashX successfully(I detect memoryaccess in device manager), but then I have no more bootloader. I cant use PICKIT 3 with LVP(microchip made it obsolete), so do i need to perhaps change or ground pins when programming the bootloader or what can I do!?

Thank you, very frustrating having more problems with expensive pic programmer, my old ps3 art2003 worked better 

Good day Forum.

I built a darkstar nand flasher using a PIC18F2550, and im trying to load the usb bootloader with my PICKIT 3. The bootloader is responsive, but the problem is that it is stuck in bootloader mode, ALL the time! I tried setting MRCL, LVP etc etc. My circuit is correct(The bootloader pin only grounds when i push the button, checked it with the multimeter).
Does someone know if I should relocate the memory in MPLAB's to get the bootloader to run only when pushing the bootloader button? Hw do I fix this please help!

Thank You!

Regards

question is, did you even flash the picxflash? it will always be in bootloader mode if the bootloader is the only thing on the chip.

just to make sure... you are grounding the pin when you insert the usb correct?

[babylonx]

I tried to run this from a development board with a 18f4550 on a 512mb jasper and I ALWAYS get diffrences in nand dumps. The dumps contain valid data. I found "microsoft" references in them and I also found my CB at 0x8400 address. So these are not random data. But I get about 150 bytes differences between one 512mb dump and any other. I get about 10 210 and 250 errors but they are always at the same addresses so I guess thats normal.

I am using the PICFLASH_v3b_plus2 files with the pic and I also tried shortening the 7 cables between the xbox and the flasher and I also tried to change the 220nF capacitor on the usb port with a 100nF one. Still the same.

So, long story short, my flasher dumps my flash without random read errors but dumps always have diffrences.

Does anyone have anything to suggest?

This is a picture of it (which I know it is not clear but it might help):



Uploaded with ImageShack.us

[Arakon]

If the differences are also always in the same spots, then the errors come from the bad blocks. Sometimes the data read from them is random.

[babylonx]

I think I found what was causing it.

I have also made a mod to be able to plug and unplug my cable from my xbox like the one with the ethernet cable but I have used DB9 plugs (like the ones at serial ports) instead. Inside the plug, the shield gnd cable may have been shorting with the J1D2.4. The shield cable was insulated but the insulation had moved a little and I believe it was touching with the other. They were pretty close like less than 1mm when i checked.

I have also powered the development board with a second usb cable from the same computer. It has the option to be powered either from an external supply or from the usb port that is used to program the PICs. I was using an external supply till now. But I do not believe that this was the problem. I am putting my bets on the shorting J1D2.4 pin.

I have made four dumps of the first 64mb of my nand since I made the changes and compared them. All of them were identical. I am now doing four full 512mb dumps. I am still at the second round so I do not have two dumps to compare but I already compared the first dump and a reconstructed one I created from 3 old "bad" dumps and they are identical! That is very promising! In a few minutes I will have a second full dump and then I can confirm that it is working!

[babylonx]

The second dump was finished. The comparison showed 2 diffrent blocks, one at 0x1E98 and one at 0x4478. Since they are both above 0x1000 i guess they are not critical. I am doing a third and a fourth dump and we'll see how it goes.

UPDATE:
The third and fourth dumps had also differences from the first one which i believe to be the 100% good one (since it matched perfectly with a reconstructed one from older dumps). The third had about 10 different bytes (1 or 2 block i think) and the fourth had only 1 byte difference. Before I checked the cables I had a lot more differences between nand dumps so I guess it is a general issue of cable and soldering quality. I will try to change everything and check again for bad connections.

I also discovered that there is a new Nandpro v3 released a couple of days ago. It has a new hex file for the LPC2148 arm controller and it states clearly that the pic version of the hardware will not work... Well I guess it will not work until someone writes a new pic program for our flashers, right?

[babylonx]

It was the freaking J1D2.4 pin again! Shorting the cable made things a little tight and the cable was pulled. The shield was very close to the J1D2.4 again! And now I believe that they were not contacting, even them being real close may create problems because the shield is plain metal without insulator. It just has a short heat-shrink tubing near the end to avoid contacting the conections in the DB9 connector. Problem is that this tubing isn't very stable and moves a little leaving a very short piece of the shield unprotected. Maybe some hot glue to stabilize the cables behind the connector will be enough.

Here in the pictures you can see the shield insulation in place and moved. The orange cable is the J1D2.4.
I am posting this to be a lesson for other people too because I have done hundreds of soldering problems in my life but something can always pass unnoticed and create problems! I lost my weekend trying to realize what's wrong. So, always check your connections even if you are 100% sure for yourself.

[duschan]

Just finished my SPI reader with 2455.

I had a lot of errors, tried to schorten cables from reader to xb, but without success.

It seems that I have uber low quality PSU and problem is solved with some electrolytic capacitors between Vcc and GND. Maybe would be helpfull for someone.

[lprot]

I have made four dumps of the first 64mb of my nand

I've got Jasper 512Mbyte too. I made only three dumps:
1. 512Mbyte
2. 64Mbyte
3. 64Mbyte

Dump 1 & 2 showed differences in some bytes. But dumps 2&3 showed no differences. So I decided to stop at dump 3. All above 64Mbyte is memory unit and is not needed in fact.

[faint_u]

Finally I managed to get my DIY-ed USB nand flasher ready. But I got another problem: It only works with nandpro20a. I saw there are posts mentioning I can program a new version hex file to get it work with nandpro20b (or even later). However, I can't get it into bootloader mode again. I was able to do that (I think) by grounding P17 because that's how I flashed it. But now, even with p17 grounded, it still shows up as the libusb device.

Anything I'm missing?

[Arakon]

Then you probably didn't flash the bootloader, but the hex directly.
Or the hex you flashed is so old that it still had a different pin for bootloader mode.

[xboxbreaker]

If there is no bootloader present then the only way you can flash it is by using a pic programmer and flashing software like pickit2.
I use a cheap icP01 off ebay and flash the bootloader to it using a breadboard and simple circuit here:

http://www.piccircuit.com/picture/ICSP%20Connection.jpg

It is not clear how you managed to flash the hex without a bootloader or pic programmer, so like arakon said, maybe you are using the wrong pins, or somehow your ground connection on the jumper is gone, etc.

EDIT: also there is no HEX for the latest Nandpro yet, so you might be better just using the old nandpro anyway, until the new hex is compiled

[faint_u]

I do have boot loader flashed with winpic8.00. And after that is flashed, I connected the board with pin17 grounded and installed microchip USB device and thn flash another hex file with pdfusb. Not sure if this step will erase the bootloaser, or just because the hex file I'm using has different pin configuration.

If there is no bootloader present then the only way you can flash it is by using a pic programmer and flashing software like pickit2.
I use a cheap icP01 off ebay and flash the bootloader to it using a breadboard and simple circuit here:

http://www.piccircuit.com/picture/ICSP%20Connection.jpg

It is not clear how you managed to flash the hex without a bootloader or pic programmer, so like arakon said, maybe you are using the wrong pins, or somehow your ground connection on the jumper is gone, etc.

EDIT: also there is no HEX for the latest Nandpro yet, so you might be better just using the old nandpro anyway, until the new hex is compiled

[babylonx]

There was a bug with the very first firmware version of this flasher. I don't know if the bug was in the firmware or the bootloader but I know it did exactly what you are saying that happens to you: after you flash the the main program with pdfusb in bootloader mode, it somehow destroys the bootloader and you can't put it in bootloader mode again. So you have to flash it again from the beginning using a flasher and the new hex files. So, long story short, even if you flashed that bootloader, you have to flash the newer one again.

The most recent firmware makes it compatible with newer nandpro versions until 2.0e. If anyone makes a new firmware it might also be compatible with nandpro 3 but I doubt anyone will do that because this project is very old.

I have another question if anyone knows:
Is it possible that we make this flasher faster? The official hardware supported by nandpro is based on an ARM processor and it reads/writes the nand about 3 times faster! This one is based on a 12Mhz crystal but according to the datasheets, 18F2455 series can support up to 48 Mhz! Couldn't we just use a faster crystal and make it faster?

[cory1492]

OK, first off, the new nandpro update (as far as I know) makes no changes to what the PIC is set up to do: SPI flashing. What it does is add new things like a POST reader and JTAG xsvf player into the exe for the ARM hardware. Updating the PIC firmware to be recognized by nandpro is likely trivial, adding all that stuff to it... not so much (also consider the PIC runs at 5V.)

Is it possible that we make this flasher faster? The official hardware supported by nandpro is based on an ARM processor and it reads/writes the nand about 3 times faster! This one is based on a 12Mhz crystal but according to the datasheets, 18F2455 series can support up to 48 Mhz! Couldn't we just use a faster crystal and make it faster?

Yes it's possible to make the flasher faster, but you aren't going to do that by messing with the oscillator. 12M/4M/8M no matter what you use, it's divided to get 48MHz for the core, and the USB frequency for USB communications. If you go outside the specs on this, the PIC might work but not USB. Any optimizations would need to be done to the bitbang SPI Darkstar implemented. Originally I had thought to use one of the hardware SPI devices on the PIC to remove any speed lost to bitbang, but it would seem this PIC revision cannot do both USB and SPI at the same time because of a shared pin.

[faint_u]

Finally I fixed this by using another hex file. It seems the bootloader hex from PICFLASH_v3b_plus2 doesn't work. So what I did first is to use the bootloader i was using with the PICFLASH.hex from PICFLASH_v3b_plus2. It works and got recognized by nandopro20d (I didn't try 20e or later), but still it won't go into bootloader again. Later I reflashed the device with some hex file with bootloader integrated (can't remember where I downloaded it, it's named as USB_Xbox360_SPI_12MHz_(incl.BootLoader)_PicXFlash_V3b.hex). It works perfect and I can also enter the bootloader.

I do have boot loader flashed with winpic8.00. And after that is flashed, I connected the board with pin17 grounded and installed microchip USB device and thn flash another hex file with pdfusb. Not sure if this step will erase the bootloaser, or just because the hex file I'm using has different pin configuration.

If there is no bootloader present then the only way you can flash it is by using a pic programmer and flashing software like pickit2.
I use a cheap icP01 off ebay and flash the bootloader to it using a breadboard and simple circuit here:

http://www.piccircuit.com/picture/ICSP%20Connection.jpg

It is not clear how you managed to flash the hex without a bootloader or pic programmer, so like arakon said, maybe you are using the wrong pins, or somehow your ground connection on the jumper is gone, etc.

EDIT: also there is no HEX for the latest Nandpro yet, so you might be better just using the old nandpro anyway, until the new hex is compiled

[iglitare]

is it possible to program the xilinx cpld that is used for the glitch hack with this flasher?

nandpro3.0 seems to be able to flash xilinx now. Possible only with lpc2146 olimex or maximus nandflasher...

has anyone tried this flasher here with nandpro 3.0 and a xilinx cpld?

[xboxbreaker]

Finally I fixed this by using another hex file. It seems the bootloader hex from PICFLASH_v3b_plus2 doesn't work. So what I did first is to use the bootloader i was using with the PICFLASH.hex from PICFLASH_v3b_plus2. It works and got recognized by nandopro20d (I didn't try 20e or later), but still it won't go into bootloader again. Later I reflashed the device with some hex file with bootloader integrated (can't remember where I downloaded it, it's named as USB_Xbox360_SPI_12MHz_(incl.BootLoader)_PicXFlash_V3b.hex). It works perfect and I can also enter the bootloader.

I used the boot.hex that was supplied with the PSgroove package, as I had similar issues with the supplied bootloader, forgot all about that until you mentioned it.

[d4m4n]

Last year I made a version of this flasher:
http://www.xboxhacker.org/index.php?topic=12306.msg95864;topicseen#msg95864

Now I made a batch of an improved version. All components are SMD. This time I had a Pickit 3 so flashing the PIC chips was easy. I just read the flash from the old working unit and flashed the image to the new ones. Worked great on my slim and fat models.

[flower0]

hi have someone have any alternative with pic18f2455 since its hard to purchase from my area
but i do have some pic18f family need your guy to check whether compatible for this spi flasher schematic 2321I/SS,4515-I/PT,2515-I/ML
Thanks alot

[ProZsolt]

Can somebody post the latast firmware for the PIC?