[SOLVED] Project to replace CY7C64613 in the ICD2

[Brem]

eagle pic24f

The ISR in the bootloader and OS are excactly the same and only service TRM0 interrupts. Using BL int for OS shouldn't be a problem... I think.

Loaded the firmware on a 2550 and it enumerates correctly. Program gets read,written and read again. Then MPLAB sends a "06" command which is probably a reset request. The following "03" command to query firmware version does not get a response... Maybe my USB monitor can not monitor through a disconnect/reconnect.

Oh, and I also needed a "GOTO ISR" on the low-priority int vector (0x0018). It wouldn't enumerate without.

This is what I can make of the bootloaders main(), so far...

    0184:main_0_0:                          
             MOVFF FSR2L, POSTINC1
    0188     MOVFF FSR1L, FSR2L
    018C     MOVF POSTINC1, F, ACCESS
    018E     BCF INTCON2, 0x7, ACCESS
    0190     RCALL GetRB7                   ;returns (RB7==0?1:0)
    0192     MOVWF INDF2, ACCESS
    0194     MOVLB 0
    0196     MOVF 0xf0, W                   ;If [0xF0]<>0 goto bootload
    0198     BNZ 0x1a8
    019A     MOVF INDF2, W                  ;If RB7==0 goto bootload
    019C     BNZ 0x1a8
    019E     RCALL TestIfOSAvail_0_5        ;If ==0 goto bootload
    01A0     IORLW 0
    01A2     BZ 0x1a8
    01A4     GOTO 0x2800                    ;start OS
    01A8:bootload:                          
             CLRF POSTINC1, ACCESS
    01AA     CALL InitTMR0_2_0, 0           
    01AE     MOVF POSTDEC1, F, ACCESS
    01B0     CALL InitIO, 0                 
    01B4     MOVLW 0x14                     ;UCFG =
    01B6     MOVWF UCFG, ACCESS             ;_PUEN|_TRINT|_FS|MODE_PP
    01B8     MOVLB 0
    01BA     CLRF usb_device_state, BANKED  
    01BC     MOVLB 0
    01BE     CLRF usb_state, BANKED         
    01C0     MOVLB 0
    01C2     CLRF usb_active_cfg, BANKED    
    01C4:while1:                            
             BTFSS PORTA, 0x4, ACCESS     ; If RC4==High
    01C6     BRA 0x1cc
    01C8     CALL Hela_RA4IsHigh, 0         ;set RB3, loop forever flashing
         RC1
    01CC     CALL USBCheckBusStatus, 0      
    01D0     CALL USBDriverService_0_1, 0   
    01D4     IORLW 0
    01D6     BZ 0x1ee
    01D8     MOVLW 0x8
    01DA     MOVWF POSTINC1, ACCESS
    01DC     MOVLW 0x40
    01DE     MOVWF POSTINC1, ACCESS
    01E0     MOVLW 0
    01E2     MOVWF POSTINC1, ACCESS
    01E4     CALL ProcessIO_4_0, 0          
    01E8     MOVF POSTDEC1, F, ACCESS
    01EA     MOVF POSTDEC1, F, ACCESS
    01EC     MOVF POSTDEC1, F, ACCESS
    01EE     BRA 0x1c4
    01F0     MOVF POSTDEC1, F, ACCESS
    01F2     MOVF POSTDEC1, F, ACCESS
    01F4     MOVFF INDF1, FSR2L
    01F8     RETURN 0

 

[Zedman]

icd 2 replace

I get the answer I mentoined for the 03 request.

Added after 1 minutes:

Of course I set the low vector too. Dunno why it uses Int priority tough.

Added after 9 minutes:

So RB7 should held low.

 

[Brem]

mplab the parameter is incorrect

RB7 Low to force it to bootload.

Mine always seems to start the bootloader, even if RB7 is high and there is a OS at 0x2800.

 

[Zedman]

