Designing a new PCB for the ODROID-GO

Post Reply
flatmush
Posts: 15
Joined: Fri Feb 22, 2019 4:37 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Designing a new PCB for the ODROID-GO

Unread post by flatmush » Fri Feb 22, 2019 4:51 am

I've been designing a new PCB for the ODROID-GO based on the very powerful STM32H7.

The design is fully open-source and can be found here:
https://gitlab.com/flatmush/f100-hardware

The basic specs are:
400MHz STM32H7 MCU with 16KiB I/D Cache
1MiB Internal SRAM
32MiB 16-bit 133MHz SDRAM (Upgradable to 64MiB, potentially overclockable to 200MHz)
320x240 18-bit 60Hz 2.4" LCD (Hardware dithering to 24-bit, may support 120Hz refresh)
Hardware 2D acceleration & JPEG decode
12-bit Audio Output with hardware volume control
2MiB Internal Flash (for bootloader really, all data will be on microsd card)
4-bit microSD Card Interface (50MHz supported, potentially overclock to 100MHz)
PWM-RGB Status LED

My only concern currently is that the routing is not good enough for the SDRAM, but from what I've read it shouldn't be too critical.

I'd be interested in any feedback.

Also many thanks to hardkernel for releasing the ODROID-GO schematics and DXF files.
Attachments
Angled.png
Angled.png (232.41 KiB) Viewed 1928 times
Back.png
Back.png (154.42 KiB) Viewed 1928 times
Front.png
Front.png (81.94 KiB) Viewed 1928 times

User avatar
odroid
Site Admin
Posts: 30015
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by odroid » Fri Feb 22, 2019 9:20 am

Very interesting project. :o
Which emulators can we expect with that CPU performance and DRAM capacity?
Can we run SNES or PC-Engine or GBA?

How about STM32MP1 which can run Linux?

flatmush
Posts: 15
Joined: Fri Feb 22, 2019 4:37 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by flatmush » Fri Feb 22, 2019 5:26 pm

Glad you like it!

I think emulator-wise this could definitely do SNES, especially since it has hardware support for sprites.
It should also be able to run basic PS1.
GBA should be possible since it's roughly the same instruction set, but would require someone writing a dynarec.
Should run the same emulators as the Dingoo A320 roughly.

The STM32H7 can run Linux! Though I'm not sure it's needed for a basic games machine. My main criteria for selecting it was that there's a qfp144 package. This is my first circuit board and I want something that I can solder and probe if needed.

I didn't know about the STM32MP1, looks very interesting. It's basically competing with lower end imx6. I think with that number of pins it'd need a 6 layer board.

mat203
Posts: 16
Joined: Sat Feb 23, 2019 7:32 am
languages_spoken: english
ODROIDs: GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by mat203 » Sat Feb 23, 2019 9:07 am

Hey flatmush, I reviewed your design and have some suggestions for improvement.

Concerning the schematics:
- If you manage to use PA9/PA10 for UART1, the ROM bootloader would be accessible via the USB/UART bridge. Furthermore you should allow setting the level of the BOOT0 pin for bootloader entry after reset (see AN2606 and AN4938 for details). This would allow an easy firmware download without an additional JTAG/SWD programmer.
- Are you sure about leaving the main power on when switched off ? You should check the idle consumption (don't forget the power draw of the regulator!), it might cause unwanted battery drain.
- Why don't you use the N-MOSFET for the backlight power enable ? It would reduce the amount of different components in your BOM. If you do so, maybe think of adding a pulldown (100K e.g.) to ensure the backlight remains off in case the STM32 is in reset or deep sleep state.
- You might want to think of adding some test points, which might ease up measuring signals and bringing up the board.

Concerning the layout:
- Always try to connect the power pins of ICS with short (and maybe a bit wider) tracks to the capacitor pads and then connect to the power planes. This helps fast switching currents to be drawn directly from the cap. For example C27 and C30 are well designed, the connections of C10, C42 and especially the decoupling of the USB/UART bridge could be improved.
- You should work on the grounding in the region of the main oscillator, as the return current of C10 shares a GND connection with the crystal. Oscillators are very critical and require careful design, therefore I strongly advise to split the connections and make use of local vias to GND.
- In general, try to minimize the length of tracks connecting pads to GND or VCC vias. This helps to reduce the impedance and you take most advantage of the solid power planes.
- The connection of the input capacitor (in your case C48) is most critical in a buck converter design and it therefore should be placed as close as possible to the IC (see the device datasheet for a good layout example). Components D1 and Q2 can easily be moved away from the IC, as their connection is not critical. You also might want to make use of multiple vias (two vias for power and GND each).
- If you want to drive your SDRAM interface at high clock frequencies, I would recommend at least a rough length matching (there are some rules in the hardware design guide of ST).
- The USB differential signals (D+ and D-) should be routed as differential pair. Your design is full-speed only (therefore runs at rather low signal rate) and I am quite sure it will work. But keep it in mind if you do a high-speed design in the future.

That's it, maybe you want to incorporate some of my suggestions in your design ;)

User avatar
rooted
Posts: 6435
Joined: Fri Dec 19, 2014 9:12 am
languages_spoken: english
Location: Gulf of Mexico, US
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by rooted » Sat Feb 23, 2019 9:34 am

@mat203

That is a hell of a first post, welcome to the forum.

flatmush
Posts: 15
Joined: Fri Feb 22, 2019 4:37 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by flatmush » Sat Feb 23, 2019 4:41 pm

@mat23, thanks a lot! I definitely do want to incorporate your ideas into my design.

For the testpointing, what would you advise? I was thinking that I can probe most of the pins manually. Or should I just testpointing every net I can?

Oh, one reason for leaving the power on was the RTC. Would it be better to connect an LDO or just VBAT directly to the vbat pin on the STM32H7?

crashoverride
Posts: 4314
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by crashoverride » Sat Feb 23, 2019 5:31 pm

flatmush wrote:
Fri Feb 22, 2019 5:26 pm
I didn't know about the STM32MP1, looks very interesting. It's basically competing with lower end imx6. I think with that number of pins it'd need a 6 layer board.
They are doing soldered SoMs for that device which should eliminate layers:
https://www.dh-electronics.com/en/produ ... tm32mp15x/

I plan to get a devkit when available. I have SNES and Genesis ready to go for something powerful enough to run them. I ran the Genesis port on a MT7688 last year as part of a proof of concept for something that I never released. It was *almost* powerful enough so I expect the STM32MP1 should be able to handle it. It also has the added advantage of a GPU so software scaling is not required.

mat203
Posts: 16
Joined: Sat Feb 23, 2019 7:32 am
languages_spoken: english
ODROIDs: GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by mat203 » Sat Feb 23, 2019 11:09 pm

@rooted
Thanks for the welcome ! I was a silent reader for quite some time :D

@flatmush
Concerning the bootloader:
I did some research and there seems to be a flash tool readily available which makes use of a "switchless bootloader entry" mechanism (see the discussion in https://sourceforge.net/p/stm32flash/tickets/37/). There is also reference to a schematic example from ST in which they used a diode to control the reset signal with a push-pull output stage of the RS232 transceiver. It is safe to connect multiple reset sources if they only actively switch to GND (open-drain/collector output stages, pushbuttons to GND), in this case the diode prevents the push pull stage of pushing high currents through.
Besides, for most microcontrollers the reset signal is not only an input pin, but also has an open drain structure internally attached. You may wonder why they do such "nonsense", but actually there is some sense in it ;) By doing so, the microcontroller is able to prolong the reset and release it under its own control. This creates a true system reset, which is released when the microcontroller is ready to run its code.

Concerning the power supply:
I totally forgot to consider the RTC support. In this case I would create a dual power domain scheme as you already suggested. The absolute maximum rating for VBAT of the STM32 is 4V (recommended range is 1.2-3.6V) and your charger regulates at maximum to 4.232V. I would never exceed the absolute maximum rating of a device, you never know what will happen. The safe option would be to use a LDO, to be precise a cheap micropower one (it doesn't matter if it draws lets say 100uA or 150uA). An alternative approach would be to make use of a silicon (not a schottky) diode in series, which would drop the voltage. This approach doesn't draw any additional current, but I am not sure if the voltage drop is sufficient at the low currents you have to expect. In theory most of the people assume a silicon diode drops the voltage by 0.7V, but actually the voltage is dependent on the current in a non-linear manner (high current -> higher voltage and vice-versa).
In any case, when RTC support is only an option, you could still allow a direct connection of VBAT to VDD by a resistor bridge (and fulfill the recommendation of ST). When using RTC, the LDO + 32K crystal are fitted and the resistor is left unpopulated.

If you decide for the dual power domain scheme, I would recommend to add an additional charging indicator LED like it is realized in the original GO design. So far I never used any of the low power modes in my STM32 designs so I am not totally sure, but it looks like you are not able to measure with the ADC or control any GPIO when only the RTC power domain is active. If this really is the case, the only connection which makes sense is the ADC channel to monitor the battery voltage during normal operation.

In principle you have to consider three cases for the distribution of the maximum 500mA current your USB power input provides:
1.) Main power off, battery charging: the 500mA can be steered entirely into the battery
2.) Main power on, battery charging: the 500mA must be split up in between the STM32 + LCD, etc. and the battery
3.) Main power off, battery full: the 500mA can be steered entirely into the STM32 + LCD, etc. and the battery.

