Ez egy bootloader része! És mint olyan, normális állapot, hogy mindent átír, még azt is amit a forráskódban konstansnak jelölök meg!

Tényleg nem érted, hogy semmi köze nincs se a ram-hoz, se a futáshoz....!!
Egyszerűen fordítási időben keletkezik a probléma, annak függvényében, mit állítok be a forráskódban eme konstansok értékének.
Az előző hozzászólásban leírtam, gyakorlatilag miért nem egészen konstans az a konstans a valóságban.

Neked normalis allapot, de egy C programnak semmikeppen. A bootloader sem magat irja felul, hanem az applikaciot. El nem tudom kepzelni, hogy milyen konstans adat lehet az egy bootloader-ben, amit felulirsz. Pedig irtam mar par bootloader-t az elmult 30 evben...

Egyszerű. Az amit ő használ csak! mégpedig annak jelzésére, hogy mi a teendő, égetés vagy user program futtatása! Ez alapján a 4 bytos kódszekvencia alapján dönti el. Sikeres letöltés után pedig átírja olyan értékre, hogy következő reset után már a user program fusson.
Te hogy jelzed ezt az állapotot, ha már olyan sok bootloadert írtál??

Nem értem, nem is akarom érteni. Segítrni akartam, de legközelebb nem teszem. Olyan degradáló ez a "nem érted" szöveg. zha valaki nem ért valamit, akkor segíts neki! Magyarázd el! De ez a "nem érted" szöveg senkinek sem segít, csak "lehülyézed" vele a beszélgető partnered, és magadat mint "mindent tudó" emeled ki, mert te érted!

Hát az nem konstans az biztos. Ez milyen bootloader? Saját?

En ugy jelzem, hogy az applikacio elejen van egy header resz. Abban a headerben benne van, hogy milyen hosszu az applikacio, hogy hol indul, hogy mi a kezdo SP ertek, benne van az app. verzioszama, forditasi datuma, es van benne egy 16 byte-os MD5 check. Ez a header fix cimen van, ezert csak raallitok egy pointert, es kesz:
Mondjuk. A fenti peldaban ez a header az 8000 hexa cimen van. 32k a bootloader, utana jon az applic. Igy nincs olyan konstans, amit forditaskor ismerne a fordito. Azt, hogy egetni kell, vagy nem, az mar attol fugg, hogy honnan jon az egetni valo. Van, amikor kulso EEPROM-bol, van, hogy Etherneten jon, van amikor a flash-t harom reszre osztom, es az elso a bootloader, a masodik az applikacio, a harmadik pedig egy atmeneti tarolo. Ez attol fugg, hogy hogyan kerul a beegetendo kod a keszulekbe. Sokszor az applikacio maga veszi at valahogy, es beegeti egy atmeneti tarba (kulso EEPROM, vagy a flash egy resze), es raugrik a bootloader-re, aki szepen atirja a flash-t. Ha maga a bootloader szerzi meg az image-et, akkor nem kell a koztes tarolo, egybol egetheti a flash-t. Az MD5 check meg arra jo, hogy ellenorizni lehet, hogy az applikacio nem serult-e. Ha atmeneti tarolo van, akkor az abban tarolt image integritasat is lehet ellenorizni. Ha letolteskor megserult, akkor nem fogja beegetni. De ha a beegetett applikacio serult, akkor nem inditja el a bootload-er, hanem valahogy jelzi a user-nek, hogy gond van. Szamtalan megoldas letezik erre. A te problemad kizarolag abbol adodik, hogy C konstans valtozoban tarolod a kodszot, nem pedig egy fix FLASH cimen. Nem csak az if-et, de siman lehet, hogy magat a valtozot is kioptimalizalja a fordito, hiszen ha csak abban az egy if-ben hasznalod az erteket, akkor nincs ra semmi szukseg. Szoval ha van egy fix FLASH cimed, ahova le tudod tenni a szekvenciat, akkor nem lesz gondod az optimalizacioval.

