PIC bevriest op Serin

Probeer de ; eens te vervangen door een hoge comma ' ...

Beste roches,

bedankt voor je reactie.
Die puntkomma dient alleen maar voor het aangeven waar de remregel begint. Dat kan naar mijn weten zowel met de appostrof als mer de puntkomma. Of is dat veranderd bij de nieuwe compiler versie?

Nogmaals bedankt

Daan Steeman

Op 13 november 2014 23:54:40 schreef Roches:
Probeer de ; eens te vervangen door een hoge comma ' ...

Meestal zijn dit soort zich verplaatsende fouten een gevolg van een andere fout, die zich ergens eerder in het programma voordoet...

Hoi Arco,

Bedankt voor je reactie
de fout verplaatst zich niet. Als ik die twee regels er uit haal (ofja... tijdelijk een remregel van maak. Maargoed het effect is het zelfde) werkt het programma precies zoala het zou moeten, voorzover dat kan zonder die twee stukken dan.

Als bij het verwijderen van een regel dezelfde fout in de volgende regel optreedt, dan verplaatst de fout zich...
(m.a.w. de fout wordt door iets anders ergens in de code veroorzaakt.)

Op 13 november 2014 19:12:39 schreef DaanSteeman:

Het enige wat er naar mijn weten is veranderd is dat ik een nieuwere compiler heb sindsdien. Maar dat veranderd niks aan de syntax voor zover ik weet.

Nee maar wel aan de code die er gegenereerd wordt...
Al is het maar door zaken als optimalisaties die anders zijn.

Ik zie twee opties...

Of er zit een bug in je compiler/linker suite.

Of je code bevat een bug die eerst geen problemen gaf doordat de oude compiler hier toch nog werkende code van maakte.

Hoi Arco,

Ik denk dat er even een misverstand is. Op het moment dat ik de volledige code (en dan boedoel ik dus ook met die twee regels)compileer loopt hij vast op de SERIN. als ik die uitschakel loopt hij pak en beet 1000 regels verderop vast op de VAL.
Dat is toch geen verplaatsende fout? Ik heb zoiets wel eens gehad. dat ik ergens een ENDIF was vergeten o.i.d en dat bleef inderdaad steeds verspringen. maar als ik deze twee regels uitschakel loopt het programma preceis zoals het hoort (voor zover dat kan zonder die twee regels).

Franzki,
Oke ja dat klinkt logisch inderdaad. Maar dan de vraag... hoe ga ik die fout vinden. Als het probleem in de compiler zit kan ik daar zelf vrij weinig aan doen geloof ik. Als de fout in mijn code zit (wat ik aanzienlijk waarschijnlijker vind eerlijk gezegd)... Normaal zoek ik fouten op door met ledjes te zoeken hoever het programma komt en dat net zo lang tot ik de fout heb gevonden. maar als de fout in de ene regel ontstaat en totaal ergensanders zich voor doet. Dan zou ik niet weten hoe ik daar überhaupt aan moet beginnen.

Bedankt voor jullie reacties

Daan Steeman

Als je syntax net zo is als je Nederlands, dan snap ik het wel... Maar goed...

Het zou best kunnen dat er door een andere compiler (linker) 'ergens anders' wat fout gaat. Ergens een stukje memory wat plat geschreven wordt, andere compiler, andere memory map, ander probleem. Dit zijn wel de leukere problemen overigens

Mijn eerste gok zou zijn dat je ergens met stack onderuit gaat. Niet ergens iets recursiefs (al dan niet opzettelijk)?

Uit de oude doos: ik heb me eens 2 dagen lang rot gezocht waarom seriele communicatie op een 8051 op z'n b*k ging na het aanpassen van een rekenfunctie (die in de verste verte niet met serieel gebruikt werd). Na een dag of 2 viel het muntje: ik heb de nare eigenschap om pointers default op NULL te zetten en in functies te checken of die we geïnitialiseerd zijn. Dat werkt op een PC prima... Maar bij die 8051 is NULL ongeveer gelijk aan 0. En 0 is een valid address in RAM. Toevallig mapte de linker nou net die pointer op 0x0000. En daar verslikte de code zich in.
De dieper liggende oorzaak was een collega die makefile had aangepast. Ik had netjes opgegeven dat we op 0x0001 mogen beginnen, hij vroeg zich het nut daarvan af en heeft die parameter verwijderd. En bedankt...

