Click here to go to the forum index Click here for the home page
 
Author Message

<  TAP and patch development  ~  USB interface patch request

Page 1 of 3
Goto page 1, 2, 3  Next
deangelj
Posted: Sat Sep 15, 2007 12:54 am Reply with quote
Frequent contributor Joined: 29 Mar 2005 Posts: 316 Location: Sydney, Australia
Hi guys,

we know that the current firmware has a broken usb firmware interface as far as developing TAPs that respond to USB requests are concerned. Is anyone interested in developing a patch to fix that interface so that developers can build these types of TAPs? I don't know if it can even be done by I do know that I don't have the skills Sad

What do you guys think?

cheers,
john
View user's profile Send private message
R2-D2
Posted: Sat Sep 15, 2007 8:31 am Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
It might be nice if somebody could summarise the problems, and maybe indicate what modified behaviour would be better.
View user's profile Send private message Visit poster's website
deangelj
Posted: Sat Sep 15, 2007 10:51 am Reply with quote
Frequent contributor Joined: 29 Mar 2005 Posts: 316 Location: Sydney, Australia
ok - the quickest way to communicate from a PC to the toppy is via the USB interface. If you talk directly to the firmware then all is well. But as soon as you want to use the API and create a tap to listen on the USB interface and do things, the toppy crashes.

I have a PC based tool that talks to the toppy - I'd like to have a tap that I can communicate with directly instead of having to send "command files" which a tap has to poll for. Additionally with my workaround the disk needs to be spun up for this to work.

So, the basic issue is that when I use the TAP USB API interface the tap crashes. This is a well known issue with the all of the firmwares releases (from my understanding this is still the case). I was wondering whether the f/w could be patched so the API worked... Maybe I'm dreaming Smile

cheers,
John
View user's profile Send private message
R2-D2
Posted: Sat Sep 15, 2007 11:02 am Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
Does the TAPdiskFix patch make any difference? If you're starting & stopping a TAP a lot of times it will (incorrectly) use up the resources which the USB system also uses -- when those resources are gone there will be a problem.
View user's profile Send private message Visit poster's website
deangelj
Posted: Sat Sep 15, 2007 11:12 am Reply with quote
Frequent contributor Joined: 29 Mar 2005 Posts: 316 Location: Sydney, Australia
well the usb issue that I'm not talking about is not about resources cause as you start it and then connect to it from a PC it crashes. Also, the TAP API sample (from Topfield Korea) called usbtest also crashes.

cheers,
John
View user's profile Send private message
R2-D2
Posted: Sat Sep 15, 2007 11:17 am Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
deangelj wrote:
Also, the TAP API sample (from Topfield Korea) called usbtest also crashes.
OK, that sounds like somewhere to start looking.
View user's profile Send private message Visit poster's website
rwg
Posted: Sat Sep 15, 2007 8:34 pm Reply with quote
TAP author Joined: 29 Oct 2005 Posts: 604 Location: Oxfordshire
There is some background in this thread

http://forum.toppy.org.uk/forum/viewtopic.php?t=330

I have to admit that I never got around to trying anything out based on the write only approach Sad

Robin

_________________
Toppy: TF5800PVR; Firmware: 5.13.65 + patches + aXel; Remote: Pronto RU940; Autostart TAPs: MyStuff 6.5 and friends
View user's profile Send private message Visit poster's website
R2-D2
Posted: Sun Sep 16, 2007 10:58 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
Had a look at the callback stuff and it seems that the firmware goes to some lengths to set things up for the TAP's callback to work... but only if exactly one TAP is running! Smile It seems like they might have forgotten to restore the stuff they so carefully set up. If I'm right, problems will occur unpredictably when there are 2 or more TAPs running and calling TAP API functions, with the result being corrupt access to a TAP's globals when a TAP API function returns.

I think it would be easy to fix, if those sound like the correct symptoms.
View user's profile Send private message Visit poster's website
deangelj
Posted: Sun Sep 16, 2007 11:05 pm Reply with quote
Frequent contributor Joined: 29 Mar 2005 Posts: 316 Location: Sydney, Australia
That could be it R2-D2 - I know at least one other person reported that symptom: ie. that it would work ok when only that tap was running. I must admit that I haven't tried that variation since I always had at least 2-3 taps running. I'll try that tonight but it sounds like you could be right!

