Is it possible to detect  NAKed IN transactions?

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Is it possible to detect  NAKed IN transactions?

ソリューションへジャンプ
854件の閲覧回数
dgalbarra
Contributor I

Hi all

 

I am using AN3564 USB Stack with a HCS08JM32  microcontroller, and I have successfully configured an Interrupt endpoint on EP1. The Host is supposed to initiate an IN transaction every 10 ms, and when the device has some data to send, It can be detected at USB_Transaction_Handler, at this line:

 

void USB_Transaction_Handler(void)

unsigned char stat = STAT;

 

...

if( (stat &0xF8) == 0x18){

//this is an IN transaction at Endpoint 1

...

}

 

But now I would like to detect all the NAKed IN Transactions, because I pretend the device to notice if USB Host is disconnected by some reason. I know I could detect that with the SOF packets, but I'm trying to detect an strange condition where the Host stops sending the IN Transaction but remains connected and sending the Start Of Frame packets.

 

Does anybody know If it is possible to detect the NAKed IN transactions?

 

Thanks for your help!

ラベル(1)
0 件の賞賛
返信
1 解決策
714件の閲覧回数
Tsuneo
Contributor IV

Unfortunately, the USB SIE on JM32 doesn't report NAKed transaction to firmware side.
You may detect absence of IN transaction by delay of completion of the armed IN endpoint.

Usually, you'll write the firmware code flow, so that any trouble on USB communication doesn't disturb your main code flow. If the IN endpoint is still occupied by the last data, the firmware just drops new data over the IN endpoint, until the IN pipe recovers.

To recover the IN pipe, host may put one of these requests.
- Pipe reset - Clear_Feature( ENDPOINT_HALT )
- Reset Configuration/Interface - Set_Configuration or Set_Interface
- Device reset - bus reset

When the firmware receives these requests, it initializes the IN endpoint.

Tsuneo

元の投稿で解決策を見る

0 件の賞賛
返信
2 返答(返信)
715件の閲覧回数
Tsuneo
Contributor IV

Unfortunately, the USB SIE on JM32 doesn't report NAKed transaction to firmware side.
You may detect absence of IN transaction by delay of completion of the armed IN endpoint.

Usually, you'll write the firmware code flow, so that any trouble on USB communication doesn't disturb your main code flow. If the IN endpoint is still occupied by the last data, the firmware just drops new data over the IN endpoint, until the IN pipe recovers.

To recover the IN pipe, host may put one of these requests.
- Pipe reset - Clear_Feature( ENDPOINT_HALT )
- Reset Configuration/Interface - Set_Configuration or Set_Interface
- Device reset - bus reset

When the firmware receives these requests, it initializes the IN endpoint.

Tsuneo

0 件の賞賛
返信
714件の閲覧回数
dgalbarra
Contributor I

Thanks for the answer, Tsuneo! This was what I was supposing... there was no info on Datasheet about this, and no flag at interrupt register....

 

I guess the idea is not to disturb the application with "useless" info (as the NAKed In transactions), but sometimes this info could also be important!

 

I will do as you said, see the delay when trying to put an IN transaction on Endpoint. If I see that a lot of time has passed since I put the message on buffer, I will assume the polling of Interrupt endpoint has stopped.

 

Thanks!

0 件の賞賛
返信