Днес се сблъсках с един бъг на тоя процесор, дето изкочи доста изненадващо. Ще си споделя опита, дано някой да му е полезен (ех защо на мен нямаше кой да ми го каже).

Значи с тоя процесор имаме устройства, няколко хиляди разпиляни из целия свят. Всички устройства минават сериозно функционално тестване при пройзводството. До днес проблема не беше изкочил, нито при тестовете, нито клиент не е изпищял.

Както знаете PIC18 има стек, който има възможност при препълване или преизпразване да генерира Reset. Тъй като устройствата предполагат висока степен на сигурност, програмата трябва да улавя всякакви "fault" състояния и блокира устройството като единственото което прави след това е да бичи код на грешка. Тъй че всякакви проблеми излизат веднага и се набиват в очи. Та това и стана. Колеги ми обясняват че след последния ъпдейт на фирмуера (писан от мен), някой платки при първоначално подаване на захранването при тест, дават грешка еди кой си номер. Като върнат стария софтуер сичко било ок. А да му.... майката, почвам аз да копам.....

Интересното е че програмата гърми при аутотест процедура (прави си тест при всяко включване). Да ама аз там не съм сменял нищо по кода. Рових, рових и накрая установих че имам ресет заради проблем със стека. Ситуацията се появява едно към 10-20 опита при първоначално пускане. Бре ровене, псуване, що стария код работи, новия не. Там дето се дъни промени нема.

Реших да видя дали нема некоя нова ерата. Е имаше. 80173c.pdf , страница 2, точка 5. Много остроумно обяснение от страна на Микрочип, нищо не можеш разбра. Аз поне схванах следното - "Незнаем кога и защо, ама в много редки ситуации при много малко приложения, първата инструкция след ресет не се изпълнява". Бре мама му стара.

Загледах се в кода генериран он MPLABC18 (повечето компилатори творят същото):


Е сещате се какво става ако прескочиш първата инструкция.

Вкарах един NOP отначало (както любезно съветват Микрочип) и нещата заспаха (засега). Няма повече стек рисети.

Интересното е че бъга наистина се прояви "незнам как и незнам що". Толкова устройства - тестове, чудесии. Предполагам, че като съм правил промени в кода, той е станал по голям и това е провокирало болеста. А даже и болно се появява пак доста рядко - обяснение никакво. Интересното е че на например 10 платки с процесори еднаква ревизия на 6 въобще не ще да избие, на 3 се появи по веднъж на ужасно много пускания, а на една излизаше 1 към 10 пъти. Нея ми пратиха да тормозя та го сгащих. Така поне се надявам

Ако някой го интересува мога да му кажа как да изнасили MPLABC18 да вкара въпросния NOP.

@Цецо, (10х)<<1000!
Какво имаш предвид да изнасилиш компилатора да ти заобикаля ератите? В Хайтек има такава директива на компилатора и винаги си ми е включена, проблема е че уъркараундва само известните бъгове .

Ами микрочипския има за някой бъгове, ама специално за тоя не съм видял, та се наложи да го принудя, стана относително лесно.

е казвай де...

Ами аз лично го "изнасилих" по следния начин.

Startup библиотеките са съответно c018.o, c018i.o и c018z.o в зависимост как искате да ви се инициализират статичните променливи (без инициализация, със инициализация или нулиране). Коя точно се ползва се указва във линкерския файл включен в проекта.

За да вкарате въпросния NOP трябва да се прекомпилират сорсовете. Намират се в mcc18/src/traditional/startup. Там сорсовете съдържат нещо от сорта:



Променяте го на нещо от сорта:



След това в предходната директория (../src/traditional) има фаил makestartup.bat който рекомпилира стартъп кода. Компилира и трите наведнъж имайте го предвид. Освен това изисква валиден път до бинарните файлове на компилатора (аз понеже пътища нямам, редактирах bat файла). След като ги компилира, компилатора вече ще ползва новите object файлове за startup кода с вмъкнатия nop.

Аз лично подходих малко по гъвкаво, предвид това, че неискам nop-а да се ръга във всеки проект за всеки процесор, а само за който аз си реша. Вместо всеки път да слагам и махам нопове и да прекомпилрам, аз си компилирах един c018.o с нопове и го слагам в директорията на проекта. MPLAB по default първо търси необходимите му файлове там. Така ако го има тоя файл ще се компилира с nop. Иначе по старо му.

Тоя подход може да се ползва за всяка от вградените библиотеки в която нещо не ви харесва.

подобно нещо го дъвкахме един път http://www.mcu-bg.com/mcu_site/viewtopic.php?p=30359&highlight=%F0%E5%F1%E5%F2#30359
е, за друг "член" на фамилията, ама явно заболяването е на епидемична основа

Е тя епидемията е ясна. Аз реших да опиша конкретния бъг и борбата с него, белким спестя ядове на някой.

Друг е въпроса колко от хората работят на принципа "ератите са за балъците", "щом работи сега начи е добре" и пр. Ама и това го нищихме.

Хм...
Този проблем го има и при други 18-ки...


Аз наскоро се сблъсках с друг проблем с PIC18F1320. В даташита пише че CCP модула може да се използва да сравнява с таймер 1 или таймер 3.

Да но... Пускам си го с таймер 3 и няма прекъсване по ССР. Таймера брои (проверявах го - прекъсването по препълване работи) всичките конфигурационни байтове са както пише в даташита и... няма compare.

С таймер 1 CCP модула си работи както трябва.

Ами ако го няма в ератата и си сигурен че е бъг, драсни им едно писъмце. Може да спестиш нерви на някой друг...

ваййй, на работата имаме някои неща с 18ки, ще им сложа ноп да съм рахат.

PIC18F4550, когато няма кондензатор на MCLR към маса, а само резистор към +VCC, от 10-тина включвания към USB, на 1-2 се самоизтриват първите 100-тина байта от програмната памет , или пък се записват с някакви глупости. В самия програмен код няма функция която да презаписва програмната памет. Решението е 100nF на MCLR към GND или да се заключи кодът в началото на програмната памет

еее, това вече с кондензатора към маса изби рибата! винаги ли се наблюдава, или на едно устройство ти се е случвало?

От 9 устройства на 9 ! Установих, че не си прави хубав RESET без кондензатора и влиза в режим на програмиране, въпреки, че не би трябвало да влезне в режим на програмиране... Не съм се задълбавал много-много, но след като сложих кондензаторите всичко се оправи. Може би при включване към USB порта на MCLR се генерира някакво напрежение над 5V с много стръмен фронт и професора се лъже и влиза в режим програмиране. За друго не се сещам.

утре ше трия сол на главата на нашия жичкажия. викам му да сложа кондензатор на ресета, оня вика йок - можело да не се ресетне пика. убу, не сложих. е, верно не ми се е програмирал до сега сам, ама кой знае. я кажи, какви вътрешни ресети са ти пуснати - таймера за ресет пуснат ли е? да не става при включването някъв импулс, който да отива чак то над 12 волта...

Това със самопрограмирането е странно, щото даже и да го вкараш в режим на програмиране чрез Vpp пина, пак си трябват определен набор команди по ICSP. Ама то вече нищо не ме учудва.

Хубаво си е да има теми с бъгове. Не само за микрочип.