WIN32CDCDrivers?

93 views
Skip to first unread message

vsurducan

unread,
Feb 24, 2021, 1:17:32 PM2/24/21
to jal...@googlegroups.com
Hi, where can I find a copy of  the Win32CDCDrivers.zip ?
The links posted in the usb_serial_demo are broken.
thanks,

Rob CJ

unread,
Feb 24, 2021, 1:41:59 PM2/24/21
to jal...@googlegroups.com
 Hi Vsurducan,

I do not know but I think you do not need them. When I updated the serial library some time ago I could test it with a JAL sample program. Windows 10 recognized the usb device without the need for driver.

If you use an older version of Windows I do not know if this is also true.

Kind regards,

Rob

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens vsurducan <vsur...@gmail.com>
Verzonden: woensdag 24 februari 2021 19:17
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: [jallib] WIN32CDCDrivers?
 
Hi, where can I find a copy of  the Win32CDCDrivers.zip ?
The links posted in the usb_serial_demo are broken.
thanks,

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/CAM%2Bj4quYAsdKiqVSCM%2BV6%2BaPFLvyeGj5WWfCgGnETB-e%2BW8wwQ%40mail.gmail.com.

Matt Schinkel

unread,
Feb 24, 2021, 2:02:15 PM2/24/21
to jal...@googlegroups.com
Hi, it is in jallib under tools/usb

Sent from my Android device.

From: jal...@googlegroups.com <jal...@googlegroups.com> on behalf of Rob CJ <rob...@hotmail.com>
Sent: Wednesday, February 24, 2021 1:41:57 PM
To: jal...@googlegroups.com <jal...@googlegroups.com>
Subject: Re: [jallib] WIN32CDCDrivers?
 

vsurducan

unread,
Feb 24, 2021, 2:33:13 PM2/24/21
to jal...@googlegroups.com
Thank you Matt and Rob,
I have a non reliable USB communication under both Win10 and Win7 so I'm suspecting everything...
The following sample is based on 18F4550_USB_serial.jal. PIC18F25K50 has the same registers as PIC18F2550 except some PLL bits which can be ignored with a delay.
However, USB works only with the echo. Trying to repeatedly send a byte from PIC to PC, communication it froze.

include 18f25k50                     -- target PICmicro
--
-- This program assumes that a 16 MHz resonator or crystal
-- is connected to pins OSC1 and OSC2.
pragma target clock 48_000_000      -- oscillator frequency
--

pragma target OSC      HSH                       -- crystal or resonator
pragma target PLLSEL   PLL3X
pragma target PLLEN    ENABLED                   -- PLL on
pragma target CPUDIV   P1                        -- Fosc divisor
pragma target WDT      DISABLED                  -- watchdog
pragma target XINST    DISABLED                  -- do not use extended instructionset
pragma target DEBUG    DISABLED                  -- no debugging
pragma target BROWNOUT DISABLED                  -- no brownout reset
pragma target FCMEN    DISABLED                  -- no clock monitoring
pragma target IESO     DISABLED                  -- no int/ext osc switching
pragma target LVP      DISABLED                   -- low voltage programming
pragma target MCLR     EXTERNAL                  -- external reset
--
-- The configuration bit settings above are only a selection, sufficient
-- for this program. Other programs may need more or different settings.
--
OSCCON_SCS = 0                      -- select primary oscillator
--
enable_digital_io()                 -- make all pins digital I/O
WDTCON_SWDTEN = OFF                     -- disable watchdog

include delay
include usb_serial
include print

-- constants
const  byte str_welcome[] = "JALLIB USB Serial Demo app\n"

-- variables

-- interrupts? No thanks
INTCON_GIE = false

-- setup the USB serial library
usb_serial_init()

var bit has_shown_welcome_msg = true
var byte ch

-- main loop
forever loop
-- poll the usb ISR function on a regular base, in order to
-- serve the USB requests
usb_serial_flush()

    -- check if USB device has been configured by the HOST
