No HID interrupt IN transfers

Ah, you have to fix EP1 OUT, too.

Endpoint Descriptor 01 1 Out, Interrupt
...
6 bInterval 1 00h

Tsuneo

Earlier I did set the interval values for the EP1 descriptors to 0x20. So on your advise, I restored these values. The reason I set those to 0 was because I saw the following SetIdle packet passing by:

Offset Field Size Value Description
0 bmRequestType 1 21h
 4..0: Recipient  ...00001  Interface
 6..5: Type  .01.....  Class
 7: Direction  0.......  Host-to-Device
1 bRequest 1 0Ah Set Idle
2 wValue.LowByte 1 00h Report ID
3 wValue.HiByte 1 00h Infinite Idle Rate
4 wIndex 2 0000h Interface
6 wLength 2 0000h

The OS HID driver sent it to my device. So I thought I could set it 0 already in the EP descriptor.

Anyway, even if I define bInterval by 0x20, I still can't send interrupt IN transfers to my device. The MSC interface has no problems sending IN-OUT bulk transfers. Strange... I used Jan Axelsson's Generic HID tester to test.

> I suppose this is your story, isn't it?

Tsuneo, right on the spot! Indeed filling in the code for USB_Configure_Event() started the EP1 IN polling. Thank you a lot for pointing it out to me, I don't think I would have found it myself.

Actually, I had to increase EP1-IN wMaxPacketSize from 6 (the size of the report) to 8. I was under the impression that wMaxPacketSize should be large enough to contain the report size (in my case 6). Can you advise me for the optimal wMaxPacketSize?

Another issue I encounter is that my application seems to miss some GetReports(). Probably because my application polls the reports less often then the host does. But I'm convident I can sort this out myself :)

The evil of this HID example is that it gives a fixed idea - read/write of endpoint buffer should be done just in the endpoint ISR. It's wrong. Rather, read/write in the endpoint ISR is a rare case in the real world code.

Consider on UART. If you would see a UART example in which UART TX ISR seamlessly puts character one after another, what do you think of the quality of the example? Is the example practical? Never. You'll take it that a beginner have made the example.

The quality of this Keil HID example is in such a level. Not just for Keil. Still low-quality USB examples have been spread out from other compiler/ chip vendors. Isn't it the time to brush them up?

You may write to the IN EP buffer using USB_WriteEP(), any where, any timing as you like (unless the EP buffer is still occupied by the last write). For example, you may write to the IN EP buffer in a timer ISR, which scans ports for keypads. You may write in ADC ISR, just when a sensor input shows change.

These ISRs should have the same priority (FAST/SLOW) as USB ISR, so that USB_WriteEP() calls from both ISRs don't interrupt each other. When you call USB_WriteEP() from main line code, disable USB interrupt temporarily around USB_WriteEP() call. Or make a SWI which calls USB_WriteEP().



> Actually, I had to increase EP1-IN wMaxPacketSize from 6 (the size of the report) to 8. I was under the impression that wMaxPacketSize should be large enough to contain the report size (in my case 6). Can you advise me for the optimal wMaxPacketSize?

wMaxPacketSize field on endpoint descriptor is set to greater or equal to the packet size you exchange. When you exchange 6 bytes, wMaxPacketSize is set to 6, or more. Greater size doesn't do any harm but no benefit. It just reserves more bandwidth on the bus.



> Another issue I encounter is that my application seems to miss some GetReports(). Probably because my application polls the reports less often then the host does. But I'm convident I can sort this out myself :)

Get_Report request is sent from host just when PC app calls HidD_GetInputReport() (Windows XP and later). When the app calls it synchronously, the app is blocked until this call finishes. Then, you'd not miss it.

ReadFile() pulls an input report from the input buffer on the HID PC device driver, which is filled with the reports carried from the interrupt IN endpoint on the device. The number of input reports held in this input buffer is altered using HidD_SetNumInputBuffers(). The default is 32 reports.

Tsuneo

> You may write to the IN EP buffer using USB_WriteEP(), any where, any timing as you like

Aha, now I see that it's a bit tricky to use the ISR to fill the buffer. I rewrote the device firmware to us USB_WriteEP() asynchronously: as soon as data for a new report becomes available, I write a report immediately. And my code got much cleaner now :)

> Or make a SWI which calls USB_WriteEP().

If I'm right, __swi is only available for the RTX kernel, which we don't use. So that leaves my with two options:

VICIntEnClr |= 1 << VIC_USB;   /* Disable Interrupt */
..
VICIntEnable |= 1 << VIC_USB;  /* Enable Interrupt */

or

int was_masked = __disable_irq();
..
if (!was_masked) __enable_irq();

Is one way preferred over the other?

> wMaxPacketSize field on endpoint descriptor is set to greater or equal to the packet size you exchange.

I found the solution to my problem. I defined the packet correctly. But because I used a char* as type for InReport and OutReport, these variables or byte aligned. What I didn't knew was that USB_WriteEP() really needs the buffer to be long-aligned (at least in the implementation I use). So adding __align(4) to the declarations fixed the bug.

> The number of input reports held in this input buffer is altered using HidD_SetNumInputBuffers().

Yes indeed. My application should read all available input reports every cycle, not just one. Then I'll receive all reports and won't miss one.

Thank you Tsuneo, you helped me again! I'm about to round up my project as the code seems stable now :)

No, __swi isn't only available with RTX. The main difference is that RTX reserves a couple of numbers. If I remember correct, __swi(0) to __swi(7) are served by RTX.

