Hiljaiseltahan täällä näyttää, mutta kysäsenpä silti... Ongelma ei välttämättä
olekaan omituinen, mutta minä en ole vaan tajunnut.

Datasheetin mukaan program counterin pitäisi selvitä kaikista hypyistä
(goto, call) yhden muistisivun alueella ilman erityistoimia, eli 0-7ff alueella.

Toistuvasti, eli ei vaan nykyisen, vaan myös aikaisempien rojektien kohdalla
törmään harhahyppyongelmaan jossain vaiheessa koodissa, heti kun se
venyy vähänkin pidemmäksi. Mutta ollaan selvästi ekalla sivulla.
Vika korjaantuu vähän koodin siirtokelpoisia paloja siirtelemällä ja uudelleen
kääntämällä.
Eli, siis toimivista koodin paloista tulee jossain järjestyksessä toimiva ohjelma,
ja toisessa järjestyksessä ei-toimiva. Mplabin simulaattori tekee saman
"hyppyvirheen", joten onko siis virhe ollenkaan? Page-bit virhe, eikä pinon
ylivuoto ole kyseessä, se on moneen kertaan varmistettu. Eikä oikeastaan
voikaan olla, kun samat palat eri järjestyksessä toimii.

Pitkässä ja ei-simulaattorikelpoisessa ohjelmassa tuo palojen summassa
siirtely alkaa pikkasen ärsyttämään... Voiskohan joku valaista, mitä mä
olen missannut.

Ja siis ihan assemblerilla ja Mplabin omalla kääntäjällä.

Aika omituinen ongelma kyllä...ei yhden sivun sisällä pomppimisessa pitäisi olla ongelmia.
Olethan ottanut huomioon, että goto ei tallenna lähtöosoitetta pinoon?
Eli sieltä ei voi palata esim. returnilla.
Call taas tallentaa, jolloin returnilla voi palata takaisin hyppypaikkaan.
Kiinnostaisi nähdä esimerkkikoodi tuollaisesta, jossa tulee hyppyvirhe.

Saitko Mplabissa näkyviin kohdan missä tämä tapahtuu, vai onko se satunnaista.
Onko sleep ja keskeytykset käytössä ?

jjw kirjoitti:Saitko Mplabissa näkyviin kohdan missä tämä tapahtuu, vai onko se satunnaista.
Onko sleep ja keskeytykset käytössä ?

Silloin kun tämä nykyinen koodi oli vielä simulaattorikelpoinen, niin kyllä
se virhe tuli siinäkin näkyviin. Jotenkin jäi mieleen kummittelemaan, ettei
se hutihyppy tullut koskaan suoraan hypyssä, vaan vasta vähän paluun
jälkeen. Ja lähinnä koskee siis "call" hyppyjä, goto ei niinkään ole aiheuttanut
todettua ongelmaa.

Sleep ei ole käytössä, keskeytys on. Keskeytyksessä on tallennus ja palautus
sekä W:lle, että statukselle.

Ja lienee selvää, ettei goto'n jälkeen palata return'lla.

Pitäis varmaan ottaa käsittelyyn edellinen projekti, jossa tämä esiintyi myös,
ja järjestellä se taas sellaiseksi, että virhe tulee. Voisi oikein ajatuksella
ajaa simussa sitä. Tätä nyt menossa olevaa ei enää hetkeen ole voinut
kuvitellakaan simuun, siinä on niin paljon ulkoista vaikutusta ja ajoitusviiveitä.
Ja mitään ei voi koodista ottaa edes tilapäisesti pois, koska jos sen pituus
muuttuu jostain väliltä, virhekin saattaa poistua. Ja vastaavasti, jos toimivaan
haluaa lisätä jotain uutta välille, vaikka noppeja, niin vika taas saattaa tulla
esiin. Tämä on just se ärsyttävin juttu.

Lienee sanomattakin selvää, että keskeytyksestä palataan RETFIE:llä?

Outoa kyllä, jos kaikki koodi tosiaan on yhdellä sivulla. Ja koodissa ei ole mitään mikä muuttaisi program counteria?
Miten jäljitit ongelman siihen väärään hyppyyn?

L18 kirjoitti:Lienee sanomattakin selvää, että keskeytyksestä palataan RETFIE:llä?

Toinen

Outoa kyllä, jos kaikki koodi tosiaan on yhdellä sivulla. Ja koodissa ei ole mitään mikä muuttaisi program counteria?
Miten jäljitit ongelman siihen väärään hyppyyn?

Edellinen koodi, missä tämä ilmeni, oli varsinkin alkuvaiheessa aika helposti
ajettavissa simussa, ja siinähän se paljastui. Mutta en keksinyt mitään syytä.
Siinäkin oli pieni kahden rivin hyppytaulu, mutta aika alussa. (varmasti ekan
FFn sisässä). Jotenkin sattumalta järjestin paloja uudelleen, ja hop, sehän
pelaa sittenkin. Siirsin palat takasin, ei pelaa.

Tässä nyt menossa olevassa kävi niin, että toimivaan alkuversioon lisäsin
vähän osia, niin sekin hyytyi. Ja kun se lisätty ei mitenkään voinut olla
viallista, niin muistin tuon edellisen tapauksen ja siirsin paloja taas vähän.
Ja niinpä taas alkoi toimimaan. Tässäkin on kaksi pientä hyppytaulua, mutta
taaskin ekan FFn sisässä.