if ( usb_cdc_line_status() !=  0x00 )  then
if !has_shown_welcome_msg then
has_shown_welcome_msg = true
print_string( usb_serial_data, str_welcome )
end if
else
has_shown_welcome_msg = false
end if
 
-- check for input character ; this works
 if usb_serial_read( ch ) then
-- echo input character
    usb_serial_data = ch
 end if
; none of the following works, the USB is frozen...
;    usb_cdc_putc ("B") 
;    format_word_dec(usb_serial_data, 0x3FC , 4, 0)
;    print_byte_dec(usb_serial_data, 0x04)



Rob CJ

unread,
Feb 27, 2021, 2:03:43 AM2/27/21
to jal...@googlegroups.com
Hi Vsurducan,

Did you fix this issue? So far I never had issues with the USB driver but I had always used it with a crystal. Why are you using udc_cdc_putc()?

About your other post about the USB driver. I saw that you used a delay of 400 ms in your main program. This may not work since the USB driver needs to be polled by usb_serial_flush() and this needs to be done quite frequently (I thought miliseconds).

I already found this polling a bit anoying myself since it would be nicer to have it done on an interrupt basis. Some time ago I started to make it interrupt driven but it did not work immediately at that time. Maybe it is a good time to pick it up again.

Kind regards,

Rob



Verzonden: woensdag 24 februari 2021 20:33
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] WIN32CDCDrivers?
 

vsurducan

unread,
Feb 28, 2021, 1:44:09 AM2/28/21
to jal...@googlegroups.com
Hi Rob,
Nope, with PIC18F25K50 at 3.3V supply nothing workswith usb_serial library except the echo part which is useless for me. Anything else is closing the USB host port and device is seen as unknown.

About delay, please take a look at one good example of funlw65 (below) where it has about 1 second delay by flushing in the meantime. However this example is not relevant for using only the usb_serial because it uses the bootloader  with different fuses configuration and different location for the code which runs.
On PIC18F2550 at 5V supply and external HOSC, the actual USB library does not send data reliably as an FT232 would do, an amount of data from ADC for example would be sent to the terminal with variable speed even if the main loop has  very simple structure with fixed computing time. Sometimes the transmission stops, to resuscitate it,  the port has to be closed and opened again on the host side...
I do not know why this happens, the library is too twisted for my taste so perhaps I will modify it if I'll have nerves for that...



-- Project: ADC read and send on USB CDC
-- Author: Vasile Guta-Ciucur (funlw65)
-- License: Code released under New BSD license
-- For jallib libraries, see de licence inside jal.zip

include freejalduino4 -- FreeJALduino4 pinout layer for the last board model

-- include libraries
include usb_serial
include print
include format
include delay

var dword Value
var word AD_RESULT
var word Volts
-- var byte Millivolts
const byte str1[] = " Volts\n\r"


-- ==================================================
-- PROGRAM START ------------------------------------
-- ==================================================
-- configure pins
enable_digital_io() -- first, all pins set to digital


-- now configure ADC constants
const bit ADC_HIGH_RESOLUTION = true -- 10bit resolution
const byte ADC_NVREF = 0 -- no voltage reference
const byte ADC_NCHANNEL = 1 -- how many ADC channels we are using,
                            -- always starting the count from A0 (RA0/AN0)
                            -- This will automatically set A0 as analog input
const word ADC_RSOURCE  = 909 -- impendance (R1*R2/(R1+R2))
-- then, load the ADC library
include adc
-- Initialize ADC
adc_init()


-- initialize the USB serial library
usb_serial_init()

-- start main loop
forever loop
  usb_serial_flush()
  AD_RESULT = adc_read(0)

  print_word_dec(usb_serial_data, AD_RESULT)
  usb_serial_data = " "
 
 
  -- Value = 537 * AD_RESULT
  Value = dword(537) * AD_RESULT -- one of the operands must be casted
                                 -- as dword to have a 32bit integer math
                                 -- because AD_RESULT is word and the other
                                 -- operand is a generic one.
 
  Volts = Value / 100
 
  format_word_dec(usb_serial_data, Volts, 4, 2)
  print_string(usb_serial_data, str1)

  for 100 loop -- delay 1 second (a little more than)
    usb_serial_flush()
    delay_1ms(10)
  end loop
 