I would design the circuit to reduce the charging current, when the main power is enabled. Lets say you assume a worst case power consumption of 400mA for STM32 and peripherals, you have 100mA left for charging.

You should also try to improve the heatsinking of the charger (its a linear regulator driving quite some current and therefore gets hot). Try to make use of copper and vias to help reducing the temperature during charging (as usual, see the datasheet for recommendation).

Concerning the LCD:
From the schematic it looks like there is touch support. Are you sure you can connect the pins directly to the microcontroller ? Evaluation of a resistive touch requires applying a drive voltage. You might want to consider adding a touch controller IC (e.g. STMPExx).

Concerning the test points:
You have made a very wise choice to only use packages where the pins are not "hidden", therefore I would not make all signals available on test points. I recommend to make potentially interesting signal available on test points, maybe you realize that you missed a connection during board bringup and then attaching a wire is very simple. At minimum I advise to make one or two unused STM32 GPIOs availabe as debug pins. You can control them during software development to trigger an oscilloscope/logic analyzer e.g. and believe me, this simple feature can help a lot ;) In principle you already have this option available on the pinheader at the top side. But you cannot use them, if you think of any future peripheral attached to it.

Other ideas:
- If you want your device to be as robust as possible, consider adding ESD protection on the pinheader (take a look on ST reference designs, in some of the eval boards they include it) and self-resetting fuses (PTCs) in series with the two power pins. This prevents potential defects in case of ESD strikes or shorts.
- For future flexibility, it would be good to have a SPI or UART available on the pinheader for potential expansion with an external peripheral board. Don't push yourself too hard on JTAG support, SWD is absolutely sufficient. A nice feature for SWD would be to have the SWO pin available, to allow for usage of tracing.
- What about adding support for a native STM32 USB ? Especially when thinking of potential Linux support, this would allow MTD (or whatever else USB gadget) support.
- Another great improvement over the original GO would be the option to fit a headphone jack.

You got plenty of space left on the PCB and all of these features come at no additional cost for manufacturing, since they can easily be left unmounted when not needed.

Further hints:
- Do you have hardware PWMs available on the GPIOs of the LED channels ? If possible make use of them, the STM32 has plenty of PWMs and dimming comes at no cost of CPU cycles.
- Maybe you know about the STM32Cube Tool. It is not perfect, but it helps selecting the right pinmux a lot.
Last edited by mat203 on Sun Feb 24, 2019 12:59 am, edited 1 time in total.

mat203
Posts: 16
Joined: Sat Feb 23, 2019 7:32 am
languages_spoken: english
ODROIDs: GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by mat203 » Sat Feb 23, 2019 11:42 pm

Two further aspects which could help you with the layout:
- Bit reordering on the data lanes of the RAM interface (you will find usage of this approach on some reference boards). In principle you can reorder the bits in a way you like, you only have to pay attention not to cross the byte lane boundary. Also never reorder any address bits!
- Rotate the STM32 by 45°, in some cases this helps routing.

User avatar
lix-alpha
Posts: 85
Joined: Fri Jul 27, 2018 9:41 pm
languages_spoken: english
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by lix-alpha » Sun Feb 24, 2019 1:12 am

Wow! Good Work.
You can count me in as a buyer once you release this m8! :)

flatmush
Posts: 15
Joined: Fri Feb 22, 2019 4:37 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by flatmush » Sun Feb 24, 2019 2:08 am

@Mat203: Thanks again! I'm on holiday this weekend but now I'm desperate to get back at it!

I think I'll redo the traces manually, hadn't thought of re-ordering the data pins but that's a great idea! I guess I can't re-order the address pins cause they're used for commands.

I did actually start off with the STM32H7 rotated 45 degrees but got a bit lazy with the autorouter. I'll check properly when I redo the traces.

The pin allocation is very tight and everything is there for a reason. The LEDs are already on PWM capable pins.

I can't do stm32 usb because of pin conflicts with the LCD sadly. That's why the ftdi chip is there. I'll have another check cause I really wanted mtd support too, but I think it was impossible without sacrificing colour resolution on the 144 pin part.

I did connect all relevant pins to interrupts too (see pin allocation file in the gitlab).

I think the best way to support the BOOT0 pin is to connect it to the FTDI chips CBUS pin. That way boot mode can fully be controlled by the usb cable.

The circuit can already switch charging currents in software, that's what Q3 is for. I think that should work? Maybe needs a pulldown on input to ensure full charging when micro is off?

For the touchscreen I just connected up to remaining ADC pins and hoped for the best. Assumed resistive touchscreen wouldn't work through the lens properly anyway, but you're right: I should read up on that a bit more and at least footprint a solution.

For the spare gpio's: Currently there's exactly one spare! There'll be two after the BOOT0 trick, I'll definitely test-point those.

Will look into heatsinking, was going to try that for the STM32 but obviously there's very little room.

Will look again at the pin header, figured JTAG would be a nice option, but I have no plan to use, so maybe I could juggle and connect the low speed spi bus from the LCD or something.

Thanks again for the advice, I'm gonna make these changes as soon as I can and post the updates.

@lix-alpha: Thanks! Haven't even thought about selling yet really. First batch will cost me personally about £70 each to make (at cost) but I might sell any spares from the first batch that works. If there's enough interest then I'd probably have to look at working with someone to produce them cheaper, but I think that's a ways off yet.

flatmush
Posts: 15
Joined: Fri Feb 22, 2019 4:37 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by flatmush » Sun Feb 24, 2019 2:15 am

@crashoverride: That SOM does look cool, but it'd probably need to fit in a shell with more buttons. Was going to footprint more buttons so that the current case could be drilled, but I couldn:'t see a way to do it. If this project works out then I might work on something a bit more comprehensive though.

@matt203: Regarding the headphone jack; I did think about it, but there's nowhere good to footprint it afaik. Also, the DAC outputs on the STM32 are very limited; currently I can get one DAC output by going through an opamp, which I'm hoping I can use for crude volume control. There's no scope to do stereo sound without an external DAC (or use PWM) which I wanted to avoid.

mat203
Posts: 16
Joined: Sat Feb 23, 2019 7:32 am
languages_spoken: english
ODROIDs: GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by mat203 » Sun Feb 24, 2019 6:24 pm

The pin allocation is very tight and everything is there for a reason.
Some suggestions here:
- Manual pinmuxing on the STM32 is cumbersome. The STM32Cube Tool helps a lot, showing alternative pinmux for selected peripherals.
- Use X8 RAM instead of X16, this saves 9 pins, simplifies routing and at the transfer rate would still be far higher than on the original GO.
- Use PE2-PE5 for other purpose, I think you won't miss the CBUS signals.
- Using the improved pwr enable mechanism (as suggested below) and a LED for charge indication frees up two additional GPIOs.
I think the best way to support the BOOT0 pin is to connect it to the FTDI chips CBUS pin. That way boot mode can fully be controlled by the usb cable.
Don't forget about the reset signal. The sequence for entering the bootloader would be: Pull RESET low - Pull BOOT0 high - Release RESET
I also don't know if the flash software is able to control the CBUS pins of the FTDI, this is a special feature and might require adjustment of the software.
RTS and the other signals instead are standard serial handshake signals and should work out of the box.
The circuit can already switch charging currents in software, that's what Q3 is for. I think that should work? Maybe needs a pulldown on input to ensure full charging when micro is off?
You need to ensure that Q3-Gate is driven high, when fast charging is required. So basically you have two states:
1.) U4-EN high (main power on), Q3-Gate low (PROG=10K -> 100mA)
2.) U4-EN low (main power off), Q3-Gate high (PROG=2.5K||10K -> 500mA)
From the switch you can create two signals PWR_EN and CHRG_FAST, which always have their inverted state. The capacitors should help to prevent that both main power and fast charging are enabled at the same time during switchover.
pwrsw.PNG
pwrsw.PNG (19.67 KiB) Viewed 1641 times
Will look again at the pin header, figured JTAG would be a nice option, but I have no plan to use, so maybe I could juggle and connect the low speed spi bus from the LCD or something.
You might want to have a debugging interface for software development, so don't kick it out completely. I would go for SWD, this interface requires only VDD, GND, SWCLK and SWDIO (even RESET is optional). As already mentioned the third signal SWO is a nice to have feature, but not mandatory. If you want to free up pins on the pinheader for other purposes you could add a second pinheader for the debug interface, which is not accessible when the PCB is housed.

You should place the filter capacitor on the RESET line close to the STM32, by the way. As a general rule of thumb: If you have local filters in your circuit, place the components close to the inputs. In the case of I/O interface filters place the filter components close to the connectors.

pmprog
Posts: 15
Joined: Thu Oct 18, 2018 4:01 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by pmprog » Sun Feb 24, 2019 8:28 pm

