Having worked on interfaces to several bus systems, but not USB, I've found the relevant specs essential. I'm not saying you have to read the whole thing but when the software gets tough its good to be able to look at the spec and compare with what your code is doing, or not doing. I found someone had coded to cope with the situation when everything happened ideally, no bus conflicts, no unresolved addresses, no planning for when a thread to receive wasn't available etc. At times it was only by reading the bus spec I could find out what should have been coded for. For instance I found an unreliable bus system on the test rig was due to no pull up resistors on the data lines, something I found in the spec, and something somebody had spent a long time trying to resolve with a debugger.
EDIT - Thanks to everyone that replied. I have found a better solution than an INF file.
My company has an existing software-only driver. The 32-bit version is being installed using InstallShield. Unfortunately for me, the company wants to get away from InstallShield as the product in question is going to be part of a customer's own installation. The build system here produces the 64-bit signed driver, and I am tasked with creating a .inf file to install this driver. I've been reading Microsoft documents about .inf files (until my eyes are bleeding) and all of this documentation seems to be centered around the Windows Driver Development Kit. I believe that this kit generates a .inx file which is really the .inf file. However, all I need to do is create a .inf file that will do the job.
When right-clicking on the .inf file and selecting Install, the install process is spectacularly silent about anything that is happening (right or wrong). So it is very difficult to determine what is happening.
Some of my problems include the following:
1. The driver is already signed, so I find it unlikely that I will need a CatalogFile. Will the .inf file work without a defined CatalogFile?
2. It seems that a software-only driver needs to have some dummy device installed, and (from the InstallShield results) I see this dummy device in HKLM\CurrentControlSet\Enum\Root\LEGACY_DRIVER_NAME. This is somehow linked to service entry in HKLM\CurrentControlSet\services\driver_name which points to the actual driver executable in \Windows\System32\drivers. I'm getting lost trying to define this dummy device.
3. I am successful installing the service, and I find it in the registry, but the install process never copies my driver into the drivers directory, so it appears to die before it gets that far.
4. I keep reading about a CoInstaller, but I get the feeling that it is not exactly necessary. Is this correct?
What I need is a clue. I haven't defined the dummy driver entry which is where I need the help. I've also made the assumption that the install directory where the .inf file is executed from is the root of the SourceDisk. Here's what I have in my .inf file so far:
That's a very good suggestion. However, since I posted my question I have become aware of the sc.exe command that can be used to directly install a software-only driver. This solves my problem. Thanks for your help.
Why are you trying to go that slow? ...you can simply oversample a slow incoming signal btw (turn it into a high rate signal), but you have to make sure you have DC coupling wherever the slow signal is coming into, not sure if USB is AC or DC coupled. If it happens to be AC coupled, the slow DC rates are going to get filtered out by the coupling capacitor.
I ran into the same problem some time back, a communication link had a 5-baud initialization sequence where communication parameters were negotiated. Unfortunately we did not find any UART that supported this reliably. So our solution was to use a GPIO pin combined with a UART, implement the 5-baud initialization by sampling the GPIO input and after the negotiation switched the GPIO to high-Z and enabled the UART, now with a supported, high baud rate.
Hope this helps.
The first six are all apparently interrput handler conflicts. Here they are (condensed and abbreviated for clarity)...
multiple definition of `_U1RXInterrupt'
multiple definition of `_U2RXInterrupt'
multiple definition of `_U3RXInterrupt'
multiple definition of `_OscillatorFail'
multiple definition of `_AddressError'
multiple definition of `_StackError'
multiple definition of `_MathError'
I'm getting one last error that is totally new to me, this one...
Link Error: Could not allocate section .nbss, size = 20004 bytes, attributes = bss near
Link Error: Could not allocate data memory
I really need
for my assembly language routines.
Can someone tell me how to get the C compliler and MpASM to cooperate and let me have those two ?
I can take out the other interrupts from my assembly language with some text editing.
Your advice and guidance will be greately appreciated.
I reckon the problem stems from your program's design - that is to say, I've heard of mixing asm and C code for decades. I don't recall ever seeing someone put c code into an asm project - it's always the other way around. Regardless of compiler/system, gcc/tc/vs and mips/x86/arm/sparc etc, etc
I'll have another play with it when it's finished installing again.
Mmmm, what version of MPLAB if it's MPLAB X is a <<very bad="" word="">> to set up the project but once you have it is quite good I am told, I have not gone there myself I tend to use MPLAB 8.80. My advice is to download a demo project from Microchip and have a play. If there demo starts to go wrong then them on their board (online, they are quite good usually only had yell once!)
You are sure that the assembly is 100% valid on the 24F as there differences in there can't really remember Best of luck!
I'm working on improving a GUI on an application, I have a tabconrol with many pages, I want to put a background Image instead of the unique color which appear behind, I didn't find any property to do it .. Is there any way ??
your help is really appreciated,
So lately I'm having a weird problem with my USB ports. I'll try to explain.
I keep hearing that sound like someone's putting in a flash drive & removing it. Over & over & over. Also, when I look in Windows Explorer, I see a number of "Removable Drives". They must be some kind of virtual drive because I certainly don't have that many pysical drives. They were there when I bought the PC.
At any rate, this problem isn't happening all the time. It just randomly starts. When it's happening, the list of drives in Windows Explorer disappears and reappears at a fast rate in sync with the sound I described.
This is a fairly new PC, and I use AVG and Malware Bytes and scan regularly.
I have a wireless keyboard & mouse, a wireless headset, a printer, and 2 monitors plugged into the USB ports.
I have no clue how to figure out what's wrong. Any hardware people wanna point me in the right direction.
I'm not a hardware-person, but.. if you open the "properties" screen of "my computer", go to "Advanced settings", then to the "Hardware" tab and press the button "Device manager" (or somthing similar, using a silly localized/non English version of Windows atm), you'd launch an app that shows a tree with all the hardware. Try to find the USB-node, and see if Windows tries adding a piece of hardware - there'd be a node appearing and disappearing in sync with the sound.
If you do find one, disable it.
If that fails, download TweakUI and disable every drive that you're not currently using.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
Does your computer have a media card reader? If so, that's probably where all those drives are coming from. Each one of those card types has an allocated virtual drive to load to.
Now, to get to your actual problem, it sounds like you're having a problem with some USB peripheral, the drives appearing and disappearing is probably just a symptom of the real problem (i.e. it keeps trying to refresh). The problem can really be anything USB (including your keyboard or mouse) or even one of the USB chips that's malfunctioning (or the power to it is dropping below whatever is it's minimum).
- Disconnect ALL external USB items and see if problem appears.
- Try to find old style keyboard and mouse to drive.
- Disable the media card reader on the device manager if there.
- Start in safe mode and see if problem occurs there.
- If problem still persists... you'll need more experienced help (need to check voltage levels to USB chips, may be problem with motherboard or powersupply... more likely motherboard since the power to the chips should be going through a regulator on the motherboard).
In system config on the target you need to enable kernel debug specifying firewire of serial.
Hook the target to the host with tht relevant cable.
Turn off the target.
Run windbg on the host and set it to kernel debug on the relevant interface (firewire or serial).
Restart the target and it should connect and you will see a lot of debug data.
You then set the path in windbg for the symbols and code for your driver (and use the global microsoft symbol server for their code, search in help for symsrv), then you can set breakpoints and step through your code.