end loop
--

Rob CJ

unread,
Feb 28, 2021, 3:04:15 AM2/28/21
to jal...@googlegroups.com
 Hi Vsurducan,

To understand this better. The program you mention does not work for that PIC running at 3.3 Volt, right? I have 2 questions:
1) Have you tried what happens when running it at 5 Volt?
2) What did you do with the 3.3 Volt generated by the PIC for the USB? I can imagine that it cannot generate that Voltage if it is powered by 3.3. Volt.

For your information. Some years ago I updated the USB driver to make it suitable for a PIC16F1455 but due to a compiler bug I had to implement a workaround to get that working. This  compiler bug was fixed some time ago so I removed all these workarounds and uploaded the 'clean' USB library again to GitHub yesterday.

Currently  I am looking at making the USB driver operate on an interrupt basis as to get rid of the need for flushing it. So if there are any other problems with the driver I can have a look but I have to understand your application.

I general if you have a problem, try to minimize the code to the essentials so that it becomes more easy to analyze the issue.

Thanks.

Kind regards,

Rob

Verzonden: zondag 28 februari 2021 07:43

vsurducan

unread,
Feb 28, 2021, 4:37:16 AM2/28/21
to jal...@googlegroups.com
On Sun, Feb 28, 2021 at 10:04 AM Rob CJ <rob...@hotmail.com> wrote:
 Hi Vsurducan,

To understand this better. The program you mention does not work for that PIC running at 3.3 Volt, right? I have 2 questions:
1) Have you tried what happens when running it at 5 Volt?

No because it has to work on 3.3V. However I will try it to see if it makes things different.

2) What did you do with the 3.3 Volt generated by the PIC for the USB? I can imagine that it cannot generate that Voltage if it is powered by 3.3. Volt.

It's within specifications Rob. 3.3V on VDD, 3.1V on VUSB.  Tio understand better, I'm a hardware guy working in electronics from 35years now. However, software is still not my favorite thing...

For your information. Some years ago I updated the USB driver to make it suitable for a PIC16F1455 but due to a compiler bug I had to implement a workaround to get that working. This  compiler bug was fixed some time ago so I removed all these workarounds and uploaded the 'clean' USB library again to GitHub yesterday.

Oki, I will test it thank you.

Currently  I am looking at making the USB driver operate on an interrupt basis as to get rid of the need for flushing it. So if there are any other problems with the driver I can have a look but I have to understand your application.

I general if you have a problem, try to minimize the code to the essentials so that it becomes more easy to analyze the issue.

It's the minimum possible: the example "18F4450_usb_serial.jal" has been adapted for PIC18F25K50.
The only thing which works from this example is  the part below:

forever loop
-- poll the usb ISR function on a regular base, in order to
-- serve the USB requests
usb_serial_flush()

-- check for input character

if usb_serial_read( ch ) then
-- echo input character
usb_serial_data = ch
end if

end loop

 

Rob CJ

unread,
Feb 28, 2021, 9:30:54 AM2/28/21
to jal...@googlegroups.com
Hi Vsurducan,

The updated USB will not solve your problem, it was only cleaned up but not functionally changed.

What might be an issue is the conversion time of the ADC. Your call adc_read(0) is a blocking call since it waits until the ADC conversion is complete. This may - not sure - be too long for the  usb_serial_flush().

If that is the problem then there are - at least - two options:
-) Start the AD conversion yourself and check if conversion is still ongoing by checking ADCON0_GO. If so skip the reading part until conversion is complete and then read the ADC value.
-) Use an interrupt based version of the USB driver. I re-started working on that today and it seems to work for USB serial (tested with a PIC16F1455 and PIC18F14K50) since then you no longer need the usb_serial_flush() because the handling of the USB driver is done in the interrupt routine.

