"Roberto Waltman" <usenet@rwaltman.com> wrote in message news:cs77o6d9s11bvdqa080684fedbdt6ivqf9@4ax.com...> Plus the constant annoyance of COM port numbers changing with the > direction from which the wind is blowing. Today is COM739, tomorrow, > who knows...If you include a unique serial number for the USB device, and the FT232R has this provision, this problem does not exist. Once assigned, the COM port number is linked to that device, no matter which USB port you plug it into. Meindert
USB as standard debug interface
Started by ●March 18, 2011
Reply by ●March 21, 20112011-03-21
Reply by ●March 21, 20112011-03-21
On Fri, 18 Mar 2011 09:52:10 -0700, acd wrote:> In the past the typical debug backdoor was a RS232 interface. I have for > instance a BlueWave multi-DSP VME board, which has beside the VME and an > ethernet board an > RS 232 for console output. > The reason RS232 was chosen for this purpose is obvious, cheap, small, > available on most PCs, easy to implement and in a way foolproof (or at > least problems such as wrong pinout can be easily fixed). > > I would expect that this role will is been taken over by USB now. The > question is however, what type of service is used. Is there something > established, or is this not necessary? I am aware that I can do a serial > interface, jtag, etc. through USB, but this variety would counter the > notion of "simply working without special SW" that the RS 232 provided. > > What do you think?Has anyone used the USB debug feature that is described in Appendix C of the EHCI spec? It's been in the spec for over a decade now, but I only found out about it recently. Brief description: EHCI controllers have an optional "USB debug" mode in which the USB transceiver can be used to communicate with another similarly configured device, with an internal interface that's not much more complicated than that of a UART, the intention being to replace the function of a UART for debugging without needing a USB protocol stack. The mode is optional, but seems to be supported on USB port 0 of all Intel devices with USB. EHCI spec: http://www.intel.com/technology/usb/ehcispec.htm Example gizmo (to connect two USB debug ports): http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=12083 There's info here showing that this mode is supported on devices from a number of manufacturers: http://www.coreboot.org/EHCI_Debug_Port Regards, Allan
Reply by ●March 21, 20112011-03-21
On 2011-03-21, Chris H <chris@phaedsys.org> wrote:> > Methods of debugging are > > ICE (best method if available) > Logic Analyser > SWD (cortex) > BDM > JTAG > serial monitor > serial (manual debug) > USB >You missed out LED (+ current limiting resistor) connected to a GPIO pin. :-) Great for debugging interrupt routines. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
Reply by ●March 21, 20112011-03-21
"Meindert Sprang" wrote:>"Roberto Waltman" wrote >> Plus the constant annoyance of COM port numbers changing with the >> direction from which the wind is blowing. Today is COM739, tomorrow, >> who knows... > >If you include a unique serial number for the USB device, and the FT232R has >this provision, this problem does not exist. Once assigned, the COM port >number is linked to that device, no matter which USB port you plug it into.Thank you, I am aware of that. Can do it on my own devices (not always,) but not with other products like the COTS USB to RS-232 dongle I used recently. Searched for a while for a way to change the COM numbers programmatically, but did not get far. Found a bunch of registry entries that I could not delete. (on Windows XP) -- Roberto Waltman [ Please reply to the group. Return address is invalid ]
Reply by ●March 21, 20112011-03-21
Rich Webb wrote:>A Google search for <Windows boot serial mouse "not work"> turns up >quite a few examples where the recommended fixes were not effective. I >couldn't get it to work reliably with an XP Embedded project and had to >make do with a hardware work-around.I had trouble with an XP-Embeded project where the PC will attempt to boot from the mouse, keyboard, etc. ignoring the only USB mass storage device connected. (Also ignoring any BIOS settings controlling enabled boot devices, their order, etc.) The workaround was also to add harware to disable some of the USB ports and re-enable them under application control, well after the XP boot process. -- Roberto Waltman [ Please reply to the group. Return address is invalid ]
Reply by ●March 21, 20112011-03-21
In message <im7lrd$12k$1@news.eternal-september.org>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes>On 2011-03-21, Chris H <chris@phaedsys.org> wrote: >> >> Methods of debugging are >> >> ICE (best method if available) >> Logic Analyser >> SWD (cortex) >> BDM >> JTAG >> serial monitor >> serial (manual debug) >> USB >> > >You missed out LED (+ current limiting resistor) connected to a GPIO pin. :-)true>Great for debugging interrupt routines.But not as good as an ICE or LA The problem is you never really know what caused the LED to light. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●March 21, 20112011-03-21
Simon Clubley wrote:> On 2011-03-21, Chris H <chris@phaedsys.org> wrote: >> >> Methods of debugging are >> >> ICE (best method if available) >> Logic Analyser >> SWD (cortex) >> BDM >> JTAG >> serial monitor >> serial (manual debug) >> USB >> > > You missed out LED (+ current limiting resistor) connected to a GPIO pin. > :-)That's a Logic Analyzer :) Mel.
Reply by ●March 21, 20112011-03-21
In message <im7nnd$r8a$1@speranza.aioe.org>, Mel <mwilson@the-wire.com> writes>Simon Clubley wrote: > >> On 2011-03-21, Chris H <chris@phaedsys.org> wrote: >>> >>> Methods of debugging are >>> >>> ICE (best method if available) >>> Logic Analyser >>> SWD (cortex) >>> BDM >>> JTAG >>> serial monitor >>> serial (manual debug) >>> USB >>> >> >> You missed out LED (+ current limiting resistor) connected to a GPIO pin. >> :-) > >That's a Logic Analyzer :)Luxury! We had to debug in a darkened room with the off the MCU watching the gates glow as they switched working with a print out of the assembled (wot's a compiler?) binary...... You tell that to the kids these days and they don't believe you. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●March 21, 20112011-03-21
On 2011-03-21, Chris H <chris@phaedsys.org> wrote:> >>You missed out LED (+ current limiting resistor) connected to a GPIO pin. :-) > > true > >>Great for debugging interrupt routines. > > But not as good as an ICE or LAOn many platforms, ICE is useless for things like timeing measurement. An LED (or better yet a few of them) works brilliantly for timing measurements.> The problem is you never really know what caused the LED to light.While I suppose that's true in a theoretical sense, it's not true in a practical sense. In the real world (at least the one I work in), you do know what cause the LED to light. -- Grant Edwards grant.b.edwards Yow! I'm EMOTIONAL at now because I have gmail.com MERCHANDISING CLOUT!!
Reply by ●March 21, 20112011-03-21
On Mon, 21 Mar 2011 10:54:03 +0100, "Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> wrote:>"Rich Webb" <bbew.ar@mapson.nozirev.ten> wrote in message >news:p647o6502mcuh9961hlh17ku8q7i75ckvi@4ax.com... >> The only gotcha that I've seen to this is that WinXP might decide that >> it "recognizes" an FTDI/Prolific USB-serial connection as something >> other than a simple COM port if the port is active when the connection >> is plugged in. I have a board, for example, that's spitting out NMEA >> sentences over an FT232R that is *always* installed as a "Microsoft >> serial ballpoint" if the port is active when it's plugged in. The mouse >> cursor goes berserk. > >You can easily prevent this problem by disabling Plug and Play enumeration >by modifying the INF files. FTDI provides documentation on how to do this.Interesting. Thanks! Any reason that you're aware of (or bad things that may happen) if the serial enumerator is de-selected for all virtual COM ports? -- Rich Webb Norfolk, VA