Overigens heb ik de fout gevonden door botweg de gegenereerde assembly te bekijken en een stukje door een simulator heen te trekken. ICE deden we in die tijd nog niet. debugWire heeft een 8051 niet .

Heeft Proton geen mogelijkheid om de gebruikte stackdiepte te zien?

Beste
een analoog probleem ben ik ooit opgelost door een paar extra variabelen te definiëren (die nergens gebruikt werden).
eddy
ps ik denk dat dit komt doordat de pic geheugen in "banken" heeft, en de compiler daar niet steeds goed mee overweg kan.

Op 14 november 2014 13:20:50 schreef DaanSteeman:
maar als de fout in de ene regel ontstaat en totaal ergensanders zich voor doet. Dan zou ik niet weten hoe ik daar überhaupt aan moet beginnen.

Op een pc-omgeving zou ik dat doen met een single-steppen in een debugger, dan zie je gewoon hoe de omstandigheden zijn op het moment dat de instructie wordt aangeroepen.

Op een embedded systeem (zonder debug-mogelijkheden) zou ik mijn code in stukjes hakken. En stukje voor stukje evalueren of al die stukjes exact doen wat ik verwacht.

Met name het niet-juist initialiseren van data kan leuke problemen geven.

Vaak worden ook problemen veroorzaakt doordat men aanneemt dat niet geinitialiseerde ram locaties altijd 0x00 zijn, dat is uiteraard niet het geval.
(inhoud van ram locaties is random bij opstarten, bij reset onveranderd)

EricP,
Even afgezien van het feit dat ik dislectisch ben en dus inderdaad moeite heb met Nederlands zie ik in mijn voorgaande bericht geen rare dingen staan. Dat even ter zijde.
Stack problemen lijken me onwaarschijnlijk gezien het feit dat dit programma al maanden zonder problemen draaide.
En om heel eerlijk te zijn volg ik vrij weinig van wat je verteld over die seriële communicatie op die 8051. Ik doe dit al een tijdje maar absoluut niet op het niveau wat jij daar gebruikt. Voor wat ik er van begrijp verwees het programma naar het verkeerde deel van het geheugen waardoor het mis ging?

Arco,
Ik zit met deze kwestie ook op het forum van proton, ik zal daar eens vragen of dat kan. Ik kan het tenminste niet zo 1,2,3 op internet vinden.

eddy2,
Bedoel je gewoon een paar variabele aanmaken die in het programma verder niet voorkomen? Dat heeft dan toch verder geen invloed op het verloop van het programma?

Allen dank voor de input

Daan Steeman

Op 14 november 2014 14:00:43 schreef Franzki:
[...]
Op een pc-omgeving zou ik dat doen met een single-steppen in een debugger, dan zie je gewoon hoe de omstandigheden zijn op het moment dat de instructie wordt aangeroepen.

Bedoel je hiermee dat ik stap voor stap het programma kan doorlopen terwijl ik te zien krijg wat de PIC precies doet? Dit is namelijk iets wat ik heel graag wil hebben maar nooit heb kunnen vinden. Kan jij me iets aanraden?

Voor debuggen kun je MPLAB/ICD gebruiken. (ik neem aan dat Proton standaard COFF files aan kan maken voor de debugger?)

Stack problemen lijken me onwaarschijnlijk gezien het feit dat dit programma al maanden zonder problemen draaide.

Dan toch nog eens lezen wat ik schreef. Je kunt best een stack probleem hebben, zonder dat je er tegen aan loopt. Een kleine wijziging zorgt dat je er wel tegen aan gaat lopen. 'Het heeft gewerkt' is dus geen enkele reden om aan te nemen dat 'het wel goed zit'. Tenzij je andere argumenten hebt, is het nog steeds een goede verdachte.

[...]Voor wat ik er van begrijp verwees het programma naar het verkeerde deel van het geheugen waardoor het mis ging?

