Home	Forums	What's new	Resources

On-chip peripheral module interrupts?

mrkotfw - Jun 20, 2012

		mrkotfw		Jun 20, 2012
			I'm looking to have the SuperH generate an interrupt for when a transfer in the DMAC is complete. I enabled interrupts (bit 2 in CHCR0 and CHCR1). I also set the vector number (ranges from 0-127) in register VCRDMA0 and VCRDMA1. I then set the vector, say 127 to the interrupt handling routine. That amounts to writing to address VBR + (127 << 2) where VBR is 0x06000000. For the life of me, I can't get INTC to generate the interrupt. Is there anything special about these on-chip interrupts? Why does it range from 0-127? Wouldn't it conflict with other predefined interrupts?

		antime		Jun 20, 2012
			The obvious question first, have you made sure the interrupt isn't masked based on SR register priority? Have you verified that the transfer completes successfully?

		mrkotfw		Jun 20, 2012
			antime said: The obvious question first, have you made sure the interrupt isn't masked based on SR register priority? Have you verified that the transfer completes successfully? I've only verified this on Yabause. Right now, I'm verifying on real hardware. Yes, I've set IRPA to the highest priority as well as unmasking on the SR register (value of 0x00) I'm seeing that I'm getting a CPU address error in my DMAC code. I'll report back in a few.

		mrkotfw		Jun 20, 2012
			mrkotfw said: I've only verified this on Yabause. Right now, I'm verifying on real hardware. Yes, I've set IRPA to the highest priority as well as unmasking on the SR register (value of 0x00) I'm seeing that I'm getting a CPU address error in my DMAC code. I'll report back in a few. Yeah, I'm seeing why there's no interrupt being generated. The transfer count is still non-zero (TCR0). Both the enable bits in DMAOR and CHCR0 are set. The error bits AE and NMIF look to be unset.

		mrkotfw		Jun 20, 2012

		mrkotfw		Jun 20, 2012
			mrkotfw said: I completely forgot about enable auto-request mode. That starts the transfer and finishes. Now it's time to check whether or not the interrupt is really masked...

		mrkotfw		Jun 20, 2012
			Yes, it works now. I didn't enable auto-request mode and I had the priority set backwards in the IRPA register.

		mrkotfw		Jun 21, 2012
			Just a FYI In the IHR, save all the registers that you're going to use. After returning from the IHR, I clobbered one of the registers with 0xFFFFFF0F. It just so happened that the previous value was 0x25F80004, the TVSTAT register. Needless to say, I was dereferencing that causing an invalid CPU address exception. Fun

		Chilly Willy		Jun 23, 2012
			Interrupt handlers are always fun to work on, especially when trying to minimize register usage so that you aren't stuck saving/restoring ALL the registers.

		mrkotfw		Jun 24, 2012
			Chilly Willy said: Interrupt handlers are always fun to work on, especially when trying to minimize register usage so that you aren't stuck saving/restoring ALL the registers. Yeah, it's actually pretty fun. You have to be somewhat creative. It's helped me realize how to do basic optimizations on the Saturn. In between loads and stores, you can insert instructions to decrease the amount of stalls in the pipeline as well as avoiding any data hazards Back to topic... How the first 0x1000 bytes in High-Work RAM is rather weird. The first 0x400 are dedicated to the vector table, and yet, there are a few vectors that are used as routines left over from the BIOS boot up.

		Chilly Willy		Jun 24, 2012
			mrkotfw said: Back to topic... How the first 0x1000 bytes in High-Work RAM is rather weird. The first 0x400 are dedicated to the vector table, and yet, there are a few vectors that are used as routines left over from the BIOS boot up. Yeah, I thought that was a bit odd when I saw that. Other than the two vector tables, the 32X doesn't reserve any of the SDRAM for anything. The vector tables are also embedded in the rom along with the start code - the 32X BIOS copies the tables, start code, and whatever data you specify into the SDRAM on startup. Another odd thing about the Saturn is they embedded the SH2 stacks around the vector tables instead of putting them at the end of the ram like you normally find. That's more like the SEGA CD where they do the same thing with the CD 68000 stack. That's why the standard SEGA startup for the Saturn used the address 0x06010000 - that left enough stack for the main SH2. Of course, if you use too much stack, you'll walk on the BIOS vectors and the vector table.