Netdcu8 external interrupt behaviour, throughput the system

andyinfsnet · Sep 27th 2010

Hello

For a future application I needed to test external interrupt capabilities of a Netdcu8. For this I connected a signal generator as interrupt input source to J5 Pin2 and measure
J5 Pin 7 (configured as output) with a scope. On interrupt rising edge at input Pin 2 I clear output Pin 7 and at interrupt falling edge I set it to high.
With this I want to see the time behaviour "through the system" without load and later under load.

So the first test was to apply some "easy" frequency input in the sub KHz area, around 158Hz. What I realized on scope was surprising me.
I speak now from the rising edge only. I saw a non surprising Jitter of about 250us(microseconds) where the output signal follows the input rising edge, this was something expected when reading the www, they give you values like this.
But then, approximately 900us later in time there is also 250us Jitter area where the output signal comes low.
Unfortunately I am not able to insert my scope picture here. I could send the scope picture per email if it helps.
I think this beavoiur is not ok. Could anyone explain this? I post the code, but this is nothing special, same as in F&S manuals. But may be you find something bad.
By the way, no other software was running, so ther was nearly no other system load.

C

// Test Netdcu8 interrupt J5 Pin 2
/*
registry settings
reg open \drivers\builtin\digitalio
reg set value port dword 0
reg set value index dword 0
reg set value UseAsIO DWORD 0x00ff0fff
reg set value DataDir DWORD 0x00000f1f
reg set value DataInit DWORD 0x00000000
reg set value IRQCfg0 DWORD 0x000000e0
reg set value IRQCfg1 DWORD 0x000000e0
reg set value IRQCfg2 DWORD 0x00000000
*/
#include "stdafx.h"
#include "DIO.h"
#include "dio_sdk.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
////////////////////////////////////////////////////////////////////////////////////////
extern "C" BOOL InterruptInitialize(DWORD idInt, HANDLE hEvent, LPVOID pvData, DWORD cbData);
extern "C" VOID InterruptDone( DWORD idInt );
extern "C" VOID InterruptDisable( DWORD idInt );
// EXTERN INTERRUPTS NetDCUX ///////////////////////////////////////////////////////////
#define SYSINTR_FIRMWARE (8+8)
#define SYSINTR_PIFIRQ (SYSINTR_FIRMWARE+15)
#define SYSINTR_EXTIO (SYSINTR_FIRMWARE+16)
/////////////////////////////////////////////////////////////////////////////////////////
#define TRIGGER_EDGE 1 // NetDCU6 only (extern interrupts via dio port pins)
#define TRIGGER_LEVEL 2 // NetDCUX
#define TRIGGER TRIGGER_EDGE
CRITICAL_SECTION cs; /*switch port*/
HANDLE hDIO;
bool fContinue=true;
int runcnt=0;
int runcntOld=runcnt;
int f;
HANDLE hIsrEvent=INVALID_HANDLE_VALUE;
bool STOP=false;
int _tmain(int argc, _TCHAR* argv[])
{
bool toggle=false;
RETAILMSG(1, (_T("(START)\r\n")));
DWORD WINAPI Stopper_Thread (PVOID pArg);
HANDLE hStopper_Thread = CreateThread (NULL, 0, Stopper_Thread , 0, 0, 0);//make a interupt service thread
hIsrEvent =CreateEvent( NULL, FALSE, FALSE, _T("ISR_Pin2") );
hDIO = CreateFile(_T("DIO0:"), GENERIC_WRITE, 0,NULL, OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL, NULL );//handle to file I/O
if( hDIO == INVALID_HANDLE_VALUE )
{
RETAILMSG(1, (_T("(Last error %i)\r\n"),GetLastError()));
fContinue=false;
return false;
}
DWORD dwIRQ, dwSysIntr;
// Pin 2 is Bit 7 in DIO mask
dwIRQ = 7;
if( !DeviceIoControl( hDIO,IOCTL_DIO_REQUEST_SYSINTR, &dwIRQ, sizeof(DWORD),&dwSysIntr, sizeof(DWORD), NULL, NULL ) )
{
ERRORMSG(1,(_T("Error initializing interrupt, InitInterrupt() failed (%d)\n\r"),GetLastError()));
fContinue=false;
return (FALSE);
}
if (!InterruptInitialize( dwSysIntr,hIsrEvent,NULL, 0 ))
{
ERRORMSG(1, (_T("Error initializing interrupt, InitInterrupt() failed (%d)\n\r"),GetLastError()));
fContinue=false;
return (FALSE);
}
InterruptDone( dwSysIntr );
CeSetThreadPriority( GetCurrentThread(), 1);
while( runcnt<70000 && STOP==false )
{
switch(WaitForSingleObject( hIsrEvent, INFINITE ))//wait for irq
{
case WAIT_OBJECT_0:
if(STOP==true)break;
if(!toggle)
{
runcnt++;
toggle=true;
BYTE pin = 2;
DeviceIoControl(hDIO, IOCTL_DIO_CLR_PIN, &pin, 1, NULL, 0, NULL, NULL);//clear output J5 pin7
}
else
{
toggle=false;
BYTE pin = 2;
DeviceIoControl(hDIO, IOCTL_DIO_SET_PIN, &pin, 1, NULL, 0, NULL, NULL);//set output J5 pin7
}
break;
case WAIT_TIMEOUT:
break;
default:
break;
}
InterruptDone( dwSysIntr );
}
//InterruptDisable(dwSysIntr);
// release sysintr
DeviceIoControl( hDIO, IOCTL_DIO_RELEASE_SYSINTR,&dwSysIntr, sizeof(DWORD), NULL, 0, NULL, NULL );
if(hDIO!=INVALID_HANDLE_VALUE)
CloseHandle(hDIO);
if(hIsrEvent!=INVALID_HANDLE_VALUE)
CloseHandle(hIsrEvent);
return 0;
}
DWORD WINAPI Stopper_Thread (PVOID pArg)
{
HWND hWnd;
hWnd = (HWND)pArg;
while (fContinue)
{
Sleep(1000);
if(STOP)SetEvent(hIsrEvent);//Set from debugger a breakpoint and STOP=true to close properly
}
return 0;
}