That's pretty amazing stuff.

User avatar
lix-alpha
Posts: 85
Joined: Fri Jul 27, 2018 9:41 pm
languages_spoken: english
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by lix-alpha » Sun Feb 24, 2019 11:03 pm

flatmush wrote:
Sun Feb 24, 2019 2:08 am
@lix-alpha: Thanks! Haven't even thought about selling yet really. First batch will cost me personally about £70 each to make (at cost) but I might sell any spares from the first batch that works. If there's enough interest then I'd probably have to look at working with someone to produce them cheaper, but I think that's a ways off yet.
Well £70 (92$US, 120$CAN) does seems like a reasonable price to me for that kind of upgrades. I think that you could easily sell them at that price here in the community. And it could cost even a little bit more in my opinion since you need to make a bit of cash out of this too.

jutleys
Posts: 83
Joined: Fri Jul 20, 2018 1:06 am
languages_spoken: english
ODROIDs: Odroid Go
Odroid X4U N64 case
Location: UK
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by jutleys » Mon Feb 25, 2019 3:37 am

Nice project i would support it any day

flatmush
Posts: 15
Joined: Fri Feb 22, 2019 4:37 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by flatmush » Mon Feb 25, 2019 7:10 am

Ok, so I've started re-doing lots of stuff:
1. Moved to SWD interface to liberate some pins on the pin header and gpio's.
2. Connected LCD command SPI to pin header using same pins as odroid go, so that peripherals should now be compatible.
3. Connected RTS/CTS to NRST and BOOT0 so that we can use stm32-flash, this means no more hardware flow control but I don't think anyone will lose any sleep.
4. Rotated chip so that routing to memory is better. Still sticking with 16-bit interface as it'd be a huge performance hit to do it, better to run 16-bit slow than liberate the pins since I can't use them for anything else.
5. Changed the power system as suggested.
6. Used an LDO to provide RTC power.
7. Re-routed USB using differential pairs.
8. Improved capacitors and grounding all around the board.
9. Switched out transistor so there's one less item in the BOM.
10. Using the spare GPIO's I'm assigning each button to a GPIO line with an interrupt.
11. Connected AUDIO_NRST to a PWM capable GPIO just in-case it can be used for volume control like on some TI amplifiers.
12. Got rid of the reset button as the new power system should make it redundant.

I checked about the touchscreen thing, it should be possible to read the touchscreen directly using ADC pins, though it'll require changing pin function on the fly to put a current loop through the other two ADC pins. Since it's an optional extra, I'm just going to leave it at that. I'll share the updates once they're finished.

Also, anyone know of a non-tedious method for doing length matched routing in kicad? I'm tempted to autoroute again and just length match the result as close as I can get.

mat203
Posts: 16
Joined: Sat Feb 23, 2019 7:32 am
languages_spoken: english
ODROIDs: GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by mat203 » Tue Feb 26, 2019 5:16 am

2. Connected LCD command SPI to pin header using same pins as odroid go
From PE2-PE6 you could easily get an independent SPI interface and don't need to care about mutual exclusion.
3. Connected RTS/CTS to NRST and BOOT0 so that we can use stm32-flash, this means no more hardware flow control but I don't think anyone will lose any sleep.
CTS is an input, this won't work unfortunately. Is there an FTDI with an additional handshake output signal available ?
Also, anyone know of a non-tedious method for doing length matched routing in kicad? I'm tempted to autoroute again and just length match the result as close as I can get.
Can't help you with KiCad, I only installed it and played around a bit so far. You could route the signals close to the center of the ICs and then interconnect, which should give roughly the same length.
ST suggests length matching within +/-10mm, but I am pretty sure the interface will still work, even if you exceed the recommendation. From my experience these recommendations are rather strict.
Keep in mind that via count mismatch increases length difference (distance from top to bottom layer is 1.6mm on a standard PCB). AN4938 is a good starting point for the hardware design, you should definitely read it.

Do you use design rules from a PCB manufacturer ? If not, better get some before starting to route again. It can be frustating to apply the rules later on and realizing that you have to move a lot of stuff, because it is not manufacturable.
In general I would give clock lines a bit more spacing, as they are "aggressive" signals and you don't want them to couple over to other signals.

flatmush
Posts: 15
Joined: Fri Feb 22, 2019 4:37 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by flatmush » Wed Feb 27, 2019 7:23 am

Yup, you're right about the SPI, shuffled around the pin mappings so it's easier to route.

Fixed the DTR issue by switching to FT231XS. Will update when finished.

The trace widths and spacings should easily be supported by jlcpcb and a few other places, made sure I was within their tolerances by a margin.

flatmush
Posts: 15
Joined: Fri Feb 22, 2019 4:37 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by flatmush » Sun Mar 03, 2019 8:35 am

Ok, so here's the big update.

As always, updates can be found in the gitlab repository: https://gitlab.com/flatmush/f100-hardware

I'm going to quote the git commit for the changes:
  • Power switch now controls power and fast-charge
  • Red LED for charging, green LED for fully charged.
  • Removed reset button as it's no longer needed
  • Buttons now have their own interrupt-capable GPIO line
  • Removed some JTAG signals so header only supports SWD
  • Header now has SPI interface that's pin-compatible with ODROID-GO
  • Switched USB-UART bridge chip to FT231XS
  • Bootloader can now be programmed over USB
  • Memory lines now length-matched between 45-55mm
  • USB data lines now differentially routed
  • All SPI and SD card lanes are length matched
  • Layout of all filter capacitors is improved
  • Ground-fill on top and bottom layers
  • Improved power plane layout
  • Pin allocations optimized to allow for better layout
  • Improved thermals for battery charge IC (U6)
  • Matched IC references with BOM
  • Put AUDIO_NSTANDBY line on a PWM capable pin for possible volume control
Missing from the git commit is that I also added a 3.3v LDO for RTC power as discussed.

@mat203
Any chance I can get a full-name and e-mail so that I can credit you in the git repo?

I've re-done all the tracing, hopefully much better this time. SDRAM NBL1 line has a minimum length because of position of 55mm, so I length matched everything else to between 45-50mm. I guess it would've been best to get them all the same, but it would've been quite hard and this seems like a good compromise.
All the filter capacitors have been re-worked to be better hopefully.
I've differentially signalled the USB, it's manually length matched a bit at the end, not that it's needed.
I length matched all of the SPI and SD card signals to be within 0.1mm of each other.
Where possible I've left as large of a gap as possible for clock signals and oscillator lines.
I had to route power on the signal layer to link up the AUDIO 3.3V plane and also to get the RTC power from the LDO to the MCU.

I had a look into a barrel jack for headphones, however due to the height constraints of the board, it wouldn't be possible to just footprint it. Nothing can be more than about 2.5mm high on the back of the board where all the components currently are.
There is one solution which is to get a jack which fits in a slot cutout (6mm by 13mm), however this brings some issues of it's own. The only place it could possibly fit is just above the A button, however the cutout would reduce the integrity of the board.
The cutout for these jacks is also a complex shape which may be hard to manufacture and requires further through holes.
While it is possible, I chose not to do it, because I don't want to risk making the board too weak.

I didn't length match the parallel LCD signals, since I don't think they're going to be going at very high speed, talking around 6MHz max, so I hope that's ok.

The one remaining issue I can think of is that now the user can power off the MCU at any point, it's possible that they could cause SD card corruption if they turn it off at the wrong time.
The only solution I can think is that if I detect a voltage drop because of a power down, it may be possible to complete the SD card transaction before the power in the capacitors runs out, but I don't know how realistic that is.

As before, any feedback is welcome!
Attachments
Angled_1-1.png
Angled_1-1.png (291.52 KiB) Viewed 1204 times
Back_1-1.png
Back_1-1.png (195.56 KiB) Viewed 1204 times
Front_1-1.png
Front_1-1.png (117.29 KiB) Viewed 1204 times

User avatar
mad_ady
Posts: 5398
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by mad_ady » Sun Mar 03, 2019 12:20 pm

Regarding sd corruption - the GO has the same potential issue. It doesn't really happen in practice because a led is on while writing to SD (software controlled) to let the user know of activity.
The only writes are saves, there is no filesystem cache and writes are quick, infrequent and user-initiated, so risk of corruption is low and shouldn't be an issue.

mat203
Posts: 16
Joined: Sat Feb 23, 2019 7:32 am
languages_spoken: english
ODROIDs: GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by mat203 » Mon Mar 04, 2019 5:37 am

Switched USB-UART bridge chip to FT231XS
There are two design issues in the power design of the FTDI, which I just found.
In the device datasheet you will find the following:
"The +3.3V LDO regulator generates the +3.3V reference voltage for driving the USB transceiver cell output buffers. It requires an external decoupling capacitor to be attached to the 3V3OUT regulator output pin."
I strongly recommend to stick to the datasheet and put a capacitor there, otherwise the voltage for the transceiver might not be regulated properly.