As said I am not yet done with the update of the USB interrrupt based driver but as soon as it works I will upload it. For now you could try the other option by checking if conversion is ongoing.


With the interrupt based USB driver my main usb_serial sample program now looks like this:

const USB_INTERRUPT_DRIVEN = TRUE    -- This needs to be set to use the interrupt driven mode

forever loop
 
    -- There is no serial flush anymore 🙂

    -- check if USB device has been configured by the HOST
   if ( usb_cdc_line_status() !=  0x00 )  then
      if !has_shown_welcome_msg then
         has_shown_welcome_msg = true
         print_string( usb_serial_data, str_welcome )
      end if
   else
      has_shown_welcome_msg = false
   end if
   
   -- check for input character
   if usb_serial_read( ch ) then
      -- echo input character
      usb_serial_data = ch
   end if
   
end loop  

Kind regards,

Rob

Verzonden: zondag 28 februari 2021 10:37

vsurducan

unread,
Feb 28, 2021, 10:35:00 AM2/28/21
to jal...@googlegroups.com
Hi Rob, thx,
Unfortunately you are right, the cleaned library behaves as the old one.
I have no ADC running yet. :) I'm just trying to send a bunch of chars from the PIC to the host in a predictive way with no success.
USB serial communication runs only if I receive a char and send a data on each received char, and even in this situation it freezes after a number of chars sent.

PIC18F25k50 runs exactly the same at 5V (3.3V on VUSB), just for the record.


Rob CJ

unread,
Feb 28, 2021, 10:54:04 AM2/28/21
to jal...@googlegroups.com
 Hi Vsurducan,

Ok I will test the sample program on the same PIC you are using to see if it is related to the PIC.

Met vriendelijke groet,
Rob Jansen
From: jal...@googlegroups.com <jal...@googlegroups.com> on behalf of vsurducan <vsur...@gmail.com>
Sent: Sunday, February 28, 2021 4:34:47 PM

Rob CJ

unread,
Feb 28, 2021, 12:56:50 PM2/28/21
to jal...@googlegroups.com
Hi Vsurducan,

I did a test on the PIC18F2550 using the standard JAL serial sample library program. That program uses these pragma's:

pragma target  clock 20_000_000
pragma target  OSC        hs
pragma target  LVP enabled                   -- allow LVP
pragma target  WDT CONTROL                   -- WDT software controlled
WDTCON_SWDTEN = OFF                          -- disable WDT

It did not work, since my computer never recognized the PIC as COM port so I changed it to this:

pragma target clock 48_000_000      -- oscillator frequency
pragma target OSC      HS_PLL                    -- HS osc + PLL
pragma target PLLDIV   P5                        -- 20 MHz
pragma target CPUDIV   P1                        -- Fosc divisor
pragma target USBDIV   P2                        -- USB clock selection
pragma target WDT      CONTROL                   -- watchdog
pragma target XINST    DISABLED                  -- do not use extended instructionset
pragma target DEBUG    DISABLED                  -- no debugging
pragma target BROWNOUT DISABLED                  -- no brownout reset
pragma target FCMEN    DISABLED                  -- no clock monitoring
pragma target IESO     DISABLED                  -- no int/ext osc switching
pragma target VREGEN   ENABLED                   -- voltage regulator used
pragma target LVP      ENABLED                   -- low voltage programming
pragma target MCLR     EXTERNAL                  -- external reset
WDTCON_SWDTEN = OFF                 -- disable WDT
OSCCON_SCS = 0                      -- select primary oscillator

This worked, my computer recognized the PIC as COM7 on my computer.

I then added a counter in the loop and had sent its value every 50 ms to the output. It sometimes stopped after a count of 300 (note that I made the 50 ms NOT using usec_delay since then the USB driver would not work). If you would enter characters when it stopped it did no longer reply them.

I then tried the same using the interrupt based version that I am currently working on (now I could use usec_delay in the main loop). That seemed to work better - while typing this the counter is at 17.000 and still counting - but also there it happend at least once that it stopped but I am not sure if that was because  I was also entering a lot of character on the keyboard. This requires some further investigation.

