Guest pedro_trying_papilio

Trouble installing (wouldnt even lift off the ground)

Recommended Posts

Guest pedro_trying_papilio

Hi everyone,

After playing around with HDL in simulations finally decided to buy a board ... winner ... papilio one!

Trouble is couldn't install it. I am running XP 32 bits Home Ed.

I ran 'Papilio Programmer Windows Installer' exe available on the website and assumed it contain any FTDI drivers i needed.

Installation seemed to go ok but in the last stages it did not recognise correctly what was connected to the ports judging by what is the outcome of the installation in the video shown in the website ('getting started').

Now if I connect the papilio post installation xp tells me i have just connected an 'optic mouse'?!  :o

I assume something didn't go right. only thing I can think of is that I am running XP portuguese edition which means a lot of win c:paths  will be named differently don't now if there is any dependency that could be in trouble with this.

Anyway if any one has any inputs on where I could have gone wrong or a bullet proof way of loading bit files to board (with or without using the loader), do let me know.

Best

Pedro

Share this post


Link to post
Share on other sites

Hello Pedro,

Usually the driver installation goes pretty well. You most likely have another driver that is using the same VID/PID and is causing a conflict. Do you still use the mouse that it is showing up as?

One quick question, did you download the Papilio Loader V2.0 beta or the Papilio Loader package. The beta package does not include the drivers.

I think there are two approaches you can take:

1) Plug the Papilio in and then remove it while watching the device manager. Once you confirm you have the right device try to do the "Upgrade Driver" option. Point to the driver directory, (C:\Program Files (x86)\Papilio Programmer\FTDI USB Drivers) and see if it updates the correct drivers.

2) If nothing else works then there is a FTDI tool you can download to clear out the installed drivers. It can be downloaded from FTDI's utilities section or directly from here. Use a Vendor ID or 0403 and a Product ID of 6011 and 6001.

Let me know how it goes, good luck.

Jack.

Share this post


Link to post
Share on other sites
Guest pedro_trying_papilio

Hi Jack thank you for reply on this,

So I disconnected everything and connected the papilio.

in the device manager it was taking up 2 COM ports

Com 5

FTDIBUS\VID_0403+PID_6010+5&37DC335C&0&3&A\0000

COM 6

FTDIBUS\VID_0403+PID_6010+5&37DC335C&0&3&B\0000

Now I assume by your information that PID is definitely not right.

I then updated COM 5 but it wouldn't allow me to take drivers from the location **Papilio Programmer\FTDI USB Drivers

So i choose to install papilio drivers directly (the other advanced option) I guess in my xp version It is complicating things because its complaining about the drivers not having a digital signature.

It install Papilio Serial Port sucessfully on COM5 (serial converter A).

But at this point i still have old COM 6 and on the device manager a 'mouse' shows up as not  correctly installed!

--> BAllpoint mouse microsoft series?!

SERENUM\BALLPOINT\8&62403E&0&0000