Furthermore it looks like the IC is not designed to work with independent VDD and VCCIO:
https://www.ftdicommunity.com/index.php?topic=74.0
http://www.ftdicommunity.com/index.php?topic=35.0
I would go for the self powered design including VBUS detection using one of the CBUS pins (with voltage divider). The latter is an optional feature and reduces power consumption in the disconnected state.
VCC, VCCIO and 3V3OUT would have to be tied to 3V3. If you wonder about 3V3OUT becoming an input, see the footnote on page 7 in the datasheet.
Ground-fill on top and bottom layers
Try to avoid GND islands which are connected at one side only. I would also avoid partially flooded vias (for example the one close to signal FAST_CHARGE).

In general, I would add some more stitching vias, this is the pattern I usually prefer:
https://www.google.de/search?q=ground+p ... C84Kvn-U9M:
Red LED for charging, green LED for fully charged.
A drawback of the bottom side mount is that you might not be able to see the indicators when the GO is laying on the desk. I would go for a single LED which is clearly visible, like in the original GO design (they used a 90 degree LED). But that is just my personal preference ;)
SDRAM NBL1 line has a minimum length because of position of 55mm, so I length matched everything else to between 45-50mm.
I am pretty sure the design will work fine. To be sure, run a RAM stress test (you will find lots of source code on the web) on the prototypes. In the unlikely case you will see errors, you can still try to reduce the clock frequency.
I had to route power on the signal layer to link up the AUDIO 3.3V plane and also to get the RTC power from the LDO to the MCU.
Audio has plenty of local decoupling and you feed power with a wide track, RTC draws only minor current. No concerns here.
I didn't length match the parallel LCD signals, since I don't think they're going to be going at very high speed, talking around 6MHz max, so I hope that's ok.
Absolutely !
While it is possible, I chose not to do it, because I don't want to risk making the board too weak.
A standard 1.6mm FR4 PCB is really strong, even thin stays are hard to break. I would say the forces you have to expect are way below being critical.
The only solution I can think is that if I detect a voltage drop because of a power down, it may be possible to complete the SD card transaction before the power in the capacitors runs out, but I don't know how realistic that is.
It's hard to tell excatly what amount of energy is necessary, but I would say you would need a significant increase in capacitance on the board. I share the opinion of mad_ady, just indicate writes using the LED.

Concerning the layout:
I would move the feedback line of the switching regulator away from the inductor, it is very sensitive to noise. An option would be to add a via and route it on the opposite layer, this results in very effective shielding.

Try to avoid acid traps, they can cause manufacturing problems.
https://www.google.de/search?q=acid+tra ... IdwW3U_NqM:
Some examples in your design would be at Pad32/32 of U1, Pad1 of C12, Pad3 of Q3.

I would check the distance of tracks to the mounting holes which are used to fixate the PCB to the top cover. As the screw head directly sits on top of the PCB, sharp edges might damage the solder mask (resulting in shorts) or cause signal disruption. You should ensure that the screw head does not cover any signal other than GND.

Concerning the BOM:
In your design you have both 100K/1% and 100K/5%. You cannot save much money there, so why not using 1% for all 100Ks ?
Any chance I can get a full-name and e-mail so that I can credit you in the git repo?
For sure, I just sent you a private message.
Last edited by mat203 on Tue Mar 05, 2019 1:12 am, edited 1 time in total.

User avatar
mad_ady
Posts: 5398
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by mad_ady » Mon Mar 04, 2019 3:17 pm

This discussion is pure gold - it deserves to be refined and published in the magazine.

Though I'm not a hardware person I always find hardware fascinating. I hope that in a parallel universe I can contribute with helpful hardware advice :)

flatmush
Posts: 15
Joined: Fri Feb 22, 2019 4:37 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by flatmush » Tue Mar 05, 2019 3:55 am

mad_ady wrote:
Sun Mar 03, 2019 12:20 pm
Regarding sd corruption - the GO has the same potential issue. It doesn't really happen in practice because a led is on while writing to SD (software controlled) to let the user know of activity.
The only writes are saves, there is no filesystem cache and writes are quick, infrequent and user-initiated, so risk of corruption is low and shouldn't be an issue.
My thought is that this is a more complicated device, which will likely use the SD card more frequently. You're probably right about the write speed, not least since the 4-bit interface should be way quicker.
As a software person, the idea of allowing power downs during an SD card write makes me cringe a bit, but I have to agree that it's the simplest solution. Worst case can use a journaling file system or something.
mat203 wrote:
Mon Mar 04, 2019 5:37 am
I would go for the self powered design including VBUS detection using one of the CBUS pins (with voltage divider). The latter is an optional feature and reduces power consumption in the disconnected state.
VCC, VCCIO and 3V3OUT would have to be tied to 3V3. If you wonder about 3V3OUT becoming an input, see the footnote on page 7 in the datasheet.
Makes sense, I did that layout for the FT230X where it was a bit of a risk cause I couldn't find any documents supporting it. I'll switch over to this mode and use one of the CBUS lines for that.
mat203 wrote:
Mon Mar 04, 2019 5:37 am
Try to avoid GND islands which are connected at one side only. I would also avoid partially flooded vias (for example the one close to signal FAST_CHARGE).
I suspected this would be the case, but I wanted to see what you'd suggest. Will add stitching vias when I'm done with the remaining changes.
For the partially flooded via's: Is this a major concern? In pretty much all the cases this occurs it's because there's GND via on the other side of the board which is on the edge of an automatic flood fill by KiCAD. If it's a major concern then I can manually do the GND fill zones, but I'd rather avoid if possible because it'd be quite painful to do.
mat203 wrote:
Mon Mar 04, 2019 5:37 am
A drawback of the bottom side mount is that you might not be able to see the indicators when the GO is laying on the desk. I would go for a single LED which is clearly visible, like in the original GO design (they used a 90 degree LED). But that is just my personal preference ;)
I've found a reverse-mount Red/Green LED so I'm going to switch to using that. Maybe I'm addicted to reverse-mount LEDs.
mat203 wrote:
Mon Mar 04, 2019 5:37 am
A standard 1.6mm FR4 PCB is really strong, even thin stays are hard to break. I would say the forces you have to expect are way below being critical.
I think the main reason that I didn't want to do it was that it's a massive pain in the arse to re-route the audio and power sections of the board to footprint the 3.5mm Jack on the other side.
But a few people have asked for it, and it seems like a waste to not bother, so I'm going to do the cutout and footprint it like you suggested, using this connector:
https://www.digikey.co.uk/product-detai ... ND/2625184

Also, thinking of switching out the PAM8301 with this TI4853MM: https://www.digikey.co.uk/product-detai ... -ND/483096
It's a class AB amplifier instead of class D, but it looks like it should have enough power for the 8 Ohm speaker that comes with the go.
mat203 wrote:
Mon Mar 04, 2019 5:37 am
I would move the feedback line of the switching regulator away from the inductor, it is very sensitive to noise. An option would be to add a via and route it on the opposite layer, this results in very effective shielding.
I wouldn't have thought of that, guess that's because inductors are good at inducing current in parallel traces and because the feedback line is analog right?
mat203 wrote:
Mon Mar 04, 2019 5:37 am
Try to avoid acid traps, they can cause manufacturing problems.
I was reading about and people were saying it's less of an issue with modern processes, but it's still a good point.
I've gone around and fixed most instances, I had to tell KiCAD to change how it did ground-fill for some of them.
Will aim to fix all instances by next revision.
mat203 wrote:
Mon Mar 04, 2019 5:37 am
I would check the distance of tracks to the mounting holes which are used to fixate the PCB to the top cover. As the screw head directly sits on top of the PCB, sharp edges might damage the solder mask (resulting in shorts) or cause signal disruption.
Good point, will measure and check these for next revision.
mat203 wrote:
Mon Mar 04, 2019 5:37 am
In your design you have both 100K/1% and 100K/5%. You cannot save much money there, so why not using 1% for all 100Ks ?
In the BOM, these parts actually link to the same part; the volume discounts on digikey just make it cheaper that way.
My general rule for the BOM was that in the description I'd list the specifications I wanted for the part, so that if anyone wants to replace components it's easier. The actual part performance in some cases will exceed what's specified.

Thanks again for the feedback, this is really useful and interesting.

I tend agree with mad_ady when he says it should be refined into an article, it'd be really cool if anyone has the time to do that at some point.
I may try to archive all of this info in the git repo of the project, given it's very important to understanding the history of the project.

mat203
Posts: 16
Joined: Sat Feb 23, 2019 7:32 am
languages_spoken: english
ODROIDs: GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by mat203 » Tue Mar 05, 2019 7:59 am