Thanks for looking at this too.

Cheers,
John
View user's profile Send private message
R2-D2
Posted: Mon Sep 17, 2007 10:27 am Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
Have a crack at this Callback patch, which also fixes the PlayPCM callback in the same way. I've not been able to test whether it works...

I'm not sure if this is well documented, but the USB_Write callback may be called a number of times with 0 size before the write succeeds (and then the callback will be called with the correct size). And I think that the USB_Read callback mechanism is a bit tricky to use for just continuous reads -- it's set up in a way that means you'll probably miss packets unless you ack them (with a USB_Write) to signal to the other end to send another packet. This is because all the callback mechanism is deactivated after a callback -- I suppose there's the possibility of fixing this to make you need to USB_Cancel, or alternatively enabling another callback during the USB_Read callback (by calling USB_Read again -- which won't work at the moment).
View user's profile Send private message Visit poster's website
deangelj
Posted: Mon Sep 17, 2007 10:51 am Reply with quote
Frequent contributor Joined: 29 Mar 2005 Posts: 316 Location: Sydney, Australia
thanks R2-D2 - probably won't get a chance to test this until Wed (Aust time), so I'll give it a go then and get back with the results. Thanks again.

Cheers,
John
View user's profile Send private message
deangelj
Posted: Tue Sep 18, 2007 5:31 am Reply with quote
Frequent contributor Joined: 29 Mar 2005 Posts: 316 Location: Sydney, Australia
R2-D2- I'd welcome a sanity check here if you have some time. I'll be using the usbtest.c sample from Topfield as a starting point. This tap handles a file transfer (receiving a file).

In TAP_Main it calls TAP_Usb_packetread passing the readcallback routine and the buffersize.

In readcallback it gets passed a size parameter but that is never used. It checks that the 32 bit header of the data is one of the ones it is expecting:

USB_CmdHddFileSend || USB_DataHddFileStart || Usb_DataHddFileData ||
USB_DataHddFileEnd

If it is, it sets a flag (A) and exits with a 0 value otherwise it sets a diferent global flag (B) and exits with 1

In the Event Handler, if A is set it calls a routine (Receive) to process the buffer, else if B is set (ie other USB data) it resets the flag and posts another TAP_Usb_packetread

In the Receive routine it does:

While more data
call TAP_usb_packetwrite (null, 0, writecallback, USB_success) //?ack
process the received buffer
call TAP_usb_packetread
if it was and end command exit while
View user's profile Send private message
R2-D2
Posted: Tue Sep 18, 2007 9:00 am Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
deangelj wrote:
I'll be using the usbtest.c sample from Topfield as a starting point.
The first thing that worries me about that example code is the fact that the _usbBuf is freed in TAP_Main(), rather than, say, after the TAP_Exit() -- although the TAP doesn't appear to ever actually exit. So it doesn't look good to start with -- continually running and scribbling all over unallocated memory...
Quote:
If it is, it sets a flag (A) and exits with a 0 value otherwise it sets a diferent global flag (B) and exits with 1
This is to flag to both the TAP and the firmware whether the packet was one this TAP wanted. If the callback returns 0 then the packet was not one it wanted, so it's passed on to other possible recipients (i.e., the firmware). And in this case the callback must also be re-registered, so this must be flagged back to the TAP (since the callback will have been deactivated by the receipt of this packet). You may have now noticed that there is the possibility of missing packets if the system is a bit busy and your TAP doesn't get an EVT_IDLE or do its processing quickly enough.

In my opinion (and I'm not an expert), I'd leave the callbacks active (especially if the packet was not one that was processed), or I'd deactivate them before the callback was processed and allow the callback to re-register itself (or another callback) if necessary.
Quote:
call TAP_usb_packetwrite (null, 0, writecallback, USB_success) //?ack
Yes, that's the ACK to the sender to tell it that it can send another packet. The callback is not really relevant in this case, since it's just a simple ACK packet, but in theory the TAP should wait until it knows that has been sent before it tries reading more packets. However....

...my post about the Write callbacks was wrong. The system will wait for up to 500 ticks for the USB system to be ready for the Write, and if that times out then the Write callback is called with a size of zero. So I was wrong, and the Write callback only ever gets called once. But in the case of the simple PacketWrite commands (which have a "size" of zero, like the USB_Success one above) it will therefore be very hard for a TAP to detect whether they have been successfully written...
View user's profile Send private message Visit poster's website
simonc
Posted: Tue Sep 18, 2007 9:18 pm Reply with quote
Frequent contributor Joined: 12 Apr 2005 Posts: 5640 Location: Cheltenham
This has the potential to be extremely handy. I've never really liked the file based USB communication that TAPs have had to employ for remote timer setting and the like.

I had a bash at circumventing the bug a year ago buy intercepting the callback before it had a chance to crash. However, my MIPS isn't as polished as yours and I couldn't quite make the leap to a generic solution. Even with my fix, I still found USB to be unreliable, mysteriously ceasing to communicate after a period of time. Perhaps this patch will be more successful.
View user's profile Send private message Visit poster's website
deangelj
Posted: Wed Sep 19, 2007 10:42 pm Reply with quote
Frequent contributor Joined: 29 Mar 2005 Posts: 316 Location: Sydney, Australia
R2-D2 wrote:
deangelj wrote:
I'll be using the usbtest.c sample from Topfield as a starting point.
The first thing that worries me about that example code is the fact that the _usbBuf is freed in TAP_Main(), rather than, say, after the TAP_Exit() -- although the TAP doesn't appear to ever actually exit. So it doesn't look good to start with -- continually running and scribbling all over unallocated memory...


yep - you're right - I've changed this to deallocate on exit.

R2-D2 wrote:

Quote:
If it is, it sets a flag (A) and exits with a 0 value otherwise it sets a diferent global flag (B) and exits with 1
This is to flag to both the TAP and the firmware whether the packet was one this TAP wanted. If the callback returns 0 then the packet was not one it wanted, so it's passed on to other possible recipients (i.e., the firmware). And in this case the callback must also be re-registered, so this must be flagged back to the TAP (since the callback will have been deactivated by the receipt of this packet). You may have now noticed that there is the possibility of missing packets if the system is a bit busy and your TAP doesn't get an EVT_IDLE or do its processing quickly enough.

In my opinion (and I'm not an expert), I'd leave the callbacks active (especially if the packet was not one that was processed), or I'd deactivate them before the callback was processed and allow the callback to re-register itself (or another callback) if necessary.


Now this part I don't quite understand. From my reading of the code, it either passes the usb call on to the firmware or processes it but in either case it posts a read?

R2-D2 wrote:

Quote:
call TAP_usb_packetwrite (null, 0, writecallback, USB_success) //?ack
Yes, that's the ACK to the sender to tell it that it can send another packet. The callback is not really relevant in this case, since it's just a simple ACK packet, but in theory the TAP should wait until it knows that has been sent before it tries reading more packets. However....

...my post about the Write callbacks was wrong. The system will wait for up to 500 ticks for the USB system to be ready for the Write, and if that times out then the Write callback is called with a size of zero. So I was wrong, and the Write callback only ever gets called once. But in the case of the simple PacketWrite commands (which have a "size" of zero, like the USB_Success one above) it will therefore be very hard for a TAP to detect whether they have been successfully written...


But isn't this the reason for the ack so that the other end doesn't send anything until it is received? Therefore on the TAP end, if it gets something more then the ack was ok otherwise it should have some sort of timeout?

I did some tests on this yesterday - it took me a while cause I needed to get into the world of firmware patches for the first time so loaded firebird's HDFW tap, patched and reloaded the firmware, then tested the usb tap. It sort of worked but didn't Crying or Very sad - I did get it to receive a file but it would hang randomly. That's why I'm trying to understand what you said cause therein might lie the solution Wink

Cheers and thanks for the help so far.

John
View user's profile Send private message

Display posts from previous:  

All times are GMT + 1 Hour
Page 1 of 3
Goto page 1, 2, 3  Next

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum