PSGroove finally ported to a new chipset: PIC18F2550

[ozman911]

Also can anyone verify these crystals to be ok for the finished board? I have ordered some 18f2550 chips and need to order some crystals to match. I know there are numerous and just wanted confirmation that these will work.

hXXp://cgi.ebay.com/5-pcs-Crystal-Oscillator-20-MHz-HC49-/110518713368?pt=LH_DefaultDomain_0&hash=item19bb6d bc18

[MetalPhreak]

Ended up getting the 360 SPI files from their website. Needed the bootloader hex and a program hex seperate.

Anyway, offset padding for program hex is from 0x0000 to 0x3FFF.

Attached is the psgroopic_btldV1.1.hex file with the padding reduced to 0x3FFF.

I also set the xtal setting to 12Mhz. That's correct right?

Let me know if it works. Was saved for an 18F4550. If your 360 SPI uses a 2550 or 2455, just double check the config settings in WinPic800. Should be ok though.


ozman911: those crystals are fine. Look up JDM Programmer on ebay if you have an onboard COM port (not usb to com adapter). You can get them for $15.

[iLLNESS]

Differences between psgroopicV1.1.hex and psgroopic_btldV1.1.hex

non-bootloader starts at 0x0000 and goes to 0x1B9F

bootloader one starts at 0x1000 and goes to 0x2B9F

It's the same code, but offset by a bit. 0x0000 to 0x0FFF is where the bootloader sits in the PIC program memory. When you load it via the bootloader, it skips the 0x0000 to 0x0FFF section of any .hex file you load, so you don't overwrite the bootloader code.

If you find out what size the bootloader code is of whatever device you are using, you can just pad out the correct number of bytes before the actual code. You can get any .hex file designed for it to see :P

i tried offsetting to 0x400 (this is where the 360 usb spi flasher FLASH starts in the normal hex) and it doesnt seem to work....

[MetalPhreak]

i tried offsetting to 0x400 (this is where the 360 usb spi flasher FLASH starts in the normal hex) and it doesnt seem to work....

What did you use to edit the hex file? normal hex editors don't work. I had to do it within winpic (which isn't the greatest thing to use xD)

[crisdo98]

Ok there are way too many hexs floating about What hex can I use to just flash 1.1 to a 18F2455 with 12mhz crystal?

[Pyong]

Ended up getting the 360 SPI files from their website. Needed the bootloader hex and a program hex seperate.

Anyway, offset padding for program hex is from 0x0000 to 0x3FFF.

Attached is the psgroopic_btldV1.1.hex file with the padding reduced to 0x3FFF.

I also set the xtal setting to 12Mhz. That's correct right?

Let me know if it works. Was saved for an 18F4550. If your 360 SPI uses a 2550 or 2455, just double check the config settings in WinPic800. Should be ok though.


ozman911: those crystals are fine. Look up JDM Programmer on ebay if you have an onboard COM port (not usb to com adapter). You can get them for $15.

the bootloader for my chip appears to end at 758
Do you think you could make it work with that loader?

Also, the chip uses the following info besides the bootloader:

USER ID MEMORY:

200000 0F 0F 0F 0F 0F 0F 0F 0F 

CONFIGURATION MEMORY:

300000 22 0E 3F 1E 00 81 81 00 07 C0 07 A0 07 40 
3FFFFE 67 
3FFFFF 12

Thanks in advance!

[skygunner]

I found two things that greatly increase the reliability:

#1 Add a 100nf cap between vcc and gnd (19 and 20)
#2 Unplug any other USB device (i.e. USB HDD)

With this, it boots the exploit almost every time.

Like the one in the PSGrooPIC blog?
http://psgroopic.blogspot.com/2010/0....html?spref=tw

[MetalPhreak]

the bootloader for my chip appears to end at 758
Do you think you could make it work with that loader?

Also, the chip uses the following info besides the bootloader:

USER ID MEMORY:

200000 0F 0F 0F 0F 0F 0F 0F 0F 

CONFIGURATION MEMORY:

300000 22 0E 3F 1E 00 81 81 00 07 C0 07 A0 07 40 
3FFFFE 67 
3FFFFF 12

Thanks in advance!

I need to know where a working program *starts*. The bootloader can end anywhere in that reserved beginning part. The last call by the bootloader is usually a jump to program memory call. Basically makes it so the next line of code executed is at whatever address, where the actual program starts. I'll have a look at this 360 SPI stuff later and see if I can figure it out. Gotta head out to uni for a few hours.

[Pyong]

I need to know where a working program *starts*. The bootloader can end anywhere in that reserved beginning part. The last call by the bootloader is usually a jump to program memory call. Basically makes it so the next line of code executed is at whatever address, where the actual program starts. I'll have a look at this 360 SPI stuff later and see if I can figure it out. Gotta head out to uni for a few hours.

To me, it looks like it starts at 800 then, as thats where it goes from null (ff) to hex again.

[MetalPhreak]

I've got PICFLASH.hex and PicXBoot_12.hex

PICFLASH.hex is all FF until 0x0400.

When you say 800, do you mean 0x0800 in WinPic?