I suspected this would be the case, but I wanted to see what you'd suggest. Will add stitching vias when I'm done with the remaining changes.
I know that it is not always possible to avoid to the "single via islands" with automatic flooding, but in many cases it is easy to set a second via somewhere. Please don't overstress yourself with this.
For the partially flooded via's: Is this a major concern? In pretty much all the cases this occurs it's because there's GND via on the other side of the board which is on the edge of an automatic flood fill by KiCAD. If it's a major concern then I can manually do the GND fill zones, but I'd rather avoid if possible because it'd be quite painful to do.
No it is not critical, but maybe you should check the design rules. It would be strange if the flooded copper had a greater distance to the tracks than the annular rings of the vias, when both "copper to track" and "via to track" clearance are set to the same value.
I've found a reverse-mount Red/Green LED so I'm going to switch to using that. Maybe I'm addicted to reverse-mount LEDs.
Even better ! Good visibility of the indicator while still maintaining a single side soldering cabable PCB.
I wouldn't have thought of that, guess that's because inductors are good at inducing current in parallel traces and because the feedback line is analog right?
Your assumption is right. It gets more severe the closer you get and the higher the currents are. Higher power designs often use shielded inductors, but this increases the component price as more material is required. In no case you should route any noise sensitive signal under the inductor, even when using a shielded one. If you take the signal and put a GND plane in between, you get a shielding effect at no additional cost.

mat203
Posts: 16
Joined: Sat Feb 23, 2019 7:32 am
languages_spoken: english
ODROIDs: GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by mat203 » Wed Mar 06, 2019 6:27 am

After a bit of thinking about the potential SD card corruption...

The following design features an additional power warning signal, that can be tied to an interrupt input. I simulated it and there should be approx. 1s delay between the warning and the actual power down. This should ensure some "grace period" for outstanding writes.
Power_Warn.PNG
Power_Warn.PNG (23.08 KiB) Viewed 930 times
According to the PAM2301 datasheet, the EN input should have plenty of hysteresis and would be capable of handling the slow slew rate without erratically switching on and off during the transition phase.
The resistors are dimensioned to make the circuit work within a voltage range of 3.5-4.8V without violating the maximum input voltage of the STM32 pins.
R26 and D4 act as a bypass for faster turn on. They are not mandatory, but without them turn on time will also be delayed. If you are interested in the simulations, I can provide them.

I also modified the fast charge enable circuit and directly coupled it to the status of the 3V3 power. When being powered by USB and 3V3 power is off (below 1.6V) the comparator will pull the output low (open collector) to enable fast charging. If the 3V3 is switched on and rises above 1.6V (which is the point at which the STM32 should internally be released from reset), the comparator U8 will shut off its output and fast charging will be disabled.

As a nice benefit, the power consumption is now reduced to a minimum when the main power is off. In my first very simple design the power switch would always drain a bit of battery through the pullup.

By the way, do you always want to fit the RTC LDO ? If not, think of adding a "bypass" resistor option to link VCC and VRTC.
I see some unsed pins on the STM32, which as already mentioned could be used as test points on the PCB. Maybe you will need debugging signals in a case where your expansion header is fully occupied with other signals.

mat203
Posts: 16
Joined: Sat Feb 23, 2019 7:32 am
languages_spoken: english
ODROIDs: GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by mat203 » Wed Mar 06, 2019 4:51 pm

Ah I totally forgot, there is a big issue with the LCD design. According to the LCD datasheet the backlight should be driven with constant current of max. 20mA. The forward voltage is typically 9.6V, therefore it won't work from 3V3 ! I would recommend to drive it with a PWM-capable constant current boost switcher.

flatmush
Posts: 15
Joined: Fri Feb 22, 2019 4:37 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by flatmush » Fri Mar 08, 2019 3:23 am

Again, all good points!

Thanks for the new power idea, that's perfect! I was trying to think of a way to hold the power high in software but that's not necessarily great either, especially since a crash could drain the battery. One second should be more than enough to finish any transactions and shutdown.

I must admit I've never really looked into simulation but it's obviously important for analog stuff. I assume you used SPICE to do the simulation? Might be cool if you could post some relevant links but I wouldn't like to waste your time by requesting you write an explanation or anything.

I had seen the 9.6V thing but assumed the voltage didn't matter that much.
I've now replaced the transistor and associated circuitry with a TPS6165: http://www.ti.com/lit/ds/symlink/tps61165.pdf
BacklightDriver.png
BacklightDriver.png (18.54 KiB) Viewed 813 times
I've fixed the USB power issue also.
USB_Power_Schematic.png
USB_Power_Schematic.png (27.94 KiB) Viewed 813 times
Fixed the vias at the edge of planes thing by changing the fill rules. I guess the KiCAD defaults weren't really as good as I thought. Set the fill boundary to 0.25mm which should be more than enough.

For the Audio I'm thinking of using the following TI chip:
https://www.digikey.co.uk/product-detai ... -ND/483096
Since it can take an analog voltage to provide hardware volume control, I was wondering what kind of filtering would be required to make the PWM output good enough. Would a single capacitor be enough?

Gonna footprint the following for a headphone jack:
https://www.digikey.co.uk/product-detai ... ND/2625184

Already started the footprint but the datasheet seems to tell me to put a pad right on the edge of the board, seems to me like the solder would drip off the board if you don't solder the jack straight away.
So I have on my TODO list to modify the footprints to ensure there's a solder mask dam between the pads and the edge of the board. I assume that's the right thing to do?
JackFootprint.png
JackFootprint.png (27.47 KiB) Viewed 813 times
Adding the jack plug is a big task since it requires moving audio to the other side of the board and swapping the position of the power. I think I'm going to swap the 2-pin connectors to make routing easier. Tested on my current go and it seems like it should work fine.

My TODO list currently has the following items:
- Implement mat203's new power scheme.
- Improve jack plug footprint by removing solder pad from very edge.
- Jack plug on right hand side.
- Find out how to filter PWM on TI amplifier for volume control.
- Add footprint for RTC LDO bypass 0Ohm resistor
- Check whether resistors are needed for touchscreen (looks like not).
- Add test-points.
- Remove all acid traps.
- GND stitching in all ground fills.
- Re-check length matching.

Obviously test-points, acid traps, GND stitching and length matching are just something I'll check before each release at this point.

mat203
Posts: 16
Joined: Sat Feb 23, 2019 7:32 am
languages_spoken: english
ODROIDs: GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by mat203 » Fri Mar 08, 2019 8:28 am

Thanks for the new power idea, that's perfect!
You are welcome, I hope it not only works in theory :lol:
I must admit I've never really looked into simulation but it's obviously important for analog stuff. I assume you used SPICE to do the simulation?
Yes, I use the free LtSpice for simulations. It's not very complicated and you can find lots of examples and tutorials on the web. Do you want the simulation file ? You can add it to the repository if you want.
I've now replaced the transistor and associated circuitry with a TPS6165
If you want to reduce both price and BOM, the MIC2287C would be a better option. It is only one third of the price, requires no compensation and package is also a hand solder friendly SOT-23 5.
Drawbacks are worse tolerance of 10% (brightness difference will be hardly noticeable) and a lower maximum output current (way below with 20mA).
Regarding component selection: I would chose an inductor with a saturation current of 750mA or higher, to ensure that it does not saturate at the maximum switch current (worst case). If you don't find a suitable one, you could also go lower. Under normal operation the current is much lower. The power is that low, that you don't have to pay much respect to series resistance of the inductor.
To stay within the absolute maximum rating of the LCD, I would use a 5.1R feedback resistor. This results in approx. 20mA LED current at the worst case feedback voltage of 105mV.
Further I would recommend to attach a pulldown to the EN input, to ensure the backlight will remain off when the STM32 is in low power mode. This could be an optional configurable feature when somebody leaves the device powered without any input for a longer time period.

Regarding the input voltage, I agree with your choice of 3V3 instead of VCC, as it does not add additional battery current in off state. In general, switching efficiency is better the lower the difference between input and output voltage, regardless if it is a buck or boost topology. But at lower power (what is the case here) the difference becomes neglible.
I've fixed the USB power issue also.
One recommendation here: Attach the capacitors to the pins they are associated to. It is a good practice to follow, especially when schematic and layout are done by different persons. In the worst case one might attach all the caps to VCC and just tie VCCIO to 3V3 without any local capacitor.
Since it can take an analog voltage to provide hardware volume control, I was wondering what kind of filtering would be required to make the PWM output good enough. Would a single capacitor be enough?
The automatic switchover between loudspeaker and headphone is a nice feature, but I can't find any information about the analog volume control in the datasheet. On which page is it mentioned ? Audio is one of the applications in which I never got involed so far. But in general, you can create an analog signal from a PWM by attaching a low-pass filter to the output. Without a resistor the filtering effect is not really given and you might overload your output pin as the capacitor pushes high currents through it. With increasing R*C constant, the ripple decreases but the response time increases. Be careful that the attached input affects the filter. If the analog input is low impedance you can insert an impedance converter (Opamp with output feedback to negative input) between filter and analog input.

As I am not an analog expert... Have you thought of an I2S capable amplifier ?
Already started the footprint but the datasheet seems to tell me to put a pad right on the edge of the board, seems to me like the solder would drip off the board if you don't solder the jack straight away.
I can't follow your point. Are you thinking of wave soldering ? If you want to go for machine soldering, it will be done in a reflow process. Solder paste is applied with a stencil onto the pads, and it is done with a certain amount of clearance to the pad outline (the pad won't be fully covered with paste). The paste adheres to the pad when melting, so I would say nothing will flood away. With hand soldering I expect no problem at all.

