C6415T: Issue with timer interrupt and BIOS init

Chris,

Are you using DSP/BIOS or SYS/BIOS?

Either is your O/S, and interrupts are part of your O/S. BIOS will expect to be configuring the interrupt vector table based on how you set it up in the .tcf or .cfg file, and BIOS will expect to be the one to enable interrupts globally. Of course, I may be confusing the BIOS versions, so we can wait until you give us a little more information.

Are you using the HWI_Dispatcher or your own "interrupt"-keyword ISR?

Have you measured the cycles required per ISR execution for your timer1 ISR? I think there is a table in the SYS/BIOS docs that lists this, at least for the HWI_Dispatcher method. You might be motivated to find a way to combine yours with the BIOS timer. Might not be possible, but could be worthwhile to consider.

Regards,
RandyP

Randy,

My BIOS version is 5.41.13.42 so I am using DSP/BIOS. I have HWI_INT15 configured with timer1 as the source and set to use the dispatcher.

So if the BIOS will enable interrupts globally, is it possible that my enabling of INT15 could be causing the issue?

By combine with the BIOS timer do you mean that I should try to use the BIOS timer to call my ISR instead of timer1?

-Chris

Signalogic

Chris,

You are probably already using a command like

C64_enableIER(C64_EINT15);

to enable the IER bit for your timer1 interrupt. You should not be enabling GIE in main(), since this will be done by BIOS when main() exits.

Which interrupt is BIOS using for its timer routine? Which timer is it using?

If you are using the HWI_Dispatcher and you are enabling an interrupt to occur before BIOS is ready, then it makes sense that things will go awry. You do not want to do this.

You are getting a regular interrupt for BIOS to count ticks. It might not be happening as often as you want timer1 to trigger, but it might be close enough that you can adjust one or the other to still meet your needs. This idea might not work, might not be practical, and I cannot fully work it out for you. If you want to try something like this, please post a new question on the BIOS Forum and post a link to that question here.

Regards,
RandyP

Randy,

Yes I am only enabling the IER bit for timer1 by setting that bit in the IER register. I don't touch the GIE bit in main().

BIOS uses timer0 on interrupt 14.

Is it possible that BIOS enables the interrupt before it is ready and the high rate on the timer causes it to sometimes run the ISR before BIOS is finished with init?

-Chris

Signalogic

Chris,

This definitely belongs in the BIOS forum. It should be there by now.

What you are speculating would be a serious bug, so I doubt the interrupt is being enabled before BIOS is ready. But you are seeing some issue with a fast rate timer under some condition.

My best advice would be to figure out what works and go with that. Whether it means starting with a longer period for the first interrupt, or waiting until a task starts to enable the timer, something will get your system working. Whether or not someone can give you a precise answer based on what is here, I do not know.

The the best chance at a precise answer will be here in the BIOS forum.

Regards,
RandyP

Alan,

I am defining it in my .tcf file under HWI_INT15. I set the interrupt source to Timer_1, the interrupt selection number to 15,  the function to _TIMER1_ISR, and use dispatcher to true.These are the lines in the .tcf file that do this:

bios.HWI.instance("HWI_INT15").interruptSource = prog.get("Timer_1");
bios.HWI.instance("HWI_INT15").interruptSelectNumber = 15;
bios.HWI.instance("HWI_INT15").useDispatcher = 1;
bios.HWI.instance("HWI_INT15").interruptMask = "all";
bios.HWI.instance("HWI_INT15").fxn = prog.extern("TIMER1_ISR");

Looking at this part of the .tcf file brings up another question. Is there a way to "clean" the textual configuration script that the configuration tool creates? I use the Configuration Tool GUI to set everything. Whenever I set a specific parameter then change it and change it back I end up with 3 lines in the config file. Like this:

bios.HWI.instance("HWI_INT15").interruptMask = "all";
bios.HWI.instance("HWI_INT15").interruptMask = "none";
bios.HWI.instance("HWI_INT15").interruptMask = "all";

The only C code involved stops the timer by writing the CTRL register, writes the PERIOD register, and starts the timer by writing the CTRL register. Then the code sets bit 15 in the IER register.

I don't think the CSR register is touched during main() but I could be wrong and will have to look more closely at the code to be sure.

-Chris

Signalogic

Chris,

The .tcf is a text file that you can edit and delete the earlier lines that have been logically replaced.

Regards,
RandyP

Chris,

Sadly, the GUI tool leaves behind those unsightly divots. As Randy mentions, you can manually edit the .tcf file to beautify it.

The definition of HWI 15 looks good to me.

Are you using the C64_enableIER() API that Randy referenced? Are you perhaps using any CSL APIs?

Can you place a breakpoint just before returning from main() and verify the state of the GIE bit?

Alan

Alan,

I am not using the CSL APIs. I write directly to the IER register with something like:
IER |= 0x8000;

Looking at the CSR register at the end of main(), I saw that the GIE bit was getting set. I found where it was getting set and changed it. Now, reading the CSR register at the end of main() shows that the GIE bit is not enabled; however, this did not fix the problem. Also, this caused an issue with an McBSP overrunning and the ISRs based on its DR and DX lines never occurring.

For the sake of time, we won't be pursuing this further and are going with the current fix of first initializing the timer to a low frequency and reinitializing it to the desired frequency in the ISR.

Thanks for your help.

-Chris

Signalogic

Alan-

As Chris mentions, we feel fortunate to have found a reliable work-around so we'll stay with that.

We have several ISRs, all high rate.  A one-shot task that enables serial ports, GPIO, and interrupts "some time" after BIOS init completes is something we might try later on.

Thanks for your help.

-Jeff

Signalogic