[jallib] [jallib build] buildbot success in jallib on jallib-standard
Hi guys, This is buildbot speaking. I have finished a build of jallib-standard on jallib. Buildslave for this Build: sebbot Build Reason: Build Source Stamp: HEAD Blamelist: rob.jansen Build succeeded! Logs are attached. sincerely, -The Buildbot -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/E1lJ3Pa-0006gY-JG%40casadeyork.com. Updating '.': Ainclude/device/18f27q83.jal Ainclude/device/18f57q83.jal UU include/device/chipdef_jallib.jal Asample/18f27q83_blink_intosc.jal Asample/18f57q83_blink_intosc.jal UU tools/devicespecific.json Updated to revision 3734. 2140 samples to validate... 1102 libraries to validate... All files validated :) Environment config JALLIB_ROOT=/home/mattschinkel/jallib/slave/standard/build JALLIB_REPOS=/home/mattschinkel/jallib/slave/standard/build/include JALLIB_SAMPLEDIR=/home/mattschinkel/jallib/slave/standard/build/sample JALLIB_JALV2=/home/mattschinkel/bin/jalv2 JALLIB_PYTHON=python2.7 Time duration: 316 secs jal jalv25r4 (compiled Dec 26 2020) Required parameter to hex is missing! no source file, use /home/mattschinkel/bin/jalv2 --help for help Error while compiling file (status=1). See previous message. 2140 samples to compile... All samples compile :) Environment config JALLIB_ROOT=/home/mattschinkel/jallib/slave/standard/build JALLIB_REPOS=/home/mattschinkel/jallib/slave/standard/build/include JALLIB_SAMPLEDIR=/home/mattschinkel/jallib/slave/standard/build/sample JALLIB_JALV2=/home/mattschinkel/bin/jalv2 JALLIB_PYTHON=python2.7 Time duration: 1499 secs
Re: [jallib] Question on blink samples
Hi Eur, I ran my new blink sample program which creates HS, INTOSC and USB samples if possible. It creates around 500 extra blink sample files which are not yet in Jallib. The count then is: -) HS: 833 blink samples -) INTOSC:834 blink samples -) USB: 124 blink samples So your suggestion would be: -) sample_blink_hs -) sample_blink_intosc -) sample_blink_usb -) sample_library The latter would be for the remaining sample files. Is that correct? Kind regards, Rob Op maandag 15 februari 2021 om 17:47:34 UTC+1 schreef Eur van Andel: > Op 13 Feb 2021, om 13:59:20 heeft Rob Hamerling het > volgende geschreven: > > I would like to suggest to have all possible types of blink-a-led samples > for all PICs and improve the directory structure: a subdirectory for HS, > INTOSC and USB variants of the blink samples and a separate directory for > the other samples (thus 4 sample directories). > > > I second that. Those blink samples have saved me from insanity more than > once and every time I try a new PIC, I start with the blink sample. > > Please make blink directory with intosc, hs, etc subdirectories. > > Yes, I agree that there are a lot of samples and I like that a lot. I > check the samples every week, most by grep-ping stuff that I look for. > Giving the samples their own (sub)directories makes scrolling the samples a > lot easier. > > --- > ir EE van Andel e...@fiwihex.nl http://www.fiwihex.nl > Fiwihex B.V. Wierdensestraat 74, NL7604BK Almelo, Netherlands > tel+31-653-286573 > > > > > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/4ae128b8-2944-4270-9ee6-a5b6eb6aa2ecn%40googlegroups.com.
[jallib] [jallib/jallib] ab4645: Added new devices with blink samples.
Branch: refs/heads/master Home: https://github.com/jallib/jallib Commit: ab4645b3b861ab4c0276f411a0011696621a614f https://github.com/jallib/jallib/commit/ab4645b3b861ab4c0276f411a0011696621a614f Author: Rob Jansen <12682653+robjanse...@users.noreply.github.com> Date: 2021-03-07 (Sun, 07 Mar 2021) Changed paths: A include/device/18f27q83.jal A include/device/18f57q83.jal M include/device/chipdef_jallib.jal A sample/18f27q83_blink_intosc.jal A sample/18f57q83_blink_intosc.jal M tools/devicespecific.json Log Message: --- Added new devices with blink samples. 18f27q83 and 18f57q83 but not yet part of release. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/jallib/jallib/push/refs/heads/master/df1521-ab4645%40github.com.
Re: [jallib] WIN32CDCDrivers?
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, DS3684B 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, On Sat, Mar 6, 2021 at 4:45 PM Rob CJ wrote: > 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 > > > > -- > *Van:* jallib@googlegroups.com namens vsurducan > > *Verzonden:* donderdag 4 maart 2021 15:17 > *Aan:* jallib@googlegroups.com > *Onderwerp:* Re: [jallib] WIN32CDCDrivers? > > 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... > > On Thu, Mar 4, 2021 at 2:36 PM vsurducan wrote: > > 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,