Fair play I am trying not to stay too confused (but i don't even recall a prior installation of a non optic mouse).

Then I figured I will update controller on COM 6 and run papilio driver which it recognises it again as a papilio Serial Port.

Now obviously after all this mess I am not sure what is what

FTDI ID are still the same:

FTDIBUS\VID_0403+PID_6010+5&37DC335C&0&3&A\0000

FTDIBUS\VID_0403+PID_6010+5&37DC335C&0&3&B\0000

But Now It claims i have 2 papilio Serial Port (one in each COM 5 && 6) Instead of a composite device in a single COM.

I guess i will just try to uninstall everything (with ftdichip utilities) and start from scratch, although I would have a like to have a better understanding of the inner workings of what happened, Food for thought?

Cheers

Pedro

Share this post


Link to post
Share on other sites

Pedro,

Ooops, I was going with the PID off the top of my head, 6011 is not right 6010 is correct. Sorry about that.

I think if both Com ports are showing up as Papilio converters then you are on the right track. Does the Papilio Loader work at that point?

You can also look at the device under the USB section and  update the driver for that.

We very seldomly get reports of driver problems, but when we do they are always a big hassle to sort out.

Jack.

Share this post


Link to post
Share on other sites
Guest pedro_trying_papilio

Hi Jack,

Thanks again for your support on this, and sorry to bring it back from the dead again.

This is sort of hard to explain without screenshots but hopeful i will get the info across (Is there a way to upload or link a few *.png i am not sure what are the forum rules on this?)

So i am back to troubleshooting drivers. I ran the ftdichip uninstaller on all 4010 PID's which it removed no issues there. I reinstalled papilio programmer, through the usual steps. This time it did recognised it as composite usb device and not each serial converter as a different device.

First serial A was recognised as Papilio Serial port (COM 4) with the PID 4010.

But this is where it gets messy... After this what i would expect was serial converter B to go into COM4 as well. Instead I get again 'Ball point mouse microsoft series'. This time around it is not allocated to a different COM but also in COM4  (where in previous trial COM5 & 6 were used) . So it appears as I have Papilio Serial port on COM 4 (assuming serial converter A?) and this Mouse on COM 4 again (assuming this is serial converter B).

Now when I look at the controllers on COM 4 one think popped out is that there is one with a digital signature. Assuming the papilio controller would not have a digital signature would this mean i have a win xp controller file getting in the way?

THis is the COM4 controllers:

Papilio Serial port (COM 4)

Controller files:

**/system32/drivers/ftser2k.sys

**/system32/DRIVERS/serenum.sys  -> this is the controller with a digital signature

// (microsoft windows component publisher)

**/system32/ftcserco.dll

**/system32/ftcserui.dll

The so called 'ballpoint point mouse' is under mouses and pointing devices in the device manager and has the following controller files:

Ballpoint mouse Microsoft series

**/system32/drivers/mouclass.sys

**/system32/drivers/sermouse.sys

It is also tagged as "This device cannot start. (Code 10)"

Now just as sanity check I tried running demo bit file (500k) into the board. all Odd pins LOW (about 0.5V) all even pins oscillating 0 to 3.3V (assume blinking) which appears OK_ish. I used pySerial and waited for USART stream got the expected ASCI charecters from COM4 again OK_ish.

Regardles of the previous I am worried that this is really not solved, after all one of the USB serial converters is seen as a mouse?! Guess my concern is that for something more complex i will start seeing some unexpected or unpredicted behaviour and unsure if its my design or an underlying issue in bit file loading.

Do you have any inputs on getting ride of this 'mouse'?! All I wanted was a clean installation :-\ .Thanks once again

PS: still in love with OSHW!

Share this post


Link to post
Share on other sites

Pedro,

Well, the good news is that functionally everything seems to be working as it should. :) Only one channel is used as a serial port, the other is used for jtag programming only.

To include images just click on the "Additional Options" link and include them as an attachment and it will show up in your post.

The latest version of the drivers that are included with the Papilio Loader is configured to turn of the VCP function so that the jtag channel does not show up as a COM port. Maybe that is what you are seeing.

Try this:

[list type=decimal]

[*]Open device manager and expand the "Universal Serial Bus Controllers" tree.

[*]You should see "USB Serial Converter A" or "Papilio Serial Converter A" or something along those lines.

[*]Look at the properties of the "A" device and then switch to the Advanced tab. Is "Load VCP" checked? This is the setting that will control whether a FTDI channel will also load a COM port.

[*]Look at the setting for the "B" device.

[*]The way I have things setup with the latest version of the driver is to disable the "Load VCP" setting for the Serial Converter A device since it is only used for jtag communications. Serial Converter B should be the actual UART and should have the Load VCP setting enabled. It was meant to make things less confusing, but in this case might be having the opposite effect. :(

post-3-13431627485528.png

Share this post


Link to post
Share on other sites
Guest pedro_trying_papilio

Hi Jack and Álvaro,

Thank you guys for all the info and insights on this. Definitely learned a lot which is always the end goal in all of these things.

I am away at the moment but didn't want to leave you with no feedback for that long.

I will back to this on sunday and let you know where the situation stands.

Thanks a lot once again.

Pedro

Share this post


Link to post
Share on other sites
Guest pedro_trying_papilio

Hi I am back with what I hope is a case closed.

Not quite straightforward because I do all the tinkering in an 'old-school' (not old!) laptop so windows menus are quite different.

So in the screenshots there is a before and after, device manager tree by connection.

Now problem is VCP is not an option as such in the available menus, also no options were available in the usb serial converters; the only advanced options were on 'papilio serial port' (COM4) (like i said an "old-school" laptop ).

Nonetheless the only ticked option in COM4 was the serial enumerator which makes sense because the mouse was popping up with a digital signature controller serenum.sys.

Maybe serial data was being misinterpreted as mouse data by the serial port enumerator (serenum.sys)?

Once this option was unchecked the tree connections showed up as the after picture (just COM4 no mouse).

I opened uart comms in COM4 again just to check if anything was affected. The board still streamed the ASCI characters as shown in the last screenshot.

So hopefully everything is ok? Not sure how equivalent of a fix is 'VCP' vs 'Serial enumerator'?

I can't say i fully understand all the ramifications of what happened but is it worth testing JTAG programming?

For the time being I think this should be enough for me to have a play with  :) . But if it's important to gather some more data on this for future reference, let me know, and i will run it through the steps/tests you guys think are relevant.