esteca55+icd2

PORTA.4 is for separate USB chip control I think. It's tricky how it sets 0xF0, at 0xE0 there are 3 function pointers, and the first function sets 0xF0 to 1. But did not found yet how & where does it call those functions.
More info: MPLAB does not issue any write command to progmem 0x0000. So it has to boot up with the BL and if there is any OS than start it. (as it seems from the code). But if the boot fw should be upgraded user may have to place a jumper to RB7.

Added after 2 minutes:

Sorry RB7 should held high. My fault.

 

[Brem]

cd0042: api: error response

Aha, I see those function ptrs now, that's nice. I wondered why those procs at 0x02B4 etc were never called.



Its the switch-over form BL to OS that doesn't work. Somehow that reg at 0xf0 allways <>0. When I skip that test and force it go go OS the response to '03' is:

>> 03 01 00 ...
<< 03 00 00 00 00 01 92 26

 

[narccizzo]

icd2 固件 icd2_4550_os_0102.bin

Ok guys, what do i have to do to make this thing work up to you already are, I can't even get the recognition of the ICD, the only thing I do its a hex file mixing the boot in the 0x80 and the os in the 0x2800 address with the rst and isr vectors corrected, this thing looks like unrecognised device, please guys help me to not spend time in things that you already have, to work in parallel.

 

[Brem]

mc34064a step-up

This is what I do:

Take your BOOTZ.HEX, change the first lines to:

0000 MOVLB 0
0002 CLRF 0xF0,BANKED
0004 GOTO 0x1fdc
..
0008 GOTO 0x1f9c
..
0018 GOTO 0x1f9c

Keep RB7 High and RA4 Low, you can have a led at RC1.

Now it should start the bootloader first time because it doesn't see a OS at 0x2800. MPLAB will download it and... still gives an error. However the OS is down loaded correctly. Next time it resets it will start the OS. MPLAB will give another error: "Unable to connect to ICD".

Added after 25 minutes:

The bootloader uses low priority TMR0 interrupt, the OS high priority.
Maybe it should be 0x0008 GOTO 0x2808

Added after 24 minutes:

Changed CPU speed to 48 Mhz, now the switchover from bootloader to OS works.

 

[narccizzo]

melabs cannot read the target device id

ok thanks, but what about the config word and the crystal freq?
the congif word that rkodaira sais:
CONFIG1: 0E24
CONFIG2: 1E38
CONFIG3: 0100
CONFIG4: 0081
CONFIG5: C00F
CONFIG6: B0E8
CONFIG7: 400F

how can the 30000b address be 0xb0 if that isn't a possible combination, i suppose that its a 20MHz crystal freq, right?

 

[Brem]

potyo2 pic32

I used config settings off another USB project on the same hardware. 20Mhz crystal with CPU at 48 Mhz.

config PLLDIV 	= 5	
config USBDIV 	= 2	
config FOSC 	= HSPLL_HS
config CPUDIV 	= OSC1_PLL2
config VREGEN 	= ON

For the rest about everything off, no wdt, portb digital, MCLR enabled, no protections

 

[rkodaira]

brown black black silver 10uh

Unless the crystal frequency is 4MHz:

With 0xB0 (1011 0000) at CONFIG1L, we have the following configuration bits:

bits 7 (1) and 6 (0) not used

bit 5 USBDIV (1 = USB clock comes from 96MHz PLL divided by 2 = 48MHz)

bits 4 and 3 (10 = XTPLL divided by 4 to derive system clock; 96/4 = 24MHz)

bits 2 1 and 0 (000 = no prescale, input is 4MHz).

With a 4 MHz crystal at the main oscillator it feeds directly the XTPLL that generates the 96MHz, which is divided by 2 to obtain the 48MHz for the USB clock. Besides that the system runs at 96 / 4 = 24MHz. No need for 20MHz crystal here.

 

[Zedman]

