Jump to content
IGNORED

Jerry timer and isr


toarnold

Recommended Posts

Next dojo in starting jaguar development.
I tried to figure out how to use a jerry timer. The exercise was to write a subroutine, getting a timer divider, a cancellation token, and an updateable counter. So it can be called from C:

typedef void(*TimerHandler)(uint32_t time, uint32_t *cancellationToken, volatile uint32_t *count);

Jerry should update the counter per interrupt until the host writes a value !=0 to the cancellationToken than Jerry has to stop.

 

The ISR (Timer0 [interrupt 2] - remember to start ISR at D_RAM + 32) should look like (compare v8.pdf)

dsp_int:        
		load    (r28),r29               ;get dsp flags
        bclr    #3,r29                  ;interrupt serviced
        load    (r31),r30               ;get return from stack
        bset    #11,r29                 ;clear int source flag
        addq    #4,r31                  ;update stack
        addq	#2,r30                  ;update return address

		; custom Code start
		load	(r27),r26
		addq	#1,r26
		store	r26,(r27)
		; custom Code end

        jump    (r30)                   ;return from int
        store   r29,(r28)               ;set dsp flags

The main loop in Jerry is very strait forward:

jwaitloop:
		load	(r9),r25
		cmpq	#0,r25				; Test cancellation Token
		jr		eq,jwaitloop
		nop

First of all I find out my ISR never was executed, because I am writing the JPIT1 divider from a running Jerry. This didn't work. Set JPIT1 before starting Jerry!

The second error was a little bit harder to detect. The program is running, but after a few seconds Jerry terminates himself by aborting the jwaitloop, but r25 was zero!

This error can only happens if the interrupts occurs between the cmpq and the jr in the mainloop and the ISR isn't restoring the flags correctly.

So I exchanged the last two line of the ISR and place a nop after the jump:

        store   r29,(r28)               ;set dsp flags
        jump    (r30)                   ;return from int
		nop

So my conclusion is. There is an error in the v8.pdf or the DSP. Under some circumstances the pipelined instruction after the jump isn't executed correctly, so the FLAGS restored wrong.

 

Attached is my Visual Studio 2013 solution (it can build by commandline, too), so you can test by yourself

 

- toarnold

JerryTimer.zip

  • Like 1
Link to comment
Share on other sites

All Atari code restores the flags AFTER the jump. In fact, it (correctly) points out that if you enable ints any other place but after the jump, another int can occur and corrupt the registers (in particular, r30 - the register you're getting ready to jump through), leading to a crash. For example, here's the int exit code for the Jerry CD audio:

 

clean_up:			; do the housekeeping, per Leonard
	bclr	#3,r29		; clear IMASK
	bset	#10,r29		; set I2S interrupt clear bit
	load	(r31),r28	; get last instruction address
	addq	#2,r28		; point at next to be executed
	addq	#4,r31		; update the stack pointer
	jump	(r28)		; and return
	store	r29,(r30)	; restore flags
Something else must be causing the crash, not the restore after jump.
  • Like 2
Link to comment
Share on other sites

I agree with you and my understanding is the same, But can you try to reproduce the error? In fact in my sample the interrupt occurs every second. So I can't believe a second interrupt occurs. The error occurs randomly between 1..30 seconds on my jag.

I don't believe it is a crash, 'cause the code after the jwaitloop executed correctly.

Changing the cancellation code to

jwaitloop:
		load	(r9),r25
		cmpq	#1,r25				; Test cancellation Token
		jr	ne,jwaitloop
		nop

seems to heal the error ...

I'learn, so if someone can point me the error I'll very happy .

 

- toarnold

Link to comment
Share on other sites

Your setting the flags early doesn't crash because the int doesn't occur until much later. If other ints could occur, it could fail. What I think might be the problem with the correct order is this (from the doc):

 

If Jerry asserts DSP bus request one cycle after a previous bus request it is possible for it to

see the end of the previous bus grant for one cycle, and this can mean that Jerry writes occur

with the wrong data. The work-around is to ensure that Jerry is off the bus before performing

a write, either by leaving a long period of bus inactivity, which is usually greater than the

maximum possible period of object processor bus ownership; or to perform a load and perform

an operation on the loaded data so that the score-board unit can ensure the load has completed.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...