Designing a new PCB for the ODROID-GO

[pmprog]

Very impressive, well done

[mat203]

Could be something to do with leakage on the diode to the DTR line holding it high enough to not reset?

The internal pullup on NRST of the STM32 is in the range of 30..50KOhm, which results in a current of 66..110uA when the debugger activates its open-drain/collector output. The reverse current of the diode is only 7uA at 10V and therefore can be neglected.

I would suggest the following:
- Disconnect both debugger and USB cable from the FTDI.
- Check the direction of D2 and D3 and ensure there is no short from NRST to GND or 3V3, by measuring the resistance with a multimeter.
- Measure the voltage on DTR, it should be 3.3V. If not configure the idle state of this pin with FT_PROG.
- Measure the voltage on RTS, it should be 0V. If not configure the idle state of this pin with FT_PROG.
- Now measure the voltage on NRST, it should be 3.3V.
- Download a simple program which e.g. blinks the LED.
- Take a cable or a low ohmic resistor and connect NRST to GND on the pinheader. The LED should now stop blinking and the voltage level ~0V until you release NRST again.

[flatmush]

I narrowed it down to the diode on the FTDI chip.
When I ground NRST it doesn't reset, but when I ground the diode (D2) on the NRST line, I get a reset.
Checking with the multimeter in diode mode and visually, the diodes are the same way around as the schematic.
The voltage on DTR is 3.3v as is the voltage on NRST side of the diode (well both sides).
Have I got the diodes backwards in the schematic?

[mat203]

When I ground NRST it doesn't reset

I assume you mean the signal on the pinheader ?

Have I got the diodes backwards in the schematic?

You want the DTR signal to only be able to pull NRST low, therefore the direction is ok. Have you checked the value of resistor R24 ? It forms a voltage divider with the STM32 internal pullup on NRST. The desired value of 22R shouldn't matter at all, but if the value is too high you might not be able to go below the low threshold of the reset pin.

What is the voltage of RTS by the way ? I think you have to reprogram the idle state in the FTDI chip to prevent entering the bootloader per default. You would also need the programming tool to configure CBUS4 for VBus Sensing.

[flatmush]

Ok, good news! It was all down to a bad solder joint on R24, reset was working fine!

I really shouldn't have used lead-free solder; words cannot describe how horrible it is. Fixed it up with some leaded solder and it all worked fine.

As expected, the RTS line is 3.3V initially on the RTS chip so after RST it tries to boot the bootloader instead of the code, but after a power-cycle it boots the code that was flashed.
I have a basic program that sets the RGB LED to RED for a few seconds and then switches to green. Will have to write some more complex tests than that, but works well enough to prove the reset issue.

I've also made a lot of changes to the schematic to make it more solderable, mostly I've made all of the pads rounded rectangles and made the wires going into the pads a bit thinner so that the solder doesn't bridge where there are square corners.
Should also mean that there's less paste deposited on the board and less stencil errors as the paste won't stick as much.

I do have an issue with the LCD connector, the lead-free solder paste under some (non-power) pins is unmelted and even with my PCB pre-heater and hot air gun, I can't melt that solder without melting the connector.
Next spin I'm going to use the hob method with leaded solder, it should easily be possible to get the board to reflow correctly without burning.

[mat203]

As expected, the RTS line is 3.3V initially on the RTS chip so after RST it tries to boot the bootloader instead of the code

As already mentioned you can fix this by programming the idle state into the internal EEPROM of the FTDI chip, using the FT_PROG utility.

I do have an issue with the LCD connector, the lead-free solder paste under some (non-power) pins is unmelted and even with my PCB pre-heater and hot air gun, I can't melt that solder without melting the connector.

Sounds like a frustrating issue, I also prefer leaded solder for manual soldering as it melts at lower temperature.

[Paspartout]

Very nice project. It makes me wanna learn KiCad and doing some PCB Design myself(e.g. a hat for the odroid-go). Great Work!

Also the STM32H7 chip looks interesting. Especially the hardware blitting would be helpful to boost game performance. In my try to port cave story(nxengine) to the go I found that the blitting and blending was most demanding for the esp32.

