Nos, működik!
Természetesen mint mindig, én voltam a figyelmetlen. Az alkatrész oldalon a forrasztások nem voltak tökéletesek a kicsi hely miatt, igaz picit néhol most megolvadt a tok alja, de most már működik Meg a hátulján a nyákban is volt egy szakadás, amit egy kis darab rézzel orvosoltam. Nem csoda hogy nem működöt.... De most már jó! Próbáltam 12f629 -est is ami 8 lábú, azt is tökéletesen olvasta!

Köszönöm szépen a segítségedet! HA itt lehetne, most adnék neked 50 pontot, az tuti!

Ezt a kétoldalas adaptert emmzolee tervezte, fent vannak a fórumon valahol a tervek, de ide is berakom, hogyha szeretnéd megcsinálni.
Itt is köszönöm emmzoleenak a segítséget!

Köszi, meg van nekem is. Emmzolee-tól megkaptam a lay fájlt.
Örülök, hogy sikerült megtalálni a hibát.

Akkor jó, ha megvan

Az a kérdésem lenne, hogyha 12f629-et akarok programozni, akkor át kell valamit állítani a programban?

Melyik programban?
PICKit2 kezelő programjában, ha automatikus a felismertetés, akkor nem.

Igen, a kezelőprogramban. Csak azért mert ennél í típusnál mindig azt írja hogy Invaild value 0000
Van egy üres 629-esem és egy ami fel van programozva (még nem általam). Az írottat tökéletesen beolvassa, hogy mi van benne, (igaz ekkor is írja az invalid value-t)
De a másikat ha törlöm, törli sikeresen, és mikor bele akarok írni, beleírja, kiír mindent hogy sikerült, viszont mikor kiolvasom belőle csak 0-ák vannak benne. És ilyenkor például 16f628-at sem programoz, de egy reboot után már a 16f628 at tökéletes írja és programozza. Mi lehet a probléma?

(Írásnál természetesen 5 V van beállítva)

És boldog Karácsonyt

A képen csak a leggyanúsabbat nem veszed észre: "All protect"...

Abban a hex -ben, amit beleprogramoztál, a kódvédelem be van kapcsolva. A programozási adatlap azt írja, beolvasott kódvédelemmel minden memória területről (kivéve az Id szabak alsó byte-ja és a config szó) 0 olvasható ki. Tehát az összes program memória szó értéke 0. A legutolsó memória szóban egy kalibrációs adtnak kell lenni, egy retlw utasítás adatában. Most ez az adat 0, azaz egy nop nem retlw. Ezért van az üzenet "Osccal - Invalid value".

A programozás menete: Teljes törlés, a program és az adatmemória, Id szavak felprogramozása, ellenőrzése, majd a legutolsó lépéskent a config szó / szavak programozása - ezzel aktivizálódik a kódvédelem, a config szavak ellenőrzése. Az programozás ellenőrzése tehát sikeres, még akkor is, ha a kódvédelem aktivizálva van a hex állományban. A további ellenőrzések már 0 -t olvasnak ki...

Filozófiai kérdés: Ha egy kód hex állománya nyilvános oldalról letölthető, mi értelme van a kódvédelmet aktivizálni benne? Ha a hex állományt megnyitod egy szövegszerkesztővel és a config szó értékét átírod a programozás előtt, a módosított hex -et programozaod be, a védelem máris ki lesz kapcsolva.

Boldog Karácsonyt Mindenkinek !

Biztos ez lehet a baj? Mert amikor törlöm, és mondjuk bele akarom írni az ürességet, akkor azok után is csak a 0-ák maradnak.
Meg a program amit bele akarok írni az innen az oldalról való, vicsys dobókocka programja, abban csak nincs ilyen védelem. Nem tudom, hogy akkor mi más okozhatja?

A 12f -nél az osccal érték (ha a szám piros) nem helyes
én ezt úgy "kerültem" meg hogy egy másik picet betéve
a osccal értéket megnézve a "hibás" picnél átírtam az értéket (a beállításoknál) Ha jól emlékszem nálam 34ff-vagy 54 ff lett a helyes érték . Egy ilyen értékkel való beégetés után már működőképes a látszólag hibás pic .
Ja és ahogy HP41 pc írta a kódvédelem ha be van kapcsolva akár a hex-re való fordítás előtt , akár a pickit
programban , akkor § fog kiolvasni beégetés után de ez nem zavarja a pic működését ,csak a készülék "klónozását "akadályozza .... nehezíti meg .

SziaÍ!

Az említett hex -ban nincs bekapcsolva a kódvédelem, viszont tartalmazza az OSCCAL regiszter feltöltését (call 0x3FF). Addig kell gyötörni a programozást, amíg hiba nélkül le nem fut. Ha a törlés után sem sikerül a programozás, akkor valami el van kötve, vezetékszakadás van. Minden kiolvasott érték 0.

