[PIC] Problem att flasha hex WISP648

[Pajn]

Jag kan inte flasha en hexfil till min 16F648A.

Kod: Markera allt

rasmus@Rasmus-Ubuntu:~$ python bin/Xwisp/xwisp.py PORT /dev/ttyS4 PORT 115200 GO MPLABXProjects/Cosmitto\ 16f648A.X/dist/default/production/Cosmitto_16f648A.X.production.hex 
XWisp 1.39, command line mode
hardware: Wisp648 1.30 (fast) 
target: 16f648a, device code 1100 revision bits 05
                                                            
verification failure: different data at address 2007: file=FFF8 target=3FF8
ERROR

Jag får samma fel hela tiden, testade även med en annan PIC (samma modell).

Jag testade att flasha en annan hex, byggd för en 12F675 och det gick, men när jag ska flasha hexen ovan blir det fel igen.
Target är fortfarande 3FF8@2007 vilket verkar lite lurt.

Jag använder Xwisp från pythonkällkoden i Ubuntu.

[sodjan]

> ...PORT /dev/ttyS4 PORT 115200...

Ska inte det andra vara "BAUD" ?

> ...GO MPLABXProjects/Cosmitto\ 16f648A.X/dist/default/production/Cosmitto_16f648A.X.production.hex...

Ska det vara ett blankt där direkt efter "Cosmitto\" ?

[bos]

sodjan: Det är ett blackslashat mellanslag. Det är helt korrekt att göra så, fast själv hade jag föredragit citationstecken runt hela strängen istället.

[sodjan]

Aha, "escape'at" som det heter i andra miljöer... !?
Ja, det var ju inte så tydligt (för mig!)

Sen så finns det en debug/verbose switch också så att man
lite bättre ser hur långt den egentligen kommer...

[Pajn]

>Ska inte det andra vara "BAUD" ?
Tydligen inte, det ser lite konstigt ut men det står så i hjälpen

PORT P : use serial port p
PORT b : use active baudrate b

och ändrar jag till något icke standard typ 115201 så får jag svaret att den bitraiten inte stöds så den verkar tolka det rätt.

"\ " är ett escapat mellanslag (mellanslag i terminalen gör annars att resten av strängen blir ett nytt argument).

>Det är helt korrekt att göra så, fast själv hade jag föredragit citationstecken runt hela strängen istället.
Kan tyckas, men jag tycker autocomplete funkar bättre om man inte har det. Och eftersom jag använder det ofta så blir det så...

>Sen så finns det en debug/verbose switch också så att man
>lite bättre ser hur långt den egentligen kommer...
Det fans det ju, fast tyvärr var den kass:

Kod: Markera allt

rasmus@Rasmus-Ubuntu:~$ python bin/Xwisp/xwisp.py PORT /dev/ttyS4 PORT 115200 GO MPLABXProjects/Cosmitto\ 16f648A.X/dist/default/production/Cosmitto_16f648A.X.production.hex VERBOSE
XWisp 1.39, command line mode
hardware: Wisp648 1.30 (fast) 
target: 16f648a, device code 1100 revision bits 05
                                                            
verification failure: different data at address 2007: file=FFF8 target=3FF8
ERROR

Egentligen så är ju felet ganska tydligt så det kanske inte blir mer "verbose", frågan är ju vad det beror på?

Jag har även testat i "lazy mode" samt sänkt bitraiten utan resultat (Båda enskilt också)

[sodjan]

Ja, det verkar som att XWisp får något läsfel från den aktuella processorn.
Det kan bero på problem i själva uppkopplingen.
När fungerade det senast?

Är det alltså ingenting mellan "target:" och "verification failure:" raderna?

[Pajn]

>När fungerade det senast?
Så fort jag tar den andra hexfilen anpassad för en annan modell så kopplingen borde vara ok.
Alltså utan att röra hårdvaran, filen för 12F675 kör jag alltså in i 16F648A med alla problem det innebär.
Men även om jag nu pajjat PICen borde det ju ha funkat innan?

Kan det vara något fel i hexfilen? Det låter långsökt och borde i vilket fall inte ge läsfel, eller?

>Är det alltså ingenting mellan "target:" och "verification failure:" raderna?
En jäkla massa mellanslag (du kan se dem om du markerar den raden från vänster till höger).
Men förutom det, nada. Kodrutan innehåller exakt allt som händer, raden efter ger en ny prompt bara.

[sodjan]

Ja, 2007 är väl adressen för CONFIG bitarna.
Hur är det med de två värden som visas ? Jag tycker att 3FF8
låter som ett rimligt värde, FFF8 låter lite underligare.
Vad står det egentligen i filen/filerna?
Jämför de två filerna med avsende på just adress 2007.
Hur är filerna skapade? Är det din egen kod?
Kan det vara något konstigt i __CONFIG direktivet (*om* det är ASM)?

Som du ser så är det mängder av okända variabler här...

[Pajn]

Det är min kod, skapade med MPLABX och Hi-Tech PICC Lite på Ubuntu (för första gången kanske bör nämnas)
Koden:

Kod: Markera allt

#include <htc.h>

// Config: int reset, no code protect, no watchdog, 4MHz int clock
__CONFIG(MCLRE_ON & CP_OFF & WDTE_OFF & FOSC_INTOSCIO);

/*
 * 
 */
void main () {
    // Init PORTA
    PORTA = 0b00000000;
    // RA1 input
    TRISA = 0b00000010;
    // Comparators off
    CMCON = 0x07;

    for (;;) {
        if (RA1 == 0) {
            PORTA = 0b00000001;
        } else {
            PORTA = 0b00000000;
        }
    }
}

Hexfilen förstår jag mig inte på

Kod: Markera allt

:040000008A11E52F4D
:100FCA0083018A11E82F83120313850102308316E5
:100FDA00031385000730831203139F00F42F85182B
:100FEA00F72FF82FFB2F01308500F42F8501F42FFE
:060FFA00F42F8A1100280B
:02400E00F8FFB9
:00000001FF

Det som uppmärksammar mig är att varken 3FF8 eller FFF8 finns med i filen, fast den kanske är kodad på nått sätt?

Om man kollar i includefilen ser man att de olika configinställningarna står för (samma ordning som i koden)
0xFFFF, 0xFFFF, 0xFFFB,0xFFFC

EDIT: Jag testade att sätta alla configbitar i koden och samma fel uppstår, enda skillnaden är vad som står i filen

Kod: Markera allt

different data at address 2007: file=FF38 target=3FF8

[Pajn]

XWisp2 hade tydligen också en Linuxversion, och den funkade dessutom

[sodjan]

Ja, rätt version är ju aldrig fel...

> Det som uppmärksammar mig är att varken 3FF8 eller FFF8 finns med i filen,

Jag ser : ":02400E00F8FFB9", notera "F8FF" vilket är sannolikt config värdet, omkastat.

[bos]

Ursäkta för att återuppliva tråden, men jag hade exakt samma fel på en 12F683 (med Xwisp från Wouter), testade Xwisp2 från Rob och det funkade direkt.

Wisp648 är ju rätt utdaterad vid det här laget så jag tänker inte felsöka på djupet, men jag lurar lite retoriskt på om det kan det vara så att jag och Pajn har kretsar som är av lite nyare revision än vad Xwisp klarar av. Hårdvaran och seriekabeln är ju uppenbarligen exakt samma i de båda situationerna, och bådas Xwisp gnäller medan Xwisp2 fixar det.

Xwisp2 säger att den är kompilerad 2014, men jag hittar ingen datuminfo på Xwisp 1.41 som jag kör.

Nåja. Tack Pajn för tipset