734 replies to this topic

[shadowshd]

Thank you MJR for your fast answer

 

Windows registry...

 

I'll try your idea that makes sense to me ASAP, I'm pretty sure you've put your finger on that registry pain

 

 

 

Edit :

 

So here's what I've done to try to resolve my issue :

 

- I deleted all old and unattached devices from the registry with Device Remover.

- I updated USBDevice in Pinscape_Controller in my workspace (right click -> update).

- I set DEFAULT_LEDWIZ_NUMBER in config.h to 0x02 (I have a Ledwiz which number is obviously 1).

- I switched from standard ID settings to emergency fallback ID settings in config.h, just in case.

 

None of these worked, I still have my unknown device at reboot. When I take a look at the Device ID in device manager, I have Vendor ID 0XFAFA, which makes sense to me.

 

I had put back my october 2015 firmware again (revision 33 in Workspace), issue has gone.

The only change I have made to the original Pinscape software is to set LaunchBallButton to 9 instead of 24 to match my buttons configuration.

 

I'll try my KL with previous revisions of Pinscape Controller, just in case it may help

 

Thank you again Sir

 

++

Edited by shadowshd, 05 February 2016 - 08:09 AM.

[Mace]

Thank you MJR for your fast answer
 
Windows registry...
 
I'll try your idea that makes sense to me ASAP, I'm pretty sure you've put your finger on that registry pain
 
 
 
Edit :
 
So here's what I've done to try to resolve my issue :
 
- I deleted all old and unattached devices from the registry with Device Remover.
- I updated USBDevice in Pinscape_Controller in my workspace (right click -> update).
- I set DEFAULT_LEDWIZ_NUMBER in config.h to 0x02 (I have a Ledwiz which number is obviously 1).
- I switched from standard ID settings to emergency fallback ID settings in config.h, just in case.
 
None of these worked, I still have my unknown device at reboot. When I take a look at the Device ID in device manager, I have Vendor ID 0XFAFA, which makes sense to me.
 
I had put back my october 2015 firmware again (revision 33 in Workspace), issue has gone.
The only change I have made to the original Pinscape software is to set LaunchBallButton to 9 instead of 24 to match my buttons configuration.
 
I'll try my KL with previous revisions of Pinscape Controller, just in case it may help
 
Thank you again Sir
 
++

Hi Mike,

I have the same issue as Shadowshd, I've been round the same loop too.

The last build is fine, the new build loads but the device fails to be recognised. If I boot the PC from a full shutdown I get the card recognised during boot the lights initially show correctly I.e. Yellow/Green then double blinking red and finally as Windows loads it goes back to Yellow/Green. I can then calibrate the card to get the lights to the usual Green/Blue all the buttons are fine so are the Ledwiz drivers (I use the original ten pwm outputs).

So far so good until I touch the card reset then the USB fails to be recognised again, I've been at this most of the day and I've not got any closer to why. I'm using Win7x64 and the USB is straight into my Asus Motherboard, I've tried deleting and reinstalling the drivers and different USB ports (USB 2.0 & 3.0) and a hub. No luck so I've dropped back to the old build for now.

I'm happy to send over anything that may help.

Edited by Mace, 07 February 2016 - 01:45 PM.

[mjr]

So here's what I've done to try to resolve my issue :

 

- I deleted all old and unattached devices from the registry with Device Remover.

- I updated USBDevice in Pinscape_Controller in my workspace (right click -> update).

- I set DEFAULT_LEDWIZ_NUMBER in config.h to 0x02 (I have a Ledwiz which number is obviously 1).

 

Just to be sure, unit #2 is one you've never used in the past, right?  If so then it can't be an old registry entry that's the problem - must be something else entirely.

 

 

None of these worked, I still have my unknown device at reboot. 

 

So far so good until I touch the card reset then the USB fails to be recognised again, I've been at this most of the day and I've not got any closer to why. I'm using Win7x64 and the USB is straight into my Asus Motherboard, I've tried deleting and reinstalling the drivers and different USB ports (USB 2.0 & 3.0) and a hub. No luck so I've dropped back to the old build for now.

 

So let's see - shadowshd, you get the "unknown device" at Windows boot time, and Mace, it loads successfully for you at Windows boot but won't come back if you reboot the KL25Z, right?  These might be entirely different problems, but clearly they're both caused by something in the new USB code.  I don't have a Win 10 system, so it's hard to look into shadowshd's issue directly; I do have a Win7-64 system that I test with, but it's working fine for me there, so it must be something other than or more specific than just the Windows version.

 