Sinänsä hauska piirre näyttää olevan, nyt kun tämä koodi on venähtänyt
jo 11-bitin alueelle (eli ne 8 pc:stä ja 3 pclath:sta), niin virheen esiinsaaminen
tuntuukin vaikealta. Antaa siirrellä paloja aika vapaasti...
Ihan kuin ne pclath:in puolella olevat bitit olis käytön puutteessa "jumissa"
alkuun. No, tää menee jo Mulderin tontille.

Omienkin ajatus- ja kirjoitusvirheiden jahtaaminen on välillä työlästä, ei
siinä kaipaisi enää outoa käytöstä prossulta.

Aika tympeetä on tämänkin selvittäminen... Nyt on kaksi eri piiriä, missä on lähes samat softat sisässä, mutta toisessa vähän mihinkään tämän ongelman
kohtaan liittymätöntä koodia enemmän. Mikä siirtää vähän joitain osia eri kohtaan program memoryssa.
Piirit ja softat on vaihdettu ristiin... Toinen toimii kun junan vessa, mutta toinen halvaantuu aina välillä ohittamaan osan koko koodista.
Siellä on kohta, jossa outputteja nollataan joko lämpöanturin lämmön, virtamuuntajan antojännitteen tai ajan mukaan. Silloin, kun ei toimi, virtamittaus ja lämpömittaus ei aiheuta sammutusta, mutta aika tekee.

Eli joko a/d:n käsittely ohitetaan tai estyy, tai a/d:n tuloksien käsittely ohitetaan tai estyy. Samaan aikaan toisaalla koodissa oleva yhden input-
karvan tunnistaminen ei myöskään tunnu toimivan, missä olisi hätäsammutus noiden arvojen ylityksen takia. Muuten koodin täytyy kulkea
suht oikeaa reittiä, koska mitään muita sekoiluja ei tule näyttöön, eikä muihin i/o karvoihin.

Sanon kele!

Ai niin, koodin pätkät on nyt eroteltu vielä org- lausumilla, joten nuo lisäykset eivät siirrä mitään muuta, kuin omassa aFF-bFF välissä olevaa
koodia. Eli jaot 00-FF, 100-1FF, 200-2FF jne.

Tää on tosi jännä vehjes. Tuossa on alirutiini, jossa nostetaan virhebitti ylös ja sammutetaan, mikäli tutkittu vika tulee kaksi kertaa
minuutin aikana ja tämä toistuu kumulatiivisesti 3 kertaa. Ykskaks rupes virhebitti nousemaan satunnaisesti 6-18 tunnin jälkeen,
ilman, että olisin havainnut mitään outoa.
Tein sitten laskurin, montako kertaa siinä alirutiinissa käydään, ja laskurin arvo näyttöön. Ei koskaan mene sinne. Eli softa joskus
täytyy hypätä itsekseen siihen virhebitin nostokohtaan... Virherekisteristä vain 7 bitti nousee aina, eli tuskin rekisteri korruptoituu.

Ei sinänsä liity aiheeseen, koska multa ainakin loppuu ideat kesken että mikä voisi olla vialla.

L18 kirjoitti::D
Ei sinänsä liity aiheeseen, koska multa ainakin loppuu ideat kesken että mikä voisi olla vialla.

Enpä keksi minäkään, softaviat alkaa olemaan niin tutkittu, ettei oikein jää sijaa. Tässä on myös sarjaliikennettä nappulaosaston
kanssa, ja sekin satunnaisesti lakkaa toimimasta hetkeksi. Alkujaan epäilin siihen syylliseksi resonaattoria, mutta ei se ollut.
4MHz ei ole kovin nopea kello tälle piirille...
En keksi enää muuta, kuin että nämä mulle päätyneet 877a:t on jotain muutaman vuoden takaista samaa sarjaa, jossa on joku vika
program counterin käsittelyssä.

Lienee pinon ylivuotota tms?

teg kirjoitti:Lienee pinon ylivuotota tms?

Eipä, kuten jo ihan alussa sanoin. Ei mahdollista, jos pino toimii, kuten sen kuuluu.
Ja miksipä se alkaa satunnaisen toiminta-ajan jälkeen, vaikka toistetaan samaa rundia?

Toimiiko laite joka ajokerralla täsmälleen samalla tavalla vai voiko jokin ulkoinen tekijä vaikuttaa ohjelman suorituspolkuun?

Mikäli voi, niin pino voi vuotaa eri aikaan yli.

teg kirjoitti:Toimiiko laite joka ajokerralla täsmälleen samalla tavalla vai voiko jokin ulkoinen tekijä vaikuttaa ohjelman suorituspolkuun?

Mikäli voi, niin pino voi vuotaa eri aikaan yli.

Kyllä ulkoiset tekijät muuttaa kulkua, mutta häiriö ilmenee toisinaan samaa reittiäkin toistettaessa, eli jos siinäkin poiketaan, sekin on
jo häiriö.
Lisäksi misään ei ole sisäkkäisiä aliohjelmakutsuja lähellekään pinon sallimaa maksimimäärää.

Onko kyseessä kuinka pitkä pätkä koodia? Saisitko sitä tuupattua näkyville, jos sieltä jotain outoa sattuisi bongaamaan?