OSCCAL: A program a hex állomány importálásánál kiolvassa (megpróbálja kiolvasni) a programozandó kontrollerból az OSCCAL kompenzációt tartalmazó memóriaszót, nem a hex -ből tölti be. Ha ilyen kontrollert programozunk, a betöltés előtt kell csatlakoztatni és felismertetni vagy kiválasztani a típust.

A PICKit2 programból egy kódvédett kontroller törlése után ki kell lépni és újra kell indítani. Az "érzékenyebb" kontrollereket érdemes e lépések előtt lecsatlakoztatni.

@kaqkk: az a 0x54FF tulajdonképen 0x14FF, mivel a 14. és 15. bit (0 -val kezdve a számolást) nincs kiépítve a program memóriában...

Köszönöm szépen a segítséget!
Szóval ha megnyitom az adott hex-et, hol találom meg benne ezt amit át kell írni hogy működjön? Meg van határozva, hogy pontosan hol található? Bocsi az értetlenkedésért, de ehhez végképp nem értek

Azt hiszem, ebben az esetben a legegyszerűbb az lenne, ha nem is törődnénk az OSCCAL kalibrálásával. Egy dobókocka esetén ez megengedhető.
Használd a mellékelt hex -et és felejtsd el az OSCCAL -t (de csak ebben a projectben).

Értem, köszönöm szépen!

Amúgy gondolom, csak véletlenül írtad a nevét 16f629 nek a 12 helyett.

Köszönöm még egyszer!

Valószínűleg, de csak a hex állomány nevében...

Szevasztok!
Szilva féle Pickit2 klónt építettem meg. Sikeresen kiolvastam vele egy 16f877-et, ICSP-n keresztül. HEX-ben elvileg azt irta ki, aminek a tokban kellet lennie. Ezután előszedtem MPLAB-ból az eredeti HEX filet, és ujrairtam vele a tokot. Innen kezdve jöttek a bajok.
A PICKIT2-be beinportált HEX adatok nem azok, mint amit az MPLAB WINDOW/Program Memori menüjében találok.
Az MPLAB-ban 16 bites /PL. 2A8b az 1-es cimen/.
A PICKIT2-ben ezzel szemben F0-át találok beinportálás után. Természetesen a program nem is megy.
Mi lehet ez a gond? Esetleg a pickit2-be beolvasás előtt valami konvertálást kell lefuttatni a HEX file-on?

Töltsd fel a hex állományt! Elvileg nem kell konvertálni az állományt.

Egy újraindítás megszüntette a hibát! Viszont ua. progi a régi égetővel beírva elindul, PICKIT2-vel beirva viszont nem. PICKIT2 tesztjénél csak 24khz-es jelet mértem 30 khz helyett. Ez okozhat-e ilyen hibát?

A PICKit2 kezelő programjában a Troubleshoot menüben a Vdd és a Vpp feszültségek jók? Voltmérővel is ellenőrizd le. Egyes Szilva féle klónokba hibásan IRFZ34 került az IRF9Z34 helyére. Ebben milyen típus van?

IRF9Z34 került beépitésre. A feszültségek jók. Az MCLR off és on állásában ugyan az a 0 feszültséget mérem. MCLR on állásban 0 ohm a GND-hez, off állásban szakadás.

Ezek rendben vannak. Van 100 nF a 16F877 táp lábai között mindkét oldalon? Mind a két pár Vdd, Vss be van kötve programozáskor?

Tegyél fel képet a kiolvasott eredményekról és a hex állományt is töltsd fel.

Az ünnepek folyamán most jutottam el oda hogy így is kipróbáljam, és így sem működik
Építettem egy nagyon egyszerű másik adaptert is, azzal sem jó.
Végképp tanácstalan vagyok hogy mi okozhatja a bajt.

Sziasztok!
Pic12F683-at szerettem volna felprogramozni Pickit2-vel.
A 2.1-es verzió nem ismerte ezért frissítettem most 2.61 van. A probléma pedig a következő OS 2.01 és töltsek le másik verziót, de mikor megpróbálom a következő hibaüzenetet kapom Downloading Failed. Tudna valaki segíteni, hogyan tudom megoldani ezt a problémát?

A firmware -ből a 2.32 kellene. A PICKit2 V2.61 ezt szeretné letölteni. Ha van másik programozó, akkor azzal is fel lehetne programozni.

Nincsen sajnos másik programozó nélkül nem tudom megoldani?

Azt írod, hogy a firmware frissítés hibára fut... Ha a PICKit2 gombját lenyomva csatlakoztatod az USB -hez, akkor a bootloader indul el benne.

A busy led-nek kéne villogni, de nem teszi.

Jobb ötletem nincs, mint valahol egy programozóval beprogramozni az újabb firmware-t.

Szerinted mennyi esélyem van rá, hogy ezzel fel tudom programozni?

Ha új a 18F2550, akkor igen - gyárilag az LVP engedélyezett, de ha már egyszer fel volt programozva a firmware -rel, akkor nem - benne az LVP le van tiltva.