I did not yet try this on another PIC but I will do that later.

I do not  know which pragma's you are using but the pragma's given in the standard sample program for the PIC18f2550 do not work.

Kind regards,

Rob

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Rob CJ <rob...@hotmail.com>
Verzonden: zondag 28 februari 2021 16:54

vsurducan

unread,
Mar 1, 2021, 1:04:11 AM3/1/21
to jal...@googlegroups.com
Rob, on PIC18F2550 works for me too, not too reliable, but works.
It does not work on PIC18F25k50.

You should know also there are minor differences between the "USB_enable_module" procedure from usb_drv.jal library contained in  jalpacks 1.5.0 and 1.6.0.
Perhaps there are also other modifications.

For PIC18F25k50 the registers involved in PLL should be:
alias OSCON_SPLLEN is OSCCON2_PLLEN        -- for PIC18F25K50
alias OSCSTAT_PLLRDY is OSCCON2_PLLRDY
However the time required for PLL to stabilize is so short (I've measured with a scope) that the modification from jalpack 1.6.0 is useless. I think that a library which worked at a moment with a compiler should be preserved "as is" with no modifications. Also the compiler version should be clearly specified manually in all libraries which worked and avoid automatic changes at each upgrade of the pack.... There is no time to check seriously all the libraries at each new jalpack release.


-- jalpack 1.5.0--------------------------------------------------------------------------------------
-- Procedure to turn on the USB device
-- --------------------------------------------------------------------------------------
procedure usb_enable_module() is
pragma inline
UIR = 0
UCON = 0x00

-- enable USB serial interface engine (SIE)
UCON_USBEN = high
usb_state = USB_STATE_DEFAULT
end procedure
-- -----------------------------------------------------------------------------------

-- jalpack1.6.0-------------------------------------------------------------------------------------
-- Procedure to turn on the USB device
-- --------------------------------------------------------------------------------------
procedure usb_enable_module() is
pragma inline
UIR = 0      -- Clear all interrupt status flags
UCON = 0x00

-- If we use the PLL we have to wait until it is ready before enabling
-- the USB serial interface (see PIC data sheet of 16F1455 section 26.2).
-- Only valid for devices that have a PLL ready indication.
if defined ( OSCCON_SPLLEN ) then
    if defined ( OSCSTAT_PLLRDY ) then
   if OSCCON_SPLLEN then
     while !OSCSTAT_PLLRDY loop  -- Wait for PLL to be ready.
        end loop
      end if
    end if
   end if

-- enable USB serial interface engine (SIE)
UCON_USBEN = high
usb_state = USB_STATE_DEFAULT
end procedure
-- -----------------------------------------------------------------------

Rob CJ

unread,
Mar 1, 2021, 2:12:06 PM3/1/21
to jal...@googlegroups.com
Hi Vasile,

I do not agree with what you are saying here. If a library has a potential bug it should be fixed (like the PLL addition).

The datasheet of the 16F1455 clearly states:

Nice that you can measure this on a scope but I do not know what happens if you would turn the PIC to sleep and wakeup from that if and 'hope' your PLL is up and running when continuing from the last statement.

Note that when I make changes I test it with different sample files, not only the one I am working on. I also update the compiler version in the JAL file to the version with which I compiled it (I may have missed this for some USB driver files but fixed that this weekend).

FYI. I am OK if you report bugs in libraries but I do not find these kind of e-mails very motivating to continue to improve JAL libraries or add  new ones. 

Kind regards,

Rob


Verzonden: maandag 1 maart 2021 07:03

vsurducan

unread,
Mar 2, 2021, 12:29:38 PM3/2/21
to jal...@googlegroups.com
Hi Rob,
Sorry for the misunderstandings I saw below. Nobody blames you for anything, on the contrary, congratulates you!
 I've noticed there is no difference with and without the if - end if block used to test the PLL ready after normal power up.
However,  I have not yet tested what's happening when dual speed oscillator mode is used  or when the PIC wakes from sleep, and here you may have right.
I was also not able to set up yet a valid USB communication with HFINTOSC, PLL and ACT. So far, my experience with USB is quite ugly.
thx for support!


Rob CJ

unread,
Mar 4, 2021, 7:16:09 AM3/4/21
to jal...@googlegroups.com
This is what I tried so far. I am using the test program that prints the value of a counter continuously. After some - random - time the program stops printing the numbers.

1) I downloaded Jallib 1.3.0. This is the version before any compiler changes and USB driver changes where made --> Conclusion. The 'halt' problem is also present there so no difference. This was tested on a PIC18F25K50.
2) The problem seems to occur on PIC18F14K50 and PIC18F25K50 (and maybe more 18F versions) but does not seem to occur on the PIC16F1455 for which I had made changes to the USB driver. I ran the program on the PIC16F1455 for a few hours but I stopped it after the counter reached 100_000. I am not saying that it will not occur on this PIC, I just did not see it after a few hours.
3) The problem occurs less (but not solved) on the PIC18 when I use the USB driver version that I created using interrupts instead of polling. This USB version is not released yet.
4) What happens when the USB connection halts is that the PIC is Stalled so it sends a STALL to the host. I do not yet know why it does that, normally it should do that if it cannot keep up with the speed. If I am right, the host should send a SETUP to get out of the STALL but since it does not continue I am not sure if that is done.
5) The USB driver initializes the connection at 115_200 baud. I lowered it to the half of the speed that but that did not solve the problem.

