Any tips on making a logic analyzer with STM32F446ZE - Page 1
Forum section: electronics / general

author: obiwanjacobi
author_rank: Super Contributor
timestamp: January 18, 2019, 08:17:22 am
content: I have aNucleo (144) boardwith aSTM32F446ZEon it.The plan is to make a Z80 in-circuit emulator with it.In order to get the timings right, I thought I would first make a purpose built logic analyzer that records running a real Z80 in my circuit.The idea is to grab the state of all pins on each clock pos-edge and neg-edge transition.An interrupt might be best for this.After I have the pin-state I thought I would put that into a buffer and blast the buffer over USB to the PC in the main loop...I can vary the Z80 clock speed to practically any value - max is 20MHz.This will be my first real STM32 project (other than flashing leds) so any tips and suggestions are welcome.I was planning on using CubeMX to get everything setup quickly.

author: lucazader
author_rank: Regular Contributor
timestamp: January 18, 2019, 09:42:47 am
content: You could setup the required pins as GPIOs on the same bus (eg PF0-15) and then use a memory to memory DMA transfer triggered on the rising or falling edge of the clock signal.The reference manual GPIO section will give you the correct memory address from which to copy the GPIO ports input data register (https://www.st.com/resource/en/reference_manual/dm00135183.pdfsomewhere around pg.189 is where it talks about the Input Data Register for the GPIO ports).This would allow you to copy the contents of the input data registers into a large array which you could then either save to local flash of the F446, or you could stream this to the PC either via USB, or something else.Should be 'Pretty Easy'(tm) to set this all up with or without the stmcube.

author: JVR
author_rank: Regular Contributor
timestamp: January 18, 2019, 12:09:06 pm
content: Start slow, work your way up to the speed you need. Slow is easy, as you just read the IO pins and report their states to a PC. Fast, that depends on if you want time or state based analysis.

author: NorthGuy
author_rank: Super Contributor
timestamp: January 18, 2019, 03:44:12 pm
content: Instead of MCU, look at FT232H. One of the interfaces - FT1248 - is practically a clocked bus, exactly what you need. They claim 30 MBytes/s, so 20 MHz should be fine.https://www.ftdichip.com/Products/ICs/FT232H.htm

author: obiwanjacobi
author_rank: Super Contributor
timestamp: January 19, 2019, 06:49:11 am
content: I looked into DMA, but I need to do more reading because Cube did not let me configure the way I thought it would work.In the spirit of start slow (and simple) I may leave DMA out of the picture for now. Maybe refactor the code a bit later when I need/want more speed. Basically all I need to do is to run all Z80 instructions at least once - I don't mind if that takes all night.I'm also planning on supporting the non-documented instructions.I really want to stick with the hardware I've got. I know there are more optimal solutions possible, but this is more a (my first little) STM32 project - if anything else.I ordered some connectors for it to connect together. Could not find any DIP40 cable sockets (DIP40 plug to flat cable) so I rigged something up. She'll be right.Currently chopping away at the disassembling part that will run on the PC.

author: blacksheeplogic
author_rank: Frequent Contributor
timestamp: January 19, 2019, 08:36:38 am
content: Quote from: lucazader on January 18, 2019, 09:42:47 amYou need use the clock and sample between the edges.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: January 23, 2019, 01:58:52 am
content: Why not simply buy a logic analyser?You can get a "24MHz 8ch" box from Ali / Ebay / China for less than EUR 10 and these work great with Sigrok / Pulseview.Any development board with a Cypress CY7C68013A on it will also work. See the Sigrok site for more documentation.There are some (very small) drawbacks though:Some old versions of this chip have a high current consumption and get warm when the USB is not initialized (after first plug in).The cheap boxes from China tend to be quite dirty inside and have agressive flux residues. So open the box and clean it with a bit of water, soap and a toothbrush.Sigrok is gaining more popularity. I've seen a british shop selling the same "salaea" clone for specific use with Sigrok, and even Sparkfun is selling similar boxes nowadays:https://www.sparkfun.com/products/15033

author: obiwanjacobi
author_rank: Super Contributor
timestamp: January 23, 2019, 06:41:10 am
content: Yeah I know, I have one, but I want to monitor all 40 pins of the Z80 - well 38 not counting VCC and GND...I don't think I can connect 5 boxes at the same time and get reliable results...Thanx.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: January 23, 2019, 10:45:43 am
content: The regual Cy7 boxes are made for only 8 channels as you probably know.When you stick a general CY7C68013 board (those with 2 doulbe row headers) onto Sigrok you get 16 channels, but those have no input protection, you'll have to add that yourself.I'm not sure how many channels the fx3fun project has in Sigrok, but it is probably not fully polished / integrated in Sigrok, it is not listed in the supported hardware part on the Sigrok site.https://github.com/cnlohr/fx3funThe FX3 board sure has impressive capabilities though. and it's also based on ARM.http://www.cypress.com/documentation/development-kitsboards/cyusb3kit-003-ez-usb-fx3-superspeed-explorer-kitThe FX3 board is also supported by:https://sysprogs.com/w/tag/analyzer2go/Analyser2go also supports various STM32F4xx boards, but without the Cypress peripheral the streaming bandwidh is much lower. It is also a commercial package, so instead of having the ability to learn something from the source code you are probably stuck with an expensive binary blob if you want to use it for more than 2 weeks.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: January 23, 2019, 12:19:25 pm
content: I don't think USB speed is an issue here. I will just run the Z80 at a slower clock speed if my ARM software is too slow.Like I said, I really want to stick with the hardware I've got.

author: MasterT
author_rank: Frequent Contributor
timestamp: January 23, 2019, 02:08:21 pm
content: I tested my stm32f446RE (64-pins nucleo) for parallel port reading, using TIM->DMA->GPIO signal /trigger path. It's able to readglitch-free at about 11.25 MHz.Have you defined 40-pins? I think, you would have to use 3-4 GPIO ports to assembly 40 lines bus. This 'd be the most difficult part, to locate pins that:1. Belongs to the same port2. Consecutive pins, A0, A1 ...etc.3. Less overall number of ports , less congestion on the DMA bus.DMA couldn't read each pin, it get's in 8-bits blocks. Block is like A0-A7, A8-A15, B0-B7 etc.It possible to not carry for 1, 2, 3 but speed would be much lower than 10 MHz, and more complex pin-bit-magic needs to re-map data.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: January 23, 2019, 03:23:28 pm
content: I have played around with CubeMX trying to figure out what pin assignments would make most sense.So far I've concluded that the 16 bit address bus would be one full port and the 8 bit data bus half a port (preferably the lower half).Now I'm looking into the clock signal, the most critical to be high speed and preferably able to trigger interrupts on both pos- and neg-edges...Not figured that out yet.So not using a timer here, but the real clock that is used in the circuit - which is adjustable.If I would get as fast as 10 Mhz I would be more than happy. For the logic analyzer it is not very important to be super fast because I can slow the Z80 down.I see this project as a 'getting my feet wet' prelude to the real thing - the in-circuit emulator. If I could get the emulator up to into the couple of MHz, that would be great. A lot more logic will run on the STM32 chip for the emulator than for the logic analyzer.

author: MasterT
author_rank: Frequent Contributor
timestamp: January 23, 2019, 03:52:50 pm
content: Study : AN4666 Application note Parallel synchronous transmission using GPIO and DMAThere is a code available to download from ST.com, unfortunately you have to adapt F429 to F446, since transmit / receive examples for F429.https://my.st.com/content/my_st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/x-cube-paral-com.html

author: TomS_
author_rank: Frequent Contributor
timestamp: January 30, 2019, 01:02:07 pm
content: Quote from: obiwanjacobi on January 18, 2019, 08:17:22 amExcept for the exercise itself, you shouldnt need to do this.The Z80 datasheet contains all of the timings for the various signals used in memory/IO read/write operations, so it should be easy enough to reproduce these in code.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: January 30, 2019, 02:13:34 pm
content: Quote from: TomS_ on January 30, 2019, 01:02:07 pmIf with 'datasheet' you mean theuser manual, than no - that does not contain enough detailed info.I have recently found aMostek documentthat (looks a lot more like a datasheet and) identifies the operations per machine cycle (one instruction may execute in multiple machine cycle, each taking multiple clock cycles), page 85 - that helps, but the details of how these operations manifest on the Z80 signal lines is not specified (have not read through the entire document yet - so disclaimer).Still, it would be a good stepping stone for a in-circuit emulator, would it not?Here are some screen shot of some simple tests I have performed.Code:org $0000start:ld b, 2loop:djnz loophaltCode:org $0000start:ld a, $AAld bc, wordld (bc), ahaltword:defb 00, 00

author: Doctorandus_P
author_rank: Super Contributor
timestamp: January 30, 2019, 05:03:19 pm
content: Pulseview has a software decoder of Z80 Asm from LA traces.

author: blacksheeplogic
author_rank: Frequent Contributor
timestamp: January 30, 2019, 07:35:36 pm
content: Quote from: obiwanjacobi on January 23, 2019, 03:23:28 pmThe logic/code is simple, your problem is trying to develop an ICE using flying leads to GPIO pins on a micro. It's not a good way to go.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: January 31, 2019, 06:36:36 am
content: Quote from: blacksheeplogic on January 30, 2019, 07:35:36 pmBut is it good enough? It might not be the best, fasted, most professional bla blaBut will it work with the hardware I've got (F446) knowing I can lower the Z80 clock speed as needed...Just saying it is no good, does not really help other than stamping out enthusiasm someone might have...Quote from: Doctorandus_P on January 30, 2019, 05:03:19 pmThanx! I don't know how I missed PulseView, but I had never heard of it before. I can even import and export data files, so I blast the recorded signals to the PC and transform them to a suitable format and then view them in PulseView. Excellent!

author: blacksheeplogic
author_rank: Frequent Contributor
timestamp: January 31, 2019, 07:40:50 pm
content: Quote from: obiwanjacobi on January 31, 2019, 06:36:36 amOr instead of thinking someone is out to get you, you cold also take it as a suggestion to rethink though the design.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 01, 2019, 05:52:34 am
content: Quote from: blacksheeplogic on January 31, 2019, 07:40:50 pmLucky for me, I don't think thatDon't you think some pointers in which area you see a problem would be more constructive?Previous posts also talked about using different hardware etc - but I really want to use the F446 I've got.

author: ale500
author_rank: Frequent Contributor
timestamp: February 01, 2019, 08:46:23 pm
content: Lowering the clock can work very well, but I was thinking maybe you can "latch" the information in some '573s and then read them in sequence using your 8 channel logic analyzer, or the STM32.Another device that may be of interest is a Cypress PSoC5. It has some logic that could do what you want, I saw a project some time ago doing almost that, and it has 5 V tolerant inputs.

author: Yansi
author_rank: Super Contributor
timestamp: February 01, 2019, 10:04:16 pm
content: I do not see it mentioned above, butUSE A DCMI INTERFACE TO CAPTURE EXTERNAL DATACan be clocked externally (slave parallel inputs) with high precision. GPIO + DMA + TIM is an amateur hour how ya doin solution. And unlikely to be faster than the DCMI interface.//Also, there is an internal burst fifo and access to fast bus. Plain DMA needs just to many bus turnaround cycles.)

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 02, 2019, 06:45:58 am
content: Quote from: ale500 on February 01, 2019, 08:46:23 pmYep, PSoC5 I know. Good call, will look into that. With the help of the programmable logic, it might just be fast enough - not sure.The Latches - don't know. I want to trigger them on the pos- and neg-edge of the clock and frankly I don't see what benefit having this extra indirection brings...You still have read that -now latched data- at the same speed as you would without latches.Quote from: Yansi on February 01, 2019, 10:04:16 pmExcellent, thanks! Will look into that - have to read up on a lot of the special interfaces these STM32's have...

author: blacksheeplogic
author_rank: Frequent Contributor
timestamp: February 02, 2019, 07:35:19 am
content: Quote from: obiwanjacobi on February 02, 2019, 06:45:58 amYou might be able to lower the clock speed but how will that effect everything else on the bus and can you met the timing constraints. Adding programmable logic on the probe head can buffer, transitioning states needs to be synchronous and there will also be skew which may violate constraints otherwise.I guess it comes down to what you are trying to accomplish, a fancy project with lots of wires flashing a LED connected to a bit of 7400 logic, or a useful Z80 ICE. The latter needs to be able to take the place of a actual CPU.Also, often overlooked is that an ICE is a tool which replaces the processor and provided quite complex debug functionality including emulation (for example memory) as well as hardware debug. There's no benefit if all it does it replace the CPU (especially if it cripples the system), far better to focus on the logic analyzer portion and make something useful - for example runs at full bus speed and provides an instruction/data trace which was a common use. You don't have to take the place of the CPU to do this.

author: Yansi
author_rank: Super Contributor
timestamp: February 02, 2019, 08:07:01 am
content: DCMI can be configured to trigger on either CLK edge and can be gated using the HSYNC signal, if configured in suitable mode.I do not think you can make any better logic analyzer than using the DCMI, without adding an external dedicated logic (CPLD/FPGA with fast RAM).Also remember, that the absolute maximum speed DCMI is operable, should be HCLK/3, i.e. 56MHz. If you go over that, it will do rubbish. I'd make the analyzer sample at 50MHz. It is a nice round value and still enough faster than those crap "Saleae whatever" clones from china.However if your target then will be to make a Z80 in circuit emulator, your best friend is an FPGA anyway. Would become very tedious to try achieving so using just software on a completely different architecture.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 02, 2019, 02:59:04 pm
content: I want to build a Z80 in-circuit emulator that supports call tracing, debugging/breakpoints and circuit manipulation (like writing to the memory in-circuit).To know how the Z80 drives its pins I thought I would make a purpose built logic analyzer and stream execution of a special program (that simply issues 'all' instructions) to the PC over USB. On the PC I would record the USB data stream and convert that into one of the import formats PulseView supports to make pretty pictures. I might even write awavedromconvertor. This information is the basis for writing the in-circuit emulator.I would like to be able to get it to run in the 4-6 MHz range or higher if feasible. That would make it a general purpose Z80 in-circuit emulator usable for anyone with a homebrew project or to repair a vintage home computer. Concerns about timing alignment and skew are reasonable, although I have half a clock cycle (25ns at 20MHz or 125ns at 4MHz) to (over?) sample the pins... True, some pins are a little slower than others but all triggered on pos- or neg-edges. Clearly this is the critical speed factor (for the in-circuit emulator): At what speed can I reliably read/write all pins and perform the (debugging)logic...?My circuit can run at 1kHz (-tested- probably even slower) so I am not worried about slowing the clock.I picked the F446 because I have that laying around (PSoC5 too) - I want to avoid having to setup an entire hardware project for this.I did play with FPGA's a bit (my circuit uses a CPLD) but writing a Z80 softcore with these features is out of my league (yes I know there are existing Z80 softcores - still would require me to add features).Also, it is a STM32 learning experience.

author: NorthGuy
author_rank: Super Contributor
timestamp: February 02, 2019, 05:18:19 pm
content: Quote from: obiwanjacobi on February 02, 2019, 02:59:04 pmIf speed is not a problem then you can do practically anything. To get 40 pins @1 kHz, even serial sampling at 40 kSa/s will work. The higher the speed, the tougher it gets.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 09, 2019, 11:04:31 am
content: I am trying to get a hello world over USB working:Spew a counter value over USB to the PC where an app using libusb is picking that up.Problem is I do not speak SMT32's HAL speak yet so I feel lost in the woods - remember this is my first SMT32 project.I use CubeMX to generate the code and Atollic True Studio as IDE.In CubeMX I've configured the USB as Device only (deselected SOF and VBUS) - kept all defaults.The USB_DEVICE middleware I have set to HID because that is easiest to get working on Windows - also all defaults.I also do not know the details on how USB works. Turns out that these are too many unknowns to be able to quickly get this going.Hence I turn to you.Found an USB sample in STM32Cube/Repository but that only shows basically the same code I get from CubeMX: it init's the USB but does not send anything (great sample guys!)I don't know what calls to use to actually send some data over USB (and can't find a CubeMX/HAL example).I have tried some (last one was USBD_CtlSendData), but they made getting the descriptors fail on the PC or returned error codes...I would really appreciate some pointers:- to CubeMX/HAL documentation- an example of using USB with an F4 (or similar) that actually does something- what type of USB config is simplest and fastest - and how to set that up?I have seen lots of other (custom) libraries, but I really would like to keep the dependencies down and not involve other stuff.Also, I hear everybody bash HAL - I would like to see for myselfAdded to MX_USB_DEVICE_Init()Code:USBD_LL_OpenEP(&hUsbDeviceFS, 1, USBD_EP_TYPE_BULK, 64);main.cCode:...MX_USB_DEVICE_Init();long counter = 0;while (1){USBD_StatusTypeDef result = USBD_CtlSendData(&hUsbDeviceFS, (uint8_t*)&counter, sizeof(counter));if (result == USBD_OK)counter++;}...*) removed all the green code markers

author: Yansi
author_rank: Super Contributor
timestamp: February 09, 2019, 12:15:50 pm
content: There is enough USB examples already present in the library packages and enough application notes and other third party materials for this.Just don't be lazyhttps://damogranlabs.com/2018/02/stm32-usb-cdc/

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 10, 2019, 06:55:47 am
content: Quote from: Yansi on February 09, 2019, 12:15:50 pmWith 'library packages' do you mean the 'STM32Cube/Repository' folder?That is where I found a 'demonstration' of USB HID but without any actual data handling.There are so many projects there that it is hard to find the right one.Quote from: Yansi on February 09, 2019, 12:15:50 pmI try not to be - I have spend a good few hours trying out different USB configs and searching online for the relevant information.But most experienced users (in any field) forget how many little bits of information you need to know to be sufficient in the object matter.Some things that might be logical and self explanatory to you - can be a mystery to me (I'm a noob in this).So asking for some pointers could just fill in that missing piece for me.Quote from: Yansi on February 09, 2019, 12:15:50 pmYes CDC - that brings up the USB device as a COM port (on windows at least). I was not sure if that was the correct interface for the highest bandwidth.Is that your recommendation - that I use CDC instead of HID? And if so, should I still use libusb on the PC or just fallback to the Windows COM API?BTW I choose HID assuming it would be the easiest to get going...Thanx.

author: Yansi
author_rank: Super Contributor
timestamp: February 10, 2019, 11:50:16 am
content: CDC is definitely NOT for high data bandwidth! Sorry if I have confused you, I thought you were attempting that.But definitely the easiest. In theory, there is no limit, but in practice, the limit are fucking stupid windows USB drivers (USB host does not ask the device for data quick or often enough) and on linux the speed is bit better, but nearly not what USB is capable of.If you need high bandwidth, make a completely custom protocol and use bulk transfer to move large amounts of data. However doing so requires in depth knowledge of USB which, guessing by your confusion with the libraries, you are lacking.This will probably require writing custom drivers and/or working around with universal ones, like the libusb or others.I am not sure how would you define a logic analyzer as an HID device. HID would most than likely be ultra slow interface, due to transfer type it uses (interrupt?).//yes, the standard COM Api is enough. If you can work with libusb, definitely use that instead over a custom protocol.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 10, 2019, 03:45:12 pm
content: No problem - I got a CDC echo working on a COM port (using putty) but as soon as I spew data in the main loop the PC does not recognize the USB device anymore.Ok custom USB protocol: Is usingZadigcustom enough?When I replaced the standard Windows driver for the CDC sample (above) with winUSB I could pick up the connection with libusb in my PC program - did not check any data transfer, but I could open the USB with the vendor and product Ids.Is there a CubeMX middelware usb device option for a custom protocol, or is that all hand coded? or- what CubeMX option would be a good starting point to copy from as a basis...?Hmm, now I have the feeling I am the first one who tries to interface a STM32 to a PC with USB FS at 'Full Speed' - that can't be right, surely loads of other people have done this before me...?

author: MarkL
author_rank: Unknown
timestamp: February 10, 2019, 05:04:41 pm
content: Quote from: obiwanjacobi on February 10, 2019, 03:45:12 pmI've done it on a STM32F767 in FS mode, and using the HAL CDC driver. It can sustain about 880kB/s (~7Mb/s) with a linux host. I haven't looked at this for about a year, but take a look at a couple of things:- In usbd_cdc_if.c APP_RX_DATA_SIZE should be 64 (not 4).- After requesting a buffer to be sent via CDC_Transmit_FS(), you cannot change the data in the buffer until the transmit completes.- And, while a buffer is being transmitted, you cannot call CDC_Transmit_FS() again until the interface is idle.To address these last two, I used hcdc->TxState to check for idle, and set up a simple double buffer to handle newlib _write()'s to the USB interface to make sure CDC_Transmit_FS() has dedicated access to the transmit buffer.Maybe ST has addressed these issues in more recent versions of CubeMX/HAL. The version I made these fixes to is at least a year old (probably more).

author: Yansi
author_rank: Super Contributor
timestamp: February 11, 2019, 01:03:35 am
content: I don't know, I am not too much of a windows programmer, I have only briefly encountered Zadig for the RTL-SDR dongle. And guess what - didn't work.LibUSB could be likely installed manually (INF file is needed to be created to assign the driver to your device).Regarding the speed - we have tested also CDC at USB HS interface, the maximum speed (linux) was about 60mbps if I remember correctly. Which is "good enough", but nearly not the fulll USB potential there.I should probably learn how to code GUI on PCs, especially to test out the libusb (I have quite some interesting applications for that too).

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 11, 2019, 06:54:13 am
content: Good pointers @MarkL - thanks a lot.I will code that up in my test program and see if I can transfer data to the PC with libusb.We'll go from there.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 12, 2019, 11:32:34 am
content: Quote from: MarkL on February 10, 2019, 05:04:41 pmSeems like the current CubeMX code has these points pretty much covered. CDC_Transmit_FS() returns USB_BUSY if TxState != 0.Stepping thru my STM32 code I can see the first call to CDC_Transmit_FS() is successful, after that it never works again.I also have trouble receiving data on the PC. Do I need to flush anything?main.cCode:MX_USB_DEVICE_Init();const char* text = "-";while (1){USBD_StatusTypeDef result = CDC_Transmit_FS((uint8_t*)text, 2);if (result == USBD_OK)HAL_Delay(200);}Also been looking at the interface and endpoint numbers. Not sure which numbers I should use. Is there any way I can find this out?On the PC side I do aCode:libusb_claim_interface-which takes an interface number and for receiving I start a transfer withCode:libusb_alloc_transferandCode:libusb_submit_transferwhich take an endpoint number (and is input | 0x80)...I have used this type of code successfully with the PSoC5 USB...Amazing how much time you can spend on something that looks simple enough...

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 12, 2019, 04:39:02 pm
content: I sniffed out the STM32 USB on the PC:I'm using interface 3 and input EndPoint 5Code:descriptors = "Configuration Descriptor"bLength = 9bDescriptorType = USB_CONFIGURATION_DESCRIPTOR_TYPE (2)wTotalLength = 67bNumInterfaces = 2bConfigurationValue = 1iConfiguration = 0Reserved = 0SupportsRemoteWakeup = 0SelfPowered = 0PoweredByBus = 1MaxPower = 0x96 -> 300 mAdescriptors = "Interface Descriptor"bLength = 9bDescriptorType = USB_INTERFACE_DESCRIPTOR_TYPE (4)bInterfaceNumber = 2bAlternateSetting = 0bNumEndpoints = 1bInterfaceClass = UsbCommunication (2)bInterfaceSubClass = 2bInterfaceProtocol = 1iInterface = 6descriptors = "Class-Specific Interface Descriptor"bLength = 5bDescriptorType = CS_INTERFACE (36)bDescriptorSubtype = 0comm_interface =bcdCDC = 272descriptors = "Class-Specific Interface Descriptor"bLength = 5bDescriptorType = CS_INTERFACE (36)bDescriptorSubtype = 1comm_interface =call_capatibilities =controls =UseClassInterface = 0SelfControl = 0Reserved = 0bmCapatibilities = 0bDataInterface = 00000011descriptors = "Class-Specific Interface Descriptor"bLength = 4bDescriptorType = CS_INTERFACE (36)bDescriptorSubtype = 2comm_interface =abstract_control_capatibilities =controls =FeatureSupport = 0LineStateSupport = 1Send_Break_Support = 1NotificationSupport = 0Reserved = 0bmCapatibilities = 00000110descriptors = "Class-Specific Interface Descriptor"bLength = 5bDescriptorType = CS_INTERFACE (36)bDescriptorSubtype = 6comm_interface =bMasterInterface = 2bSlaveInterface = 3descriptors = "Endpoint Descriptor"bLength = 7bDescriptorType = USB_ENDPOINT_DESCRIPTOR_TYPE (5)bEndpointAddress = 4Reserved = 0Direction = Inputtype = Interrupt (3)reserved = 0wMaxPacketSize = 2bInterval = 255descriptors = "Interface Descriptor"bLength = 9bDescriptorType = USB_INTERFACE_DESCRIPTOR_TYPE (4)bInterfaceNumber = 3 <<==bAlternateSetting = 0bNumEndpoints = 2bInterfaceClass = UsbCommData (10)bInterfaceSubClass = 0bInterfaceProtocol = 0iInterface = 7descriptors = "Endpoint Descriptor"bLength = 7bDescriptorType = USB_ENDPOINT_DESCRIPTOR_TYPE (5)bEndpointAddress = 5Reserved = 0Direction = Outputtype = Bulk (2)reserved = 0wMaxPacketSize = 8bInterval = 0descriptors = "Endpoint Descriptor"bLength = 7bDescriptorType = USB_ENDPOINT_DESCRIPTOR_TYPE (5)bEndpointAddress = 5 <<==Reserved = 0Direction = Input <<==type = Bulk (2)reserved = 0wMaxPacketSize = 16bInterval = 0

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 13, 2019, 04:57:13 pm
content: Several things were wrong but the understanding that the Host initiates the USB communication with the device got me looking in the right place.My basic test program now works. I can send data from the STM32 (CDC USB) to the PC and have libusb read that data.When my order of connectors come in I can wire up a test setup and progress further.