[SOLVED] Project to replace CY7C64613 in the ICD2

icl7621 replace

I am not stuck with it.

3d pcb

Oh.. Ok, thought you said it was waiting for some hardware. I was wondering where in the firmware that was.

mplab icd2 header pin6

I find it strange that the reset-vector and isr-high vector are at 0x00C0 & 0x00C8 instead of 0x0000 an 0x0008.

Click to expand...

Brem how do you disassemble boot bin?

pic 18f4550

Brem said:

I used the hex files from earlier in this thread.

Click to expand...

Import them in MPLAB, View Program Memory, click Symbolic..

driver usb rs232 + redfox

, Okay how do you make hex from the bin?

Added after 5 minutes:

Iam just curious how you see the vectors at c0/c8.

disassembler with icd2

narccizzo said:

These are the two files bin converted into hex, i've opened the bin files with the
ic-prog software then i save the files in hex format, if you take a look to these files you can see a readable string "Microchip Tecnology ICD2 USB Device icd2 usb" in the address 0x0ee7 for the boot.hex file and the same string in the 0x0b8e for the
os.hex file, i dont have a disassembler to explore in more detail this files but something tells me that these two files are all that we need.

BR
Narccizzo

Click to expand...

I downloaded those hex files

icd 2 firmware client loader difference

In boot bin gotos are at 0x40

icd2 clone source code

I started with boot.bin now instead off the downloaded hex file. Indeed at 0x40, but the GOTO's there point to empty space. GOTO 0x1fdc should be GOTO 0x1f5c which is the mcc18 _startup.

icd2 cy

Okay, theres some help:

MPLAB downloads boot bin starting from 0x80, and os bin to 0x2800. If you do it with and empty chip the reset / isr vectors are points to nowhere. So you must set gotos at 0x0000.

mplab icd 2 validate device id

When I convert boot.bin to hex and import it in MPLAB, all adresses seem to be messed up. The program doesn't make sence.

I downloaded a hex\ICD24550.hex in a hex.zip file from this forum. I cannot find it anymore now.

That one contains the bootloader and a OS at 0x2800. All addresses are ok but the reset vector is at 0xC0. I can follow the program flow with MPLAB SIM and it does make sence.

programar delay mplab dspic 30f

As zedman says the if you offset the boot.hex file by 0x80 bytes forward, the dissasembled file turns to be simulated correctly, but assuming that is correct what is the real problem? thank for your answer .

30f3014 .lkr

do you guys think that if we can mix both files in one and program the uC its the thing solved?
i'd like to know WHAT THE REAL PROBLEM IS i really wanna help.

tl497 icd2

Ah, that's better, thanks. No problem, explains the reset vector at 0xc0..

How do you offset it 0x80 bytes forwards?

12f683 circuit

i have a xeltek universal progremmer it opens various file formats and allows a little more things to do with it.

Added after 1 minutes:

I've opened in binary format and save it in intel format after the little modification of course

download mplab7.40

I use bin2hex supplied with Keil with -O128.
MPLAB sends boot image to 0x80.

Added after 1 minutes:

U can dl it from keil site it's free.

icdwarn0052

Hi zedman, I want to help, but if you already done with the bin files, what's the problem do you have?

rj11 pcb protel dxp

Ok,

as we know MPLAB sends boot to 0x80 and OS to 0x2800. We should reconstruct the initial jumps at 0x0000. So if you set reset vector to 0xc0 and ints to 0xc8 than it's ok. It enumerates correctly, and MPLAB tries to connect to it. When it sees it's version is 0x0010 than it tries to send OS.bin onto it. If you check it in USBMon, first it sends where it wanna write, reads the progmem, writes progmem, reads it back again to check the write was ok. After this it drops itself off from the USB bus, and connects back. At this point it issues a getversion command and the device replies with:


Here it says: Unable to Reprogram OS.
If you look closer, the bytes 2-5 represents the version number. If Iam correct than it seems the first one is: 0x0001 (this may or may not the OS version) and the second word is 0x0180.
If we sent version 0x0100 than why 0x0001 appears?

Also it's interesting that if you set int vectors to 0xc8 than what about the OS's int?
There is no check in the boot code which int to call. And no space at 0x08 to write an if...
Currently OS runs using boot's int handler.

I figured out the port connections too, but they are for later use. 8)

These are the problems, now HELP!

eagle file legalizer

Finally I built a small board with a 18f4550 and I did some research at the USB FS kit from microchip.
I downloaded the firmware that cames with the kit and it worked (I still have a problem)

The USB FS has a bootloader too. It is activated by pressing S2 while resetting (RB4 to GND). The board is recognized as another device and accepts the downloading of .hex files. There is a PC program that handles the download.

There are some similarities with previous post in that the reset and interrupt vectors are offset by 800h and 808h. That is this bootloader occupies the normal vectors and rewires them.
May be the two bootloaders share more similarities. Ill try to compare both.

The problem that I have now is:
Bootloader seems to correctly write the demo firmware but when the demo runs it is briefly recognized as another USB device (which is correct ) and then dissapears.
Any ideas?

Today Im going try downloading the .hex posted before to see if it enumerates as an ICD2.

picburner usb

hi albert!
I had that problem before and i correc it, the problem is in the an1 (pin3) its because it is looking for the usb power sense you must comment out the two definitions USE_SELF_POWER_SENSE_IO and USE_USB_BUS_SENSE_IO in the USBCFG.H for each project.

thanks for your reply zedman, i'll do my best to help.

see ya

icd2 error icd0031

Nice pigs tough

Added after 4 minutes:

Brem, any idea for the OS int vector?