Hello,

Use of __swi does not depend on RTX.
The difference is that RTX already contains a SWI handler and SWI functions __swi(0) to __swi(7) are reserved.
If you do not use RTX and want to use SWI functions than you must include an own SWI handler.
Please check example C:\Keil\ARM\Examples\SWI.

Best Regards,
Martin Guenther

You'll find __swi version of USB_WriteEP in Keil USBCDC example, as follows.

C:\Keil\ARM\Boards\Keil\MCB2300\USBCDC

usbhw.h

extern DWORD __swi(8) USB_WriteEP (DWORD EPNum, BYTE *pData, DWORD cnt);

usbhw.c

/*
 *  Write USB Endpoint Data
 *    Parameters:      EPNum: Endpoint Number
 *                       EPNum.0..3: Address
 *                       EPNum.7:    Dir
 *                     pData: Pointer to Data Buffer
 *                     cnt:   Number of bytes to write
 *    Return Value:    Number of bytes written
 */

DWORD __swi(8) USB_WriteEP (DWORD EPNum, BYTE *pData, DWORD cnt);
DWORD __SWI_8              (DWORD EPNum, BYTE *pData, DWORD cnt) {
//DWORD USB_WriteEP (DWORD EPNum, BYTE *pData, DWORD cnt) {
  DWORD n;

  USB_CTRL = ((EPNum & 0x0F) << 2) | CTRL_WR_EN;

  TX_PLENGTH = cnt;

  for (n = 0; n < (cnt + 3) / 4; n++) {
    TX_DATA = *((__packed DWORD *)pData);
    pData += 4;
  }

  USB_CTRL = 0;

  WrCmd(CMD_SEL_EP(EPAdr(EPNum)));
  WrCmd(CMD_VALID_BUF);

  return (cnt);
}

In the background, SWI.s is dragged in from RL_ARM,

;/*****************************************************************************/
;/* SWI.S: SWI Handler                                                        */
;/*****************************************************************************/
;/* This file is part of the uVision/ARM development tools.                   */
;/* Copyright (c) 2005-2006 Keil Software. All rights reserved.               */
;/* This software may only be used under the terms of a valid, current,       */
;/* end user licence from KEIL for a compatible version of KEIL software      */
;/* development tools. Nothing else gives you the right to use this software. */
;/*****************************************************************************/

T_Bit           EQU     0x20

                PRESERVE8                      ; 8-Byte aligned Stack
                AREA    SWI_Area, CODE, READONLY
                ARM

                EXPORT  SWI_Handler
SWI_Handler

                STMFD   SP!, {R12, LR}         ; Store R12, LR
                MRS     R12, SPSR              ; Get SPSR
                STMFD   SP!, {R8, R12}         ; Store R8, SPSR
                TST     R12, #T_Bit            ; Check Thumb Bit
                LDRNEH  R12, [LR,#-2]          ; Thumb: Load Halfword
                BICNE   R12, R12, #0xFF00      ;        Extract SWI Number
                LDREQ   R12, [LR,#-4]          ; ARM:   Load Word
                BICEQ   R12, R12, #0xFF000000  ;        Extract SWI Number

                LDR     R8, SWI_Count
                CMP     R12, R8
                BHS     SWI_Dead               ; Overflow
                ADR     R8, SWI_Table
                LDR     R12, [R8,R12,LSL #2]   ; Load SWI Function Address
                MOV     LR, PC                 ; Return Address
                BX      R12                    ; Call SWI Function

                LDMFD   SP!, {R8, R12}         ; Load R8, SPSR
                MSR     SPSR_cxsf, R12         ; Set SPSR
                LDMFD   SP!, {R12, PC}^        ; Restore R12 and Return

SWI_Dead        B       SWI_Dead               ; None Existing SWI

SWI_Cnt         EQU    (SWI_End-SWI_Table)/4
SWI_Count       DCD     SWI_Cnt

                IMPORT  __SWI_8

SWI_Table
                DCD     SWI_Dead               ; SWI 0 Function Entry used by RTX
                DCD     SWI_Dead               ; SWI 1 Function Entry used by RTX
                DCD     SWI_Dead               ; SWI 2 Function Entry used by RTX
                DCD     SWI_Dead               ; SWI 3 Function Entry used by RTX
                DCD     SWI_Dead               ; SWI 4 Function Entry used by RTX
                DCD     SWI_Dead               ; SWI 5 Function Entry used by RTX
                DCD     SWI_Dead               ; SWI 6 Function Entry used by RTX
                DCD     SWI_Dead               ; SWI 7 Function Entry used by RTX
                DCD     __SWI_8                ; SWI 8 Function Entry
;               ...
SWI_End

                END

Also, LPC2300.s is modified a little to support SWI (SVC)

LPC2300.s

SVC_Stack_Size  EQU     0x00000100



Vectors         LDR     PC, Reset_Addr
                LDR     PC, Undef_Addr
...
...
IRQ_Addr        DCD     IRQ_Handler
FIQ_Addr        DCD     FIQ_Handler

                IMPORT  SWI_Handler

Undef_Handler   B       Undef_Handler
;SWI_Handler     B       SWI_Handler
PAbt_Handler    B       PAbt_Handler
DAbt_Handler    B       DAbt_Handler
IRQ_Handler     B       IRQ_Handler
FIQ_Handler     B       FIQ_Handler

Tsuneo