Nazdar borci.
Už se Vám někdy povedlo najít nespecifikovaný BUG v ERRATA v nějakém procu od Microchipu?
Já na to mám asi docela štěstí. Bug s TMR2 jsem lovil asi 2 měsíce, ted druhý bug naštěstí jen 2 dny, ale stálo mě to opravdu hodně energie a nějaké spálené tranzistory.
dsPIC33FJ64MC204 - revize A5
Při zápisu do předvolby do PR2 občas nenastane přerušení od TMR2.
TMR1, nastaveno přerušení na 10ms, při tom se zapsala předvolba do PR2 aby se čas TMR2 mohl měnit od cca 100us po 1ms. Pokud došlo k zápisu do předvolby v nevhodný okamžik, netuším přesně kdy, tak se přerušení od TMR2 zaseklo až do dalšího zápisu do PR2
Řešení: Zapisovat předvolbu až z rutiny TMR2, tzn. nastane přerušení od TMR2 a až po přerušení se zapíše PR2
dsPIC33EP64GS504 - revize C0
PWM modul 1 a 2
Oba PWM nastaveny Center aligned, timebase PTPER, Complementar output, PHASEx = 0, SPHASEx = 0. PTPER = 34000 (cca 28kHz na výstupu), 70MIPS
Teď co to dělá za peklo - pokud PDC1 = PDC2, tak jsou výstupní pulzy opravdu krásně zarovnaný na střed a nemají mezi sebou žádný fázový posun. Deadtime nemá na funkci vliv, dělá to při jakémkoli deadtime. Ale jak nastane situace že PDC1 a PDC2 si nejsou rovny, tak nastane mezi moduly fázový posun. Cca o deadtime.
Podobná věc je popsána v ERRATA, ale ta chyba má být jen pro Push-Pull mode, je tam na to workaround, který na toto nefunguje.
Doplnilbych k tomu aji nějaký průběhy, ale dneska na to už nemám sílu.
Na to že to má být defakto vlajková loď Microchipu pro jakékoli výkonové aplikace, tak mi to přijde dost zabugovaný a moc ty chyby nemizí u nových revizí . 
To jsou hodnotné informace, a dovolím si za všechny - díky za ně. Třeba někomu pomůžou.
Doplním k tématu něco sice souvisejícího, ovšem trochu jinak než by se dalo čekat: Začal jsem pomalu, ale jistě realizovat to, co tu radili Electrin s Radiusem. Než to rozjedu a doladím pořádně tak zatím přežívám na PK2 (ačkoliv mám i novější programátor) a starších microchipích broucích, ovšem obecně už mě s Microchipem už tak nějak došla trpělivost.
Důvodem je právě to co píšeš, protože to není jen pár chyb na pár nových broucích, ale „novodobý standard” snad u všech jejich brouků (třeba takový 18F26K22 byl pro mě vyloženě zklamáním v tomto ohledu, ačkoliv se “papírově” jevil jako ideál); navíc mě už ani kdovíjak nebaví jejich polofunkční pracovní prostředí a téměř nefunkční soft k programovacím nástrojům (PK3 mám na mysli). Zkrátka opruz obecně.
Je věčná škoda že to takhle pomalu pohřbívají, je to unikátní architektura a bylo to nadějné, nicméně člověk má jen jedny nervy a času taky není nekonečno.
Za málo, ono toho bylo víc, ale už si to ani nepamatuju.
PIC18F26K22 - na něm mám několik konstrukcí a nenašel jsem problém co vím. Celkově osazeno několik tisíc kusů, spíš teda levnější varianta 23K22
PICkit3 a MPLAB IPE používám bez problémů defakto denně - PIC12F1822, PIC18F13K22, PIC18F2xK22, PIC24FJ64GA306, dsPIC33FJ16GS504, dsPIC33FJ64MC204 a poslední dsPIC33EP64GS504 (výkonově absolutní TOP pro mě)
Ten poslední dsPIC mě donutil přejít na MPLAB X, po tom co jsem zvětšil ram ze 4GB na 6GB je to o něco lepší a hlavně jak je to nainstalovaný na SSD. Ale stále to 10 minut hrabe do disku po otevření projektu pod záminkou “Parsing project” Zlatý MPLAB 8.92
Jo ještě jsem si vzpomněl na megazákeřnou chybu anebo super vychytávku, kterou jsem lovil taky hooodně dlouho:
PIC24FJ64GA306 - revize nevím, myslím že všechny.
V jedné konstrukci jsem dost nešťastně vyřešil referenci pro A/D převodník. AVDD napájím pomocí MCP1525. Problém je, že po naběhnutí napájecího napětí na VCC PIC a na VCC té reference trvá referenci 6ms než dá napětí na výstup. Tohle způsobí megavelký zásek PIC, že ani nekomunikuje za žádných okolností s PK3 ani ICD3, totální mrtvola. MCLR nepomůže, jedině odpojit napětí od PIC a přivést VCC a AVDD zaráz anebo pod 1 ms.
Pořešil jsem to 100uF elytem mezi VIN a VOUT reference aby nabití toho elytu způsobilo strmý nárůst napětí na AVCC.