Is it possible to detect  NAKed IN transactions?

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Is it possible to detect  NAKed IN transactions?

跳至解决方案
788 次查看
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 解答
648 次查看
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 回复数
649 次查看
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 项奖励
回复
648 次查看
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 项奖励
回复