Using an USB_SOF_HOOK macro (only one instruction: sbi PINB,1 ) in order to toggle PB1 for testing SOF detection, instead of getting a square wave signal on output pin 1, a narrow pulse appears in every 1 ms. The pulse width is less then 100us. Actually it is around 5us.
Can the USB driver of the device detect 2 SOF instead of 1 in every 1ms? How can I eliminate it?
During a data exchange between host and device the PB1 pulse polarity changes several times, but between two data exchange the polarity is stable. It seems to have a second SOF detected following by 100us the first one, but some times only a single SOF is detected.
The PB1 signal sequence looks like:
1ms rate: ........|......|......|......|.......|......|.......|....
PB1 output: L...LHL...LHL...LHL...LHH...HLH...HLL...LHL...
The expected PB1 sequence would be:
PB1 output: L...LHH...HLL...LHH...HLL...LHH...HLL...LHH...
(I am using a HID application based on ATtiny45. The USB D- and D+ lines are connected to PB3 and PB4 respectively. The application uses PB0 and PB2 as input, PB1 as output, PB5 as reset. Only pin change interrupt on D- is used. The HOST exchanges data with the device in every 400ms.
The main parameter setings:
#define USB_CFG_HAVE_INTRIN_ENDPOINT 1
#define USB_CFG_HAVE_INTRIN_ENDPOINT3 0
#define USB_CFG_EP3_NUMBER 3
#define USB_CFG_SUPPRESS_INTR_CODE 0
#define USB_CFG_INTR_POLL_INTERVAL 10
#define USB_CFG_IMPLEMENT_FN_WRITE 1
#define USB_CFG_IMPLEMENT_FN_READ 1
)
2 SOF detection in 1ms
-
exuvo
Re: 2 SOF detection in 1ms
sbi does not toggle: "Set Bit in I/O Register" "I/O(P,b) ← 1"
So really it should be High(1) all the time, you must have something else setting it Low(0).
So really it should be High(1) all the time, you must have something else setting it Low(0).
Re: 2 SOF detection in 1ms
I summarize the problem again:
- Since the USB host sends Start-Of_Frame (SOF) packet to the device in every 1ms, I want to detect the arriving of SOF packets to the device. I thought, there is only one SOF packet in each 1ms time interval, but using the SOF detection capability of the V_USB software, I found, sometimes it detects more then 1 in 1ms.
To see SOF on oscilloscope I defined the myUSB_SOF_HOOK macro to contain the instruction “sbi PINB,1”. This instruction toggles PB1 pin (if its direction is set to output) when SOF is detected. But instead of getting a square wave signal on PB1 with 50% duty cycle and 2ms cycle time, I got a narrow spike in every 1 ms. It means, that an SOF detection is followed nearly immediately with an other SOF detection.
My question is:
How can I detect only the first SOF in each 1ms period?
- Since the USB host sends Start-Of_Frame (SOF) packet to the device in every 1ms, I want to detect the arriving of SOF packets to the device. I thought, there is only one SOF packet in each 1ms time interval, but using the SOF detection capability of the V_USB software, I found, sometimes it detects more then 1 in 1ms.
To see SOF on oscilloscope I defined the myUSB_SOF_HOOK macro to contain the instruction “sbi PINB,1”. This instruction toggles PB1 pin (if its direction is set to output) when SOF is detected. But instead of getting a square wave signal on PB1 with 50% duty cycle and 2ms cycle time, I got a narrow spike in every 1 ms. It means, that an SOF detection is followed nearly immediately with an other SOF detection.
My question is:
How can I detect only the first SOF in each 1ms period?
-
EmbeddedCreations
- Posts: 4
- Joined: Sun May 13, 2012 11:37 pm
Re: 2 SOF detection in 1ms
I had the same issue as you, and was using the SOF hook to capture the value of a timer and clear it. I skipped the extra run through the hook routine by looking for a low timer value and jumping past the rest of the code in the routine if the value was too low.
Hope that helps (maybe not you, but someone else searching for an answer to this issue)
Hope that helps (maybe not you, but someone else searching for an answer to this issue)
Re: 2 SOF detection in 1ms (SOLVED!!!)
I have received from OBDEV expert a correct answer for my original problem as follows: ( 
)
>>
>>This behavior does not surprise me, since the SOF detection does not actually
>> trigger on SOF but rather on malformed sync patterns.
>> If we see an edge, but can't detect a valid sync pattern, we assume it's
>> a SOF spike. We don't have the time to identify SOF correctly, the
>> pulse is long over when the interrupt handler executes.
>>
>> Furthermore, SOF pulses are frequently followed immediately by
>> valid data packets. If you do some SOF processing (even if it's only a couple
>> of instructions), you miss the data packet.
>>That's not a problem because the host will retry the packet.
>> However, the remainings of the packet trigger another USB interrupt and
>> at that point we usually can't detect a valid sync pattern.
>> This makes us believe that it's another SOF pulse.
>>
>> This is not a problem for our purposes of SOF detection since we do a kind of PLL
>> synchronization only. If the SOF time is far from the expected value, we simply
>> ignore it.
>>
>> If you need precise timing, I would recommend that you do the same.
>> Use the built-in oscillator to set a reasonable window for the distance between
>> SOF pulses. This will eliminate the second one.
>>
>> BTW: Whether or not there is a second SOF detected depends on the host/hub
>> implementation.
>>
>>
>>This behavior does not surprise me, since the SOF detection does not actually
>> trigger on SOF but rather on malformed sync patterns.
>> If we see an edge, but can't detect a valid sync pattern, we assume it's
>> a SOF spike. We don't have the time to identify SOF correctly, the
>> pulse is long over when the interrupt handler executes.
>>
>> Furthermore, SOF pulses are frequently followed immediately by
>> valid data packets. If you do some SOF processing (even if it's only a couple
>> of instructions), you miss the data packet.
>>That's not a problem because the host will retry the packet.
>> However, the remainings of the packet trigger another USB interrupt and
>> at that point we usually can't detect a valid sync pattern.
>> This makes us believe that it's another SOF pulse.
>>
>> This is not a problem for our purposes of SOF detection since we do a kind of PLL
>> synchronization only. If the SOF time is far from the expected value, we simply
>> ignore it.
>>
>> If you need precise timing, I would recommend that you do the same.
>> Use the built-in oscillator to set a reasonable window for the distance between
>> SOF pulses. This will eliminate the second one.
>>
>> BTW: Whether or not there is a second SOF detected depends on the host/hub
>> implementation.
>>