pic24f samples

I'm using 4550 with 20MHz crystal and

config:

0x24
0x0F
0x39
0x81
0x80
0x0F
0xC0
0x0F
0xE0
0x0F
0x40

it should use HSPLL (48 MHz) indeed.

Added after 1 hours 6 minutes:

I corrected the int vectors (high=OS/low=BL), but the thing is the same:

MPLAB issues:

03 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00

and gets:

Get 0x8 bytes from the device:
 03 00 01 00 80 01 00 00

and here it says OS download failed. I traced icd2.dll, it checks the version number, tomorrow i'll do some more IDA on icd2.dll.

 

[Brem]

icd2 unknown device

I think your OS never gets started because that reg at 0xf0 has never been initialised. Try to add a CLRF 0xf0 before the GOTO 0x1fdc. OS should reply with

03 00 00 00 00 01 92 26

You could change the BCF at 0x0F72 to a BSF. That way RC1 is high when the bootloader is running, low for the OS.

 

[Gobol]

inchworm+ target vpp reads 3 volts

Zedman & Brem : Does your prototypes of 4550-icd2 has 877 mounted and connected via PSP to 4550 ? Or you are only trying to communicate with bootloader-burned 4550 ?
I'm askin, because I will do some research on this topic too...

 

[Brem]

inchworm+ vpp low

I have neither 4550 nor 877, so PSP is not an option for me (using a 2550). I'm trying to let it load my own OS. Also my hardware needs CCP1 for a chargepump.

 

[Zedman]

pic32 starter kit firmware 18lf4550

Yes, I have connected a 877, so here are the connections I figured out:

on 4550 - 877:

RB4 -> RE2 (~CS)
RE1 -> RE0 (~RD)
RE0 -> RE1 (~WR)
PORTD <-> PORTD (data)
RC0 <- RB0 (=0 if 877 is BUSY)

but nothing works yet.

Added after 27 seconds:

Brem, it does not use PSP.

 

[Gobol]

pickit2 pic32

Brem : So, you want to write your own universal ICD2 OS that will cope with all PICs ?

 

[Brem]

mcdrv48f.dll,mcinstlsprop

Ok, no PSP, but it does use PORTD. The 2550 doesn't have that.

Gobol: no not all, just the PICs I own and play with..

 

[Zedman]

pickit2 pic32 vpp

Sorry Brem, the PSP thing was aimed to Gobol. Tried to clear the 0xF0, now it starts, but can't talk to 877, it just reads back what it sends.

Added after 2 hours 15 minutes:

Took a small step forward:

Connecting to MPLAB ICD 2
...Connected
ICDWarn0054:  MPLAB IDE has lost communications with the MPLAB ICD 2.  Would you like to attempt to reconnect? (here I said no)
ICD0286: Unable to communicate with ICD
MPLAB ICD 2 Ready

Brem, now 877 answers 01 01 01 03 for the 0x5A request.
after that (all sent back on EP2):

0x55 -> 0x03
0x55 -> 0x75
3C 30 38 30 31 43 39 3E -> 75
3C 30 38 30 31 43 39 3E (<0801C9>) -> no answer
3C 30 38 30 37 43 46 3E (<0807CF>) -> no answer
and here it stucks

Any idea?

 

[Brem]

pic24fj32 read

No OS yet on the 877?

0x55->0x75 is handled by the 877 bootloader, <0801C9> should be handled by 877 OS.

 

[Zedman]

mplab invalid target 0x58

Sure there is no OS in it. But after the sequence I mentoined it wont answer on EP2 when I try to dl OS to 877 with MPLAB.
I noticed that 64 bytes of data is written to 0x4E00 meanwhile Iam trying to connect. And there is a routine which check for OS existence in the 4550 which is some kinda checksum on the memory from 2800-7FFF and if there is that 64 byte block than this function returns OS not exist and falls back to the BL.
I should debug it out.