734 replies to this topic

[cyril92]

Hi mjr,

 

I was looking in the code of config tool and I saw something strange. I m not very skilled in programming C#, but coudl you check this and tell me if it is not an error

 

First this your code in Form2.cs :

           byte[] buf = new byte[9];
            buf[0] = 0x00;   // report ID - always 0
            buf[1] = 0x41;   // 0x41 -> pinscape special request
            buf[2] = 0x01;   // 0x01 -> request type = set config options
            buf[3] = (byte)(u - 1);   
            buf[4] = (ckEnablePlunger.Checked ? (byte)0x01 : (byte)0x00);
            if (dev.WriteUSB(buf))
            {
                // update our internal settings
                dev.plungerEnabled = ckEnablePlunger.Checked;

  Second is your code in Deviceinfo.cs :

       // read a status report
        byte[] buf = ReadUSB();
        if (buf != null)
        {
            // parse the reponse
            this.plungerEnabled = (buf[1] & 0x01) != 0;
        }

 
  For me, it seems that you don't read and write in the same place in your buf variable :

 

buf[4] = (ckEnablePlunger.Checked ? (byte)0x01 : (byte)0x00); // in Form2.cs

this.plungerEnabled = (buf[1] & 0x01) != 0; // in Deviceinfo.cs

 

Could it be the error ?  ... or should I shut my mouth  ?? 
 

[mjr]

I was looking in the code of config tool and I saw something strange. I m not very skilled in programming C#, but coudl you check this and tell me if it is not an error

 

Thanks for checking that.  That code is actually all correct, though.  It's definitely a bit confusing that the same information appears in different buffer locations in the two functions, but there's a good reason for it.  The first bit of code is preparing a command packet to send from the PC to the device.  The byte layout there is defined by a private protocol extension (to the LedWiz protocol) that I made up for the device.  The second bit of code is unpacking a USB report from the device to the PC, which uses the USB HID joystick protocol.  The private command format and the USB joystick format are unrelated, so even though they happen to have some of the same information, the layout of the bytes is quite different.  If you want to look into the protocols in depth, main.cpp in the firmware has fairly extensive comments describing the LedWiz protocol and my private extensions, and USBJoystick.cpp has the descriptors for the joystick reports.

 

I'm pretty confident that I found the real culprit, on the firmware side.  If you look at main.cpp in the firmware, in the struct NVM::save() method, that code is setting the checksum value before setting the structure size member (d.sz = sizeof(NVM)).  The size field figures into the checksum value, so on the first time through the code, the checksum is calculated based on uninitialized data.  That structure is allocated on the stack in main(), so I'm not sure whether it's deterministically initialized to all 0 bytes or just has random data; in the former case it's definitely going to have the wrong value for d.sz the first time through, and in the latter case it's going to have the wrong value 255 times out of 256.  So anyway, the value saved to flash on the first attempt will have the wrong checksum value, so on the next reboot, the software will determine that the flash data is invalid and restore the defaults.  If you go through the save() process twice (or more) before rebooting, though, the correct checksum will be stored because d.sz will have already been properly initialized from the first save() call.

Edited by mjr, 29 October 2015 - 07:20 PM.

[cyril92]

Nice ! So I understand that you found the problem.

Can we hope a new release of your config tool soon ?

[mjr]

Nice ! So I understand that you found the problem.

Can we hope a new release of your config tool soon ?

 

Yeah, I'll post an update soon.  I just want to test it out a little more on my own cab to make sure I haven't broken anything with all the expansion board changes.

[cyril92]

'Expansion board' ? what are you talking about ? you can tell me more ? Another system you are working on ?

 

Oh ok, right, I saw the topic on your expansion board ... I follow your work then ... great job, as usual

Edited by cyril92, 30 October 2015 - 11:42 AM.

[court461]

 

I was looking in the code of config tool and I saw something strange. I m not very skilled in programming C#, but coudl you check this and tell me if it is not an error

 

Thanks for checking that.  That code is actually all correct, though.  It's definitely a bit confusing that the same information appears in different buffer locations in the two functions, but there's a good reason for it.  The first bit of code is preparing a command packet to send from the PC to the device.  The byte layout there is defined by a private protocol extension (to the LedWiz protocol) that I made up for the device.  The second bit of code is unpacking a USB report from the device to the PC, which uses the USB HID joystick protocol.  The private command format and the USB joystick format are unrelated, so even though they happen to have some of the same information, the layout of the bytes is quite different.  If you want to look into the protocols in depth, main.cpp in the firmware has fairly extensive comments describing the LedWiz protocol and my private extensions, and USBJoystick.cpp has the descriptors for the joystick reports.

 

I'm pretty confident that I found the real culprit, on the firmware side.  If you look at main.cpp in the firmware, in the struct NVM::save() method, that code is setting the checksum value before setting the structure size member (d.sz = sizeof(NVM)).  The size field figures into the checksum value, so on the first time through the code, the checksum is calculated based on uninitialized data.  That structure is allocated on the stack in main(), so I'm not sure whether it's deterministically initialized to all 0 bytes or just has random data; in the former case it's definitely going to have the wrong value for d.sz the first time through, and in the latter case it's going to have the wrong value 255 times out of 256.  So anyway, the value saved to flash on the first attempt will have the wrong checksum value, so on the next reboot, the software will determine that the flash data is invalid and restore the defaults.  If you go through the save() process twice (or more) before rebooting, though, the correct checksum will be stored because d.sz will have already been properly initialized from the first save() call.

 

 

It is posts like these, that make me appreciate guys like you for doing this.  Because honestly, I have no idea what any of this means.  Thanks for all the work on this, it is very interesting to read, even though I don't know what any of it means.

[Xendo]

 

Nice ! So I understand that you found the problem.

Can we hope a new release of your config tool soon ?

 

Yeah, I'll post an update soon.  I just want to test it out a little more on my own cab to make sure I haven't broken anything with all the expansion board changes.

 

Any updates on this?  I'm looking to build one, but would like to build with the latest and greatest components.

[mjr]

 

 

Nice ! So I understand that you found the problem.

Can we hope a new release of your config tool soon ?

 

Yeah, I'll post an update soon.  I just want to test it out a little more on my own cab to make sure I haven't broken anything with all the expansion board changes.

 

Any updates on this?  I'm looking to build one, but would like to build with the latest and greatest components.

 

There's a new version of the software as of mid December.  I've just finished assembling the main board and will start testing ASAP, probably tomorrow.  The next steps will depend on whether it works - if so, the current testing design will become v1, otherwise I'll have to make any necessary revisions and do another build/test round.

 

Main board assembled:

 

With the KL25Z attached:

[vampirolatino2]

Can't wait for test results, I'm hanging on my components to build one.

[LeStef31]

I splurged and bought the CCD for plunger simulation, and am having trouble getting it to work correctly. When I use the tool to view the CCD output, it shows what I believe is a good range of black and white pixels, and they change properly when I pull back the plunger. The min is around 4000 and the max is around 30000 with zero and saturated values both 0.

The problem is that both the Windows Joystick diagnostic and VP itself show the position as rapidly flickering between the correct state and fully covered (as though the plunger isn't pulled back at all.) Any suggestions about what the problem could be?

 

Hi,

before asking I'd like to thank the community for all the help you provide and especially Mjr for his work.. impressive !

I am struggling with my CDD .. I've the same issue as quoted above ..

The Raw view is working pretty well but the joystick calibration is flickering after it is pulled for more than 1cm ..

I've tried with windows calibrations and also DIView..

 

I don't know what to do ..

Here are some videos of the problem:

 

https://www.youtube....bed/iC4MDLMeuLI

https://www.youtube....bed/NYE6UaoyIG8

 

 

Thanks for your help ..

Edited by LeStef31, 01 February 2016 - 10:33 AM.

[mjr]

The Raw view is working pretty well but the joystick calibration is flickering after it is pulled for more than 1cm ..

I've tried with windows calibrations and also DIView..

 

This is probably a dumb question, but does the same thing happen when you're *not* running the configuration/calibration tool?

 

The reason I ask is that the jumpy behavior *while* the config program is running is coming from the config program itself.  The device uses "fake" joystick messages to send the calibration data, which regular joystick clients interpret as random X/Y/Z data and show as values jumping all over the place.

 

Just wanted to confirm that you're seeing the same behavior when the config tool isn't running - if so then I'll see if I can think of some way to figure out what's going wrong.  The image data coming in from the CCD shown in your video looks really good and stable, so it doesn't look like it's a simple exposure problem or anything like that.

[LeStef31]

Hi and thank you very much for your first class support.

You are right it was not the CDD exposure but only the fact that I've mount the cdd in reverse.. :-)

I was pretty sure that you said in the documentation that the software would adapt itself to the sensor position that I put the wires on the right side..

 

I've just reverse it and it works rock solid !!!

 

https://youtu.be/7pP8HRmP2M4

 

I hope it can be usefull to other people with this strange idea to mount it this way ..

 

Thanks a lot .. now it's time to configure emulators and nudge ..

 

Stéphane

Edited by LeStef31, 01 February 2016 - 08:02 PM.

[mjr]

You are right it was not the CDD exposure but only the fact that I've mount the cdd in reverse.. :-)

I was pretty sure that you said in the documentation that the software would adapt itself to the sensor position that I put the wires on the right side..

 

I've just reverse it and it works rock solid !!!

 

Glad to hear it!

 

You read right in the documentation - it's *supposed* to adapt automatically to mounting in either direction.  There must be a bug with the auto direction sensing.  I'll take a look and see if I can track it down.  At least there's a workaround for now if anyone else runs into the same problem - thanks for figuring that out!

[LeStef31]

Thanks again for this brilliant piece of software (   I'm a software engineer ..) and your time !

[Gribnif]

Yeeeeha! Reversing the CCD solved the problem for me, too! That's been bugging me for a year now.

[LeStef31]

Nice to hear ..

[mjr]

I think I've tracked down the problem with the CCD orientation sensing - just published an updated version with the fix.  If anyone who's been having the problem has a chance to give it a try, please let me know if it helps!

 

As a bonus, I also updated this to the latest version of the USB device library, which has some bugs fixes to improve connection stability.  This probably won't have any noticeable effect for most people, but if you've had occasional problems with random disconnects, the bug fixes might help.  (Or might not; I'm not convinced every possible bug is fixed in there, since the code is quite complex and the hardware interface is poorly documented.  But it's definitely better than it used to be!)

[LeStef31]

Thank you very much !

 

I'll test it tonight.

I spread the news on the french forum as well ..

[shadowshd]

Hi MJR,

 

First of all a big thank you for your contribution to our pincab world

 

I use a PCI USB 2.0 card, because I have the red LED flashing syndrome if I connect my KL to one of my motherboard's USB ports.

The PCI card solves this issue.

 

I have a strange issue with the new version of the Pinscape Controller : my KL25Z becomes an unknown device each time I boot or reboot my cab.

I have to go to the device manager, uninstall the unknown device, and check for device changes to get my KL back to life.

 

I then updated the OpenSDA software to the 01/11/16 version, to no avail.

I reflashed the OpenSDA bootloader (v111), reflashed the OpenSDA v118, then reflashed Pinscape Controller's new version, issue persists.

 

I've put back my 11/15/15 Pinscape .bin and the issue has gone.

 

Maybe my issue has something to do with the latest version of the USB device library (my cab is running Windows 10 x64) ?

 

Anyway thanks again MJR

 

++

[mjr]

I have a strange issue with the new version of the Pinscape Controller : my KL25Z becomes an unknown device each time I boot or reboot my cab.

I have to go to the device manager, uninstall the unknown device, and check for device changes to get my KL back to life.

 

I've put back my 11/15/15 Pinscape .bin and the issue has gone.

 

Very strange - the USB changes *should* only fix bugs on the device side.  They shouldn't have any effect on a connection that was previously working - they should only improve matters for connections that weren't working properly.

 

 

 

I've put back my 11/15/15 Pinscape .bin and the issue has gone.

Maybe my issue has something to do with the latest version of the USB device library (my cab is running Windows 10 x64) ?

 

That seems like a possibility, although it's pretty baffling because - as above - the new code *shouldn't* have any effect at all on a working connection.  I don't have a Win 10 system to test on, so I haven't tried the new code there.  

 

Is anyone else on Win 10 who can try out the latest version?

 

 

I then updated the OpenSDA software to the 01/11/16 version, to no avail.

I reflashed the OpenSDA bootloader (v111), reflashed the OpenSDA v118, then reflashed Pinscape Controller's new version, issue persists.

 

I'm afraid there's no point in doing that - no harm either, but it will definitely never help with a problem like this.  The OpenSDA part runs on a whole separate CPU on board the KL25Z card.  The only function of that separate CPU is to program the main CPU's flash with new .bin files.  It's literally a separate computer residing on the same physical card.  If you're able to load new .bin files, the OpenSDA part is working.  The only time you'd need to update OpenSDA is if the .bin loader isn't working.

 

 

If you have a chance, there's a test I'd like you to try with the new version.  You mentioned that you had problems in the past that forced you to start using a USB 2 card.  It's *possible* that the problems you had in the past created some registry entries that have been lurking in there all this time, and that somehow the new version is making those old registry entries re-surface.

 

So here's the test.  If it's old registry entries at fault, they'll be keyed to the particular device ID you're using.  Part of that is the LedWiz unit number set in the configuration.  In your mbed copy, go into the compiler page and open config.h.  Find the part where it sets the LedWiz unit number, and change it to a different value - make it something you're sure you've never used before, *ever*, since we want to be sure we're trying a value that couldn't possibly be in your Windows registry from past attempts.  Build it and install the .bin, then try the system reboot to see if you get the invalid device problem again.  If not, then it's probably some old registry data causing the problem - it's a pain to clean that out, but it can be done; I'll explain how if it turns out to be the problem.