PIC Bootloader/ICSP hacking...

Hej gruppe.

Jeg sidder med et problem på jobbet, og ville lige høre her om nogen har en idé til hvordan at jeg løser det.

Jeg sidder i RMA afdeling, og står for reparation af nogle avancerede batteriopladere. Laderne er software baserede, og software løsningen i dem består af 2 dele - en bootloader og et stykke firmware.

Firmwaren i laderen er noget kunden selv kan opgradere via Serial eller USB (same shit, bare en indbygget USB kreds i nogle modeller)

Der sidder også en standard Microchip ISCP header på motherboardet, der passer direkte i en Pickit2 f.eks.

Processoren i produktet er en PIC24FJ64

Når kunden lægger en ny firmware ind i laderen, og den er markant nyere end den gamle, skal bootloaderen også opdateres, og her sker det af og til at noget går galt, og man ender op med en ret død lader der ikke kan boote.

Firmware re-flash er af gode grunde ikke muligt, da bootloaderen der lytter via Serial, ikke virker.

På værkstedet har vi nogle "brikker" der flasher firmwaren om. Disse består af et lille print med en ATMEGA128 processor, lidt passive komponenter, et par lysdioder osv.

Den sættes i laderen og den flasher en bootloader ned. Kildefilen til kredsen udleveres ikke. Egentlig nok et forsøg på at forhindre piratkopiering af produktet.

Vi har kun én brik for hver model af produktet, og går den i stykker er vi mildest talt på skideren - så en kopi af den, eller bare muligheden for at smide en Pickit2 i og flashe fra computeren ville være en super løsning.

Jeg kan ikke udlæse koden i laderen via Pickit2 da code protect er slået til, så alt læses som "00"

Kan jeg stole på de configuration bits som Pickit2 kan udlæse fra kredsen, selvom at code protect er slået til? I så fald ser jeg en mulig løsning. Inden i firmware flasher programmet, i selve exe filen ligger der også en opdateret bootloader - hvis jeg åbner exe filen i en hex editor står der højt og tydeligt BOOTLOADER og så en stor blok af data bagefter.

Hvis ellers at config bits er korrekt, burde jeg kunne flashe denne blok data ned med Pickit2, og så starte laderen op, og flashe selve firmwaren via Seriel porten....

Jeg har spekuleret over en anden mulighed. Reverse ICSP - er der nogen der har en idé om det kan lade sig gøre at "snuse" til ICSP programmeringen med en logic analyser/datalogger og så gendanne hex data den sender til kredsen ?

Nå, det var en lang smøre, jeg håber at det ikke var for stor en mundfuld at tygge sig igennem ;-)

Iøvrigt, vi har konfronteret producenten af laderen med vores projekt, og de har ikke noget problem med at vi roder med det, det er trods alt ladere uden for garanti vi eksperimenterer med p.t. - så ingen grund til at himle op om at der nok er en grund til at de ikke udleverer hexkoden osv - de har simpelthen ingen interesse i det, det er langt nemmere for dem at sende os en "brik" der programmerer produktet. Det er nemt og (næsten) idiotsikkert.

Det mest frustrende er næsten, at aller nyeste model i programmet, den har vi ikke engang en brik til, så når kunden får fejlflashet den, så er den død - ihvertfald indtil at vi får en brik der passer til den.....

Hvis du har nogen ideer eller indspark, så råb op!

// Per.

Reply to
Per Jensen
Loading thread data ...

Per Jensen skriver:

Kig på kommunikationen mellem brik og lader.

Klaus

--
 Modelbane Europas hjemmeside: http://www.modelbaneeuropa.dk
        Min egen hjemmeside: http://www.moppe.dk
 Click to see the full signature
Reply to
Klaus D. Mikkelsen

Det var også planen.

Jeg må læse lidt op på hvordan at ICSP er implementeret, og så sætte en logic analyser på brikken og sniffe alt hvad der foregår.

Jeg har ellers forsøgt at sniffe den serielle kommunikation når der flashes en bootloader ind via seriel.

Problemet er, at det jeg får frem i terminalprogrammet ikke ligner strukturerede data (en hexfil f.eks.) så dér kommer jeg ikke videre.

Kunne man evt. tænke sig at bruge f.eks. hyperterminal til at modtage en fil på serielporten, og således logge alle dataene ned i en fil, så giver det måske mening det der sendes... ?

Jeg sniffer serielporten vha. 2 USB/seriel adaptorer koblet som et Y (kun én dataretning selvf.)

// Per.

Reply to
Per Jensen

Hej

Hvis du har brug for at "splitte" seriel porte for at sniffe / logge så er virtuelle porte ganske praktiske :-)

formatting link

Wiljan

Reply to
Wiljan

Henvend dig til producenten !

/Kjeld

Reply to
Kjeld

De er tunge at danse med, derfor at vi selv må finde en løsning...

// Per.

Reply to
Per Jensen

Tak for tips og ideer.

Jeg har faktisk løst problemet på en lidt opfindsom måde.

Den programmer "brik" vi har, den er f.eks. 30 sekunder om at flashe target PIC'en - og så læste jeg mig til at ICSP programmeringen foregår således at PIC'en først slettes, så programmeres data, og til sidst protection bits.

Jeg fandt ud af ved at slukke for strømmen efter 25 sekunder, at det virkede, og den ikke havde flashet security bits. Så formodentlig flasher den data, laver en verify og så låser den PIC'en.

Den nyeste lader vi har i programmet, den har jeg ingen "brik" til. Jeg havde en jeg alligevel havde kasseret da powertrinet var sprunget luften, så jeg tog chancen og flashede den med brikken til modellen mindre - det virker, og laderen bipper - det indikerer at bootloaderen leder efter et program den kan eksekvere.

PC applikationen flasher herefter softwaren beregnet til laderen uden et problem, men efter en genstart bipper laderen stadig.

Tilsyneladende, så er start-adresen på programmet ikke ens i laderene, så jeg skal bare have hitte ud af den, rette den i Hex filen og så skulle det virke.

// Per.

Reply to
Per Jensen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.