5. Software debugging van het ISDN terminal board
5.3 Fouten in de low-level device drivers
Door de verschillen in de hardware met enerzijds de PC met de MITEL kaarten (zie hoofdstuk 3.1) en anderzijds het tenninal board met zijn speciale componenten (zie hoofdstuk 3.2), moesten er voor het tenninal board andere low-level drivers geschreven worden. Deze konden nog niet goed getest worden door het ontbreken van een S-bus verbinding. Tijdens het testen van de eerste verbinding over de S-bus tussen de MITEL kaart (in de NT-mode) en de tenninal board kwamen de eerste fouten in de low-level drivers naar voren.
Een van de fouten was de (random) weigering om de S-bus te activeren. Bij de bestudering van de initialisatie-routine en de datasheets [17] bleek dat er niet werd gewacht (minirnaal 250 Jls) na het aanzetten van de ontvanger van de DSC en niet werd gekeken naar de toestand van de LIU als een 'activation request' werd gegeven. Het aanzetten van de ontvanger en het 'activation request' werd door een schrijfoperatie tijdens
het opstarten in het LID Mode Register [17] geschreven.
Verder werd er meteen een interrupt door de DSC gegenereerd na het opstarten van de software omdat na verwijderen van alle interrupts door het lezen van de interrupt registers, nogmaals in een andere initialisatieroutine een gedeelte van de DSC weer werd gei"nitialiseerd. De interrupts werden vervolgens niet verwijderd. Door het optreden van dit interrupt werd random data in de D-kanaal FIFO werd geschreven.
In totaal werden er drie losse initialisatieroutines voor de DSC gebruikt, een voor de DSC in het algemeen, een voor het DLC-gedeelte en een voor het LIU-gedeelte. In deze routines werden verschillende registers tweemaal gei"nitialiseerd. Er is daarom een nieuwe routine geschreven die de onderstaande initialisatie procedure doorloopt:
• Reset van de registers door de DSC idle mode
• Activeren van de ontvanger
• Wacht minimaal250 J.ls
• Bekijk de toestand van de LIU en wacht totdat deze goed is. (State F3, F6 of F7, zie 1.430 [2])
• Geef 'Activation Request'
• Initialiseerdeoverige DSC registers
• Verwijder alle mogelijk status en interrupt bronnen door het lezen van de interrupt en statusregisters: DSR1, DSR2, DER, LSR. [17]
De eerste problemen werden hierdoor opgelost maar tijdens het debuggenkwameen ander interrupt probleemaanhet licht.
In de speciale startup-code CSTART.ASM) geschreven in assembler door H. Oudelaar [4]/IBeijnsberger[6] werd een andere interrupt-tabel opgezet dan de interrupt-tabel die bij de vele testprograrnma's [5] gebruikt werd. De startup-code zette een interrupt-tabel op die gebruik maakte van door INTEL gereserveerde interrupt-nummers en niet van de voor de gebruiker gereserveerde interrupt-nummers (32 en hoger). Tevens werd in de startup-code de segment-registers DS, ES en SS gelijk aan 0 gesteld, zodat parameters voor de segment-indeling die aan de locater-utility werden meegeven niet werkten. Het kan dan voorkomen dat het programma vastloopt zodra de stack door het datagebied begint te lopen of als er data in de stack wordt geschreven. Ook werden de libraries van de C-compiler niet geinitialiseerd zodat functies uit deze C-libraries fout konden gaan.
Om dit probleem op te lossen, is besloten de standaard 'embedded' startup-code te gebruiken van de INTEL C-compiler. Hierdoorzal inieder geval geen probleem ontstaan
met eventuele C-functies, standaard input/output functies blijven natuurlijk verboden.
Het opzetten van de interrupt-tabel kuooen we doen met een speciale INTEL compiler functie en zogenaamde 'pragma' functies:
• setinterrupt( interruptnr, interrupt_routine_abcd) : deze functie koppelt de 'interrupt-routine_abcd', met behulp van de onderstaande 'pragma' gedeclareerd, aan interrupt-nummer 'interruptnr'.
• #pragma interrupt( int_routine_l, int_routine_2, •..) : door het vennelden van de naam van de interruptroutine in deze pragma-functie, weet de compiler dat de genoemde functie speciaal moet worden voorbereid voor dat doel ( uitschakelen en inschakelen van de interrupts, beveiligen van de registers, enz.) We kunnen deze functies vergelijken met resp. deTURBOC functies:
• setvect(interruptnr, interrupt_routine_abcd)
• het interrupt keyword dat bij de defmitie van een interrupt functie gebruikt moet worden
De nieuwe interrupt instellingen staan in de file INTSETUP.C.
Zodra de verbinding goed kon worden opgezet ontstond er een probleem met het verzenden van het tweede protocol frame. Deze bevatte random-data die vervolgens niet door de NT herkend kon worden als een toegestaan protocol frame. Een simpele toevoeging die ervoor zorgt dat er niet teveel bytes in deFIFOwordt geschreven, moet in zendO-routine worden toegevoegd (XMTBUFF.C). Deze routine vult als eerste de 8-bytes FIFO buffer van het D-kanaal in de DSC, waarna de interrupt routine het eventueel ovemeemt om de aanvullende bytes naar deFIFOte sturen.
void zenden(void) {
while ((DSC->DSR2 & TBE) && (DscRam->xmtcnt!= 0)) {
/*#MR changed, counter added*/
DSC->DCTB_DCRB
=
*(DscRam->xmtnext++);DscRam->xmtcnt--;
}
DSC->CRJR
=
DTCR;DSC->DR
=
(byte)(DscRam->xmtpktsz & OxfJ);DSC->DR
=
(byte)((DscRam->xmtpktsz»
8)& Oxjf);/* transmission started*/
}
Tijdens het testen van de data link verbinding op laag 2 kwam het een enkele keer voor, dat de protocol monitor maar een gedeelte van een bericht of frame naar de ANSI-terminal doorstuurde. Tijdens het onderzoeken van de IDPC en USART routines kwamen we de volgende problemen tegen:
• verkeerd index gebruik voor de terminalbuffer voor het lezen en schrijven van data in de interrupt-routine. Een zelfde soort fout is ook in de afdruk en toetsenbordroutines geslopen, die echter geheel vervangen zijn door het window-systeem. De interruptroutine wordt als voIgt hersteld:
- usart_int()in USART.C:
case Ox04:/*Receive FIFO threshold reached*/
while ((IDPC->usartLSR &OxOl)
==
OxOl) ( outbyte(Ox2000,Oxfj);/* Terminal[Termcount++ %MAXTERM] */
Tenninal[Tenncount]
=
IDPC->usartfifo;Tenncount=(Tenncount++) %MAXTERM;
Lengthterm++;
i/((IDPC->usartLSR & OxOe)/=0) ( outbyte(0x2002 ,Oxfj);
haZt();
} }
break;
• niet gemtialiseerde en gedeclareerde structures die in de onderstaande files werden toegevoegd:
-GLOBAL.C:
struct idpcdf *IDPCDEF[2];
struct idpcdf IDPCDEFO, IDPCDEFI; /* #MR added */
- INITPROC.C:
IDPCDEF[Oj=&IDPCDEFO; /* #MR added */
IDPCDEF[lj
=
&IDPCDEF1;Verder zijn nog tijdens het debuggen van de bovenstaande problemen de volgende fouten gevonden en verbeterd:
• INITPROC.C, pointer initialisatie:
DMAram[Oj
=
&DMAramO; /* #MR added, pointers in DMAram were never initialised (not used yet!)*/DMAram[IJ
=
&DMAram1;• INITPROC.C: Het process MONITOR dat werd geiilitialiseerd is verwijderd omdat het niet wordt gebruikt maar vooral omdat de array dimensie wordt overschreden.
• DSCRAMIN.C:
1* DscRam->rcvfree
=
DscRam->rcvbuff=&RamBuffer[DscRam->rcvrefnoJ.info[OJ,o*/
DscRam->rcvfree
=
DscRam->rcvbuff=&RamBuffer[DscRam->rcvrefnoJ.info[1J,o
5.4 Samenvatting
In dit hoofdstuk is beschreven hoe de ISDN software is gedebugged. De fouten in de ISDN software voor het terminal board maakten het onmogelijk om een laag 2 verbinding te maken met de MITEL kaart via het Srr interface.
De fouten waren vooral ontstaan door het gebruik van twee verschillende C compilers en door de twee verschillende ISDN systemen.
Nu deze fouten verbeterd zijn, is het mogelijk om een laag 2 verbinding te maken tussen een MITEL kaart en het ISDN terminal board. Om een telefoonverbinding te kunnen opzetten hebben we echter nog de Call Control en het Resource Management nodig. Deze functies worden in het volgende hoofdstuk gerealiseerd. Ook zullen we een betere protocol monitor implementeren.
6. Software ontwikkeling t.b.v. het ISDN terminal board
Het is nu mogelijk om een verbinding op te zetten over het S/T-interface vanaf laag 2 van het OSI-model tussen het MITEL systeem en het ISDN terminal board. Om nu een telefoonverbinding te kunnen maken, moeten we de Call Control en het Resource Management voor het terminal board omzetten en aanpassen voor de AMD ISDN IC's.
Dit wordtinde volgende paragraaf uitgelegd.
Daarnaast ontbreekt de uitgebreide protocol monitor die bij de Mitel kaarten wordt gebruikt ter controle van de protocollen en die het zoeken naar fouten vergemakkelijkt.
Omdat beiden, Call Contro]JResource Management en de Protocol Monitor, op de PC veel gebruik maken van de standaard PC input/output bibliotheken en gespecialiseerde window functies van TURBO C voor het weergeven en controleren van de processen, berichten, frames, IC registers, enz., leek het gemakkelijker om een TURBO C-compatibel window systeem te ontwerpen voor het tenninal board zodat de Protocol Monitor van de PC vrijwel zonder moeitekandraaien op dat board. Dit ontwerp komtinde laatste paragraaf aan de orde.