search

emard / ulx3s-bin

Quickstart binaries for flashing ULX3S to factory-default state
25 stars 8 forks source link

USB issue building ulx3s_v20_85f_f32c_selftest_2ws_89mhz.bit from source #6

Open sathibault opened 4 years ago

sathibault commented 4 years ago

I've tried to build this myself from https://github.com/f32c/f32c but the USB serial port does (unlike yours which works fine). Windows reports and error the the USB device malfunctioned. Any ideas what the difference could be?

emard commented 4 years ago

There are a lot of compile-time options and many binaries are released with options modified than default in source or compiling too much options was resulting in unreliable builds so default is less things enabled

USB serial does..?. if you refer to US2 - usb port with soft-serial core yes I think it is disabled in default build because it doesn't work very reliable.

It's good for selftest to check that everything is wired ok

On 7/17/20, Scott Thibault notifications@github.com wrote:

I've tried to build this myself from https://github.com/f32c/f32c but the USB serial port does (unlike yours which works fine). Windows reports and error the the USB device malfunctioned. Any ideas what the difference could be?

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/emard/ulx3s-bin/issues/6

sathibault commented 4 years ago

Yes, I mean US2 but it does not look disabled to me. C_sio is 2, C_usbsio is "0100" and C_clk_freq is 89 which provides clk_usbsio. There is a Windows toast notification that the USB device malfunctioned so it seems to be doing something.

emard commented 4 years ago

I need to check this. with some settings US2 will work but expect it to loose serial packets. I think but Im not sure that some part of the USB higher level protocol like packet retry or similar is not implemeted properly. Lower level part of the protcol (RX side PC->US2) I have rewritten and I'm pretty sure is good now.

So I think still direction PC -> US2 packets get lost much more than in US2->PC direction.

On 7/17/20, Scott Thibault notifications@github.com wrote:

Yes, I mean US2 but it does not look disabled to me. C_sio is 2, C_usbsio is "0100" and C_clk_freq is 89 which provides clk_usbsio. There is a Windows toast notification that the USB device malfunctioned so it seems to be doing something.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/emard/ulx3s-bin/issues/6#issuecomment-660080271