ATmega16, for lidt FLASH rom?

Hej!

Nørder lidt med Atmel her i ferien! :-) Sidder og koder derudaf, og pludselig efter en tilføjelse nægter skidtet at starte. Fjernede kaldene til de nye rutiner, men det hjalp ikke. Rutinerne skulle væk før det kørte igen. Så fjernede jeg noget andet i stedet for, og det virker også. Har så opdaget at når programmet kommer op på ca. 2K words, går det galt. Det er som om der ikke er plads til slutningen af programmet, og her ligger rutiner der kaldes under opstart. Men der skulle jo være 8K words i sådan en...?? Jeg har ikke slået noget til af f.eks. boot-område, flyttede IRQ-vektorer eller ligendende, i mine fuses. Og jeg har included filen "m16def.inc", hvori der er en ".device ATmega16" linie.

Noget andet jeg har undret mig dybt over tidligere, og som måske er relateret, er at interruptvektoren til timer0, som bør ligge på adresse hex

12, ikke virker. Efter noget frustreret banden fandt jeg ud at hvis jeg placere mit hop til interruptrutinen på adresse hex 58 (ikke hex 48, som ellers ville ha' været en 4-dobling, underligt nok), så virker det!!?? Dette problem har jeg på to forskellige projekter, så det er ikke processoren der er defekt.

Det er som om 'noget' bruger ca. 4 gange mere plads end det skal, ganger adresserne med 4 eller et eller andet sygt, men jeg kan ikke regne ud hvad der foregår. :-/

--
Ulrik Smed
Denmark, Aarhus
Reply to
Ulrik Smed
Loading thread data ...

Det er der skam også. Men det lyder som om du bruger rjmp / rcall. De kan kun hoppe 2K frem eller tilbage i koden. I stedet for skal du bruge jmp / call til længere hop.

Det lyder dybt mystisk. Hvordan har du lavet din interruptvektortabel? Hvis du også bruger rjmp her, kan det let gå galt, da der er reserveret plads til en jmp (der fylder mere) pr interrupt.

M.v.h. Mikael

--
Mikael Ejberg Pedersen
http://www.ejberg.dk (Elektroniske dimser til modelflyvning)
Reply to
Mikael Ejberg Pedersen

Skal måske lige nævnes at jeg bruger AVR studio (v4.09) og STK500.

--
Ulrik Smed
Denmark, Aarhus
Reply to
Ulrik Smed

Hmm, ja det var også en af mine første tanker, men assembleren siger jo 'relative branch out of range', hvis jeg forsøger et for langt rjmp eller rcall. Den fejl får jeg godt nok når jeg skal, har jeg lige testet. Men den assemblerer uden fejl og laver en hexfil, som så crasher når jeg kører den.

Ja, det så jeg netop et andet sted. Men jeg bruger .org, for at være sikker på adressen bliver den rigtige:

.org 0 rjmp reset .org 0x58 ; virker ;.org 0x12 ; virker ikke rjmp sampleccdint ...

--
Ulrik Smed
Denmark, Aarhus
Reply to
Ulrik Smed

Argh, det havde jeg åbenbart ikke testet godt nok, for da jeg ændrede et kald en til en rutine i slutningen fra rcall til call, virkede det sgu! Assembleren melder først 'out of range' ved lidt længere hop end der kan lade sig gøre i virkeligheden, det må da være en fejl i assembleren. Men fedt, nu kan jeg komme videre, tak for tippet, du havde jo ret et eller andet sted, selvom det var svært at se! :-)

--
Ulrik Smed
Denmark, Aarhus
Reply to
Ulrik Smed

HA! Det var fordi "Wrap relative jumps" var slået til, inde i AVR assembler setup! Lusket! Nu får jeg "relative branch out of range" fra assembleren når jeg skal. :-)

--
Ulrik Smed
Denmark, Aarhus
Reply to
Ulrik Smed

Åh ja. Det er en klassiker. Den havde jeg bare lige glemt alt om igen.

Men interruptproblemet er der vel stadig? Har du en lille stump kode der har problemet, som vi andre kan kigge på?

M.v.h. Mikael

--
Mikael Ejberg Pedersen
http://www.ejberg.dk (Elektroniske dimser til modelflyvning)
Reply to
Mikael Ejberg Pedersen

Jeps. :-/

Hmm, koden virker jo fint, det er bare rjmp'en til timer0 interrupt rutinen der skal placeres på adresse 58 hex, istedet for på adresse 12 hex, hvilket undrer mig dybt og inderligt. Her er starten af programmet:

.cseg .org 0 rjmp reset .org 0x58 ;.org 0x12 rjmp sampleccdint