I will consider ordering one of your pcbs myself. 70 pounds doesn't sound too bad but I don't have much experience soldering these SMD Parts myself.

[pmprog]

@flatmush. How are the boards coming? Interested to know if you've got it booting yet

[flatmush]

Ok, so the current process is that I'm testing various things with the board so that the next spin of the board has none of the niggles I had with this one.

These pictures are WIP, and I expect 1.3 will still change a bit before I order the next run of boards. I'll be ordering matte black with ENIG (gold) plating next run.

Angled_1-3.png (323.54 KiB) Viewed 2671 times

Back_1-3.png (230.9 KiB) Viewed 2671 times

Front_1-3.png (146.7 KiB) Viewed 2671 times

The main changes so far are:

• Fixed a footprint bug where the charge status light doesn't work.
• Fixed the incorrect mounting hole location.
• Widened the LCD slot so that there's less stress on the ribbon cable, current boards just about fit but it may damage the LCD.
• Switched to partially through-hole micro-USB connector like ODroid GO uses currently because it's more robust.
• Moved a couple of capacitors which were too close to connector footprints.
• Improved solderability by using rounded corners on ALL pads and using thinner traces to connect to the pads.
• Removed all shorts between pins where the pitch is too small to have soldermask.
• Used exposed copper/gold for logos.
• Improved silk-screen so there are less glitches.

@pmprog: I've got it booting, but it doesn't do much exciting yet.
I've uploaded a video so you can see, it's not very exciting but it does work: https://www.youtube.com/watch?v=Ynfe8RZ8M0c

So far I've tested a few things:

• SWD debug interface, this works fully: The reset "bug" was a soldering fault on my part.
• RGB Status LED
• NRST & BOOT0 Pins
• FTDI USB chip and firmware
• Battery charging and power
• Power system (i.e. powers on and off correctly)
• RTC Power

I need to do at least basic tests (write a small program) of the following before I order the next board:

• UART
• 25MHz Oscillator
• 32.768KhZ Oscillator
• Audio Output
• SDRAM
• Battery Voltage
• Buttons

The current board's LCD connector isn't well soldered and I don't expect any electrical issues with it, so I'm going to test that on the next revision of the board. I'll be using leaded solder and cooking it on the hob again so there will likely be far fewer soldering issues. I've also made some changes to the board (listed above) which should make things way easier.

Currently I'm testing programming over USB. I've reconfigured the FT231X chip to properly handle the low-power mode, I've also changed the defualt logic level of the BOOT0 pin and increased the USB power request to 500mA so that the battery should be able to charge.
I'm struggling to get stm32flash to enter bootloader mode with the UART. I've checked all the solder joints and the traces are connected fully. I'm hoping it's just an issue with some of the hardware flow control inputs, but I'll need to play with it more.

At some point I'll try to upload the current test code, it's a bit messy right now though as you can imagine.

@Paspartout: As you can probably tell from this post; I'm still a way off being able to send out boards. They take me about an hour to make and £70 is making them at cost, but if you're interested in programming for it then I'll be happy to make you a board when I'm comfortable that everything works.

[flatmush]

Quick update: I found out the issue with USB flashing.
Turns out that the STM32H7 requires a higher baud-rate than the default: 115200 works, while the default 57600 does not.
Likely I'll have to write a patch for stm32flash to make it work as it can't identify the device, but that should be about it, looks like no hardware fault.

I've had to patch the FTDI flasher to flash the USB chip too, so I'll have to post my patches to that too.

[pmprog]

I'm certainly interested in developing for it, so I'll buy a board off you when your happy it's all working.

I'm currently working on a framework for cross platform development, supporting "desktops" (odroid boards that run Linux will work too) and the original go board, so extending to support your new board makes sense.

It's a bit of a shame that the go's case is very thin. If they'd made the back half a little deeper, would have made all sorts of hackery possible

[flatmush]

Not had much time to play, but I've done a few things.

Found a pinout bug with the status LED, turned out I'd connected Blue and Green via the wrong resistors, and also Green was not connected to a PWM capable output. I've reshuffled the pin allocation and schematic a bit to fix that.
Widened the LCD slot again slightly (0.2mm) and made the hole for the charge LED a bit smaller.

