I am in the process of designing up a schematic and PCB for a project that will use a USB/uSD-Card bootloader similar to the SFE one.
I have noticed that the Logomatic and MP3 dev board both have a different USB schematic to the Uber Board.
The Uber Board does not use the MBT3906 and is much simpler.
Anyone got any ideas as to why this is?
Obviously both must work, maybe the Uber board if just a refined newer version, but surely the MBT3906 has a purpose otherwise it wouldn’t have been used?
The MBT3906 is used so that P0.31 can indicate the status of the USB link on an LED (the transistor is there to provide the current required by the LED). If you don’t need to see the USB link status, then you don’t need that part of the circuit. It appears that on the Uber Board, they are using P0.31 as a “sleep” signal (not sure what’s being put to sleep, though).
The sleep signal is for the MMA7260 accelerometer.
They do have a USB_SENSE signal on P0.21, which is used for detecting if the USB is plugged in.
I do not need a USB status LED for my project so I will leave that bit out and go with the Uber schematic.
Thanks again for the help 
If I were you, I’d use the schematic from the MP3 player. While there is support for USB in the UberBoard, the LPC USB libraries will not work with it.
P0.31 must be used in the USB circuit, this is what initiates the USB communication with a PC. If this part of the circuit is not included, a PC will respond with “USB device not recognized” every time you try and plug it in.
If you want you can read through the LPC2148 user manual, it mentions that while using the USB registers, P0.31 is pulled high after recognizing a USB connection. The transistor in the USB circuit then pulls D+ (or D-…I can’t remember) high which starts the communication properly.
I hope this didn’t get to you too late…
btw, the UberBoard circuit is being updated to replicate that of the MP3 player. You’ll see the same circuit on the KinetaMap as well as the new logomatic.
ryowens84:
If I were you, I’d use the schematic from the MP3 player. While there is support for USB in the UberBoard, the LPC USB libraries will not work with it.P0.31 must be used in the USB circuit, this is what initiates the USB communication with a PC. If this part of the circuit is not included, a PC will respond with “USB device not recognized” every time you try and plug it in.
If you want you can read through the LPC2148 user manual, it mentions that while using the USB registers, P0.31 is pulled high after recognizing a USB connection. The transistor in the USB circuit then pulls D+ (or D-…I can’t remember) high which starts the communication properly.
I hope this didn’t get to you too late…
btw, the UberBoard circuit is being updated to replicate that of the MP3 player. You’ll see the same circuit on the KinetaMap as well as the new logomatic.
Not too late at all, I will update my circuit.
From what you say, it would be better if I held off buying my uberboard until the (I think 4 or 5) remaining units are sold and new stock is in?
Also, does the KinetaMap and the LogoMatic use power from USB or do you still need the additional power supply, in this case the batteries?
Heres another question. Does the LED really need to be connected in the circuit? As far as I can tell its not acting as a pull down so it can be left out.
does the KinetaMap and the LogoMatic use power from USB or do you still need the additional power supply, in this case the batteries?
USB can provide enough power to run both of these boards, but you would have to change the firmware for them to work properly. Currently when the board detects the presence of the USB cable, the code stops running to allow the user to access the SD card via the FAT16 interface (Removable Disk Drive on a PC). It wouldn’t be too much of a code change, but why would you want to run Kineta map over a USB cable? Unless you’re attaching this to a laptop and then driving it around I don’t know how it would be useful.
Does the LED really need to be connected in the circuit? As far as I can tell its not acting as a pull down so it can be left out.
You’re correct, the LED can be left out, it just acts as an indicator.
Currently when the board detects the presence of the USB cable, the code stops running to allow the user to access the SD card via the FAT16 interface (Removable Disk Drive on a PC). It wouldn’t be too much of a code change, but why would you want to run Kineta map over a USB cable? Unless you’re attaching this to a laptop and then driving it around I don’t know how it would be useful.
Hi folks, I’m most interested to modify the firmware to enable/create a composite USB device that presents both a Mass Storage Device and a Communication Device (CDC). Specifically the CDC will present the user with a management/diag interface similar to that provided via the bluetooth interface; but via serial and to be able to stream data via the USB port to a GUI application on the host PC.
As such, to achieve the management interface via the USB CDC i need to have the firmware continue to operate my code as well as the USB code.
I’m keen to know more about the ease of which the code can be changed to enable this to occur. I’ve had a half reasonable look around this forum and not found too much more than your discussion on the subject.
Looking forward to your reply.
I know it's been a while but better late than never!ryowens84:
USB can provide enough power to run both of these boards, but you would have to change the firmware for them to work properly. Currently when the board detects the presence of the USB cable, the code stops running to allow the user to access the SD card via the FAT16 interface (Removable Disk Drive on a PC). It wouldn’t be too much of a code change, but why would you want to run Kineta map over a USB cable? Unless you’re attaching this to a laptop and then driving it around I don’t know how it would be useful.
What I meant was that you have a board that run’s off a battery, now when you plug this into USB, you still need that battery connected to provide the 3.3v rail to the ARM.
What I was getting at was that if you remove the board from where its logging (say in a car, running of a cigarette socket) and bring it to a computer, you also need to have a power supply for it.
What would make more sense would be if the board could be powered off the 5v USB bus, thus eliminating any need for external power sources to the board.
I am not quite sure how this would be hooked up though. As there is always someone who will plug into USB while there is a battery present.
What I am thinking is having a second 3.3v LDO on my board which will regulate the USB 5v rail down to 3.3v, and just connect that to the original 3.3v rail of the board.
That way, as far as I see it, in the event that you connect both power supplies it is just like having two LDO’s in parallel.
There could be a much simpler way to do this but I am not sure how at the moment.
Could you use a transistor or something that will break the connection to the battery when power comes in via USB?
Connect USB power to a 3.3V LDO regulator, then connect that to the main 3.3V rail through a transistor (which is also connected to the battery and accompanying circuitry). That way, when power is coming from USB the battery isn’t used, and vice versa.
That sounds like a good idea with the transistor but with that approach wouldn't there be a possibility of a brown-out while the supplies are being switched?s_ridenour:
Could you use a transistor or something that will break the connection to the battery when power comes in via USB?Connect USB power to a 3.3V LDO regulator, then connect that to the main 3.3V rail through a transistor (which is also connected to the battery and accompanying circuitry). That way, when power is coming from USB the battery isn’t used, and vice versa.
The solution was simple. Just two diodes that OR the two supplies.
If only USB or battery is available it will use whats there, or if both are present it will use the one with the highest voltage. Simple.