Azzal nem segitesz, ha talalgatsz, raadasul nagyon messze az igazsagtol, mert magat a kerdest sem erted. Azt mondta, hogy mast fordit a fordito, ha egy konstans valtozo erteket megvaltoztatja. Ez azt jelenti, hogy atir a forrasszovegben egy inicializalt const valtozot, es ujbol leforditja a programot. Pl. const int a = 3; helyett a 3-bol 4-et csinal es ujbol leforditja. Ettol egesz mas assembly kodot forditott a fordito, es ezt nem ertette, hogy miert. Mi koze ennek a kerdesnek a tombokhoz, es ahhoz, hogy futas kozben mi tortenik? Semmi. De mivel ez a halado topic, itt mar elvarhato lenne, hogy egy ilyen egyszeru kerdest megertsen az, aki valaszolni akar ra.

Pontosan így van! Sajonos nekem nincs ennyi türelmem, mint neked, hogy ilyen szépen elmagyarázzam 5x-re is, ha valaki nem érti a talán nem tökéletes, de azért nagyvonalakban érthetően leírt problémámat...

Ez egy szép, összetett rendszernek tűnik, amit leírtál!

Nálam egyszerűbb az eljárás... Van egy fix címen lévő konstans szekvencia, amit a bootloader kiolvas minden reset után. Kényelmi okokból eddig magában a forráskódban állítottam be az értékeket(pl hibakereséskor, stb). Eddig érdekes mód nem futottam ebbe bele, pedig ez az eljárás már régóta működik nálam, nem most találom ki.
Az egész bootloader nálam a legutolsó törölhető programszegmensben helyezkedik el. Oda ugrik a reset után, ahol is kiértékelődik a szekvencia alapján, mi a teendő, és ha letöltés van, akkor pl soros vonalon 256Bytos csomagokban veszi az adatot, majd beégeti a megfelelő helyre. A végén crc16-ot számolok a teljes memória-bootloader rész, s ha ok volt, átírom a szekvenciát a helyességet jelző értékre(gyak. mondjuk törlöm), és jön egy reset.
Ha nem egyezik a crc, akkor marad minden a régiben, vár egy újabb próbálkozásra.
Az egész cucc, bootloader+user program egyszerre íródik, egy projecten belül. Ez kicsit megbonyolítja a helyzetet, de eddig ez működött 16, 32 bites mikrovezérlőkön is. Most egy kicsit újabb családra gyúrom át, ezért faragok rajta, és futottam így ebbe bele.
Mondjuk az is tény, hogy az eddigi verziók 0 optimalizálási szinten voltak fordítva, mivel volt hely és sebesség is elég, de ennél már kell a max optimalizálás egyéb okok miatt.

Sikerült egy értékelhető webet kialakítanom HTML-el és az általad javasolt libraryból kinyert webvend demo app source codeból egy sajátot alakítani. Most ott akadtam meg hogy nem tudok a weblapról egy bizonyos szöveget , egy szót elmenteni a PIC-be úgy hogy az áramtalanítás után is úgy maradjon. Az alap programban megvan írva hogy az aktuális szöveget amit az lcd-n megjelenít azt írja ki egy text boxba az oldalon , de én meg fordítva akarom ezt.

Sziasztok,
PIC24FJ128GA010
MPLAB X IDE v4.10, fordító: XC16 v1.33
Új projektet hoztam létre, majd a forráskódhoz hozzáadtam egy üres C forrásfájlt, az alábbi kóddal:

MPLAB debuggert használnám, ám debugnál ha soronként ("Step into") megyek végig a programon, akkor a "__delay_ms(1000);" sornál ezzel a hibaüzenettel fogad a debugger konzol:

Megnézve a programmmemória/disassembly ablakot, mikor a delay sorra lépek, elkezdi a képen látható MOV.. utasítást végrehajtani, majd valóban a 0x2d6 címre ugrik, és ott látszólag "megakad", nem nagyon lép tovább. Viszont ha Run/Continue-val futtatom a progit, akkor nem ír ki ilyet, csak ha a pause-val szüneteltetem a futást.
Találkozott már valaki ilyennel? Ez megint valami Microchip X feature?
Előre is köszönöm!

Ha jól emlékszem a __delay_ms 8/16 biten egy makró függvény amiben van egy számítás, hogy az adott időhöz mennyi ciklust kell várni és meghívja az extern előtaggal definiált _delay() függvényt. Azért írtja, hogy No source... mert ez egy belső függvény, ha jól emlékszem 16 biten már az stdio függvényeit se látod külön source-ba megnyílni ha step-elsz.

Én mikor még használtam a gyári delay fv.t akkor bp-vel léptem át a delay-t.