I've programmed the board over USB to confirm this works, just needs to be at 115200 baud and using the latest upstream stm32flash (0.5 is not new enough).
I've tested the buttons with the odroid-go silicone and they work fine.

Next step I have to write expand this small demo program into a basic OS really and test the clocks, ram, sdcard, etc.

At some point soon I'll probably get impatient and order revision 1.3 boards, but makes sense to test as much as possible before then.

[deerwings]

I am so looking forward to this project when it is completed! I hope it addresses the minor nitpicks I have with the current Mobo. Screen Synching/Tearing/Framerates? Better speed in emulation? When these are available for purchase, I'm so gearing to get one! I hope it's compatible with the current screen? I know that the screen has no built-in vsynching and I didn't catch in the thread if a workaround was designed into this or not.

[flatmush]

The screen I'm using is different and costs roughly £11, maybe less in volume. Unfortunately the go's existing screen in SPI only and the hardware acceleration on the STM32H7 requires a parallel interface.
The screen is a bit thicker but it seems to stick between the current clips with a bit of force, another option would be to file the clips down slightly.

[flatmush]

So I've been making some progress on the software, but nothing that's ready to demo yet, just all the boring but important bits like setting up clocking, power, timers, dma, etc.

I'm thinking I may order revision 1.3 as soon as possible, but at the last minute I decided to re-vamp the power system:

• I want to switch to using a power-hold transistor, so that the MCU can hold the power on until it's ready to shutdown but not turn the power on from cold. This allows for variable shutdown times, which would allow saving state for emulators reliably.
• I want to charge at the full 500mA when connected to a charger port even when the machine is on, as more current should always be available and the FT231X has a battery charge detect feature.

I've come up with this digital solution for the power, it works out marginally cheaper and lower component count too.

DigitalPower.png (33.33 KiB) Viewed 2309 times

@mat203: Does this look sensible?

[mat203]

Regarding the switcher enable control:
- You won't be able to switch off Q2, since it's body diode is in forward bias regardless of POWER_HOLD. After you turn on the switcher, it will remain on until you disconnect both USB cable and battery.
- You can't just swap drain and source, since this time the body diode will allow a current flow from VCC into 3V3.

Regarding the charge current control:
- Q3B is a P-channel MOSFET, it's body diode will always conduct some current via R13 into GND. You won't be able to switch it off completely and therefore the charge current will be higher as expected.

In a typical application scenario you use N-channel MOSFETS as low-side switches (an active switch to GND, source terminal attached to GND) and P-channel as high-side switches (an active switch to a voltage like e.g. 3V3, source terminal attached to 3V3). The drain terminal will be the "switched potential" and a gate-source voltage greater exceeding the threshold voltage will turn the transistors on. Keep in mind that for the P-channel MOSFET this voltage is negative !

[flatmush]

Ok, take 2! I've removed the pesky transistors since I couldn't find a low component count way of using them compared to a diode and a logic gate:

DigitalPower2.png (29.46 KiB) Viewed 2256 times

The AND gate is open-drain so it should cut the path to ground for R13 only when POWER is enabled and BCD is low (NBCD is high).

For the power hold I figure I can get away with the diode, since that line is never going to require more than the 8mA that the MCU can provide, and with the 0.7v voltage drop it's still above the 1.5v the enable on the buck converter requires.

I guess it's ok to power the AND gate from the voltage divider used for VBUS_SENSE since it's so low power, not sure how vital a filtering capacitor would be here, I figured it could be omitted since minor instabilities wouldn't matter much here?

[mat203]

The switcher enable control circuit should work now.

Regarding the AND gate:
- Maximum quiescent current is 40uA, this is not much. But you never know what happens during switching. If the instantaneous current draw is too high, the voltage drop over the resistor might lead to undervoltage at the gate.
I would leave the option to fit a small capacitor. Unfortunately there seems to be no TTL version of the AND gate with open drain output (the high threshold is 2V for TTL compatible inputs even when being powered with 5V). To create a lower voltage from VBUS you could also use 3 silicon diodes in series with an optional resistor to GND (~10KOhm) to have a well defined voltage drop even at low supply currents.
- The voltage level of POWER can exceed the supply voltage, but according to the datasheet the device seems to be protected against this condition ("input structure provides protection when voltages up to 7 V are applied, regardless of the supply voltage").
- If the USB cable is not connected the device has no supply voltage, but you would still provide a voltage on the A input. I am not sure whether the protection covers this. In my circuits I always avoided such conditions, but it might be worth a try.

