RE: defektní PIC16F18015

Jindrich Fucik FULDA na seznam.cz
Středa Duben 3 13:57:16 CEST 2024 

Trochu si myslím, že přeložením to ztratí kouzlo. Spíš pošlu celý projekt, nebo ukázku, jak jej mám vytvořený.

EQU je direktiva EQUivalent. Tedy jenom říká, že když napíšu TRISA_INI, tak jsem vlastně chtěl napsat 00000000B. Jak tuto hodnotu použiji už se neřeší. Pokud jí přiřadím jako literál, tak zůstane literálem:
movlw TRISA_INI ; tohle přiřadí do W literál 00000000B
movwf TRISA ; a tohle pak hodnotu z W do TRISA

Ano, pokud bych použil TRISA_INI jako referenci, byl by to ukazatel do paměti na pozici 0, ale tak to nedělám.

V dokumentu "MPLAB_XC8_PIC_Assembler_Users_Guide_50002974.pdf" je popis v kapitole 4.9.16. Případně poznámka v kapitole 4.6.4.

Ono jde o to, že tenhle defekt pozoruji právě na té sadě deseti procesorů co mám doma. Na jiném typu se to neděje a tak mi trvalo strašnou dobu to pochopit. Je to něco, co používám často a pořád to funguje, tak to beru jako fakt. Čili zajímavé by bylo to vyzkoušet na stejném procesoru z jiné série. Třeba na PIC16F15313 žádný problém není.

---------- Původní e-mail ----------
Od: Miroslav Draxal <evik na volny.cz>
Komu: 'HW-news' <hw-list na list.hw.cz>
Datum: 3. 4. 2024 11:32:56
Předmět: RE: defektní PIC16F18015

Vytvořte úplně nový projekt na C:\
Hoďte tam ten váš kód a zkompilujte. Pokud to projede, tak to sem hoďte. Bude to mít pár kB. 
Tím eliminujeme nesrovnalosti v nastavení projektu.
 
Za moment budu mít čas se na to podívat a třeba to nahrát i do jiného PICu.
ALE!
Všiml jsem si včera letmo, možná že to má nějaký důvod.
Pokud používáte 
TRISA_INI equ 00000000B;
Tak TRISA_INI nemá hodnotu 0x00, ale přiřazujete TRISA_INI  registr v nulté stránce paměti RAM s adresou 0x00
 
Takže podle mě 
#define TRISA_INI  00000000B
Nebo 
TRISA_INI  set d'0'
 
ALE: pokud něco dělám v asm, tak jenom opravuji staré projekty z doby do 2010 a to ještě v MPLAB8.92, možná se pro mplabx něco změnilo.
Míra
From: Hw-list [mailto:hw-list-bounces na list.hw.cz] On Behalf Of Jindrich Fucik
Sent: Wednesday, April 3, 2024 10:11 AM
To: HW-news
Subject: RE: defektní PIC16F18015


 
používám mplabx verze tuším 6.5. V zásadě jsem nic neměnil proti defaultu, vlastně jen tu definici vektorů, která je napsaná v prvním řádku kódu.

Co píše pic-as? 

Vlastné - není problém se jménem souboru, které obsahuje mezery a mínusko? Pravda je, že v editoru to mám s romantickým náznem default.s

 

---------- Původní e-mail ----------
Od: Miroslav Draxal <evik na volny.cz>
Komu: 'HW-news' <hw-list na list.hw.cz>
Datum: 2. 4. 2024 21:16:30
Předmět: RE: defektní PIC16F18015


Nakopněte mě. V jakém editoru to píšete (MPLABx to defect - config.s otevře) ale nedokážu to asemblovat (pic-as to nějak nebere)
Míra

-----Original Message-----
From: Hw-list [mailto:hw-list-bounces na list.hw.cz] On Behalf Of Jindrich Fucik
Sent: Tuesday, April 2, 2024 7:11 PM
To: hw-list na list.hw.cz
Subject: Re: defektní PIC16F18015

Bezva, tak jsem to dotáhl téměř k dokonalosti. Vytvořil jsem kód, který 
je složený převážně z instrukcí "nop" a "#ifdef". Na začátku jsou pak 
dva #define, které umožňují si vybrat, co se stane. Možnosti jsou:
1) program funguje jak má.
2) program zamrzne zhruba na 2ms před každým přerušením
3) program zamrzne úplně

Ke stažení jako zip i se záznamem z analyzátoru:
https://www.uschovna.cz/zasilka/OX4JT76LTH6MCBD2-XU7

Jdu se zeptat na support, co s tím.