The USB driver does not make use of the PING-PONG buffer feature of the PIC which is meant to get deal with higher speeds. Although I do not think this is a high speed problem but maybe there is a timing problem. I am not sure if the implementation of the PING-PONG buffer feature would solve the problem but would require quite some changes to the USB driver.

Kind regards,

Rob



Verzonden: dinsdag 2 maart 2021 18:29

vsurducan

unread,
Mar 4, 2021, 7:36:52 AM3/4/21
to jal...@googlegroups.com
Hi Rob,
I can confirm that the problem occurs on both PIC18F2550 and PIC18F25K50. Major difference between PIC16F1455 and PIC18F25K50/18F2550 seems to be the USB_BDT_ADDRESS and related registers assuming that everything else is ok with the oscillator.

I've tested communication in your suggested fashion directly with the usb_cdc_putc procedure and the stall occurs after a variable number of bytes, apparently randomly, however the programmed delay after each byte sent is modifying the overal length of the entire pack received until stall.

forever loop
   
   one_ch_ad_read (4, 0b10, 0b00, 1) ; channel AN4 (RA5), using 2V internal Vref,  right justify

   wADRESH = ADRESH
   adc_value = 256*wADRESH + ADRESL
   
     usb_serial_flush()
     usb_status = usb_get_state ()

     if usb_status == USB_STATE_CONFIGURED then  ; check if USB ready

      LED_USB_READY = ON
     else
      LED_USB_READY = OFF
     end if

     host_ready = usb_cdc_line_status()
     if host_ready then
        LED_host_ready = ON
     else
        LED_host_ready = OFF
     end if
     
     
        timer = timer + 1
        if timer == 1000 then
           timer = 0
           usb_cdc_putc(counter)
           usb_serial_flush()
;           print_dword_dec( usb_serial_data, counter )
;           usb_serial_data = " "
;           format_word_dec(usb_serial_data, adc_value, 4, 0)
;           print_crlf(usb_serial_data)
           counter = counter + 1
        end if
        _usec_delay( 1 )
 end loop


vsurducan

unread,
Mar 4, 2021, 9:17:59 AM3/4/21
to jal...@googlegroups.com
One more thing I forgot: when communication freezes the uown_bit is set, while when the communication works, uown_bit is zero.
So far I understood, SIE took control of the shared USB memory when communication hangs, please see also the does_sie_owns_tx_buffer() function from usb_drv_cdc_class.jal library.