My concern would rather be that the copper layer gets damaged during outline machining. On my designs I usually go for 0.5mm clearance from copper to board outline, but I wouldn't say this is a must-do. Anyway, I think you could easily pull back the pads a bit from the PCB outline and the solder connection will still be good.
Check whether resistors are needed for touchscreen (looks like not)
From my point of understanding I agree that no resistors are needed. If there is some space maybe you can add an option to fit small filter caps to GND.

Three other topics:
May I ask why you went for the highest frequency of 48MHz ? I would go for an intermediate value there (maybe something in the range 8-24MHz) to keep frequencies of routed signals on the PCB low.
How did you calculate the load capacitance values by the way ? Use NP0 capacitors for the very small values here and go for X5R/X7R for the larger value capacitors.

On the evaulation board PDR_ON is connected to 3V3 using a pullup resistor. For non-power pins it is also my preference to not directly connect them to power. This also allows you to connect a wire to GND in case you want to turn off the internal supervisor.

Think of adding a polyfuse to the power pins of the external connector (especially on Vbus), it is a self resetting fuse and protects against shorts. For example with 200mA hold current:
https://www.digikey.com/product-detail/ ... ND/4156270
If not want to use it you can still fit a 0-Ohm resistor.

flatmush
Posts: 15
Joined: Fri Feb 22, 2019 4:37 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by flatmush » Sat Mar 09, 2019 2:35 am

mat203 wrote:
Fri Mar 08, 2019 8:28 am
Yes, I use the free LtSpice for simulations. It's not very complicated and you can find lots of examples and tutorials on the web. Do you want the simulation file ? You can add it to the repository if you want.
Sounds like a good idea: If you're comfortable with git then feel free to submit a merge request, otherwise post it here and I'll be happy to add it.
mat203 wrote:
Fri Mar 08, 2019 8:28 am
If you want to reduce both price and BOM, the MIC2287C would be a better option. It is only one third of the price, requires no compensation and package is also a hand solder friendly SOT-23 5.
Drawbacks are worse tolerance of 10% (brightness difference will be hardly noticeable) and a lower maximum output current (way below with 20mA).
Thanks, that's a much better choice!
mat203 wrote:
Fri Mar 08, 2019 8:28 am
Regarding component selection: I would chose an inductor with a saturation current of 750mA or higher, to ensure that it does not saturate at the maximum switch current (worst case). If you don't find a suitable one, you could also go lower. Under normal operation the current is much lower. The power is that low, that you don't have to pay much respect to series resistance of the inductor.
The inductor I had chosen was about within this, though I realised it was too tall (or close to being) for the back side of the PCB. So I've now selected this:
https://www.digikey.co.uk/product-detai ... ND/2002865
mat203 wrote:
Fri Mar 08, 2019 8:28 am
Further I would recommend to attach a pulldown to the EN input, to ensure the backlight will remain off when the STM32 is in low power mode. This could be an optional configurable feature when somebody leaves the device powered without any input for a longer time period.
Makes sense, done the same thing with audio standby, although I guess that's less critical.
mat203 wrote:
Fri Mar 08, 2019 8:28 am
Regarding the input voltage, I agree with your choice of 3V3 instead of VCC, as it does not add additional battery current in off state. In general, switching efficiency is better the lower the difference between input and output voltage, regardless if it is a buck or boost topology. But at lower power (what is the case here) the difference becomes neglible.
I had considered this kind of thing when I was first designing the power stuff for the board, but this time I mostly picked 3.3V because otherwise routing would be a pain as VCC goes nowhere near that part of the board.
Glad it turned out to be the right decision for standby power though!
mat203 wrote:
Fri Mar 08, 2019 8:28 am
One recommendation here: Attach the capacitors to the pins they are associated to. It is a good practice to follow, especially when schematic and layout are done by different persons. In the worst case one might attach all the caps to VCC and just tie VCCIO to 3V3 without any local capacitor.
So in this case I followed the schematics on the datasheet for the FT231XS: https://www.ftdichip.com/Support/Docume ... FT231X.pdf
On page 23 it suggests a single 100nF capacitor on the 3V3OUT pin, and connect that to VCCIO too.
It then seems to suggest 2x 100nF capacitors on the VCC pin as well as the 4.7uF one, this didn't make much sense to me either.
There's no mention of what happens capacitor-wise when 3V3OUT is an input pin, even though it's described earlier in the document.

Would you suggest a single 100nF capacitor on each of VCC, 3V3OUT and VCCIO. And leave the 4.7uF cap near VCC?
mat203 wrote:
Fri Mar 08, 2019 8:28 am
The automatic switchover between loudspeaker and headphone is a nice feature, but I can't find any information about the analog volume control in the datasheet. On which page is it mentioned ?
This is a mistake on my part, pretty much all TI amplifiers have this feature and I was reading a lot of similar datasheets.
mat203 wrote:
Fri Mar 08, 2019 8:28 am
As I am not an analog expert... Have you thought of an I2S capable amplifier ?
I did want to use an I2S DAC/Amplifier, unfortunately I couldn't find any in a suitable form-factor. All the ones I can find are either a DAC only, or only come as a BGA.
mat203 wrote:
Fri Mar 08, 2019 8:28 am
I can't follow your point. Are you thinking of wave soldering ? If you want to go for machine soldering, it will be done in a reflow process. Solder paste is applied with a stencil onto the pads, and it is done with a certain amount of clearance to the pad outline (the pad won't be fully covered with paste). The paste adheres to the pad when melting, so I would say nothing will flood away. With hand soldering I expect no problem at all.
My current plan is to use a solder stencil and try the hot-plate soldering technique documented here:
https://www.sparkfun.com/tutorials/59#H ... 0Reflowing
I also plan on using low temperature Tin/Bismuth solder which melts at only 140 degrees C and is lead free. I figure it's likely to be a bit more brittle, but shouldn't be too much of an issue?
I do have a proper soldering iron (Hakko FX-888D) if that fails.

I've decided to drop the headphone jack completely, and stick with the PAM8301, for a number of reasons:
1. The datasheet from TI required too much implied knowledge, none of the equations match up with the terms given on the page and the only example is for 5V.
2. The cutout would only fit just above the A button, which requires extensive re-routing and will still result in long traces. Would also fit where the SDRAM chip is, but I'm not considering that for obvious reasons.
3. The TI chip has half of the power output of the PAM8304, so would reduce the volume I assume.
4. Would've required drilling the plastic and cutting bits off the rubber key-pads to fit in.
5. Makes the placement of the charging LED very difficult. Not much free space in places that aren't covered by buttons.
I might re-consider for a future update, but for now it's just becoming too much of an issue I think.
mat203 wrote:
Fri Mar 08, 2019 8:28 am
From my point of understanding I agree that no resistors are needed. If there is some space maybe you can add an option to fit small filter caps to GND.
Something like 10nF to filter out any noise on the inputs?
mat203 wrote:
Fri Mar 08, 2019 8:28 am
May I ask why you went for the highest frequency of 48MHz ? I would go for an intermediate value there (maybe something in the range 8-24MHz) to keep frequencies of routed signals on the PCB low.
I chose the 48MHz frequency because of the way clock scaling works on the STM32H7. It basically works out that you can tweak the clock frequency within the range of the oscillator given, for example I could clock between 380-428MHz with a 48MHz oscillator.
I was hoping to use that with the inbuilt temperature sensor to do some more advanced overclocking, i.e. tweak the frequency at runtime based on temperature thresholds.
I'm not sure if it'd work well though, so if you think it's too risky using 48MHz I'd be happy to change it. Woudln't be too painful to just use the 24MHz one from the reference board.
mat203 wrote:
Fri Mar 08, 2019 8:28 am
How did you calculate the load capacitance values by the way ? Use NP0 capacitors for the very small values here and go for X5R/X7R for the larger value capacitors.
The BOM currently has NP0 capacitors, so I assume that part is fine?
For the 32.768KHz crystal I used the same crystal and capacitor values as the STM32 nucleo board does, so I assume that should be fine.
For the 48MHz crystal I looked around at examples and used a calculation off a stack overflow post (corrected for the way the STM32 ref boards pick) to pick a value that seemed sensible.
I was assuming that'd be ok, and worst case I'd just have to use the HSI (internal) since there's actually no real reason to have the high frequency oscillator that I can think of.
If you can check, calculate or point me in the direction of picking better cap values then I'd be happy to change them obviously.
mat203 wrote:
Fri Mar 08, 2019 8:28 am
On the evaulation board PDR_ON is connected to 3V3 using a pullup resistor. For non-power pins it is also my preference to not directly connect them to power. This also allows you to connect a wire to GND in case you want to turn off the internal supervisor.
Hadn't really thought of this, but will do.
mat203 wrote:
Fri Mar 08, 2019 8:28 am
Think of adding a polyfuse to the power pins of the external connector (especially on Vbus), it is a self resetting fuse and protects against shorts. For example with 200mA hold current:
https://www.digikey.com/product-detail/ ... ND/4156270
If not want to use it you can still fit a 0-Ohm resistor.
I had looked into this when you mentioned it the first time but couldn't find any with values I thought would be ok (couldn't find the STM reference boards with them).
I had assumed that you'd want 500mA hold in-case you use the pins to power the battery charger, but I guess that's a weird use-case.
Anyhow, I've fooprinted and BOM'd these now, seems like a good idea!