reset: ; init stack pointer ldi r16,low(ramend) out spl,r16 ldi r16,high(ramend) out sph,r16 ...

--
Ulrik Smed
Denmark, Aarhus
Reply to
Ulrik Smed

Og det bør også undre. For der er et eller andet råddent ved det. Det kan godt være at det virker nu, men det er et potentielt problem, der ligger og bobler lige under overfladen.

Ja, det kunne jeg ikke lige se så meget galt i :-( Ligger sampleccdint inden for 2K fra interruptkaldet? Også med org

0x12 ? Har du (evt ved en fejl) enablet andre interrupts end Timer0?

Det er vel ikke tilfældigvis sådan at du vil af med hele sourcekoden, evt. bare i en email til mig? Så kunne jeg prøve at køre den med min JTAG debugger på, og måske se hvad der præcist sker ved timerinterruptet.

M.v.h. Mikael

--
Mikael Ejberg Pedersen
http://www.ejberg.dk (Elektroniske dimser til modelflyvning)
Reply to
Mikael Ejberg Pedersen

Hehe, ja jeg har det heller ikke så vildt godt med det!

Jeps.

Ja, også det.

Hm, det skulle jeg ikke mene. Sampleccdint programmere timer0 til en ny tid ved hvert interrupt, og det virker, så jeg tvivler på interruptet kommer fra andet end timer0.

Det vil jeg godt. Men der skal nok disables nogle rutiner, for der er et display på som processoren venter på noget acknowledge fra, og så vil den hænge i det venteloop, hvis det ikke er tilsluttet. Ved ikke om du har tid til at rode med det. Men jeg vil skyde på problemet viser sig hvis du bare prøver at lave en simpel timer0 interrupt. Eller det har du måske allerede prøvet, hvor det virkede med adresse 12? Jeg har lavet timer0 interrupt på en 8515 uden problemer, det var da jeg skiftede til ATmega16 det pludselig ikke virkede.

--
Ulrik Smed
Denmark, Aarhus
Reply to
Ulrik Smed

Tjo, lidt tid skulle jeg da nok have ind imellem.

Ork ja da. Du kan f.eks. tage et kig på denne her:

formatting link
(og så ligger sourcekoden under downloads). Der bruger jeg en Mega16 med en ordentlig håndfuld forskellige interrupts, og alle ligger på de adresser som er opgivet i databladet. Ved nærmere eftertanke bruger jeg vist lige præcis IKKE Timer0 overflow interruptet, men det ved jeg at jeg har gjort i en tidligere version af softwaren. Senere flyttede jeg den så til Timer2.

M.v.h. Mikael

--
Mikael Ejberg Pedersen
http://www.ejberg.dk (Elektroniske dimser til modelflyvning)
Reply to
Mikael Ejberg Pedersen

Hm, jamen det ser jo pænt og ordentligt ud i dit program. Det må jo være mig der har lavet et eller andet snavs et sted, synes bare ikke lige jeg kan forestille mig hvordan man får rodet i de vektorer. Det er den eneste interrupt jeg bruger. Jeg har lige smidt sourcen her, så hvis du eller andre gider at kigge, kunne det da være sjovt at få en forklaring.

formatting link

--
Ulrik Smed
Denmark, Aarhus
Reply to
Ulrik Smed

Jeg har kun lige foretaget et hurtigt kig, da jeg er på arbejde nu. Men jeg kan ikke lige umiddelbart se noget galt. Simulatoren virker også fint med .org 0x12. Jeg vil prøve at smide den gennem min JTAG i aften, så jeg kan se hvad der i virkeligheden sker i kredsen. Jeg stoler nemlig ikke så meget på simulatoren i sådan nogle underlige fejlsituationer.

Men mit umiddelbare gæt er, at du måske er offer for en compilerfejl. Jeg bruger ikke selv Studio 4.09. Jeg har hørt om flere, der har haft problemer med den. Dog ikke så slemt som det her.

M.v.h. Mikael

Reply to
Mikael Ejberg Pedersen

Så har jeg moret mig lidt med min JTAG, og resultatet er det samme. Det virker uanset om jeg bruger .org 0x12 eller 0x58. Interruptsene kommer en lille bitte smule hurtigere ved 0x12 (vi snakker cirka 20 us ved 10 MHz krystal).

Jeg kan forestille mig to forklaringer. Enten er der et eller andet galt med assembleren. Jeg bruger som sagt en lidt ældre version (1.74) fra Studio 4.08.

Eller også er problemet timingskritisk. Ved 0x58 bliver der et lille delay ved hvert interrupt, nemlig for at komme igennem det uprogrammerede område i flash fra 0x12 til 0x58. Du kan efterprøve dette ved at bruge 0x12 som interruptvektor, men lad det første i interruptrutinen være en masse NOP's. Gerne en 35-40 stykker. Hvis det så virker, så er der et problem med timing (hardwarerelateret?).

M.v.h. Mikael

--
Mikael Ejberg Pedersen
http://www.ejberg.dk (Elektroniske dimser til modelflyvning)
Reply to
Mikael Ejberg Pedersen

Det var faktisk netop den metode med nop'erne jeg brugte, for at finde ud af hvorfor jeg ingen interrupts fik på adresse 0x12. Jeg fyldte nop'er i fra resetvektoren og et stykke frem, og placere min jmp derefter, og fik det til at virke. Så slettede jeg nop'er lidt ad gangen, og nåede til at hvis jmp'en stod på adresse 0x56 virkede det ikke, men på 0x58 virkede det.

Hos mig er der ikke disse 20 uS's delay, faktisk ligger nogle af interrupts'ene med mindre end 20 uS imellem, så et så langt delay ville ødelægge timingen. Det burde da iøvrigt ikke tage 20uS at køre nop'er fra

0x12 til 0x58 ved 10MHz. Jeg kører med ca. 45000 interrupts i sekundet, og timingen er pænt kritisk.

Her er det første stykke af assemblerens hex-fil, kan man se noget ud fra det?

:020000020000FC :0200000058C0E6 :1000B000F6C20EE50DBF04E00EBF88E593E088248C :1000C0009924E4E8F0E0E0937800F093780000E011 :1000D000C02E002700937B0000E00093620001E047 :1000E0000093640000E000937D0008E0A02E0093E0 :1000F0007F000FE00093800000E000937E00002767 :100100000093810000E000938200002700938100AB :100110000E9444030E9473020E948B0A0E944705BA :100120000E94050A0E94D6040E94DD020E94250357 :100130000E942D030FE0FDD0D69A7CD446D300FD5B :1001400065D002FD68D004FD6BD001FD6BD003FDCE :100150006BD0A5D3E3D300918200013009F441D0E4

--
Ulrik Smed
Denmark, Aarhus
Reply to
Ulrik Smed

Ahaa, det bestyrker min mistanke om timingsproblemerne. Jeg er overbevist om at du stadig fik interrupts på adresse 0x12, men af en eller anden årsag skal du bare have brændt lidt tid af. Hvad hvis du i stedet sætter de NOP's ind efter din sampleccdint: label (og lader "rjmp sampleccdint" være på adresse 0x12)?

Nej, det er mig, der har vrøvlet. Jeg så 20 us mellem separate interrupts, og fik rodet det tal sammen med noget andet. Det er jeg ked af.

Jaaaaeh, umiddelbart ser det ud til at det ikke er et assemblerproblem. Adresserne er rigtige (for 0x58).

M.v.h. Mikael

Reply to
Mikael Ejberg Pedersen

Hm, nu har jeg rodet lidt med det, og har nu interrupts på adresse 0x12. Jeg kan ikke reproducere fejlen i det her program længere. Det andet program jeg oprindelig havde fejlen i, er på mit arbejde. Prøver lige i næste uge at se om det viser fejlen. Da jeg startede på det her program, brugte jeg rutinerne fra programmet der viste fejl, men de er ændret siden.

Men jeg kan se at når jeg bruger adresse 0x12, så får jeg en lidt kortere interrupt responstid, så det passer fint med at interruptet kom på den adresse, og der så bare blev løbet nogle nops igennem før 'sampleccdint' blev kaldt, da jeg havde kaldet på 0x58. Så jeg fik lige lidt tid foræret her, 70 nops 45K gange i sekundet er der jo ingen grund til! :-)

--
Ulrik Smed
Denmark, Aarhus
Reply to
Ulrik Smed

Bahh, jeg havde aktiveret compare interruptet i stedet for overflow interruptet, DOH! :-/

Det var iøvrigt også adresse decimal 58, og ikke hex 58, det drejede sig om. Men nu virker det begge steder på adresse 0x12, og jeg fik ro i sjælen, LOL! :-)

Takker for hjælp og inputs!

--
Ulrik Smed
Denmark, Aarhus
Reply to
Ulrik Smed

Alt har en forklaring. Jeg er glad for at det virker nu.

M.v.h. Mikael

--
Mikael Ejberg Pedersen
http://www.ejberg.dk (Elektroniske dimser til modelflyvning)
Reply to
Mikael Ejberg Pedersen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.