Re: Which serial driver for the development board?
- Reply: Hans Petter Selasky : "Re: Which serial driver for the development board?"
- Reply: Hans Petter Selasky : "Re: Which serial driver for the development board?"
- In reply to: Hans Petter Selasky : "Re: Which serial driver for the development board?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 23 Mar 2023 21:03:42 UTC
On Thu, 23 Mar 2023 17:19:46 +0100 Hans Petter Selasky <hps@selasky.org> wrote: > On 3/23/23 17:00, Milan Obuch wrote: > > On Thu, 23 Mar 2023 15:05:02 +0100 > > Hans Petter Selasky <hps@selasky.org> wrote: > > > >> On 3/23/23 13:04, Milan Obuch wrote: > >>> Hi, > >>> > >>> I just received Sparkfun QuickLogic board. [ snip ] > >>> Searching for VID and PID did not get me anything. Trying any of > >>> our USB serial driver did not create any device. How can I > >>> connect to this device? It should be some serial port because > >>> that's what Sparkfun page says... Any hint? > >>> > >>> Regards, > >>> Milan > >>> > >>> N. B. I was able to connect to this device using my Mac: > >>> > >>> # cu -l /dev/tty.usbmodem1411 > >>> Connected. > >>> ############## > >>> > >>> > >>> > >>> Hello world!! > >>> > >>> #******************* > >>> Command Line Interface > >>> App SW Version: qorc-sdk/qt_apps/qt_helloworldsw > >>> #******************* > >>> > >> > >> Hi! > >> > >> Did you try to dump the configuration descriptor? > >> > >> Maybe umodemX can handle it ... > >> > > > > I forgot to write I have all available serial drivers loaded, i.e. > > in kldstat output > > > > 54 1 0xffffffff81ae9000 23a0 umodem.ko > > 55 7 0xffffffff81aec000 4d10 ucom.ko > > 56 1 0xffffffff81af1000 22a0 uchcom.ko > > 57 1 0xffffffff81af4000 2200 ucycom.ko > > 58 1 0xffffffff81af7000 21e0 umoscom.ko > > 59 1 0xffffffff81afa000 2aa0 uplcom.ko > > 60 1 0xffffffff81afd000 32e0 uslcom.ko > > 61 1 0xffffffff81b01000 2260 uvscom.ko > > > > This is from a 13.1-STABLE system. > > > > What you mean by configuration descriptor? Is it this: > > > > # usbconfig -d ugen0.5 dump_all_config_desc > > ugen0.5: <vendor 0x1d50 product 0x6141> at usbus0, cfg=255 md=HOST > > spd=FULL (12Mbps) pwr=ON (100mA) > > > > # usbconfig -d ugen0.5 dump_curr_config_desc > > ugen0.5: <vendor 0x1d50 product 0x6141> at usbus0, cfg=255 md=HOST > > spd=FULL (12Mbps) pwr=ON (100mA) > > > > There is just this, nothing more. Could some usbdump help to > > identify the issue? I have no experience with this, also no idea > > how an initial device discovery could be catch with usbdump :( > > > > Regards, > > Milan > > Hi, > > cfg=255 means there is an error to set the configuration index. > > Try to use usbconfig to set config index 0 again? Maybe it just works? > > --HPS > If you mean issuing # usbconfig -d ugen0.5 set_config 0 it does not help. Descriptors are the same after this command: # usbconfig -d ugen0.5 dump_all_desc ugen0.5: <vendor 0x1d50 product 0x6141> at usbus0, cfg=255 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0002 <Communication device> bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0020 idVendor = 0x1d50 idProduct = 0x6141 bcdDevice = 0x0000 iManufacturer = 0x0000 <no string> iProduct = 0x0000 <no string> iSerialNumber = 0x0000 <no string> bNumConfigurations = 0x0001 I think there is some bug in device's firmware, but as MacOS was able to communicate with it out-of-the-box, no configuration necessary on MAC, there should be a way... Regards, Milan