PIC 16F628A - problem z programowaniem, losowe dane w pamięci flash

Witam

Chcę zaprogramować 16F628A. Sto razy wszystkie połączenia sprawdzałem. Sprawdzałem też sygnały częstotliwość lini zegarowej (1.8kHz) itp.

Procesor kasuje się dopiero za którymś podejściem i przechodzi test czystości. Przy programowaniu jest problem wgrywa randomowe śmieci w kilku miejscach pamięci flash i tyle.

Mój programator to Oshon Parallel Port PIC Programmer i też programuję za pomocą dedykowanego softu (programator wykonałem wg strony radio.dxp.pl).

Napięcie Vdd to 4.98V a Vpp 13.3V. Układ sprawdzony pod kontem zwarć i innych.

Nie pierwszy raz mam takie problemy z zaprogramowaniem ale zawsze za którymś razem się udawało. Dziś zwyczajnie zabrakło mi cierpliwości.

Testowałem opóźnienia od 1ms do 30ms. Najsprawniej kasuje w okolicach 14ms (przy innych wartościach jest to mocno losowe).

mkpl napisał:

Nie pierwszy raz mam takie problemy z zaprogramowaniem ale zawsze za którymś razem się udawało. Dziś zwyczajnie zabrakło mi cierpliwości.

1. Nie prościej byłoby kupić PICkit'a (lub nawet jakiś klon), niż męczyć się z LPT?
2. Nie masz za długich przewodów połączeniowych?

Programator składałem jakieś 5 lat temu. Używam sporadycznie raz na rok ale może chyba warto zainwestować. Chwilowo kombinuję programator USB na PL2303.

Przewody połączeniowe do lpt to około 1m a z samego programatora do procesora 10cm więc myślę, że są ok

Po głębszych testach wyszło, że pamięć eeprom się programuje poprawnie natomiast flash procesora to same 3FFF. Czyli niestety muszę założyć uszkodzenie układu?

Problem rozwiązany. Picowi przeszkadzał kondensator 100n w zasilaniu Vdd. Nie przypuszczałem, że to może mieć taki wpływ...

mkpl napisał:

Nie przypuszczałem, że to może mieć taki wpływ...

Bo to niemożliwe

Przecięcie ścieżki Vdd od procesora i wpięcie się w nią programuje go za każdym razem bezbłednie. Wiec chyba czegoś nie rozumiem.

Czyli masz zwarcie, itp. na PCB lub zasilanie z programatora nie jest w stanie pociągnąć zasilania całej płytki.

Witam . Kondensator to mógłby ci przeszkadzać na pinie MCLRE czyli reset , ale nie na zasilaniu .

Aby PIC wszedł w tryb programowania, musi być podane napiecie VDD oraz na MCLR podane we włwściwej kolejnosci. Cżęść mikrokontrolerów pic wymaga by napiecie VDD narosło w czasie nieco szybszymj niż na MCLR (ok. 100us). Pojemność 100n akurat wystarczy do tego by napiecie VDD narosło nieco później niż na MCLR. Stąd PIC nie chciał wejść w tryb programowania

No i praktyka potwierdza to co kolega rysel dokładnie napisał. Jak się przed tym chronić projektując układ?

Czasami muszę coś zaprojektować z picem a nie lubię elementów przewlekanych więc zostaje programowanie w układzie. Na MCLR daję zawsze diodę a na VDD to chyba tylko rozwiązanie z zworką? Dawanie tam diody zaprzecza temu aby dawać pojemność jak najbliżej układu cyfrowego...

rysel napisał:

Aby PIC wszedł w tryb programowania, musi być podane napiecie VDD oraz na MCLR podane we włwściwej kolejnosci. Cżęść mikrokontrolerów pic wymaga by napiecie VDD narosło w czasie nieco szybszymj niż na MCLR (ok. 100us). Pojemność 100n akurat wystarczy do tego by napiecie VDD narosło nieco później niż na MCLR. Stąd PIC nie chciał wejść w tryb programowania

Poprosimy o źródła tych informacji tym bardziej, że programator steruje MCLR i może zrobić dowolne opóźnienie.

Witam . Kondensatory na zasilaniu nie mają najmniejszego wpływu na proces programowania . Ja stosuję zawsze 100nF jak najbliżej każdej nóżki VDD . Ale już zastosowanie kondensatora na resecie do masy powodowało zakłucenia w procesie programowania . Dlatego stosuje ścieżki tak zwane sierżanty . Po ostatecznym zaprogramowaniu zwieram kroplą cyny .

archanoid napisał:

Ale już zastosowanie kondensatora na resecie do masy powodowało zakłucenia w procesie programowania.

na co Microchip zwraca uwagę w instrukcjach programatorów (np. PICKIT3):



a jak łatwo zauważyć, nie ma tutaj nic na temat zagrożeń ze strony kondensatorów na Vdd.