Laat maar (als in: ik wil het je met alle plezier uitleggen, maar in deze discussie is het 'ruis' en brengt de uitleg je niet nader aan je doel).

Bedoel je gewoon een paar variabele aanmaken die in het programma verder niet voorkomen? Dat heeft dan toch verder geen invloed op het verloop van het programma?

Dat hangt dus van je compiler en je probleem af. Een beetje compiler optimaliseert ze gewoon weg en geeft er wat warnings op. Als dat niet gebeurt, dan verandert je memorymap. Als daarmee je probleem ook verandert, dan kom ik toch weer bij dat memory probleem (vermoedelijk stack) uit.

Op 14 november 2014 13:37:10 schreef EricP:
Als je syntax net zo is als je Nederlands, dan snap ik het wel... Maar goed...

ik heb de nare eigenschap om pointers default op NULL te zetten in in functies te checken of die we geïnitialiseerd zijn.

Stack problemen zijn inderdaad de meest aannemelijke oorzaak. Zoals @EricP reeds zei, kom je er soms wel mee weg.
Dit omdat een sprong naar een verkeerd adres niet fataal hoeft te zijn. Je komt dan (via een onbedoeld stukje code) weer in het hoofdprogramma terecht.
Totdat je een sprong naar code maakt, die niet meer 'recht te breien' is. De zaak loopt dan vast.

Even om misverstanden te voorkomen... Stack problemen zijn problemen die voortkomen uit het verwijzen naar bepaalde stukken code toch? (goto, gosub)

Met een tip van het forum van Proton zelf heb ik een deel van het probleem intussen opgelost. In mijn stestopstelling had ik de Rx vrij gelaten. Blijkbaar blijft de PIC hangen in het SERIN command als de ingang zweeft.

Afijn dat is in elk geval geregeld. Om de een of andere reden blijkt hij nu de knoppen te negeren. De pullup weerstanden werken en het voltage gaat netjes naar 0V als ik de knop indruk. Maar de PIC gaat niet verder.

Even er vanuitgaand dat mijn beeld bij stackproblemen klopt. Dit is helemaal in het begin van het programma. Nog voor de lus waar hij permanent in blijft draaien. Tot het punt waar hij komt zit geen enkele goto of iets dergelijks. Of zou dit toch nog een stack probleem kunnen zijn?

Dank jullie allen voor de input

Daan

Veel van de interne Proton functies zullen ook wel stack gebruiken (omdat ze intern weer andere functies aanroepen), of dat gedocumenteerd is weet ik niet.

idd , enkele variabelen aanmaken en er een 1 in schrijven
eddy

Op 14 november 2014 14:18:04 schreef Arco:
Voor debuggen kun je MPLAB/ICD gebruiken. (ik neem aan dat Proton standaard COFF files aan kan maken voor de debugger?)

Arco,

Voor wat ik er van kan vinden op internet heb ik hier ook nog een apparaatje van microchip zelf nodig of begrijp ik iets verkeerd?
Weet iemand toevallig een goede beschrijving van hoe ik daarmee kan beginnen?

Eddy2,
Als ik een bijvoorbeeld een byte-variabele aanmaak maar die verder in het programma niet meer gebruik, dan veranderd er toch niks aan wat de PIC doet?

Dank voor jullie reacties

Daan

Ik weet niet welke controller je gebruikt. Voor 10F/12F/16F heb je inderdaad vaak een ICD header nodig. (die MCU's hebben geen interne debug hardware)
En je hebt ook de ICD hardware (ICD2 of ICD3) nodig...

Op 14 november 2014 15:43:20 schreef Arco:
Ik weet niet welke controller je gebruikt. Voor 10F/12F/16F heb je inderdaad vaak een ICD header nodig. (die MCU's hebben geen interne debug hardware)
En je hebt ook de ICD hardware (ICD2 of ICD3) nodig...

ik gebruik de 18f4520. En het enige wat ik heb kunnen vinden aan hardware was ruim 200 euro... en als student kan ik dat momenteel niet echt missen .
Bestaat er misschien en soort simulator wat het programma regel voor regel doorloopt en dingen als geheugen e.d zichbaar maakt?