I'll take another look at the code and see if I can spot anything that way.  Not sure what else to try right now - definitely stick with the old version until I figure out what's wrong or what tests we can perform.

[Mace]

Mike,

 

Hope this may help.

 

I've used Ghostbuster and an image of my clean build on a second SSD Drive and the standard unmodded config.h to double check everything:

 

So on install with the last code repository - no issues straight in, boot reset etc.

 

Using the new code on a scrubbed install shows that the Pinscape is recognised by the hardware (yellow/green) on boot but then as the OS (Win7 x64) loads the driver installation fails with code 10, so its seen as a USB device and as Pinscape controller but the driver is not pairing up, so erasing the old driver install has changed the behaviour as before on boot the Pinscape was recognised and the OS could see the device until the reset button was triggered.

 

As soon as the old code is dropped back onto the controller it all works straight away again.

 

Changing the LEDWiz port allocation from 8 to 4 has no effect on the above.

Edited by Mace, 07 February 2016 - 01:44 PM.

[shadowshd]

Just to be sure, unit #2 is one you've never used in the past, right?  If so then it can't be an old registry entry that's the problem - must be something else entirely.

 

Hi MJR,

 

That's right, since I've set up my cab, I ever only had one Ledwiz and one KL25Z, so I've never had unit numbers else than #1 and #8.

 

I've just did this test :

 

- In my workspace, I reverted to revision 33, modified my LaunchBallButton = 24 to 9 and injected the .bin in my KL : no issue at all.

- In my workspace, I updated USBDevice and only USBDevice, injected the .bin in my KL : unknown device.

 

++

[LeStef31]

Brilliant test Shadow .. you've found the guilty one for sure ...

[mjr]

 

Just to be sure, unit #2 is one you've never used in the past, right?  If so then it can't be an old registry entry that's the problem - must be something else entirely.

 

That's right, since I've set up my cab, I ever only had one Ledwiz and one KL25Z, so I've never had unit numbers else than #1 and #8.

 

Thanks for verifying.  That should rule out any issues with the registry, so I think we can give up on that theory.  

 