Display More

fs-support_HK · Sep 29th 2010

Well, this is really odd. I had a quick look into the DIO driver source and there is nothing that can block the IOCTL_DIO_CLR_PIN and IOCTL_DIO_SET_PIN functions at all. Therefore I don't see what can cause this long delay. However we had some issues with edge triggered interrupts that were solved in Kernel 1.37 (080602). So are you sure that you use a sufficiently new kernel?

Two comments about your code:

- The check for STOP in your loop does not work. The break there does only break the switch, but not the while loop.
- InterruptDone should only be done in case WAIT_OBJECT_0.

andyinfsnet · Sep 29th 2010

I tried user defined Kernel from 15.3.10 and I tried V1.45 Kernel. Behaviour is the same.

The STOP workÃ‚Â´s fine, why donÃ‚Â´t you believe? It is set by debugger to true with a breakpoint.

I will think about InterruptDone() to use only in WaitForSingleObject(). I am not sure what happens If I leave WaitForSingleObject() without a real interrupt.
After this, no interrupt would be possible without reboot.

Have you made already such test like I described with signal generator at input and scope at an output?

Or could be some issue with wiring of my input signal? I use a standard signal generator TTL output and wire that via a 1k resistor to the
3,3V input of Pin2. Pin 2 doesnÃ‚Â´t need a pull up, so you desrcibed it in your documents. I measure 3,4V at the input of Pin2.

fs-support_HK · Sep 29th 2010

Quote from "andyinfsnet"

I tried user defined Kernel from 15.3.10 and I tried V1.45 Kernel. Behaviour is the same.

That's sad. I hoped using a newer kernel would be the solution.

Quote

The STOP workÃ‚Â´s fine, why donÃ‚Â´t you believe? It is set by debugger to true with a breakpoint.

Ah, OK, I missed the additional check for STOP in the while condition. So yes, you're right, STOP is working.

Quote

I am not sure what happens If I leave WaitForSingleObject() without a real interrupt.

If there really was no interrupt, there is no problem at all. But think of the following case. Assume your call to WaitForSingleObject() returns with a value different to WAIT_OBJECT_0, for example with WAIT_TIMEOUT while using a real timeout, not INFINITE. But immediately after this return from WaitForSingleObject() while running your code and right before your call to InterruptDone(), the interrupt does actually happen. If you call InterruptDone() now, then you're acknowledging an interrupt that you haven't actually seen and handled in your thread yet. Doing this, you might miss an interrupt because the kernel thinks it can already signal the next interrupt while you still need to be signaled about the current interrupt.

Quote

Have you made already such test like I described with signal generator at input and scope at an output?

I'm sorry, but we don't have the time right now to do such a complex test on such a rather aged platform like the NetDCU8. But I have the following suggestion. In WinCE 5.0, there still were all the remote tools included with Embedded Visual C++ (menu "Tools"). Try to connect the Kernel Tracker for a few seconds when running your program. The Kernel Tracker will log the task switches of the program and shows this as a rather useful graphic. Probably you'll find out yourself what process/thread causes the delay. Only connect for a short period of time as the amount of collected data is tremendous. You should see a regular switch to your thread with every interrupt edge, but some of these entry points will be delayed. These are the interesting points. Check what thread/process caused this delay, i.e. what thread is running before finally switching to your thread. Maybe you need to output the thread ID in your program so that you know which is your thread in the Kernel Tracker output.

Quote

Or could be some issue with wiring of my input signal? I use a standard signal generator TTL output and wire that via a 1k resistor to the
3,3V input of Pin2. Pin 2 doesnÃ‚Â´t need a pull up, so you desrcibed it in your documents. I measure 3,4V at the input of Pin2.

I think, this should work. I see no mistake here.

Share