Thanks once again.

Best Regards

Pedro

 

post-0-13431627486149.png

post-0-1343162748617.png

post-0-13431627486189.png

post-0-13431627486203.png

Share this post


Link to post
Share on other sites

Ok! I think you are ok now. :)

I think the serial enumerator setting you found is the same as the VCP setting, its just different since the driver is for an older version of Windows.

I think you should be totally set now.

Thank you for your patience.

Jack.

Share this post


Link to post
Share on other sites

I've done some deep digging on this issue and I found that this seems to  be a pretty common problem and, if what I think is happening truly is  the problem then we should have a pretty easy fix.

 

  Here is an example of other FTDI based products having the same type of problem.  I found quite a few examples of the problem, I was thinking the problem  was a driver conflict but it looks like the problem is caused by the  default bit file that I have loaded to the Papilio before they ship out.  The default bit file will spit out the ASCII table when power is  applied to the Papilio and also by default the FTDI drivers are  configured to do a "Serial Enumeration" where it looks for serial data  on the com port to determine if a serial mouse is connected. In some  circumstances, it seems that the "Serial Enumeration" will interpret the  ASCII table as serial mouse data and the device is detected as a  "Microsoft Ballpoint serial mouse".

 

  There are two things we can do to disable this undesirable behavior:

  [list type=decimal]

[*]I added a delay to the default bit file so it waits 3 seconds before sending out serial data, the updated bit file is attached.

[*]There is a setting in the FTDI drivers that we can disable so it does not perform a serial enumeration.

[*]

  • Go to device manager, Ports/Papilio Serial Port and choose properties.
  • Go to Port Settings/Advanced
  • Under Miscellaneous Options deselect "Serial Enumerator"

  In my testing here both options stopped the behavior. I was getting a  "Microsoft Ballpoint serial mouse" showing up every 10-15th time I  would plug in the Papilio with the default bit file loaded. Either one  of the above options ended the behavior.

Jack

P1_QuickStart_wDelay.zip

Share this post


Link to post
Share on other sites
Guest klazen108

  • There is a setting in the FTDI drivers that we can disable so it does not perform a serial enumeration.
    • Go to device manager, Ports/Papilio Serial Port and choose properties.
    • Go to Port Settings/Advanced
    • Under Miscellaneous Options deselect "Serial Enumerator"

Got my Papilio One about an hour ago, excited to get started! I was having the same problem as the OP, and disabling "Serial Enumerator" also worked for me. However, my port was under Ports/USB Serial Port (COM6). I have a COM7 port too but I didn't change it at all.

Jack: You say that you changed the default bit file to not output ASCII data for the first three seconds, but my board was still characterized as a "ballpoint mouse". It might be because when I plugged it in, it took longer than 3 seconds to install the correct drivers. Just a thought.

Share this post


Link to post
Share on other sites

Thank you for the update klazen.

Glad to hear that disabling "Serial Enumerator" fixed your problem. :) Sorry you had to look in the forum to find the solution.  :(

Unfortunately it will take some time before the change makes its way to production boards. All of the boards that are available for sale right now have already been tested, verified, and programmed months ago. This next batch of boards that are being manufactured will have the fix since the test plan that will be used will have the update.

Thank you!

Jack.

Share this post


Link to post
Share on other sites
Guest klazen108

Of course, the fact that my board probably predates that change struck me about 5 seconds after I posted  :D  at least this problem was documented somewhere, most of the time I have to spend hours browsing the web trying to find a solution!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now