Will post an update to github soonish, it'll likely be sometime next week.

Thanks again for all the help!

mat203
Posts: 16
Joined: Sat Feb 23, 2019 7:32 am
languages_spoken: english
ODROIDs: GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by mat203 » Sat Mar 09, 2019 10:33 am

Sounds like a good idea: If you're comfortable with git then feel free to submit a merge request, otherwise post it here and I'll be happy to add it.
It's attached, feel free to add it to your repository.
Would you suggest a single 100nF capacitor on each of VCC, 3V3OUT and VCCIO. And leave the 4.7uF cap near VCC?
You are right the datasheet is not clear about the decoupling, if you want to be safe do it this way. At minimum I would give VCC and VCCIO a local 100nF capacitor each, as the pins are far apart.
The 4.7uF acts as a bulk capacitor and doesn't need to be very close.
I did want to use an I2S DAC/Amplifier, unfortunately I couldn't find any in a suitable form-factor.
There seem to be non-BGA I2S chips: viewtopic.php?f=162&t=34080
I also plan on using low temperature Tin/Bismuth solder which melts at only 140 degrees C and is lead free. I figure it's likely to be a bit more brittle, but shouldn't be too much of an issue?
Never tried this type of solder, but having a lower melting point than usual is a good idea when you want to use the hot-plate soldering.
I've decided to drop the headphone jack completely, and stick with the PAM8301
I have another idea which you might know from Smarthpones: USB / Audio multiplexing with a special IC (e.g. the TS5USBA224) and a Micro-USB to 3.5mm audio adapter cable. Makes the device ready for headphones without requiring a case modification or touching the memory layout. Unfortunately most of these chips come in leadless packages nowadays (the few MSOP ones are end of life), but they don't have an exposed pad and therefore could be soldered by hand.
Something like 10nF to filter out any noise on the inputs?
ST recommends 10nF for panels larger than 6" for their touch ICs. I would use something in the range of 1-10nF.
The BOM currently has NP0 capacitors, so I assume that part is fine?
Perfect choice for oscillators.
If you can check, calculate or point me in the direction of picking better cap values then I'd be happy to change them obviously.
For the calculation you take the CL value given in the datasheet of the crystal, make an assumption of the stray capacitance Cs and then you can calculate the load capacitor values.
Section 3 in AN2867 is worth reading to get a better understanding.
I chose the 48MHz frequency because of the way clock scaling works on the STM32H7. It basically works out that you can tweak the clock frequency within the range of the oscillator given, for example I could clock between 380-428MHz with a 48MHz oscillator.
According to the datasheet, the input clock range of the PLLs is 1-16MHz allowing you to pump up to max 836 MHz.
I was hoping to use that with the inbuilt temperature sensor to do some more advanced overclocking, i.e. tweak the frequency at runtime based on temperature thresholds.
I am using a STM32F7 at 216MHz in one of my designs and it gets pretty warm when using the internal LDO to provide Vcore. Therefore I would recommend not to overclock the core.
I'd just have to use the HSI (internal) since there's actually no real reason to have the high frequency oscillator that I can think of.
The HSI should be a viable option, only the UART at very high baudrate could become a problem. Would be worth giving it a try, but I would keep the mounting option for the crystal oscillator.

Unfortunately the STM32H7 has no MMU, which restricts Linux usage.
Attachments
Power_Warn.zip
(8.18 KiB) Downloaded 4 times

mat203
Posts: 16
Joined: Sat Feb 23, 2019 7:32 am
languages_spoken: english
ODROIDs: GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by mat203 » Sun Mar 10, 2019 3:11 am

I had some concerns regarding the stability of the fast charge enable circuit and therefore:
1.) added some hysteresis
2.) made the reference voltage more stable
Fast_Charge.PNG
Fast_Charge.PNG (9.53 KiB) Viewed 615 times
The simulation files are attached.
Attachments
Fast_Charge.zip
(2.67 KiB) Downloaded 4 times

flatmush
Posts: 15
Joined: Fri Feb 22, 2019 4:37 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by flatmush » Tue Mar 12, 2019 4:20 am

Revision 1.2 upload time!

Ok, so I've done most of the changes we've discussed, with the exception of ditching audio improvements for now, here's the changelist:
- Switched to reverse-mount LED for charging and moved it near power switch
- Added boost-converter for backlight as it's 9.6V
- Used self-powered method for USB chip and improved power filtering.
- Added self-resetting fuses to power pins on header
- Swapped 48MHz oscillator for 25MHz
- Add optional resistor to connect VRTC to 3.3V
- Added pull-up resistor for PDR_ON pin.
- Added pull-down resistor for backlight enable.
- Added pull-down resistor for audio standby.
- Added test-points
- Did ground stitching

As is tradition, I forgot to add to the git commit that I changed how ground-fills were done and I removed all the acid traps that I could spot.
I also removed ground-fill from under the inductors as I thought it could lead to a noisy ground plane.
mat203 wrote:
Sat Mar 09, 2019 10:33 am
It's attached, feel free to add it to your repository.
Cool I'll add these to the repository.
mat203 wrote:
Sat Mar 09, 2019 10:33 am
You are right the datasheet is not clear about the decoupling, if you want to be safe do it this way. At minimum I would give VCC and VCCIO a local 100nF capacitor each, as the pins are far apart.
The 4.7uF acts as a bulk capacitor and doesn't need to be very close.
Cool, I've done this now.
mat203 wrote:
Sat Mar 09, 2019 10:33 am
There seem to be non-BGA I2S chips: viewtopic.php?f=162&t=34080
My criteria for part selection for this design were:
1. Must be on digikey.
2. Must be active and in stock.
3. Must be leaded.

I've had a look and the only I2S chips I can find are either DFN or quite large chips which are basically a fully PC sound-card.

I guess it might seem silly given I plan to re-flow, but I'm not amazing at soldering and I'd rather keep the list of things that can go wrong to a minimum.
mat203 wrote:
Sat Mar 09, 2019 10:33 am
I have another idea which you might know from Smarthpones: USB / Audio multiplexing with a special IC (e.g. the TS5USBA224) and a Micro-USB to 3.5mm audio adapter cable. Makes the device ready for headphones without requiring a case modification or touching the memory layout. Unfortunately most of these chips come in leadless packages nowadays (the few MSOP ones are end of life), but they don't have an exposed pad and therefore could be soldered by hand.
Nice idea, hadn't thought of that, but same as above. I think I'll leave it for now, it'd be a lot of work to re-route for either of these things and I can easily do it in the future.
mat203 wrote:
Sat Mar 09, 2019 10:33 am
ST recommends 10nF for panels larger than 6" for their touch ICs. I would use something in the range of 1-10nF.
I can't really find a good place to put the filtering caps near the MCU, so I figured it'd be fine to leave them off? I don't really plan on using the touchscreen anyway as it's behind a hard lens, so I figure losing some accuracy isn't a big deal?
mat203 wrote:
Sat Mar 09, 2019 10:33 am
For the calculation you take the CL value given in the datasheet of the crystal, make an assumption of the stray capacitance Cs and then you can calculate the load capacitor values.
Section 3 in AN2867 is worth reading to get a better understanding.
I actually did this. The stack-overflow post I was reading claimed stray capacitance to be roughly 3-5pF. I calculated from the datasheets and they use 6.05pF for their stray capacitance value. So I picked something in the middle.
I've changed the BOM and picked a pin compatible NDK part with the same load capacitance as the EVAL board but running at 25MHz instead of 26MHz. I figured if I use the same 3.9pF they do then it's likely to work fine?
mat203 wrote:
Sat Mar 09, 2019 10:33 am
I am using a STM32F7 at 216MHz in one of my designs and it gets pretty warm when using the internal LDO to provide Vcore. Therefore I would recommend not to overclock the core.
I guess it's just leaving the avenue open for things people can play with, but good to know.
Realistically I wouldn't expect overclocking to help much anyway, 400MHz is already quite fast and an additional 50MHz is unlikely to make the difference for anything.
mat203 wrote:
Sat Mar 09, 2019 10:33 am
Unfortunately the STM32H7 has no MMU, which restricts Linux usage.
Yeah, this doesn't bother me too much. I used to develop for the Dingoo A320 native (actually created the SDK) which was ucos-ii based.
This is really my prototype device to see if I can do electronics well enough to try something more complicated with a SoM.

Thanks again for all the input, I've credited you directly on the board because at this point you've definitely contributed a significant amount to the design and layout of the board.

Look forward to any feedback!
Attachments
Angled_1-2.png
Angled_1-2.png (280.91 KiB) Viewed 540 times
Back_1-2.png
Back_1-2.png (226.28 KiB) Viewed 540 times
Front_1-2.png
Front_1-2.png (138.74 KiB) Viewed 540 times