"Although USB RAM is available to the microcontroller
as data memory, the sections that are being accessed
by the SIE should not be accessed by the
microcontroller. A semaphore mechanism is used to
determine the access to a particular buffer at any given
time. This is discussed in Section 24.4.1.1 “Buffer
Ownership”."

"When UOWN is clear, the BD entry is “owned” by the
microcontroller core. When the UOWN bit is set, the BD
entry and the buffer memory are “owned” by the USB
peripheral. The core should not modify the BD or its
corresponding data buffer during this time. Note that
the microcontroller core can still read BDnSTAT while
the SIE owns the buffer and vice versa."


I think a serious debug labor via USART looks imminent...

Rob CJ

unread,
Mar 6, 2021, 9:45:31 AM3/6/21
to jal...@googlegroups.com
Hi Vasile,

The USB driver is still one big mystery for me. I installed Wireshark to see what is happening  on the USB bus and found that after the request URB_FUNCTION_SYNC_RESET_PIPE_AND_CLEAR_STALL the program stops. 

Looking for this request I found the following: "First, for all pipes except isochronous pipes, this URB sends a CLEAR_FEATURE request to clear the device's ENDPOINT_HALT feature."

So I checked the CLEAR_FEATURE request but this request is not implemented in the USB Driver. 

What they say is that when you get this request to do the following " The USB device should reset the data toggle on the device side when the bus driver clears its ENDPOINT_HALT feature."

I am still in the testing phase but you can try to see if this change in the USB driver code works. 

In the file usb_drv.jal you find this piece of code in the procedure _usb_handle_standard_request():

.....
            usb_stall_ep0();
         end if
      end block
     
      USB_REQUEST_SET_ADDRESS:
      block
         usb_address = wbt_value[0]
         if USB_DEBUG > 0 then

.....

If you change that by inserting the handling of the USB_REQUEST_CLEAR_FEATURE request as given below :

....
            usb_stall_ep0();
         end if
      end block
     
      -- This request is part of URB_FUNCTION_SYNC_RESET_PIPE_AND_CLEAR_STALL
      -- or URB_FUNCTION_SYNC_CLEAR_STALL or URB_FUNCTION_SYNC_RESET_PIPE.
      -- The USB device should reset the data toggle and clear the STALL.      
      USB_REQUEST_CLEAR_FEATURE:
      block
          -- Sending an ack will clear the DTS bit. That seems to be sufficient
          -- to continue.
         usb_send_status_ack()        
      end block
     
      USB_REQUEST_SET_ADDRESS:
      block
         usb_address = wbt_value[0]
         if USB_DEBUG > 0 then

....

While typing this message I got 22 times STALLs but the counter is currently at 10_000 and still running. Normally it would have stopped after one STALL.

As said I will need to do some more testing after which I will upload the new USB driver (with the interrupt driven feature) but you can test in parallel. Please let me know if this solves your problem.

Thanks.

Kind regards,

Rob



Verzonden: donderdag 4 maart 2021 15:17
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] WIN32CDCDrivers?
 

vsurducan

unread,
Mar 7, 2021, 5:29:00 AM3/7/21
to jal...@googlegroups.com
Hi Rob,
I've tested your solution, unfortunately for PIC18F25K50 I got exactly the same behavior.
My impression is that the BSTALL bit (USB RAM register 24-5 or BDnSTAT, DS30000684B page 347, PIC18F25K50 datasheet), has to be kept in low state to avoid stalling.

BSTALL: Buffer Stall Enable bit
1 = Buffer stall enabled; STALL handshake issued if a token is received that would use the BD in the given location (UOWN bit remains set, BD value is unchanged)
0 = Buffer stall disabled

I was not able to find exactly which is that BDnSTAT register since the library uses different names for them, but I'm on the track.
I still don't understand how the USB FIFO works (why both microcontroller and SIE took control of the FIFO)...
There isn't, or I did not find the appropriate Microchip application note and code describing how USB really works...
thx,


