This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Countless VDINT0 interrupts per second

Anonymous
Anonymous


Hi All,


I would like to report a very strange behavior on VDINT0 interrupt on 6437.

According to the document description, VDINT0 follows every VD, for which there should be 60 VDINT0 interrupts (NTSC's BT.656 sampling) every second. But I record hundreds of thousands of them.

I have configured the interrupt control register to map VDINT0, whose event number is 24, to CPUINT4 by the follow code:

Interrupt controller configuration said:

extern far unsigned int ISTP_START;
extern cregister volatile unsigned int ISTP, IER, ISR, CSR;

#define INTMUX1    *( volatile Uint32* )(0x01800104)

main()
{
 ISTP = (unsigned int)(&ISTP_START);
 IER |= (1<<4) + (1<<1);  // set INT4 and NMIE
 CSR |= 1; 
 
 
 INTMUX1 = 24; // maps

  ...
}

And I have added a global counter within the ISR to count the number of VDINT0 interrupts:

interrupt service routine (ISR) said:

//global variables, initialized to 0
int count_int=0; 
long long count_long_long=0;

interrupt void my_isr()

  count_int++;
  count_long_long+=1;
}

This my_isr() is extremely short so there is no possibility for nesting, or interrupting with other code. Contrary to my expectation that both counters (use two like a double check) should increment with every new field which is 60 per second, they actually increase their value for over 100000 per second, almost unbelievable.

Here is the screenshot showing very large quantity after seconds of running:

           

             
As a comparison, and also to ensure that the interrupt controller is configured and working properly, I map VPBE's VENCINT to CPUINT4, which also indicates end-of-frame event. In this way my_isr() is being triggered by VENCINT which happend 60 times per second. The experiment runs as expected and the following screenshot show the counter value after around about 4 seconds:

                             

                                     
To summarize:
1. If CPUINT4 mapped to VPBE's VENCINT, everything is fine.
2. If CPUINT4 mapped to VPFE's VDINT0, the counter seems to show that there are hundreds of thousands of VDINT0 interrupts per second.

Does any one know the cause or could provide any suggestion?

Another question is that do I need to capture all these interrupts myself, rather than using DSP/BIOS? Could there be any pitfall in doing this?

 

 

Sincerely,
Zheng

  • Hi,

    Below is the tip from our designer. Hope this is the case and it can be solved by shifting the location of interrupt...

     

    The VINT0 fires every time the line counter hits the number specified in the VINT0. The line counter is cleared on every rising edge of the Vsync pulse. The Vsync is generated by sampling the V bit in the BT stream every SAV packet. If the V bit is toggling during the blanking period we could keep resetting the counter but for a properly formatted 656 stream we should see it as 1 per frame. If this is the case if they set VINT0 to say 2 instead of 0 you probably could miss any strange behavior on V bit during the blanking period.
     

     

    regards,

    Sang-Yong

  • Anonymous
    0 Anonymous in reply to SANG-YONG

    Dear Sang-Yong,

    Thanks for the update. I seem to get some clue on this and I will report it if I get the problem solved.

     

    Regards,

    Zheng

  • Anonymous
    0 Anonymous in reply to SANG-YONG

    This is an update on the question:

    The cause of the problem has been identified to be an erroneous CCDC register setting in the example code provided with the EVM to me. The EVM is from a third party provider, not TI or Spectrum. In page 127 of TMS320DM643x DMP Video Processing Front End (VPFE) User's Guide, SPRU977a, CCDC.SYN_MODE.VDHDOUT (bit 0) is described as:

    VDHDOUT VD/HD sync direction.
    0 Input
    1 Output

    For BT.656 stream which has embedded VD/HD sync signal within SAV/EAV bits, the VDHDOUT register should be set to 0 (input). However, they set that as 1 (output) in the default initialization code.

    Not sure if the 6437 chip has some internal "error correcting/tolerance" capability such that even with this opposite VD/HD direction setting, VPFE could still send the data to the correct address and VPBE also output it correctly. But when I tried to capture the interrupts, CCDC sends me around 500,000 interrupts per second. After I corrected VDHDOUT to 0 (input), everything went back to normal and CCDC gives exactly 60 VDINT0 interrupts for NTSC BT.656 stream.

     

    Zheng

     

  • Hi Zheng,

     It is good to hear that you solved the problem

    Also, I appreciate your detail summary. It will definitely help community people.

    Please keep posting if you see/ solve any interesting issues.

     

    Thank you.

    Regards,

    Sang-Yong

     

     

  • Anonymous
    0 Anonymous in reply to SANG-YONG

    Dear Sang-Yong,

    I am just happy for eventually being able to get this solved. The VDHDOUT problem proved to be the biggest hindrance I have encountered so far and there is really no triviality in the setting of each single register bit.

    Zheng