A delay macro/függvény asm nyelvű forráskódot tartalmaz. Érthető, hogy ha léptetgeted, akkor azt is lépésenként hajtja végre ami benne van.
Használj töréspontokat a léptetés helyett, vagy csak ott léptesd, ahol c utasítások vannak...

Na én is gondoltam erre, csak reménykedtem benne, hogy valamilyen módon nyomonköveti a belső rutinokat is.
Köszi a választ, sdrlab-nak is!

PIC32MZ ADC 4. csatorna, AN4 bemenet. Digitális szűrés 64x-es.
Referenciafesz, MCP1525, 2,5V. Poti 10k reff. feszről osztva.
AVss külön szálon vezetve (1ohm-al vagy nélküle Digit GND-re a tápnál csatlakozik.
A REF- a ref IC-nél csatlakozik az AVss-re.
A REF+ a ref IC-ről megy egy 220uH, 4,5ohm induktivitáson át, + 1µF kerámia...

Szűrés nélkül a hiba 7bitnyi, szűréssel 4bites.
Ez 78mV illetve 9mV nagyságrend a referenciafeszt figyelembe véve és a 12bites ADC felbontást.
Nem létezik, hogy ekkora zavar van a tápon, illetve a ref feszen.

A hiba nagyobb szűréssel csökken, de az sps lecsökken 10 alá, ami nonszensz egy ilyen nagysebességű ADC-nél.

Mit tanácsoltok?

Őőő.. biztos kell oda az a tekercs?

Ja nem a REF+ nál van, hanem az AVdd előtt.
Eredetileg 10ohm volt ott, de több helyen láttam induktivitással, kipróbáltam, nagyon kicsivel jobb lett, de nem számottevő.

Adatlap szerint jobb a nagyobb kapacitású kondenzátor a kimenetre (10 µF). Oszcilloszkóppal nézted valamelyik feszültséget? Az adatlap erre is kitér, RC szűrővel lehet jelentősen csökkenteni a kimeneti zajt.

Azt viszont nem tudom, hogy ha a Vref-re kötöd a potit, mennyire szól bele a mérésbe. Próbáld ki egy 1,5 V-os elemmel, az garantáltan nem zajos és nem is terheli a referencia IC-t.

Én a 4,096 V-os változatát hazsnáltam 12 bites ADC-hez, a vártnál is stabilabb volt a dolog.

A tekercs akkor jó, amikor külső feszültség zajoktól véded a belső kört. Jelen esetben viszont a belső fogyasztásod okozza az ingadozást. Az a tekercs jelenleg az ellenséged, nem a szövetségesed. Az ADC nem tudom, mennyit fogyaszt, de az a gyanúm, kevés az 1 uF, hogy önmagában ingadozástól védjen. Szerintem sokkal több kellene.

Szia! Elnézést, az első leírásomban összekavartam a dolgokat, amit utána helyesbítettem.
A ref IC-n 10 mikro van a kimeneten.
Próbáltam elemmel is, semmi javulás.
18F-eken nagyon sokszor használtam 12bites ADC-t, ilyet egyik sem csinált...

A tekercs a Vdd-ről megy az AVdd-re. Ha a digitális Vdd-n zavar van, akkor az segyíthet csillapítani az AVdd-n. De volt helyette 10ohm is, semmit nem változtat. Biztosan táp zavarra kell gondolni?
A nagyobb kondit megpróbálom, igaz nem tudom hogyan fér majd el, mert nem erre terveztem a nyákot, de majd rámókolom.
Szkópot elő kell szednem (nagy dög, lent a pincében )...
Köszönöm mindkettőtöknek a javaslatokat!

A tekercs a táp zajoktól is védeni tud, de ugyan milyen táp zajt remélsz egy stabkocka kimenetéről érkezni? Az is csak akkor zajos, ha lehagyod azokat a kondikat a kapcsairól, amiket az adatlap direkt hangsúlyozni is szokott, hogy kell az oda (vagy nagyon erős dinamikus árammal terheled a stabkockát). És kell a pic lábra is a kondi még akkor is, ha nincs ott soros tekercs. Ha soros tekercs / ellenállás is van, valójában még több kondi kell a pic lábra, például 1 nano kerámia + 100 nano kerámia + 10 mikro tantál, és ha túl nagy tekercset raktál oda, akár még az 1000 mikro elektrolit is melléjük. Szóval gondold át, tényleg akarsz-e oda tekercset rakni.

Legyen rendesen szűrve a tápod, legyenek ott a kondenzátorok kerámia + tantál + elektrolit rendesen a stabkocka külső felén is meg kerámia + tantál a belső felén is (ha erősen ugrál a fogyasztásod, legyen elektrolit kondi a belső oldalon is), meg kell közvetlenül legalább a kerámia közvetlenül a pic lábra + a feszültség referencia lábaira is. Pic lábakra kellenek máshova is kondik, adatlapban megtalálod. Ne hagyj le egyet sem, nem viccnek írja az adatlap. Ha minden kondi a helyén van, akkor megtetted, amit megtehettél. A tekercset, meg az ellenállást, meg a többit pedig felejtsd el, mert akkor csak még több kondi kell.

Ami pedig az eredményt illeti - hogy milyen kondi mennyire hatásos - azt oszcilloszkóp tudja neked megmutatni, amit közvetlenül a pic lábra szúrj rá. Ne tőle centiméterekre mérj, mert az nem ugyan az. Tüske elektróda kell a pic lábra rászúrva, és működés közben (miközben folyamatosan mintákat dolgoz fel a pic), mert az AVdd-n csak olyankor van "forgalom". Nézd meg azt a lábat külön időléptékekkel: 10 nanosec / div, 100 nano, 10 mikro.

Mindazokat megteszed, vagy megkerül a bűnös, vagy megszűnik a baj.

Még valami. Te soros tekercset raktál a pic táplábra nagyobb kondenzátor nélkül? Csak hogy tudd, akár megzúzhattad a pic-et, és az már attól is zajos lehet. Ha ugrál az AVdd-n a fogyasztás, és nincs rajta a kapcsain a kondi, de soros tekercsen kapja az áramot, akkor a fogyasztás esésekor a tekercs nagyobb tápfeszt fog ráküldeni, mert semmi sem fogja azt az extra töltést lefogni. Attól bizony baja lehet.

A félelmed csak akkor igaz, ha az AVdd valóban terhel és olyan mértékben, hogy az rángatja a tekercset (nem valószínű). Az ellenállás, amit szerinted nem kell odatenni, minden adatlapban láthatod ajánlásként és én minden áramkörömben használtam is eddig, eredményesen. Kondikkal soha nem spórolok, tisztában vagyok vele hova kell és mekkora, ezért is kérdeztem, hogy esetleg valaki küzdött-e PIC32MZ-vel, mert eddig ilyen rossz eredményt nem láttam ADC-től.
Sajna ma nem lesz időm foglalkozni vele, majd ha lesz, akkor beszámolok az eredményről. Köszi!

Próbáld meg legalább AC-ban rövidre zárni az ADC bemenetét, akkor is mérsz zajt, avagy megszűnik ?!

AC alatt mire gondolsz?

Váltóáram... Ha nem lehet a DC(=egyenáram) összetevő miatt közvetlenül rövidrezárni, egy párszor 10µF kondin keresztül megteheted. Akkor semmi sem mászik el, de a bemenetre már nem kerül semmi, max valami alacsonyfrekis összetevő....

Gyakorlatilag hidegítsem le egy szál 10µF-al a bemenetet? Megpróbálom (holnap Du). Talán azt is meg lehetne próbálni, hogy szimmetrikus bemenetre váltok és úgy zárom rövidre kondival.
Na jó, de mi lesz akkor, ha így is ugrál? (egyébként vélhetően fog, mert 1,5µF már volt a bemeneten 1kohm után kötve és semmi nem változott.). Pajti2-nek lesz igaza, hogy a PIC a nagy freki miatt a program futása közben változó mértékben terheli a tápot, e miatt változik a fesz a táplábain, amiről végül is szűréssel kapja az AVdd a feszt. Lehet, hogy teljesen külön stabról kéne táplálni az AVdd-t...

Tudsz mutatni egy panel rajzolatot errol a kornyekrol? A referencia foldje es az Avss hogyan van osszekotve?

De neked ha jól értettem külön REF-ed van! Azt nem valószínű, hogy bármi rántgatná, viszont a mért értékek hozzá vannak rendelve, nem a tápfeszhez! Az csak parazita módon járul hozzá a bizonytalan méréshez, azt is inkább csak nagyobb frekvenciákon(>10kHz)
Mérni kell, nincs mese...elő a szkópot! )