pmprog
Posts: 15
Joined: Thu Oct 18, 2018 4:01 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by pmprog » Wed Mar 13, 2019 12:14 am

Couple of questions:

1. Would this be able to run a NeoGeo Pocket Colour emu?

2. The board looks quite busy, but do you think a headphone port could be fit somewhere? If it's an optional component, then it could work as-is with the current Go, but also a new back piece could be designed a little deeper and 3D printed, giving room for the socket

mat203
Posts: 16
Joined: Sat Feb 23, 2019 7:32 am
languages_spoken: english
ODROIDs: GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by mat203 » Wed Mar 13, 2019 4:30 am

Nice idea, hadn't thought of that, but same as above. I think I'll leave it for now, it'd be a lot of work to re-route for either of these things and I can easily do it in the future.
For the first batch of PCBs, I would do the same.
I can't really find a good place to put the filtering caps near the MCU, so I figured it'd be fine to leave them off? I don't really plan on using the touchscreen anyway as it's behind a hard lens, so I figure losing some accuracy isn't a big deal?
I would omit them, because as you mentioned this feature is optional and you can still get stable readings by software filtering.
I've changed the BOM and picked a pin compatible NDK part with the same load capacitance as the EVAL board but running at 25MHz instead of 26MHz. I figured if I use the same 3.9pF they do then it's likely to work fine?
Yes, should be fine.
Thanks again for all the input, I've credited you directly on the board because at this point you've definitely contributed a significant amount to the design and layout of the board.
You are welcome, thanks for the credit. I think you did a really good job with the design.

After review of schematic and layout:
1.) There is a small mistake in the schematic. Resistor R20 should be 47K instead of 100K.
2.) I would add some more stitching vias at the PCB corners. This is not mandatory, it is just a good practice to get used to.
Stitching.png
Stitching.png (43.68 KiB) Viewed 425 times

Some tips for board bringup:
1.) Mount only the power supply related parts
2.) Take a multimeter and measure the resistance between the supply pins to GND, this should be >1K. If not check for shorts.
3.) If you have a power supply with current limit, power it up at reduced limit (e.g. 100mA) and measure the voltages. If they are out of range check the regulators.
4.) Mount all other parts. I recommend you to get desoldering wick, which helps removing shorts between pads of the fine pitch leaded packages.

flatmush
Posts: 15
Joined: Fri Feb 22, 2019 4:37 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by flatmush » Wed Mar 13, 2019 5:54 am

pmprog wrote:
Wed Mar 13, 2019 12:14 am
1. Would this be able to run a NeoGeo Pocket Colour emu?
I believe it would be able to, the console should be roughly as powerful as the NeoGeoX.
pmprog wrote:
Wed Mar 13, 2019 12:14 am
2. The board looks quite busy, but do you think a headphone port could be fit somewhere? If it's an optional component, then it could work as-is with the current Go, but also a new back piece could be designed a little deeper and 3D printed, giving room for the socket
See the conversation above. It is definitely doable, but it's quite difficult. I'm not going to do it for now, but I may do it in the future. This project is fully open-source, so it's also an option to give it a go yourself.
I think if this project were going to turn into a production device, it'd make sense to use smaller components and BGA chips, at which point it'd be fairly trivial to have higher quality sound and an audio jack. For now I'm focusing on making something I can hopefully solder together since it's my first PCB.
mat203 wrote:
Wed Mar 13, 2019 4:30 am
You are welcome, thanks for the credit. I think you did a really good job with the design.
\o/
mat203 wrote:
Wed Mar 13, 2019 4:30 am
1.) There is a small mistake in the schematic. Resistor R20 should be 47K instead of 100K.
Good catch! Will fix that immediately!
mat203 wrote:
Wed Mar 13, 2019 4:30 am
2.) I would add some more stitching vias at the PCB corners. This is not mandatory, it is just a good practice to get used to.
Stitching.png
Will do, is that to stop the signals from reflecting?
mat203 wrote:
Wed Mar 13, 2019 4:30 am
Some tips for board bringup:
1.) Mount only the power supply related parts
2.) Take a multimeter and measure the resistance between the supply pins to GND, this should be >1K. If not check for shorts.
3.) If you have a power supply with current limit, power it up at reduced limit (e.g. 100mA) and measure the voltages. If they are out of range check the regulators.
4.) Mount all other parts. I recommend you to get desoldering wick, which helps removing shorts between pads of the fine pitch leaded packages.
So I was thinking about doing it this way: I do have a current limiting power-supply and solder wick so equipment shouldn't be an issue.

I was hoping to use a stencil and reflow even the first board, would it be possible (or advisable) to hotplate with just the power components after having used the full stencil and then add the components later and reflow again? It wouldn't be paste the 2nd time which may be an issue. I guess I'd have to re-check with eyes and a multimeter after the 2nd reflow to check for shorts?

If the above isn't practical, I can always try the old fashioned way.

Looking forward to ordering the PCBs soonish!

flatmush
Posts: 15
Joined: Fri Feb 22, 2019 4:37 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by flatmush » Wed Mar 13, 2019 6:01 am

One quick issue with the stitching, just checked now and some of the places you've said to stitch are covered in traces.

The worst offenders are the pin header traces which I routed around the edge of the board. I guess it's not critical to skip these?

Edit1: I guess you already answered where you said it's not mandatory, so I'll just leave them off where there's no hope, and for the rest I'll try close.
Edit2: Pushed changes to gitlab, most stitching vias fit apart from the ones on the top right.

mat203
Posts: 16
Joined: Sat Feb 23, 2019 7:32 am
languages_spoken: english
ODROIDs: GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by mat203 » Wed Mar 13, 2019 6:32 am

Will do, is that to stop the signals from reflecting?
I would say, the primary aim is reducing the overall GND impedance.
So I was thinking about doing it this way: I do have a current limiting power-supply and solder wick so equipment shouldn't be an issue.
Perfect, this will help a lot.
I was hoping to use a stencil and reflow even the first board, would it be possible (or advisable) to hotplate with just the power components after having used the full stencil and then add the components later and reflow again? It wouldn't be paste the 2nd time which may be an issue. I guess I'd have to re-check with eyes and a multimeter after the 2nd reflow to check for shorts?
If you use the stencil, there should be no shorts after heating up, even after the second time. What I am more concerned about is the possibility of cold solder joints, because too much flux is gone. These joints look good, but will have no reliable electrical connection and can be a pain in the ass (excuse the bad language). But I can only take a guess here, since I have neither experience with this soldering method nor the type of solder you intend to use.
One quick issue with the stitching, just checked now and some of the places you've said to stitch are covered in traces.
Sorry, I was a bit lazy and didn't check possible collisions on the opposite layer ;) Leaving out any of them is absolutely fine.

pmprog
Posts: 15
Joined: Thu Oct 18, 2018 4:01 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by pmprog » Wed Mar 13, 2019 3:17 pm

Hmmm, I did write a reply, maybe I forgot to post it before closing the window? anyway, thanks for the replies
flatmush wrote:
Wed Mar 13, 2019 5:54 am
This project is fully open-source, so it's also an option to give it a go yourself.
This is all over my head TBH. I've done PCBs before, but they're literally just as a replacement for wires, and my soldering skills extend nothing beyond DIP packages :)

flatmush
Posts: 15
Joined: Fri Feb 22, 2019 4:37 am
languages_spoken: english
ODROIDs: ODROID-GO
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by flatmush » Fri Mar 15, 2019 5:40 am

pmprog wrote:
Wed Mar 13, 2019 3:17 pm
This is all over my head TBH. I've done PCBs before, but they're literally just as a replacement for wires, and my soldering skills extend nothing beyond DIP packages :)
If it makes you feel better, this is my first PCB ever and I've never soldered a DIP chip!
I have had a fair amount of help from mat203 though, and I know people who can help solder if I struggle too much.

In other news, I ordered the boards now. So we'll get to see how bad I am at soldering in a week or two.

deerwings
Posts: 13
Joined: Mon Oct 08, 2018 9:11 am
languages_spoken: english
ODROIDs: Odroid Go
Contact:

Re: Designing a new PCB for the ODROID-GO

Unread post by deerwings » Mon Mar 18, 2019 12:15 am

flatmush wrote:
Fri Mar 15, 2019 5:40 am
pmprog wrote:
Wed Mar 13, 2019 3:17 pm
This is all over my head TBH. I've done PCBs before, but they're literally just as a replacement for wires, and my soldering skills extend nothing beyond DIP packages :)
If it makes you feel better, this is my first PCB ever and I've never soldered a DIP chip!
I have had a fair amount of help from mat203 though, and I know people who can help solder if I struggle too much.

In other news, I ordered the boards now. So we'll get to see how bad I am at soldering in a week or two.
Fun part about soldering is learning new ways to do it. I've never used a heat gun solder system but apparently it's essential when soldering BGA, and apparently also useful for some SMA. Personally, I need to get some more solder flux and some finer tips for my solder irons and I dread doing SMA because it's such fine work but some videos I've seen, the guys are like wizards!

Post Reply

Return to “General Topics”

Who is online

Users browsing this forum: No registered users and 1 guest