To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/AM0PR07MB6241A918356C8DE772163EAEE6959%40AM0PR07MB6241.eurprd07.prod.outlook.com.

Rob CJ

unread,
Mar 7, 2021, 7:43:36 AM3/7/21
to jal...@googlegroups.com
Hi Vasile,

Strange. It could be that it is not fixed but I could not reproduce it anymore. I know that it also depends on the speed of your computer. It seems to happen more frequently on slower computers.

But to be sure that we are testing the same thing I attached an update of the USB driver including one sample file for the 28f25k50. This version can be used in poll mode or in interrupt mode. In the sample program the default poll mode is used where it regularly calls usb_serial_flush(). You can also try and see what happens if you set the following:
-)  const USB_INTERRUPT_DRIVEN = TRUE      
If you set it, the sample program will no longer call usb_serial_flush() but uses the interrupt.

Not sure if that would make a difference but I did notice that the before the fix the interrupt mode did not give the problem very often but it still did.

Can you see if the problem still occurs when using this version of the USB driver?

Some answers to your commments:
-) If you do not enable stall then I do now know what will happen. You may lose characters. Stall is also used to indicate that an illegal request was received. 
-) The BDnstat is not actually a register but data that is exchanged between the PIC and the SIE via the buffer description. 



If it still does not work I have to dive deeper into the USB driver. Initially I thought I had to clear the stall (I saw that Endpoint 3 generates the stall) but I did not clear that since it made no difference. But if you encounter it you could try to see if clearing that would help.
 
So instead of;

      USB_REQUEST_CLEAR_FEATURE:
      block
          -- Sending an ack will clear the DTS bit. That seems to be sufficient
          -- to continue.
         usb_send_status_ack()        
      end block

You could change this into (this is a hack but just see what it does):

      USB_REQUEST_CLEAR_FEATURE:
      block
          -- Sending an ack will clear the DTS bit. That seems to be sufficient
          -- to continue.
         UEP3 = UEP3 & 0b1111_1110 -- Remove stall from Endpoint 3
         usb_send_status_ack()        
      end block

Looking forward to your results.

Thanks.

Kind regards,

Rob

Verzonden: zondag 7 maart 2021 11:28
USB_Driver_Update.zip

vsurducan

unread,
Mar 8, 2021, 1:43:53 AM3/8/21
to jal...@googlegroups.com
Thx, I will test your suggestions on three different boards: PIC18F2550, PIC18F25K50, PIC18F26J50 but will take a while.
The issue is not related to the host speed, it has the same behavior on any USB2.0, I've tested on i7 four core, i3 two core and Intel atom all running Win.
It's something else I don't understand yet. Which is your terminal software you're working with? Perhaps you can give me a link.
thank you,


vsurducan

unread,
Mar 8, 2021, 4:45:21 AM3/8/21
to jal...@googlegroups.com
Hi Rob,
I can confirm that PIC18F25k50 running at 3.3V from a Li-Ion battery via LDO,  was able to send about 135.000 data without freezing, but only on Win10 and a relatively fast computer (i7 four core 2.2GHz). The usb_drv.jal was modified with your last suggestion (UEP3 = UEP3 & 0b1111_1110).
I've used Realterm 3.01.44 on the host and I had previously tested it's reliability with PICmicro/ FT232 with thousands of data correctly received.

This result seems to me still unreliable... because USB should work on any device it has USB1.1/2.0/3.0 and up, no matter of it's processor speed.
I got gaps in data sent from the microcontroller as shown in the capture below.
On win7 and slower computers after each gap or wrong data, following a few (3-10) more correct received data,  the communication freezes.


5266  999
0
5268 1002
...
6851 1000
6852  999
9
6854 1000
5  999
6856 1000
6857 1001
....
7252 1002
9
7254 1000
...
8460  999
88462  999
8463  999
...
10379  999
04
10381  999
...
40924 1001
409240926  999
40927  999
40928  997
40929  999
...
75098 1000
99
75100 1001
Reply all
Reply to author
Forward
0 new messages