Dne 01.04.2024 v 22:02 Jindrich Fucik napsal(a):
> Bezva, tohle funguje jak by se dalo očekávat.
> Jdu hledat, co tohle udělá jinak než já.
> V příloze pro porovnání výstup ze Saleae. Je hodně podobný tomu ze 
> simulátoru (ne zcela stejný).
> 
> Jdu hledat, co je tady nastaveno jinak.
> 
> 
> Dne 01.04.2024 v 21:08 Miroslav Draxal napsal(a):
>> Zkuste tohle, ověřeno v MPLABx simulátoru a výstup taktéž MPLABx Logic 
>> Analyzer (viz příloha).
>>
>> #include <xc.h>
>> #include <pic16f18015.h>
>>
>> // Configuration bits: selected in the GUI
>>
>> //CONFIG1
>> #pragma config FEXTOSC = ECH // External Oscillator Selection 
>> bits->EC (external clock) above 16 MHz
>> #pragma config RSTOSC = HFINTOSC_32MHz // Reset Oscillator 
>> Selection bits->HFINTOSC (32 MHz)
>> #pragma config CLKOUTEN = OFF // Clock Out Enable bit->CLKOUT 
>> function is disabled; i/o or oscillator function on OSC2
>> #pragma config VDDAR = HI // VDD Range Analog Calibration Selection 
>> bit->Internal analog systems are calibrated for operation between VDD 
>> = 2.3 - 5.5V
>>
>> //CONFIG2
>> #pragma config MCLRE = EXTMCLR // Master Clear Enable bit->If LVP = 
>> 0, MCLR pin is MCLR; If LVP = 1, RA3 pin function is MCLR
>> #pragma config PWRTS = PWRT_OFF // Power-up Timer Selection 
>> bits->PWRT is disabled
>> #pragma config WDTE = OFF // WDT Operating Mode bits->WDT disabled; 
>> SEN is ignored
>> #pragma config BOREN = ON // Brown-out Reset Enable bits->Brown-out 
>> Reset enabled, SBOREN bit is ignored
>> #pragma config DACAUTOEN = OFF // DAC Buffer Automatic Range Select 
>> Enable bit->DAC Buffer reference range is determined by the REFRNG bit
>> #pragma config BORV = LO // Brown-out Reset Voltage Selection 
>> bit->Brown-out Reset Voltage (VBOR) set to 1.9V
>> #pragma config ZCD = OFF // ZCD Disable bit->ZCD module is 
>> disabled; ZCD can be enabled by setting the ZCDSEN bit of ZCDCON
>> #pragma config PPS1WAY = ON // PPSLOCKED One-Way Set Enable 
>> bit->The PPSLOCKED bit can be cleared and set only once after an 
>> unlocking sequence is executed; once PPSLOCKED is set, all future 
>> changes to PPS registers are prevented
>> #pragma config STVREN = ON // Stack Overflow/Underflow Reset Enable 
>> bit->Stack Overflow or Underflow will cause a reset
>>
>> //CONFIG4
>> #pragma config BBSIZE = BB512 // Boot Block Size Selection 
>> bits->512 words boot block size
>> #pragma config BBEN = OFF // Boot Block Enable bit->Boot Block 
>> disabled
>> #pragma config SAFEN = OFF // Storage Area Flash (SAF) Enable 
>> bit->SAF disabled
>> #pragma config WRTAPP = OFF // Application Block Write Protection 
>> bit->Application Block is NOT write protected
>> #pragma config WRTB = OFF // Boot Block Write Protection bit->Boot 
>> Block is NOT write protected
>> #pragma config WRTC = OFF // Configuration Register Write 
>> Protection bit->Configuration Register is NOT write protected
>> #pragma config WRTD = OFF // Data EEPROM Write Protection bit->Data 
>> EEPROM is NOT write-protected
>> #pragma config WRTSAF = OFF // Storage Area Flash (SAF) Write 
>> Protection bit->SAF is NOT write protected
>> #pragma config LVP = ON // Low Voltage Programming Enable bit->Low 
>> Voltage programming enabled. MCLR/Vpp pin function is MCLR. MCLRE 
>> Configuration bit is ignored
>>
>> //CONFIG5
>> #pragma config CP = OFF // Program Flash Memory Code Protection 
>> bit->Program Flash Memory code protection is disabled
>> #pragma config CPD = OFF // Data EEPROM Code Protection bit->EEPROM 
>> code protection is disabled
>>
>> void main(void) {
>> // Set the CLOCK CONTROL module to the options selected in the 
>> user interface.
>> //
>> OSCCON2 = 0x0;
>> // SOSCPWR Low power;
>> OSCCON3 = 0x0;
>> // HFOEN disabled; MFOEN disabled; LFOEN disabled; SOSCEN 
>> disabled; ADOEN disabled;
>> OSCEN = 0x0;
>> // HFFRQ 8_MHz;
>> OSCFRQ = 0x3;
>> //
>> OSCSTAT = 0x0;
>> // TUN undefined;
>> OSCTUNE = 0x0;
>> // ACTEN disabled; ACTUD enabled; ACTLOCK Not locked; ACTORS In 
>> range;
>> ACTCON = 0x0;
>>
>>
>> /**
>> LATx registers
>> */
>> LATA = 0x0;
>> LATA0 = 1;
>>
>> /**
>> TRISx registers
>> */
>> TRISA = 0x34;
>>
>> /**
>> ANSELx registers
>> */
>> ANSELA = 0x34;
>>
>> /**
>> WPUx registers
>> */
>> WPUA = 0x0;
>>
>> /**
>> ODx registers
>> */
>>
>> ODCONA = 0x0;
>> /**
>> SLRCONx registers
>> */
>> SLRCONA = 0x37;
>> /**
>> INLVLx registers
>> */
>> INLVLA = 0x37;
>>
>> /**
>> PPS registers
>> */
>>
>> /**
>> APFCON registers
>> */
>>
>> /**
>> IOCx registers
>> */
>> IOCAP = 0x0;
>> IOCAN = 0x0;
>> IOCAF = 0x0;
>>
>> //TMR0H 119;
>> TMR0H = 0x77;
>>
>> //TMR0L 0;
>> TMR0L = 0x0;
>>
>> //T0CS FOSC/4; T0CKPS 1:1; T0ASYNC not_synchronised;
>> T0CON1 = 0x50;
>>
>> //Clear Interrupt flag before enabling the interrupt
>> PIR0bits.TMR0IF = 0;
>>
>> //Enable TMR0 interrupt.
>> PIE0bits.TMR0IE = 1;
>>
>> //T0OUTPS 1:1; T0EN enabled; T016BIT 8-bit;
>> T0CON0 = 0x80;
>>
>> ei();
>>
>> do {
>> LATA1 = 1;
>> NOP();
>> LATA1 = 0;
>> } while (1);
>> return;
>> }
>>
>> void __interrupt() myHighIsr(void) {
>> if (TMR0IF == 1) {
>> TMR0H = 0x77;
>> TMR0IF = 0;
>> LATA0 = 0;
>> NOP();
>> LATA0 = 1;
>> }
>> }
>>
>> -----Original Message-----
>> From: Hw-list [mailto:hw-list-bounces na list.hw.cz] On Behalf Of 
>> Jindrich Fucik
>> Sent: Monday, April 1, 2024 7:14 PM
>> To: hw-list na list.hw.cz
>> Subject: Re: defektní PIC16F18015
>>
>> Tak to jsem z toho jelen. Vzal jsem nový procesor a chová se stejně.
>> V příloze je obrázek z analyzátoru.
>> pochopitelně když program krokuji, tak se chová normálně. Nic 
>> takového, že by přerušení skočilo někam jinam a běžel kus jiného 
>> programu.
>>
>> Dne 01.04.2024 v 17:22 Jindrich Fucik napsal(a):
>>> To není můj případ, start přerušení trvá tuším 3 instrukční cykly,
>>> procesor jede 8MHz, takže 1,5μs nebo tak něco. Program je velmi
>>> primitivní, je napsaný v assembleru, abych vyloučil nějakou botu z 
>>> jazyka.
>>> Nakopíruji sem podstatnou část programu. Nepodstatná nastavuje config:
>>> vypnutý watchdog, interní oscilátor 8MHz a tak.
>>>
>>> Program nedělá nic, než že v mainu bliká jedním výstupem a v přerušení
>>> druhým. přerušení je od časovače (v příkladu Timer 0, ale stejně se
>>> chová i Timer 2) a je nastaveno na 60 μs.
>>>
>>> Na analyzátoru je pak velice zřetelné, že proběhne 25 bliknutí RA1,
>>> pak je těch 350μs mezera a pak jedno bliknutí RA0 a pak hned zase 25x
>>> RA1 (jasně, ten kód není optimální, je to poslední troska, než jsem to
>>> zabalil). Podstatné je, že ta díra je větší, než vlastní běh, takže je
>>> to velmi zřetelné a nemá cenu zjišťovat, jestli je něco ± jednotky
>>> instrukčních cyklů. Zábavné je, že stejný čas dostanu i při přepnutí
>>> rychlosti procesoru na 4MHz (tedy díra je asi 350μs, běh se 2x 
>>> prodlouží).
>>>
>>> -------
>>>
>>> ; Timer0 management ; used for software serial Tx time ticks -
>>> 60 micro sec per tick T0CON1_INI equ 0x51 ; T0CS FOSC/4; T0CKPS
>>> 1:2; T0ASYNC not_synchronised; T0CON0_INI equ 0x80 ; T0OUTPS
>>> 1:1; T0EN enabled; T016BIT 8-bit; TMR0H_INI equ 0x3B ; in 8 bit
>>> mode the TMR0H is compared same as
>>> timer2 0x3B = 59 = LN baud rate
>>>
>>> PIE0_INI equ 0x20 ; Enable TMR0 interrupt.
>>> PIE1_INI equ 0x00 ; none used
>>> PIE2_INI equ 0x00 ; none used
>>> PIE3_INI equ 0x00 ; none used
>>> PIE4_INI equ 0x00 ; none used
>>>
>>> INTC_INI equ 0xC0 ; GIE enable, PIE enable
>>>
>>>
>>> PSECT resetVec,class=CODE,delta=2,abs
>>> resetVec:
>>> PowerUp:
>>>
>>> clrf INTCON ; Disable all interrupts
>>> clrf PCLATH ; Tables on page 0
>>> ;clrf STATUS ; reset flags
>>> goto START
>>>
>>> PSECT isrVec,class=CODE,delta=2
>>> isr:
>>> Interrupt:
>>>
>>> movlb 0 ; BANK 0
>>> bsf LATA,0
>>> nop
>>> bcf LATA,0
>>> nop
>>> bsf LATA,0
>>> BANKSEL PIR4 ; BANK 14
>>> bcf TMR0IF ; clear timer overflow
>>> retfie
>>>
>>> START:
>>> (...tady je miliarda přiřazení *_INI do správných registrů ...)
>>>
>>> movlw INTC_INI ; GIE enable, PEIE enable
>>> movwf INTCON
>>>
>>> movlb 0 ; BANK 0
>>>
>>> testloop:
>>> bsf LATA,1
>>> nop
>>> bcf LATA,1
>>> goto testloop
>>>
>>>
>>> Dne 01.04.2024 v 13:46 Miroslav Draxal napsal(a):
>>>> Dobrý den,
>>>> Pozor na to, PICi si při přerušení ukládají registry soft, ne hw.
>>>> Kolikrát ta obsluha toho uložení registrů je docela časově náročná.
>>>> Standardně se ukládá
>>>> STATUS
>>>> WREG
>>>> BSR
>>>> Pokud se někde v používájí FSRx registry, a v přerušení Se používají
>>>> také, potom se i ty ukládají
>>>> FSR1
>>>> FSR1H
>>>> FSR2
>>>> FSR2H
>>>>
>>>> A můžou se ukládat i další. Při ukončení přerušení se zase registry
>>>> obnovují. Tudíž je tam nějaká režie a prodleva, než se přerušení
>>>> dostane na příslušnou obsluhu. Takže pokud by docházelo k velmi
>>>> častému přerušení, může se i občas nějaké ztratit.
>>>>
>>>> A ještě jedna věc, na kterou se zapomíná.
>>>> Novější procesory umí ukládat STATUS, WREG, BSR v režimu FAST. Nebudu
>>>> vypisovat podrobnosti, nakoukněte do *-.pdf konkrétního PICu, jestli
>>>> umí. Ovšem pozor, pokud odlaďujete program třeba s ICDx, potom tyto
>>>> FAST rutiny využívá ICDx. Pokud pak natvrdo pustíte program v
>>>> samotném PICu, tyto rutiny většinou potom používá přerušení s vysokou
>>>> prioritou. Takže časování je následně o něco rychlejší než při ladění
>>>> HW prostředky.
>>>>
>>>> Nahoďte při jaké příležitosti se seká, jestli je to při periodickém
>>>> přerušení (např. od TMRx), nebo něčeho externího. Třeba nás něco 
>>>> napadne.
>>>>
>>>> Míra
>>>>
>>>> -----Original Message-----
>>>> From: Hw-list [mailto:hw-list-bounces na list.hw.cz] On Behalf Of
>>>> Jindrich Fucik
>>>> Sent: Monday, April 1, 2024 12:09 PM
>>>> To: HW-news
>>>> Subject: defektní PIC16F18015
>>>>
>>>> Ahoj,
>>>>
>>>> občas si tu někdo hraje s těmito typy procesorů. Narazil jsem na
>>>> jeden defektní kus. Bohužel to byl ten, kterej jsem si odvezl na
>>>> velikonoce a nemám tu náhradu.
>>>> Projevuje se tak, že při vyvolání přerušení se procesor na cca 350 μs
>>>> zasekne. jak to tak bývá, tak mi trvalo dva dny zjistit, co se děje a
>>>> proč se nemohu dopočítat času nějaké události.
>>>>
>>>> Tak třeba se někomu tato informace bude hodit. Nebo možná někdo ví o
>>>> něčem, co jsem špatně nastavil a může mi to říci.

Další informace o konferenci Hw-list