[flatmush]

I'm half tempted to make the RTC LDO non-optional and just use that to power the gate, this would solve all of the above issues. Additional components are likely to cost the same as the LDO anyway right?
I guess it always makes sense to footprint for the capacitor as it costs nothing and I can omit it later if needs be.

[mat203]

This would be another possible circuit (R3 and V1 are just for simulation), maybe you like it:

FastChrg2.png (8.22 KiB) Viewed 2179 times

But there is a big issue which has to be resolved first ! In the current design signal BCD won't be available when 3V3 is off, as the FTDI is unpowered. Providing its power from VBUS brings back another issue, as you have to provide isolation of the RX/TX lines. I thought some seconds about it, but so far I found no good solution.

[flatmush]

So I've got a take 3, which combines some of your earlier ideas into one:

DigitalPower3.png (30.06 KiB) Viewed 2154 times

This resolves the issue with the gate power, uses an NMOS transistor to switch to ground, and supports the correct voltage levels to work for all (POWER signal) inputs (2.6v to 5v).

The main issue with this is that by using VCC, it's quiescent current will drain the battery. I was hoping to avoid this, but it may be harder than I imagined.

By switching to the Nexperia part for the 74LVT100 (https://assets.nexperia.com/documents/d ... LV1T00.pdf), the quiescent current will only be 10uA which I guess is probably tolerable?

I guess your solution is actually better as it's fewer expensive parts
The BCD issue shouldn't matter. When POWER is off then we charge at 500mA anyway irrespective of BCD. BCD is only relevant when POWER is high. So your solution should work?

[mat203]

When POWER is off then we charge at 500mA anyway irrespective of BCD. BCD is only relevant when POWER is high. So your solution should work?

You are right, sorry for the confusion

Basically my circuit is just an inverter for the POWER signal, allowing BCD to enforce fast charging.
I would recommend to use VCC instead of Vbus on R2 (there would be some voltage on Vbus when 3V3 is on and no USB cable is connected, which is not desirable), the circuit should drain only a minor leakage current from the battery in off state.

the quiescent current will only be 10uA which I guess is probably tolerable

Yeah for sure, I would expect self discharge of the battery to be higher.

[flatmush]

I would recommend to use VCC instead of Vbus on R2 (there would be some voltage on Vbus when 3V3 is on and no USB cable is connected, which is not desirable), the circuit should drain only a minor leakage current from the battery in off state.

BCD can only be high when VBUS is high, so that shouldn't cause leakage, is the leakage from one of the transistors?

Thanks again for doing the charging circuit! I think I'll order some new rev 1.3 boards soon now.

[flatmush]

Ok, take 4! I've just implemented what you put basically, I've added 360Ohm capacitors on BCD and POWER so that the gate capacitance on the mosfets doesn't draw more than 4mA peak (the GPIO's on STM32 are rated for 8-20mA and on the FT231X it's 4-16mA).

DigitalPower4.png (31.54 KiB) Viewed 2092 times

Regarding the leakage onto VBUS issue, I had considered adding a diode to VBUS and using a 100k resistor to provide pull-down on that piece of circuitry, but ultimately I don't think it's needed.

BCD should never in normal usage be able to be high when VBUS is low. It may be possible if you manually short the D+ and D- pins to trick it into BCD mode without VBUS, but given the FT231X shouldn't be powered when VBUS_SENSE is low, I suspect even that wouldn't work.
In the unlikely case that BCD does end up powering VBUS, it'd be via 20360 Ohms of resistance, so at 3.3V it could draw a maximum of 162uA unless I'm calculating wrong? So I guess that wouldn't be likely to cause any issues?

I want to avoid routing VCC to the battery charge circuitry as it'd be a bit of hassle to route, and will cause additional battery drain, but I'll do it if there's any issues I'm missing with the current implementation.

[mat203]

BCD can only be high when VBUS is high, so that shouldn't cause leakage, is the leakage from one of the transistors?

If you have a look into the datasheet, the leakage current is given as 1uA max when the gate voltage is zero and the Drain-Source voltage is 30V. Furthermore D6 will leak some minor current through BCD to ground (through internal IC structure of the FTDI). As you are operating at low voltage, I would expect leakage current <5uA in total. Very neglible in comparison to the battery self discharge rate.

I've added 360Ohm capacitors on BCD and POWER so that the gate capacitance on the mosfets doesn't draw more than 4mA peak

You should think of energy in such cases. For sure there will be a peak current above 20mA when charging the capacitance, but as it is very low the time constant will be very small and therefore also the total energy. Also consider that the MOSFET itself has a gate resistance of 80Ohms already. You definetely don't need series resistors there. Good choice with the dual MOSFET by the way, I also wanted to suggest this instead of two single ones.

In the unlikely case that BCD does end up powering VBUS, it'd be via 20360 Ohms of resistance, so at 3.3V it could draw a maximum of 162uA unless I'm calculating wrong? So I guess that wouldn't be likely to cause any issues?

Shouldn't be critical. You could still increase the value of R21 to reduce the current further. If you want to be perfectly safe and conform, you could add a diode there.

I want to avoid routing VCC to the battery charge circuitry as it'd be a bit of hassle to route, and will cause additional battery drain, but I'll do it if there's any issues I'm missing with the current implementation.

Thats why I have chosen Vbus at first, because it eases up the design. I also prefer circuit blocks to be powered from least possible voltages. As mentioned before, I think it should work fine.

Thanks again for doing the charging circuit! I think I'll order some new rev 1.3 boards soon now.

You are welcome, I like the idea to simplify and both improve the power design.

[flatmush]

You should think of energy in such cases. For sure there will be a peak current above 20mA when charging the capacitance, but as it is very low the time constant will be very small and therefore also the total energy. Also consider that the MOSFET itself has a gate resistance of 80Ohms already. You definetely don't need series resistors there. Good choice with the dual MOSFET by the way, I also wanted to suggest this instead of two single ones.

I did take the built-in resistance into account, my aim was to reduce the current draw in one time constant to under 4mA, but I guess I neglected the fact that the time constant is so ridiculously small that it's unlikely to cause any damage.
I've removed these resistors now, so the component count is quite a bit lower.

Ok, so I think I'm getting close to done for revision 1.3, it now looks like this:

Angled_1-3.png (333.95 KiB) Viewed 2010 times

Back_1-3.png (235.63 KiB) Viewed 2010 times

Front_1-3.png (146.76 KiB) Viewed 2010 times

I've added a ground plane slot between the battery charging and the audio amplifier, it's probably not sensitive enough to matter much but I figure it'll shield it a bit.

Other than that it's mostly just ground stitching improvements, adding a tacky logo, and changes to make it easier to solder stencil.
Hopefully with this revision I can just connect everything up and put it in the case while I program it.

Software is coming along slowly, nothing exciting to show yet. My goal is to get stuff on the screen before I start sharing that.

As always, the hardware changes are pushed to git: https://gitlab.com/flatmush/f100-hardware

[mat203]

Looks good ! The placement of the battery voltage analog sense filter is not optimal which I just figured out. But just keep it as it is (not really crucial), the area close to the MCU pin is pretty crowded.
Just keep it in mind for future designs, especially when you want to sense very small voltages e.g.

I've added a ground plane slot between the battery charging and the audio amplifier, it's probably not sensitive enough to matter much but I figure it'll shield it a bit.

I think you won't need that, but if you do so don't forget to create the split on all GND planes.

[saraparker]

I am having an issue with the indication lights.. I dont know what is wrong. I am going to visit https://freecardgenerator.com/ guide. It might have some more info on this.

[flatmush]

I am having an issue with the indication lights.. I dont know what is wrong.

Sorry for the late response, did you build one of these?
The project has stalled a bit, but I do have some basic test code which proves that the lights and quite a few other things work.

If you share your code with me then I could have a look, alternatively you could wait until the code I've written is a little more ready for release.

[lix-alpha]

I hope this project will see completion! I am a buyer!!!