BradC said...
I assume you mean you get the prop to send data to XP without hyperterminal open and things get ugly?
No, the Prop is only sending when HyperTerm is open. I spoke too soon earlier; still getting sending stopping even with crc checks removed when not touching anything.
BradC said...
Also nasty things happen when you send data to the prop from hyperterminal and you are not calling usb.rx on the prop?
Yes, that's correct.
BradC said...
Will have a play, thanks for the detailed feedback and testing, I really appreciate it.
No problem, I'd like to see it working as much ( perhaps more so on Windows ? ) as you do
Can you send me your main spin routine and a detailed set of steps to reproduce it? I'd love to see it fail here. (There's setting myself up for a fall!)
In any case, I've shaved 3 bit times off the receive data routine (which is about 1/3 the time taken to calculate the CRC).. so that was a prod in the right direction even if it won't immediately help you.
I now write the data to the hub while sending the EOP of the ack packet, rather than writing it all out and then starting to send the ack.. Brings us closer to the spec anyway.
BradC said...
Can you send me your main spin routine and a detailed set of steps to reproduce it? I'd love to see it fail here. (There's setting myself up for a fall!)
It's not far off your own original USB Demo code. Running the 'send only' routine and typing back characters to the Propeller which never does an rx call, it's after the 33rd character sent there's a stall. Suspiciously near the $1F buffer size, but I haven't investigated your code in too much detail.
Test process ( assuming VID/PID already has a device driver ) ...
Unplug USB.
Burn the code.
Switch off Protoboard.
Unplug PropPlug.
Power up Protoboard.
Wait ~ 4 seconds, plug in USB.
Wait for "Bing-Bong" device detected sound ( Thanks Bill, my XP has now stopped giving that )
Launch HyperTerm, select previously saved 'Use COM4.ht' which is what I have it as.
Wait ~ 15 seconds, displays "0 1 2 3 4" etc
Type "a" 32 times, should keep counting
Type "a" 33rd time and output stalls, wait and it starts up again.
Type "a" 32 times, should keep counting
Type "a" 33rd time and output stalls
Keep finger on the "a" key for auto-repeat and Windows grinds to a halt.
Good luck in making it fail - fingers crossed that it will !
Ok, that is expected behaviour and I can reproduce it using linux also.
What is happening is hyperterm (or whatever) is trying to send data, the send blocks waiting for space in the transmit buffer (in the OS) to become available. Hyperterminal obviously has a transmit timeout
and after each character times out as not being able to be sent, it goes back to receiving data (the recovery you noted).. notice no break in the number sequence, it just dumps the queued up buffers in as quickly as possible.
Using minicom under linux, it never recovers (as minicom waits forever for space to become available).
This is normal unfortunately. Not a bug, but a "feature". My copy of XP and hyperterm does not go to 100% CPU under any circumstances and windows does not even blink, but I can see how a program might
do that if it's busy looping waiting for buffer space to become available. Solution of course is to intermittently check to see if there is data to receive and just discard it. If you think about it, using RS232 or
similar, the data gets spat out the port whether you are listening for it or not. Maybe my build of XP or hyperterminal is a little more intelligent in the way it copes with a blocked buffer.
...Further testing.. it does make Hyperterminal very slow to respond and laggy while it's trying to send.. once the send times out (takes a while) then it all returns to normal.
Hyperterminal Version 5.1 (Build 2600.xpsp_sp2_gdr.070227-2254 : Service Pack 2)
usbser.sys 5.1.2600-2180(xpsp2_sp2_rtm.040803-2158)
I've tested with and without the prop-plug connected and I don't notice any difference (as I guess I shouldn't)
I can reproduce exactly your symptoms as described above, but when "Windows grinds to a halt" for you, hyperterminal grinds to a halt for me, windows stays responsive. Hyperterminal then recovers (after anywhere up to 60-90 seconds) and just picks up where it left off.
I can't reproduce the loss of comms errors though. That is perplexing me. I've got 3 different cardbus USB cards (OHCI/EHCI), plus the built in port in the laptop (UHCI), plus the Mac (UHCI/EHCI) and my other laptop (UHCI/EHCI) and it just works flawlessly with all of them. I've even tried it on my server (which is a VIA chipset and prone to bugs).
Did it seem to get more reliable when you commented out the crc16check or was that just an oddity of the test?
I've left it running here and the count has just cracked 4600. I stall it from time to time by holding down a key until it latches up, but it always recovers and picks up where it left off.
Wanna mail me your computer for a week?? [noparse];)[/noparse]
Actually, on that. What _is_ your hardware? Mainboard, chipset and PCI ID's for the USB controller?
Maybe I can scrounge up something locally to reproduce the failure.
Quick question. Do you perchance have a USB keyboard and/or mouse and are they plugged into the same USB bus segment?
Just found a major oopsie where we were receiving ACK packets that were destined for a USB keyboard or mouse (or any other low speed device on that segment), causing major communication packet loss
between the Prop and PC.
Anything from just dropping packets through to enumeration failures... I, of course was always testing it on its own USB bus segment.. as soon as I plugged it into the HUB built into my Mac keyboard things
got real "interesting"
Ok, I hope this is the last major revision coz I've well and truly run out of COG ram in the lowlevel routine.
This had 2 major bugs that prevented it from playing nicely with anything else on the same USB segment. Keyboard/Mouse was the first one, then I plugged it into the same
bus segment as my APC HID/UPS and all hell broke loose. This has passed all regression tests and I can't fault it here. Hopefully it'll solve your problems too [noparse]:)[/noparse]
I had uploaded a half fixed version, but luckily nobody had downloaded a copy when I found the last (I hope) bug, so here is a complete package with the latest code.
BradC said...
What is happening is hyperterm (or whatever) is trying to send data, the send blocks waiting for space in the transmit buffer (in the OS) to become available.
So does the Propeller USB stack always ask for data, or is data sent from the Host and a 'buffer now full' / 'sorry, buffer is full, could not accept data' reply cause the stalling ?
I'm guessing the later because 'rx' and 'rxcheck' do not kick anything to provoke the host into sending data ( or that's handled at the lower level whenever the buffer is not full ). Hence 32 bytes fill the Propeller buffer, then the 33rd does not get accepted, HyperTerm goes to the Land of Nod.
In effect -- The host does stream data out while it can, and then stalls when the Propeller indicates, "now hold on, we have not dealt with the last stuff sent" ? If that's so, it would be possible to have the Propeller USB stack throw away incoming data if the buffer were full and there would consequently be no stalling ( accepting that data would be lost forever ) ? This is not something I'm asking to be implemented, but would probably suit my application.
I'm afraid I'm only slowly getting up to speed on USB - fascinating stuff, and your code has been really beneficial to understanding what's going on, but it hasn't all sunk in yet. Never, ever dreamed I'd be doing anything with bit-banged USB or USB stacks !
BradC said...
Hyperterminal Version 5.1 (Build 2600.xpsp_sp2_gdr.070227-2254 : Service Pack 2)
usbser.sys 5.1.2600-2180(xpsp2_sp2_rtm.040803-2158)
Hyperterminal Version 5.1 (Build 2600.xpsp_sp2_rtm.040803-2158 : Service Pack 2)
usbser.sys 5.1.2600-2180(xpsp2_sp2_rtm.040803-2158) - Same as yours
BradC said...
What _is_ your hardware? Mainboard, chipset and PCI ID's for the USB controller? Maybe I can scrounge up something locally to reproduce the failure.
If I've not given the information you need, just let me know, Win XP innards are as new to me as USB is ...
Celeron 1GHz + 384MB
GA-6VEM motherboard ( GigaByte ) and according to manual ...
Chipset : VT8601T HOST/AGP/Controller + VT82C686B
I/O Control : VT82C686B
And it does look like VIA USB controllers, both USB 1.1 I believe. I have a "motherboard_drivers_chipset_via_4in1433v.exe" on disk which I am sure I had previously installed, but forgot to when I did the re-install a day ago ...
Matching Device Id :
pci\ven_1106&dev_3038&cc_0c0300
Service :
usbuhci
BradC said...
Quick question. Do you perchance have a USB keyboard and/or mouse and are they plugged into the same USB bus segment?"
No, both are traditional PS/2, so my turn for a "...next" retort
I only have one pair of USB ports exposed on sockets so everything on the same Host Hub / Segment; FTDI PropPlug on one, Propeller USB on the other. No passive / active hubs used.
I'll try your latest USB_002 and see how that affects things. I'll then also run the "VIA 4 in 1" chipset driver install and see if that does anything to help.
Many thanks for taking the time to look into this and helping someone who is pretty much still stumbling around in the dark, but the light's getting brighter !
Ok.. what happens with the CDC-ACM driver is this..
Hyperterminal places a byte in the windows transmit buffer. Windows queues up an OUT packet with that byte in it (or up to 8 bytes depending on what is available).
If the prop has buffer space available, it processes the OUT packet and sends an ACK, to let windows know it's all good.
If it does _not_ have buffer space available it sends a NAK, which says to windows.. I'm busy right now and have no way to process that packet, try me again soon.
It will continue to try for all intents and purposes forever sending an OUT and getting a NAK. This is where windows is chucking a wobbly. Your understanding is good young Jedi!
Yes, it would not be terribly difficult to have the app level routine say, buffer full.. have not had space available for 2 seconds, let's chuck the packet away.
I've not done it this way as I built the whole thing from the ground up _not_ to lose _any_ data _ever_.. but I could probably add a timeout there that you can set as an option to allow it to chuck data away.
The easy way though is in your app, just periodically call usb.rxcheck and that will read data from the buffer if there is any to read and just toss it away if you don't do anything with it.
It also won't block if there is nothing to read.
I've been thinking about a timeout in the tx routine also.. as for example in my thermostat, if the PC stops or minicom dies or anything happens that stops the PC pulling data from the prop,
then the main routine will stall on the tx() and my AC will never change state (not pretty).. but I've got to think about the best way to do that without getting to complex or ugly.
Was thinking of a timeout in the tx() spin routine itself..
Bummer about the no usb keyboard or mouse.. I'm rapidly running out of ideas...
I do have an old machine here somewhere with a VT82C686 on it though, so I'll dig it out and see if I can reproduce some of the problems you are seeing.
It's an _old_ machine.. I wonder if WinXp will install in 32MB of ram?? [noparse];)[/noparse]
@ BradC : Once again, many thanks for the explanations. The fog thinning it is.
timeouts : I wouldn't really need them. I suspect others would be more interested in seeing other USB device classes coded up than getting bogged down in tweaking the interfaces. Hope I haven't side-tracked you too much already.
Paul Baker (Parallax) said...
Kill all cat? that's not a very nice thing to do, but at least you were well rested before you did it .
I always sleep well prior to feline abuse, better after however [noparse]:)[/noparse]
It's funny, I guess I'm so used to the command line syntax I just never think about what I'm actually typing.
I recall a very offended blonde secretary who took great offence to receiving mail from root.
hippy said...
@ BradC : Once again, many thanks for the explanations. The fog thinning it is.
timeouts : I wouldn't really need them. I suspect others would be more interested in seeing other USB device classes coded up than getting bogged down in tweaking the interfaces. Hope I haven't side-tracked you too much already.
Win Xp : I think it needs 64MB minimum.
Hrm.. I'm more interested in getting the bugs beaten out of the low level driver before working on new classes and objects..
Once the low level driver is working solidly then we have a decent foundation to build upon.
As to being side tracked.. I'd rather spend time getting it _right_ first, then we can look at adding features
I don't mind being side tracked if it helps get things working smoothly.. in any case.. I've only spent some time writing/tweaking code, it's *you* who completely re-installed windows! Who's sidetracked??
I've managed to scrape another 14 longs free in the low level code with some nasty hacks/tweaks.. and I've located a 6Mhz resonator in an old board I had floating around, so I'll look
at building a lowlevel variant to run at 96Mhz tomorrow as well.
I really do appreciate all the time you've put into this..
Added : Our posts crossed in the ether ... I'm not baling out, just needing a bit of a break
Okay ... where we currently stand, having tried lots of things and various combinations. This is with USB_Serial_004 and USB_LowLevel_007, only Prop USB connected, PropPlug unplugged from USB, no apps running other than HyperTerm.
With the Propeller doing send only and nothing being sent its way to stall transmission, comms stays up from between 5 seconds and 15 minutes, usually lasting around 5 to 10 minutes before it just stops, and that appears always to always be after the first character of the number I'm displaying ( the first byte sent after a 500mS delay ) is shown by HyperTerm.
Installed Bus Hound from Perisoft and that showed interesting things, but not as to how the failure arises or events surrounding it. It appears though that when the Prop USB goes down WinXP starts a USB enumeration again of some kind. Every minute or so it reports something different to the previous commands, but I didn't understand what ( STAK:READ event data changes ). I'm not sure if failures are related/synchronised to this or not.
I also now suspect that the blue (Tx) Led flashing on the PropPlug may be WinXP searching unopened serial ports to find new modems or something like that, but didn't investigate. It only happens after the Prop USB has died.
I'm going to put this to one side for a while, but will almost certainly come back to it. If anyone else could give this an endurance test to see how long it stays up for it would confirm that it's something with my PC or setup not a general problem.
The only other thought I have is that it could be mains borne interference or electrical noise. I'll try running my ProtoBoard from a 12V SLA and see how that does.
I was completely out of ideas, until I remember that VIA controllers had a bug with Babble.. (sending more bytes than they should) .. did a bit of source digging and googling and the early UHCI VIA silicon
turns out to be quite buggy.
This is one error condition I don't check for, and if we get more than 12 bytes (token + 8 + 2 for crc is max we _should_ get) then we will start overwriting ram and things
go south.. I've got to really think about this a bit as I can't actually make it happen, but I need to test the check for it properly..
Anyway, looks like the VIA silicon I have here is newer than what you are running.. I'll let it run tonight and see what happens, if I can't get it to lock up I have an old K6-II 300 on a Via 86C586 chipset that I'll break
out and try an XP install on.. they don't get much older than that with USB anyway. XP on an original ISA Monochrome VGA card with 32 MB of ram.. I can see this being fun...
Great walk-through on recompiling the ubuntu kernel. Worked perfectly. Although as you mentioned I did lose my restricted drivers stuff.
Rebuilt the nvidia drivers ok. VMWare still doesn't work, but hopefully a reinstall will fix that too. Wireless works ok still.
And the USB driver seems to work too. cool.
BTW, I tried to run it in a WindowsXP virtual machine (linux as host) and it recognized and installed the driver ok. I thought maybe this would
get around needing to recompile the kernel but no luck. It didn't error out or anything, but when windows tried to write to the port the transmit
would just hang in the tx buffer. I'll try it again once I get VMWare back up and running.
EDIT: one more thing...
I saw it mentioned (maybe in the code don't remember) that there was the possibility for a new linux driver that doesn't require a kernel rebuild.
What is involved in getting this to work? Even after doing it myself, I think a kernel rebuild (and everything that subsequently breaks) is a little
much to ask for a long term solution.
-Chad
Post Edited (Chad George) : 9/21/2007 12:15:42 PM GMT
Heya Chad, you can run Windows in a VM and use the USB serial port, but only _after_ you have patched the linux kernel.
As for the no-patching thing.. it's kinda in-progress, but will not hit mainline for another revision or two, so you won't see it in a distribution for probably 6 months.. so there is a long term solution in the works..
A re-install of VMware shoule re-compile the kernel module and you should be good to go.
I use Virtualbox, and a simple /etc/init.d/vboxdrv setup - and I was back on line.
@hippy.. I've managed to reproduce what I _think_ is your failure.. I've had it die 3 times now.. the problem is it takes a minimum of 2 hours, which makes debugging slow.. but we'll get there.
I could not get it to fail on my newer VIA based machine, so I loaded Win2k on my old VIA 586 based board with a huge 32MB of EDO ram.. the windows install alone took 3 hours.. *BUT* I can get it to fail!
have any of you tested it on a non PC based system
eg game console (gp2x [noparse][[/noparse]http://en.wikipedia.org/wiki/GP2X] has a USB host 1.1 mode)
Long answer : I don't own any kind of gaming console, and I'm head down chasing a _very_ annoying bug related to the low level driver right now which will likely take me a week or so.
Until I have that bug nailed I can't say how well it might work.
Once I've got that sorted, I'd be more than happy to knock something up you can use to test on a game console if you have one.
Alternatively, if you want to play with the existing code, go right ahead. It's 99.9% certain that the interface between the App level and low level code will remain stable for the
immediate future and you can always update to the latest low level code when I have it working properly.
custom made data glove (http://en.wikipedia.org/wiki/Wired_glove)/ head tracking system / 1990's VR setup, etc
I currently dont own a Propeller chip/board [noparse]:([/noparse]
Ok, I _think_ I have this pegged. It's taken a while (I took an entire week off to chase this down) and I now thoroughly detest Windows, its driver model and USB stack
New versions have an added parameter in the Start() routine to pace outbound packets to stop Windows crapping itself on old VIA chipsets.
Users of sane operating systems may leave pace==0 while VIA chipset users should set pace==1. In all reality, the measured throughput difference is small enough
to leave pace==1. (Almost so small as to be insignificant actually)
Also, lowlevel has now been broken into _80Mhz and _96Mhz versions. It's passed all my regression tests, but my 96Mhz version was developed with a resonator pulled
from an old board with leads tacked onto it.. so if it does not work for you, let me know and I'll source a crystal to test with..
(Why do I get this horrible feeling that as soon as I press the Submit button the bug will re-surface on my test rig??)
Read on for a long winded description of the Windows bug
PS. Hyperterminal's connection time counter wraps at 24 hrs..
<snip>
Windows does strange stuff with old VIA controllers.
Devices will enumerate properly and run until they lock up.
In the process of recovering, the root hub stops separating commands between the ports, and
windows confuses the devices with simultaneous resets and enumeration commands, which prevents
successful re-enumeration of the Propeller (and sometimes everything else plugged into that bus).
This does not appears to occur on later silicon VIA chips. (Or is far less frequent) And I've not seen
it at all using Intel chips.
I've tested this on Rev $02, Rev $61, Rev $80 and Rev $81 of the via 3038:1106 USB controllers.
I've used different hubs, different configurations of ports and different controllers.
Thus far, I've spent about 90 hours chasing this bug and I think I finally have it pegged.
In the process I had to build a low-speed USB bus analyser so I could actually watch the bits
on the wire, which was a learning experience in itself.
Low-Speed BULK violates the USB spec, pure and simple. Linux by default prevents this on UHCI
controllers and has to be patched to allow it to occur, but Linux on exactly the same hardware listed
above behaves perfectly in every respect for as long as I care to test.
Windows appears to choke intermittently when receiving bulk packets in response to IN tokens.
It *always* happens on the second consecutive data packet. Windows will recieve the 1st packet
successfully, then it will delay the next IN token quite significantly. It will receive and sometimes
ACK the second packet, then it will just stop polling the bus (sending IN tokens). 300-330ms later
it will complain loudly that the device has stopped responding (when in reality it's stopped asking
for a response!). At this time, it confuses the root hub such that when it tries to reset and
re-enumerate the device, anything else on that bus will also get confused and start colliding.
Nasty stuff.
The Rev $02 controller is the worst.. it locks up anywhere between 5 mins and 5 hours into a test run.
It seems to get progressively better from there on, and I've only seen one un-reproducible lockup
on a Rev $80 and Rev $81 device.
At this point, I *think* the way to work around the problem is not to send consecutive data packets.
I've built packet pacing into the low level stack which can be enabled by setting the "par" in coginit
to anything other than zero. The driver will make the required changes on bootup. This will reduce
the throughput of the device, however it does appear to stop it locking up on Windows with VIA chipsets.
Now, why did I not detect this during the initial development? Well, firstly my limited Windows testing
was done on an old Intel chipset based laptop. Secondly, my test case involved pumping masses of
data through the propeller in both directions. My theory on this is that each packet of data leaving the
propeller was paced by a packet of data entering the propeller. The test devised by Hippy simply involved
outbound packets. Due to the speed "limitations" involved with using a SPIN routine to feed the buffer, a
simple usb.dec(12345) is slow enough that the usb system will send a packet with a "1" in it, then possibly
another with "23" then "45", and it will do this in three consecutive packets. This is where it was locking up.
Interestingly enough, VIA has a patch for this particular scenario available on their website (lockup while
transfering large amounts of data), however it would not install on my main affected machine (something
to do with being unable to modify an .inf file). I suspect this would also affect Full-Speed transfers under
the same conditions, but have no way of reliably testing that theory as I don't possess a Full-Speed bus analyser.
I will note installing the Via 4-in-1 chipset drivers appeared to make the situation slightly harder to trigger,
however it still hits.
@ BradC : Many thanks for putting so much time into this. It really is appreciated, and especially when it's not a bug on your part.
Your analysis makes sense and the chaos on recovery after failure fits with my observations of other USB devices getting 'shaken up' after the link went dead. That my tests were sometimes failing incredibly quickly is probably an issue of OS / Driver timing with my particular PC.
I haven't looked at the new code yet but presume that pacing involves replying to an IN then waiting for Windows / VIA to have asked for another before sending another. I don't see that as a problem for myself and an acceptable price to have to pay.
I'll upgrade to the new USB object, run my tests again and let you know how I get on.
USB being a master/slave bus, the device *never* speaks unless it's asked to by the controller. So Windows sends an IN. If we have data to send, we send the data.. if not we send a NAK
Previously.. It would go like this..
IN | Nak
IN | DATA | ACK
IN | DATA
<Lockup>
Now we do
IN | NAK
IN | DATA | ACK
IN | NAK
IN | DATA | ACK
IN | NAK
IN | DATA | ACK
and so on.. in all reality, my tests here for raw speed really don't show any loss in throughput.. I still get about 7k/sec.
The reality is most of the holdup is in the serial high level cog, so we do tend to skip IN packets anyway when it's under load.
I'll look at a more intelligent algorithm at some point in the near future and probably make it the default.
I've just had a lightbulb moment, and managed to shave another instruction out of each component of the RX loop. enough so I can now time the rx loop with waitcnt rather than nops..
this means I've got it auto-switching to cope with 5/6Mhz crystals.. It detects the clock speed at cog init time and configures itself accordingly.. so there will be a new lowlevel update in the
next day or so I suspect. No functional changes to do with any other part of the system though. Hopefully means Chad can use it on his bots now.
Using my serial loopback benchmark, I get a good 7kb/sec at 80Mhz, which increases to 7.6kb/sec at 96Mhz.. so the app level throughput is certainly a factor.
As you can see by the counts on hyperterminal in my desktop shot.. I've run each test for at least 24 hours continuously, so at least here.. it behaves itself now.
Forgot to mention, the _other_ issue that hit me very hard on the VIA controller, is the pullup resistor must be 1.5k or less. 2.2k/3.3k was causing the propeller to bounce
on and off line.. which just confused Windows even further!
It's mentioned in the changelogs, but thought it best to make it bleedin' obvious as it took me 2 days to figure out what was going on.. frustrating..
Edited : Circuit corrected as per BradC's posting below
Running with USB_Serial_005 and USB_LowLevel_80_008, with the new configuration, when I plug in the USB cable Windows brings up a USB icon in the Sysem Tray, and clicking on that shows an "Unknown Device". Using the earlier configuration the device connection is detected and it all works as before.
I'll admit I used a 1K2 not 1K5 because I don't have any 1K5. Is 1K2 plus 680R causing the problem ?
Anyway, with the latest software ( and pace := 1 ) but earlier hardware, results are about the same as before; HyperTerm shows nothing being transmitted after 800-1100 numbers displayed.
With your comment as to VIA not liking the 3K3 I'm not sure if the problem I have is related to that or something else. Any suggestions on moving forward ?
Ok, those are supposed to be 68Ohm 68, not 680. And the 1.5k connects to the D- side of the cable, not the prop pins.. that would certainly be causing issues..
I've re-read the .spin file and I can see how it looks like 680 as the O in ohm is hard up against the numbers 68Ohm. I'll change that.
I've used anything from 45 Ohm to 100 Ohm here and it works.. but 68 seems to be closest to the specs.
With a 680 and the 1.5k connected to the port pin you will be seeing random disconnects.. which is somewhat consistent with what you saw before.
I've used a 1.2k here with no problem.
If that fails, well then I've only got one wrist left....
BradC said...
Ok, those are supposed to be 68Ohm 68, not 680 ... I've re-read the .spin file and I can see how it looks like 680 as the O in ohm is hard up against the numbers 68Ohm. I'll change that.
I guess that's what "R" is for ( ) but I'll also accept dyslexia on my part. I also managed to sneak 680R through on an earlier circuit but with you being neck deep in nS timings and Windows detritus trying to fix bugs it's no surprise that one snuck through. I'll go back through the posts and correct the circuits. Then I'll re-do my hardware and have another go -- You're still on my virtual Christmas Card list.
On the plus side, if I hadn't ballsed-up so badly then I may never have had the problems I've encountered and the nasty buggettes with the VIA hardware and Windows may not have surfaced until much further down the line. There's a silver lining to be found in most things.
Oh, look.. I literally spent 90 hours at the keyboard/breadboard chasing these bugs.
In the process I learned an awful lot about Windows (Or is that a lot about awful Windows) and it's abortion of a USB stack.
I flushed about 5 non-compliance bugs with the upper and lower level stacks, got to build a low-speed USB analyser and made the code more compliant and smaller
at the same time. All in all it's been a very productive bug hunt. If it does not fix it for you though, maybe it'd be cheaper if I just fedex'ed you a new mainboard/processor [noparse];)[/noparse]
I _am_ having a swine of a time with the 96Mhz stack timings.. but that is due to the resonator I'm using being unstable rather than anything else.. I'll get myself a 6Mhz crystal
to test with which is bound to make it better.
I always postulate you never stop learning until you are 6 feet under.. this has been a fun chase, but man I hope it's over [noparse]:)[/noparse]
Do very much appreciate the feedback though.. once we get this nailed and stable, I have some fun additions in the works..
I've often found that the elation of success is entirely proportionate to the difficulty of getting there, but that doesn't mean there isn't a point where the pain outweighs the gain. From my own bug hunting marathons I know exactly where you're coming from when you say, "I hope it's all over".
@ BradC : I think we're almost there. My test program ran for an unheard of length of time so I'm pretty certain you've got whatever was causing me problems beaten.
I say almost there because there's one particular issue I've got to overcome. As an object within my test code it's fine, but as an object within my real application ( modified to a send incrementing number loop after initialisation completes ), whereas the older code runs, this always stops after sending the first byte. That's regardless of pace setting. Weirdly the receive character / echo it back tests work and that involves multiple consecutive sends.
I haven't started pruning my application's code down nor really investigated further yet, but I will look into it. I don't think I'm trampling on any Hub memory during initialisations, so my gut feeling is some sort of alignment issue depending upon how/where the object ends up loaded. I cannot see any obvious alignment issues in the USB code, so it could be something with my code. I'll let you know how I get on, but I can now see a bright light at the end of the tunnel.
Comments
No, the Prop is only sending when HyperTerm is open. I spoke too soon earlier; still getting sending stopping even with crc checks removed when not touching anything.
Yes, that's correct.
No problem, I'd like to see it working as much ( perhaps more so on Windows ? ) as you do
In any case, I've shaved 3 bit times off the receive data routine (which is about 1/3 the time taken to calculate the CRC).. so that was a prod in the right direction even if it won't immediately help you.
I now write the data to the hub while sending the EOP of the ack packet, rather than writing it all out and then starting to send the ack.. Brings us closer to the spec anyway.
It's not far off your own original USB Demo code. Running the 'send only' routine and typing back characters to the Propeller which never does an rx call, it's after the 33rd character sent there's a stall. Suspiciously near the $1F buffer size, but I haven't investigated your code in too much detail.
Test process ( assuming VID/PID already has a device driver ) ...
Unplug USB.
Burn the code.
Switch off Protoboard.
Unplug PropPlug.
Power up Protoboard.
Wait ~ 4 seconds, plug in USB.
Wait for "Bing-Bong" device detected sound ( Thanks Bill, my XP has now stopped giving that )
Launch HyperTerm, select previously saved 'Use COM4.ht' which is what I have it as.
Wait ~ 15 seconds, displays "0 1 2 3 4" etc
Type "a" 32 times, should keep counting
Type "a" 33rd time and output stalls, wait and it starts up again.
Type "a" 32 times, should keep counting
Type "a" 33rd time and output stalls
Keep finger on the "a" key for auto-repeat and Windows grinds to a halt.
Good luck in making it fail - fingers crossed that it will !
What is happening is hyperterm (or whatever) is trying to send data, the send blocks waiting for space in the transmit buffer (in the OS) to become available. Hyperterminal obviously has a transmit timeout
and after each character times out as not being able to be sent, it goes back to receiving data (the recovery you noted).. notice no break in the number sequence, it just dumps the queued up buffers in as quickly as possible.
Using minicom under linux, it never recovers (as minicom waits forever for space to become available).
This is normal unfortunately. Not a bug, but a "feature". My copy of XP and hyperterm does not go to 100% CPU under any circumstances and windows does not even blink, but I can see how a program might
do that if it's busy looping waiting for buffer space to become available. Solution of course is to intermittently check to see if there is data to receive and just discard it. If you think about it, using RS232 or
similar, the data gets spat out the port whether you are listening for it or not. Maybe my build of XP or hyperterminal is a little more intelligent in the way it copes with a blocked buffer.
...Further testing.. it does make Hyperterminal very slow to respond and laggy while it's trying to send.. once the send times out (takes a while) then it all returns to normal.
Hyperterminal Version 5.1 (Build 2600.xpsp_sp2_gdr.070227-2254 : Service Pack 2)
usbser.sys 5.1.2600-2180(xpsp2_sp2_rtm.040803-2158)
I've tested with and without the prop-plug connected and I don't notice any difference (as I guess I shouldn't)
I can reproduce exactly your symptoms as described above, but when "Windows grinds to a halt" for you, hyperterminal grinds to a halt for me, windows stays responsive. Hyperterminal then recovers (after anywhere up to 60-90 seconds) and just picks up where it left off.
I can't reproduce the loss of comms errors though. That is perplexing me. I've got 3 different cardbus USB cards (OHCI/EHCI), plus the built in port in the laptop (UHCI), plus the Mac (UHCI/EHCI) and my other laptop (UHCI/EHCI) and it just works flawlessly with all of them. I've even tried it on my server (which is a VIA chipset and prone to bugs).
Did it seem to get more reliable when you commented out the crc16check or was that just an oddity of the test?
I've left it running here and the count has just cracked 4600. I stall it from time to time by holding down a key until it latches up, but it always recovers and picks up where it left off.
Wanna mail me your computer for a week?? [noparse];)[/noparse]
Actually, on that. What _is_ your hardware? Mainboard, chipset and PCI ID's for the USB controller?
Maybe I can scrounge up something locally to reproduce the failure.
Just found a major oopsie where we were receiving ACK packets that were destined for a USB keyboard or mouse (or any other low speed device on that segment), causing major communication packet loss
between the Prop and PC.
Anything from just dropping packets through to enumeration failures... I, of course was always testing it on its own USB bus segment.. as soon as I plugged it into the HUB built into my Mac keyboard things
got real "interesting"
This had 2 major bugs that prevented it from playing nicely with anything else on the same USB segment. Keyboard/Mouse was the first one, then I plugged it into the same
bus segment as my APC HID/UPS and all hell broke loose. This has passed all regression tests and I can't fault it here. Hopefully it'll solve your problems too [noparse]:)[/noparse]
I had uploaded a half fixed version, but luckily nobody had downloaded a copy when I found the last (I hope) bug, so here is a complete package with the latest code.
I'm guessing the later because 'rx' and 'rxcheck' do not kick anything to provoke the host into sending data ( or that's handled at the lower level whenever the buffer is not full ). Hence 32 bytes fill the Propeller buffer, then the 33rd does not get accepted, HyperTerm goes to the Land of Nod.
In effect -- The host does stream data out while it can, and then stalls when the Propeller indicates, "now hold on, we have not dealt with the last stuff sent" ? If that's so, it would be possible to have the Propeller USB stack throw away incoming data if the buffer were full and there would consequently be no stalling ( accepting that data would be lost forever ) ? This is not something I'm asking to be implemented, but would probably suit my application.
I'm afraid I'm only slowly getting up to speed on USB - fascinating stuff, and your code has been really beneficial to understanding what's going on, but it hasn't all sunk in yet. Never, ever dreamed I'd be doing anything with bit-banged USB or USB stacks !
Hyperterminal Version 5.1 (Build 2600.xpsp_sp2_rtm.040803-2158 : Service Pack 2)
usbser.sys 5.1.2600-2180(xpsp2_sp2_rtm.040803-2158) - Same as yours
If I've not given the information you need, just let me know, Win XP innards are as new to me as USB is ...
Celeron 1GHz + 384MB
GA-6VEM motherboard ( GigaByte ) and according to manual ...
Chipset : VT8601T HOST/AGP/Controller + VT82C686B
I/O Control : VT82C686B
And it does look like VIA USB controllers, both USB 1.1 I believe. I have a "motherboard_drivers_chipset_via_4in1433v.exe" on disk which I am sure I had previously installed, but forgot to when I did the re-install a day ago ...
"USB Root Hub" ( two off )
Device Instance Id :
USB\ROOT_HUB\4&1E8F7657&0
Hardware Ids :
USB\ROOT_HUB&VID1106&PID3038&REV001A
USB\ROOT_HUB&VID1106&PID3038
USB\ROOT_HUB
Matching Device Id :
usb\root_hub
Service :
usbhub
"VIA Rev 5 or Later USB Universal Host Controller" ( two off )
Device Instance Id :
PCI\VEN_1106&DEV_3038&SUBSYS_12340925&REV_1A\3&61AAA01&0&3A
Hardware Ids :
PCI\VEN_1106&DEV_3038&SUBSYS_12340925&REV_1A
PCI\VEN_1106&DEV_3038&SUBSYS_12340925
PCI\VEN_1106&DEV_3038&CC_0C0300
PCI\VEN_1106&DEV_3038&CC_0C03
Matching Device Id :
pci\ven_1106&dev_3038&cc_0c0300
Service :
usbuhci
No, both are traditional PS/2, so my turn for a "...next" retort
I only have one pair of USB ports exposed on sockets so everything on the same Host Hub / Segment; FTDI PropPlug on one, Propeller USB on the other. No passive / active hubs used.
I'll try your latest USB_002 and see how that affects things. I'll then also run the "VIA 4 in 1" chipset driver install and see if that does anything to help.
Many thanks for taking the time to look into this and helping someone who is pretty much still stumbling around in the dark, but the light's getting brighter !
Hyperterminal places a byte in the windows transmit buffer. Windows queues up an OUT packet with that byte in it (or up to 8 bytes depending on what is available).
If the prop has buffer space available, it processes the OUT packet and sends an ACK, to let windows know it's all good.
If it does _not_ have buffer space available it sends a NAK, which says to windows.. I'm busy right now and have no way to process that packet, try me again soon.
It will continue to try for all intents and purposes forever sending an OUT and getting a NAK. This is where windows is chucking a wobbly. Your understanding is good young Jedi!
Yes, it would not be terribly difficult to have the app level routine say, buffer full.. have not had space available for 2 seconds, let's chuck the packet away.
I've not done it this way as I built the whole thing from the ground up _not_ to lose _any_ data _ever_.. but I could probably add a timeout there that you can set as an option to allow it to chuck data away.
The easy way though is in your app, just periodically call usb.rxcheck and that will read data from the buffer if there is any to read and just toss it away if you don't do anything with it.
It also won't block if there is nothing to read.
I've been thinking about a timeout in the tx routine also.. as for example in my thermostat, if the PC stops or minicom dies or anything happens that stops the PC pulling data from the prop,
then the main routine will stall on the tx() and my AC will never change state (not pretty).. but I've got to think about the best way to do that without getting to complex or ugly.
Was thinking of a timeout in the tx() spin routine itself..
Bummer about the no usb keyboard or mouse.. I'm rapidly running out of ideas...
I do have an old machine here somewhere with a VT82C686 on it though, so I'll dig it out and see if I can reproduce some of the problems you are seeing.
It's an _old_ machine.. I wonder if WinXp will install in 32MB of ram?? [noparse];)[/noparse]
timeouts : I wouldn't really need them. I suspect others would be more interested in seeing other USB device classes coded up than getting bogged down in tweaking the interfaces. Hope I haven't side-tracked you too much already.
Win Xp : I think it needs 64MB minimum.
I always sleep well prior to feline abuse, better after however [noparse]:)[/noparse]
It's funny, I guess I'm so used to the command line syntax I just never think about what I'm actually typing.
I recall a very offended blonde secretary who took great offence to receiving mail from root.
There's a number in every crowd..
Hrm.. I'm more interested in getting the bugs beaten out of the low level driver before working on new classes and objects..
Once the low level driver is working solidly then we have a decent foundation to build upon.
As to being side tracked.. I'd rather spend time getting it _right_ first, then we can look at adding features
I don't mind being side tracked if it helps get things working smoothly.. in any case.. I've only spent some time writing/tweaking code, it's *you* who completely re-installed windows! Who's sidetracked??
I've managed to scrape another 14 longs free in the low level code with some nasty hacks/tweaks.. and I've located a 6Mhz resonator in an old board I had floating around, so I'll look
at building a lowlevel variant to run at 96Mhz tomorrow as well.
I really do appreciate all the time you've put into this..
I'm having fun anyway..
Okay ... where we currently stand, having tried lots of things and various combinations. This is with USB_Serial_004 and USB_LowLevel_007, only Prop USB connected, PropPlug unplugged from USB, no apps running other than HyperTerm.
With the Propeller doing send only and nothing being sent its way to stall transmission, comms stays up from between 5 seconds and 15 minutes, usually lasting around 5 to 10 minutes before it just stops, and that appears always to always be after the first character of the number I'm displaying ( the first byte sent after a 500mS delay ) is shown by HyperTerm.
Installed Bus Hound from Perisoft and that showed interesting things, but not as to how the failure arises or events surrounding it. It appears though that when the Prop USB goes down WinXP starts a USB enumeration again of some kind. Every minute or so it reports something different to the previous commands, but I didn't understand what ( STAK:READ event data changes ). I'm not sure if failures are related/synchronised to this or not.
I also now suspect that the blue (Tx) Led flashing on the PropPlug may be WinXP searching unopened serial ports to find new modems or something like that, but didn't investigate. It only happens after the Prop USB has died.
I'm going to put this to one side for a while, but will almost certainly come back to it. If anyone else could give this an endurance test to see how long it stays up for it would confirm that it's something with my PC or setup not a general problem.
The only other thought I have is that it could be mains borne interference or electrical noise. I'll try running my ProtoBoard from a 12V SLA and see how that does.
I doubt it's mains, but then I've been wrong once or twice before.. I guess when you get to this point anything is possible..
turns out to be quite buggy.
This is one error condition I don't check for, and if we get more than 12 bytes (token + 8 + 2 for crc is max we _should_ get) then we will start overwriting ram and things
go south.. I've got to really think about this a bit as I can't actually make it happen, but I need to test the check for it properly..
Anyway, looks like the VIA silicon I have here is newer than what you are running.. I'll let it run tonight and see what happens, if I can't get it to lock up I have an old K6-II 300 on a Via 86C586 chipset that I'll break
out and try an XP install on.. they don't get much older than that with USB anyway. XP on an original ISA Monochrome VGA card with 32 MB of ram.. I can see this being fun...
Lucky Friday is my weekend..
Great walk-through on recompiling the ubuntu kernel. Worked perfectly. Although as you mentioned I did lose my restricted drivers stuff.
Rebuilt the nvidia drivers ok. VMWare still doesn't work, but hopefully a reinstall will fix that too. Wireless works ok still.
And the USB driver seems to work too. cool.
BTW, I tried to run it in a WindowsXP virtual machine (linux as host) and it recognized and installed the driver ok. I thought maybe this would
get around needing to recompile the kernel but no luck. It didn't error out or anything, but when windows tried to write to the port the transmit
would just hang in the tx buffer. I'll try it again once I get VMWare back up and running.
EDIT: one more thing...
I saw it mentioned (maybe in the code don't remember) that there was the possibility for a new linux driver that doesn't require a kernel rebuild.
What is involved in getting this to work? Even after doing it myself, I think a kernel rebuild (and everything that subsequently breaks) is a little
much to ask for a long term solution.
-Chad
Post Edited (Chad George) : 9/21/2007 12:15:42 PM GMT
As for the no-patching thing.. it's kinda in-progress, but will not hit mainline for another revision or two, so you won't see it in a distribution for probably 6 months.. so there is a long term solution in the works..
A re-install of VMware shoule re-compile the kernel module and you should be good to go.
I use Virtualbox, and a simple /etc/init.d/vboxdrv setup - and I was back on line.
@hippy.. I've managed to reproduce what I _think_ is your failure.. I've had it die 3 times now.. the problem is it takes a minimum of 2 hours, which makes debugging slow.. but we'll get there.
I could not get it to fail on my newer VIA based machine, so I loaded Win2k on my old VIA 586 based board with a huge 32MB of EDO ram.. the windows install alone took 3 hours.. *BUT* I can get it to fail!
Cheers lads!
Good luck with the bug hunt.
eg game console (gp2x [noparse][[/noparse]http://en.wikipedia.org/wiki/GP2X] has a USB host 1.1 mode)
Long answer : I don't own any kind of gaming console, and I'm head down chasing a _very_ annoying bug related to the low level driver right now which will likely take me a week or so.
Until I have that bug nailed I can't say how well it might work.
Once I've got that sorted, I'd be more than happy to knock something up you can use to test on a game console if you have one.
Alternatively, if you want to play with the existing code, go right ahead. It's 99.9% certain that the interface between the App level and low level code will remain stable for the
immediate future and you can always update to the latest low level code when I have it working properly.
What can you plug into a console anyway ?
I currently dont own a Propeller chip/board [noparse]:([/noparse]
New versions have an added parameter in the Start() routine to pace outbound packets to stop Windows crapping itself on old VIA chipsets.
Users of sane operating systems may leave pace==0 while VIA chipset users should set pace==1. In all reality, the measured throughput difference is small enough
to leave pace==1. (Almost so small as to be insignificant actually)
Also, lowlevel has now been broken into _80Mhz and _96Mhz versions. It's passed all my regression tests, but my 96Mhz version was developed with a resonator pulled
from an old board with leads tacked onto it.. so if it does not work for you, let me know and I'll source a crystal to test with..
(Why do I get this horrible feeling that as soon as I press the Submit button the bug will re-surface on my test rig??)
Read on for a long winded description of the Windows bug
PS. Hyperterminal's connection time counter wraps at 24 hrs..
<snip>
Windows does strange stuff with old VIA controllers.
Devices will enumerate properly and run until they lock up.
In the process of recovering, the root hub stops separating commands between the ports, and
windows confuses the devices with simultaneous resets and enumeration commands, which prevents
successful re-enumeration of the Propeller (and sometimes everything else plugged into that bus).
This does not appears to occur on later silicon VIA chips. (Or is far less frequent) And I've not seen
it at all using Intel chips.
I've tested this on Rev $02, Rev $61, Rev $80 and Rev $81 of the via 3038:1106 USB controllers.
I've used different hubs, different configurations of ports and different controllers.
Thus far, I've spent about 90 hours chasing this bug and I think I finally have it pegged.
In the process I had to build a low-speed USB bus analyser so I could actually watch the bits
on the wire, which was a learning experience in itself.
Low-Speed BULK violates the USB spec, pure and simple. Linux by default prevents this on UHCI
controllers and has to be patched to allow it to occur, but Linux on exactly the same hardware listed
above behaves perfectly in every respect for as long as I care to test.
Windows appears to choke intermittently when receiving bulk packets in response to IN tokens.
It *always* happens on the second consecutive data packet. Windows will recieve the 1st packet
successfully, then it will delay the next IN token quite significantly. It will receive and sometimes
ACK the second packet, then it will just stop polling the bus (sending IN tokens). 300-330ms later
it will complain loudly that the device has stopped responding (when in reality it's stopped asking
for a response!). At this time, it confuses the root hub such that when it tries to reset and
re-enumerate the device, anything else on that bus will also get confused and start colliding.
Nasty stuff.
The Rev $02 controller is the worst.. it locks up anywhere between 5 mins and 5 hours into a test run.
It seems to get progressively better from there on, and I've only seen one un-reproducible lockup
on a Rev $80 and Rev $81 device.
At this point, I *think* the way to work around the problem is not to send consecutive data packets.
I've built packet pacing into the low level stack which can be enabled by setting the "par" in coginit
to anything other than zero. The driver will make the required changes on bootup. This will reduce
the throughput of the device, however it does appear to stop it locking up on Windows with VIA chipsets.
Now, why did I not detect this during the initial development? Well, firstly my limited Windows testing
was done on an old Intel chipset based laptop. Secondly, my test case involved pumping masses of
data through the propeller in both directions. My theory on this is that each packet of data leaving the
propeller was paced by a packet of data entering the propeller. The test devised by Hippy simply involved
outbound packets. Due to the speed "limitations" involved with using a SPIN routine to feed the buffer, a
simple usb.dec(12345) is slow enough that the usb system will send a packet with a "1" in it, then possibly
another with "23" then "45", and it will do this in three consecutive packets. This is where it was locking up.
Interestingly enough, VIA has a patch for this particular scenario available on their website (lockup while
transfering large amounts of data), however it would not install on my main affected machine (something
to do with being unable to modify an .inf file). I suspect this would also affect Full-Speed transfers under
the same conditions, but have no way of reliably testing that theory as I don't possess a Full-Speed bus analyser.
I will note installing the Via 4-in-1 chipset drivers appeared to make the situation slightly harder to trigger,
however it still hits.
Best of luck
Your analysis makes sense and the chaos on recovery after failure fits with my observations of other USB devices getting 'shaken up' after the link went dead. That my tests were sometimes failing incredibly quickly is probably an issue of OS / Driver timing with my particular PC.
I haven't looked at the new code yet but presume that pacing involves replying to an IN then waiting for Windows / VIA to have asked for another before sending another. I don't see that as a problem for myself and an acceptable price to have to pay.
I'll upgrade to the new USB object, run my tests again and let you know how I get on.
USB being a master/slave bus, the device *never* speaks unless it's asked to by the controller. So Windows sends an IN. If we have data to send, we send the data.. if not we send a NAK
Previously.. It would go like this..
IN | Nak
IN | DATA | ACK
IN | DATA
<Lockup>
Now we do
IN | NAK
IN | DATA | ACK
IN | NAK
IN | DATA | ACK
IN | NAK
IN | DATA | ACK
and so on.. in all reality, my tests here for raw speed really don't show any loss in throughput.. I still get about 7k/sec.
The reality is most of the holdup is in the serial high level cog, so we do tend to skip IN packets anyway when it's under load.
I'll look at a more intelligent algorithm at some point in the near future and probably make it the default.
I've just had a lightbulb moment, and managed to shave another instruction out of each component of the RX loop. enough so I can now time the rx loop with waitcnt rather than nops..
this means I've got it auto-switching to cope with 5/6Mhz crystals.. It detects the clock speed at cog init time and configures itself accordingly.. so there will be a new lowlevel update in the
next day or so I suspect. No functional changes to do with any other part of the system though. Hopefully means Chad can use it on his bots now.
Using my serial loopback benchmark, I get a good 7kb/sec at 80Mhz, which increases to 7.6kb/sec at 96Mhz.. so the app level throughput is certainly a factor.
As you can see by the counts on hyperterminal in my desktop shot.. I've run each test for at least 24 hours continuously, so at least here.. it behaves itself now.
on and off line.. which just confused Windows even further!
It's mentioned in the changelogs, but thought it best to make it bleedin' obvious as it took me 2 days to figure out what was going on.. frustrating..
Firstly, can we clarify the hardware connections ...
N/C --< Vusb ___ P0 <>---|___|----.----<> D- 68R | ___ | P1 <>---|___|----|----<> D+ 68R | ___ | P2 >----|___|----' .--> 0V 1K5 _|_ Correct Hardware ConfigurationEdited : Circuit corrected as per BradC's posting below
Running with USB_Serial_005 and USB_LowLevel_80_008, with the new configuration, when I plug in the USB cable Windows brings up a USB icon in the Sysem Tray, and clicking on that shows an "Unknown Device". Using the earlier configuration the device connection is detected and it all works as before.
I'll admit I used a 1K2 not 1K5 because I don't have any 1K5. Is 1K2 plus 680R causing the problem ?
Anyway, with the latest software ( and pace := 1 ) but earlier hardware, results are about the same as before; HyperTerm shows nothing being transmitted after 800-1100 numbers displayed.
With your comment as to VIA not liking the 3K3 I'm not sure if the problem I have is related to that or something else. Any suggestions on moving forward ?
Post Edited (hippy) : 10/1/2007 12:50:01 PM GMT
I've re-read the .spin file and I can see how it looks like 680 as the O in ohm is hard up against the numbers 68Ohm. I'll change that.
I've used anything from 45 Ohm to 100 Ohm here and it works.. but 68 seems to be closest to the specs.
With a 680 and the 1.5k connected to the port pin you will be seeing random disconnects.. which is somewhat consistent with what you saw before.
I've used a 1.2k here with no problem.
If that fails, well then I've only got one wrist left....
Post Edited (BradC) : 10/1/2007 6:06:00 AM GMT
I guess that's what "R" is for (
On the plus side, if I hadn't ballsed-up so badly then I may never have had the problems I've encountered and the nasty buggettes with the VIA hardware and Windows may not have surfaced until much further down the line. There's a silver lining to be found in most things.
In the process I learned an awful lot about Windows (Or is that a lot about awful Windows) and it's abortion of a USB stack.
I flushed about 5 non-compliance bugs with the upper and lower level stacks, got to build a low-speed USB analyser and made the code more compliant and smaller
at the same time. All in all it's been a very productive bug hunt. If it does not fix it for you though, maybe it'd be cheaper if I just fedex'ed you a new mainboard/processor [noparse];)[/noparse]
I _am_ having a swine of a time with the 96Mhz stack timings.. but that is due to the resonator I'm using being unstable rather than anything else.. I'll get myself a 6Mhz crystal
to test with which is bound to make it better.
I always postulate you never stop learning until you are 6 feet under.. this has been a fun chase, but man I hope it's over [noparse]:)[/noparse]
Do very much appreciate the feedback though.. once we get this nailed and stable, I have some fun additions in the works..
I say almost there because there's one particular issue I've got to overcome. As an object within my test code it's fine, but as an object within my real application ( modified to a send incrementing number loop after initialisation completes ), whereas the older code runs, this always stops after sending the first byte. That's regardless of pace setting. Weirdly the receive character / echo it back tests work and that involves multiple consecutive sends.
I haven't started pruning my application's code down nor really investigated further yet, but I will look into it. I don't think I'm trampling on any Hub memory during initialisations, so my gut feeling is some sort of alignment issue depending upon how/where the object ends up loaded. I cannot see any obvious alignment issues in the USB code, so it could be something with my code. I'll let you know how I get on, but I can now see a bright light at the end of the tunnel.