(I'm actually kind of glad that it wasn't the registry after all, since it's such a horrible mess to try to sort that out.  I've had that happen myself, and it's a huge pain in Win 7 and later because Windows applies very high protection ACLs to all of the relevant keys, which makes it extremely time-consuming to delete them.  It's still possible, but they intentionally made it really difficult as protection against malware and unintentional corruption by errant software.  But it backfires horribly in situations where you legitimately need to get rid of bad keys that were created in the first place by errant software.  But anyway, that's all beside the point.)

 

 

- In my workspace, I reverted to revision 33, modified my LaunchBallButton = 24 to 9 and injected the .bin in my KL : no issue at all.

- In my workspace, I updated USBDevice and only USBDevice, injected the .bin in my KL : unknown device.

 

That's really good to know.  I think the easiest way to track this down is going to be to just roll back changes and see if we can pinpoint the one(s) that caused the problems.  I've just created a forked version of the repository for this purpose:

 

https://developer.mb..._Controller_v1/

 

If you have a chance, try the latest version on that fork (with your config.h customizations applied as usual, of course) and see what happens.  I went through the code again and identified a couple of specific changes in the USB protocol handling, and reverted them to the previous behavior.  Those look like the only recent changes that could have directly affected the USB protocol sequence, which is almost certainly the issue here, so they're my top candidates for the culprits right now.  

 

If that fixes it, great - that should tell us that the rolled-back changes were indeed the problem.  If not, I'll find something else to roll back and we can try again, and repeat until we find the magic change.  It has to be in there somewhere given your test results with reverting entirely to the old version.

 

Thanks for your patience and your help sorting this out!  

[Xendo]

@mjr - When and where can that Pinscape board be purchased?

[mjr]

@mjr - When and where can that Pinscape board be purchased?

 

Check out this thread:  http://www.vpforums....showtopic=32700, and this site: http://mjrnet.org/pinscape/expansion-board.html.  I'll probably get the first group order placed this week - let me know (you can post to the thread) if you want to get in on that.  If you're on the fence, no need to make up your mind immediately - there will be more orders later, I'm sure.

[shadowshd]

MJR, thanks for your informations

 

And you're so right about the Windows registry, very often the best bet is to reformat and reinstall Windows.

 

I'll try the forked version tonight, I must leave for work

 

Will feedback ASAP.

 

 

 

Edit : I've just tested with the forked version, and still have the issue 

Put back rev 33, KL works like a charm.

 

Very weird MJR ??

 

But I'm sure we'll find the culprit, and I'm ready to test and feedback as much as wanted or needed

 

 

 

Edit 2 : I've just tested the forked version on my wife's notebook that never seen anything related to my cab, in case the issue's source is in my cab's PC.

The issue is still here.

 

So, like you, I definitely think this is not a Windows or PC related issue, but the USBDevice library.

 

++

Edited by shadowshd, 09 February 2016 - 06:11 PM.

[mjr]

Edit : I've just tested with the forked version, and still have the issue 

Put back rev 33, KL works like a charm.

 

Thanks for testing it.  I'll find the next change to roll back and let you know when I've posted an update to try.  We'll find it sooner or later!

[mjr]

 

Edit : I've just tested with the forked version, and still have the issue 

Put back rev 33, KL works like a charm.

 

Thanks for testing it.  I'll find the next change to roll back and let you know when I've posted an update to try.  We'll find it sooner or later!

 

One more thing to try!  Same place as before, new version in the repos:

 

https://developer.mb..._Controller_v1/

[shadowshd]

I'll try tomorrow morning MJR (in less than 12 hours with the time difference between USA and France;) )

++

[Mace]

 

Edit : I've just tested with the forked version, and still have the issue 

Put back rev 33, KL works like a charm.

 

Thanks for testing it.  I'll find the next change to roll back and let you know when I've posted an update to try.  We'll find it sooner or later!

 

 

Yep, I've also run it up on my Win 7 rig too Mike, no change same behaviour.

 

I tried changing the config.h to use the fall-back USB option too - also no change in behaviour.

 

I can try the new version on Thursday when I'm back in the workshop.

Edited by Mace, 10 February 2016 - 12:13 AM.

[shadowshd]

Hi Mike,

 

So I've just tested with the latest rev, and still unknown device.

 

If I delete the driver in the device manager, then search for new devices, the KL is installed and its state LED blinks yellow/green.

If I unplug then replug the KL or reboot the PC => unknown device.

 

++

[mjr]

So I've just tested with the latest rev, and still unknown device.

If I delete the driver in the device manager, then search for new devices, the KL is installed and its state LED blinks yellow/green.

If I unplug then replug the KL or reboot the PC => unknown device.

 

Well, this is proving to be a seriously resilient bug.  I've checked in four more revisions to test, with incremental rollbacks:

 

Revision #51

#50

#48

#47

 

(Skip #49 - accidentally checked in a typo on that one.)  

 

Probably start with rev #51, since that one is cumulative (it has all of the rollbacks so far).  If that works, switch to #50 and try again, then #48, etc.

 

Rev #51 is practically back to the October starting point, but not quite, because my bug fixes to the low-level USB code involved a pretty big overhaul that can't be easily reverted back piece-by-piece.  The overhaul is kind of an all-or-nothing deal.  So if #51 doesn't work, I think I'll have to create another fork that starts with the October code completely unchanged, and start working forward from there instead of backwards.

 

Hopefully one of these will finally isolate it, but it's getting hard to be optimistic given how elusive this bug has been so far.  It has to be something, though!

[shadowshd]

I'll try it in a few moments and will feedback.

 

Mike, do you think the "bug" can come from batches of KL25Z, maybe in USB design/hardware or something ?

 

I mean, I and Mace may have a certain revision of the KL25Z that is not "compatible" with the new USBDevice library ?

 

I will edit this post as soon as I'll have tested with rev #51

 

 

 

Edit : OK Mike, I tried all revs from #51 to #37, skipping #49. None of these latests revs are working on my KL.

With Pinscape_Controller_v1, I cannot revert back to a previous rev, Mbed compiler tells me that it was unable to update library to revision : /Pinscape_Controller_v1/FastAnalogIn:.

If I close error and try to compile, I have compilation errors.

 

I always get my now famous unknown device. I also tried to plug my KL on a USB 3.0 port on my machine, just in case, it doesn't change anything.

 

++

Edited by shadowshd, 11 February 2016 - 11:24 AM.

[Mace]

Hi Mike,

 

No good news I'm afraid - I'm working today but I compilled v51 (as far as I can tell you have updated the Pinball_Controller_v1 repository with that build) and the behaviour remained identical:

- H/W recognised on boot by the PC (Yellow/Green flash)

- No OS pick up by Win 7 (dual Red flash, reset button kills that)

 

I've tried cleaning out the registry and hidden/open drivers along with the USB hub reset/drivers, no change. I also forced the driver from USB Drive to Game Controller - it resulted in no device found.

 

Build 33 works the moment it's dropped back in.

 

Given your comments I didn't import the #47 #48 & #50 builds, let me know if you want anything else from my end.

 

By the way, thank you, I know this is a lot of work and I'd like you to know it's appreciated.

 

Mark

Edited by Mace, 11 February 2016 - 12:00 PM.

[mjr]

No good news I'm afraid - I'm working today but I compilled v51 (as far as I can tell you have updated the Pinball_Controller_v1 repository with that build) and the behaviour remained identical:

- H/W recognised on boot by the PC (Yellow/Green flash)

- No OS pick up by Win 7 (dual Red flash, reset button kills that)

 

Build 33 works the moment it's dropped back in.

 

Given your comments I didn't import the #47 #48 & #50 builds, let me know if you want anything else from my end.

 

Well, par for the course!  Thanks for taking the time to keep trying these out.

 

Okay, time to try a different approach.

 

As a sanity check, I did a full reversion to the original source code in rev 33 and checked it in as rev 53 on the Pincape_Controller_v1 branch.  So the next thing to try is rev 53.  That one pretty much has to work because it's the original code.  If #53 doesn't work, the problem must be something completely different from what I've been assuming (namely a code change I made since rev 33) and we need to figure out what that might be.

 

If #53 works, go ahead and try rev #54, then #55, then any subsequent versions you find in there.  #55 is the last one right now but I'll probably have added some more by the time you try it, given the time zone difference.  Each rev after #53 rolls one of the code changes back in, so if the problem is a code change as I've been assuming, we should eventually find it when one of these revs breaks again.

 

Edit - it's up to #64 now, which has everything rolled back in.  Hopefully #53 will work for you, and then something from #54 to #64 will break again.  

 

Mike, do you think the "bug" can come from batches of KL25Z, maybe in USB design/hardware or something ?

 

That seems unlikely because the older revision (#33) works.  At least, I'm assuming rev #33 works for you.  I know Mace can always get it working again by going back to that old version, but I guess I'm not sure if the same is true for you.  If not, maybe you're onto something about a hardware problem in the KL25Z itself.

 

 

 

With Pinscape_Controller_v1, I cannot revert back to a previous rev, Mbed compiler tells me that it was unable to update library to revision : /Pinscape_Controller_v1/FastAnalogIn:.

If I close error and try to compile, I have compilation errors.

 

I've run into this myself.   I'm not sure what's going on with that, but I think there's a bug in the mbed source control system with imported library versioning.  I've changed FastAnalogIn and USBDevice to local folders in the Pinscape_Controller_v1 branch to avoid that in the future.

Edited by mjr, 11 February 2016 - 11:41 PM.

[shadowshd]

Thanks again Mike

 

I'll try rev #53 to #55 in a few minutes.

 

I think like you : there must be something somewhere that breaks USB connection, so your idea of going reverse to put our fingers on the culprit is very clever.

 

Also I can revert back to rev #33 whenever I want, like Mace, without any issue.

 

One more thing... Yesterday when I tested a rev (can't remember which one), I had compilation errors but the bin was although generated.

I put it in my KL, and one of my two relay boards connected to the KL, started to switch on and off one of the relays constantly...

I just put that on the generated errors during compilation, but in case, it may have some importance for you to know.

 

Will edit and feedback ASAP.

 

 

Edit : OK Mike, rev #61 (USBHAL_KL25Z_ stall fixes) is the culprit.

 

I started from #64 to #61 -=> unknown device.

#60 -=> working flawlessly, as good as #33 

 

I stopped at #60, I'm sure previous revisions will work as well

 

Now waiting for further instructions 

 

++

Edited by shadowshd, 12 February 2016 - 07:53 AM.