EVBox charger autostart module

The schematic diagram is a textbook implementation of an RS-485 interface, a linear regulator, and a microcontroller. In this specific design an input capacitor for the regulator is not required, as it is located very close to the main filter capacitor within the charger. Local decoupling for the microcontroller is similarly unnecessary, since it is very close to the voltage regulator output capacitor.

Due to the low component count, and my fondness for optimisation, I aimed to make the module as compact as possible. The result is a 22 × 22 mm PCB, matching the width of the charger connector. There is a ground pour on both sides of the board, with via stitching to improve performance in a noisy environment. The PCB was designed using KiCad.

Accompanying the firmware are unit tests, integration test, and regression tests. There now are many more lines of test code than firmware code. Writing the tests really paid off, catching so many errors and edge cases. This is also where AI became useful; creating unit tests and finding gaps in test coverage. With the passing of tests, my confidence in the firmware grew.

I think I wrote the proof of concept code in a day or two, but the C firmware and unit tests took me over a month, making sure it's solid and covers all edge cases. I'm not usually this thorough in my own projects, which usually end in the proof of concept stage.

PCB production is, once again, handled by PCBWay (affiliate link). There is simply no way that local fabs can match their pricing. I had also requested a quote for assembly, but this turned out to be more expensive than I had hoped. PCBWay generally offers very competitive component pricing, but a few of the components were surprisingly expensive. Together with the setup fee, this made assembly prohibitively expensive for such a small batch. So over to plan B; sourcing components and handling assembly myself. Obviously I was unprepared for what came next.

In fairness, the quotes I had requested were for 5, 10, and 20 units — not 50. The per-unit cost at larger quantities would likely have been considerably lower, making the comparison less straightforward than it first appeared.

I spent the following days searching Conrad Electronic, Farnell, DigiKey, and other relatively local suppliers, before turning to eBay, AliExpress, and AliBaba. Some components proved difficult to source at a reasonable price — or to source at all with certain suppliers — such as the Analog Devices RS-485 transceiver, the Microchip AVR (due to its extended temperature rating), and the Phoenix Contact connector. Fortunately, all other components were generic and readily available.

I did briefly explore replacing the ADM3485 with a more affordable alternative, but this necessitated reworking the power supply to 5 V, which introduced its own complications. After doing this, I concluded that the changes were not worth the trouble and reverted to the original part — the one I had wanted to use from the start.

I made a conscious effort to avoid counterfeit parts and "too-good-to-be-true" offers. Eventually I found Shenzhen Nanfeng Quancheng Electronics Co., Ltd., a supplier for one of the difficult components, and decided to order everything from them. In hindsight, instead of locating suppliers for each individual part, I should probably have searched for "BOM fulfilment" from the beginning.

This process took me several days, and I was still not entirely confident that I had found genuine parts at a good price — or that they would arrive at all. It's scary ordering from an unknown company, with considerable geographical, language, and cultural distance.

Luckily everything arrived, and is exactly what I wanted. With this experience I now find the PCBWay assembly setup fee much easier to understand.

The PCBs themselves arrived with an unexpected detour. The shipment was marked as delivered, but I could not find it anywhere — it had been sitting in the paper recycling bin for nine days. I only found it because I happened not to have the bin emptied in the meantime. Remarkably, the exact same thing happened with the second shipment.

There is so much more involved in producing a product than I expected. I thought sourcing parts was a rabbit hole, but there is far more to deal with: production repeatability, traceability, quality control, end-of-line testing, generating test reports, packaging, shipping, and the list goes on. To me, a project mostly meant R&D. Who knew that is only the beginning.

One of the sub-project I hadn't seen coming was that I had to create a step-by-step installation manual. I’ve done my best to make it understandable for people who are not hardware geeks like me.

The workflow took some figuring out as well. I started with LibreOffice, but I do not particularly like WYSIWYG editors, and maintaining multiple versions for different languages quickly became a pain. I ended up converting everything to Markdown (one file per language) and use Make to build PDFs from the Markdown and image sources using ImageMagick, Pandoc, and LaTeX. This is a build system I feel much more at home with.

The installation manual, both sources and rendered, can be found here.

After ordering all components, I reviewed the fuse configuration of the ATtiny402 and discovered a design oversight. Pin PA0 could be configured either for UPDI programming (which was required) or as a GPIO pin (which was also required). Once configured as GPIO, standard UPDI programming was no longer possible.

Reprogramming was still possible, but required a high-voltage programmer, which applied a 12 V pulse to force the AVR into programming mode. The complication was that this same pin also served as a GPIO connected to DE/RE on the RS-485 transceiver, as it was the only pin providing USART XDIR functionality. Applying 12 V directly to that input could damage the transceiver.

The solution was a simple clamping network: a series resistor between the AVR and the transceiver, and a diode to VCC on the transceiver side. The existing PCBs could be modified relatively easily, even after assembly, and the fix was incorporated into the v1.1 hardware revision.

This issue affected only reprogramming of modules. The initial firmware could still be programmed via standard UPDI; the high-voltage programmer is required only for subsequent updates. The modification will therefore be applied only to modules that actually require reprogramming.

This is what you get when you rush into production with an unfamiliar MCU, and skip prototyping. Fortunately, the problem was contained and straightforward to correct.

For initial programming I had simply used a USB-to-serial converter. When the HV programming issue popped up, I thought I could just use the AVR Dragon used for Reverse engineering DebugWire, which supports HV programming, but unfortunately not UPDI. So I ended up ordering the Adafruit High Voltage UPDI Friend, which I can recommend. Adafruit consistently produces well-documented, practical hardware, and this was no exception.

Assembly was done in-house—quite literally. The boards were stencilled and assembled manually, on the kitchen table. The essential requirements were workspace, adequate lighting, and a pair of reading glasses.

This was my first time using solder paste stencils. In a previous project I had applied solder paste by hand, but stencils are so much easier to use, faster and more consistent. I obtained a used stencil printer; however, it supported only framed stencils, which I did not have. Instead, the stencil was taped directly over the PCBs. For the five panels in this batch, this approach was good enough.

During assembly I dropped a resistor and realszed I hadn't ordered any spares at all. Fortunately, I managed to find it again.

For reflow soldering I acquired a used Puhui T-962A oven. Given the number of problems, modifications, and upgrades for this model found online, I was surprised by how well it performs stock. All panels were soldered cleanly. I inspected every panel under the microscope and no rework was required.

Reflow soldering is a rather smelly process, because of the flux, so I placed the oven on the cooktop under the fume hood. This setup worked well.

The firmware had already been tested, as much as possible, through integration tests. However, many hardware-specific aspects — including interrupts, timers, UART behaviour, watchdog operation, brown-out detection, and stack and RAM usage — could only be verified on the actual hardware. This proved worthwhile: several issues were uncovered during system validation.

The first issue was a non-firing UART interrupt. After spending a full day reviewing the USART and interrupt configuration against the datasheet, the root cause became clear: the CPU was trapped inside a timer interrupt. The timer interrupt flag required manual clearing, whereas I had assumed it would be cleared automatically upon entering the interrupt handler. Once the flag was explicitly cleared, the UART interrupts operated as expected.

The next issue concerned the connection of the RS-485 transceiver to the AVR. TX and RX shared a single bidirectional pin, and this configuration caused received data to become corrupted after transmission. I experimented with several approaches: disabling receiver interrupts during transmission, disabling the receiver entirely, and disabling loopback. None resolved the problem. Ultimately, I chose a simpler and more robust solution: incoming data were ignored during transmission. This eliminated the corruption.

Given the limited RAM available on the AVR, stack and memory utilisation were measured. Of the 256 B total RAM, 42 B were allocated to global variables and 38 B were used for the stack, leaving 176 B free. The firmware therefore remained comfortably within the available memory constraints.

Once the module performed reliably in laboratory scenarios, it was time to test it in real-word situations.

The test modules were pluged into different development chargers, and into my own wall-mounted charger I use for charging my motorbike. In all cases, they behaved exactly as specified. Communication was stable, charging sessions completed, and no unexpected resets or faults occurred. This stage provided confidence that the firmware and hardware functioned not only in isolation, but as part of a complete system.

With the test modules validated, the final step in production was to test and flash every produced unit, before shipping them out. This process was largely automated, using PyTest.

The lab setup was expanded to include an Owon XDM1041 digital multimeter with USB control, and an Eletechsup UD85C08 8-channel USB relay board. Together with the existing bench power supplies, programmable load, AVR programmer, and USB-to-RS-485 converter, this formed the automated testing and flashing rig.

Initially, my plan was to add the clamping circuit for UPDI HV programming to the v1.0 hardware and begin production. However, I then realised that the module is installed in an electrically noisy environment and has no meaningful electromagnetic interference (EMI) protection. The v1.0 hardware design was somewhat rushed due to a self-imposed deadline, so I never formally defined requirements. On the other hand, no hardware failures were reported from the field, so the EMI resilience was apparently sufficient.

This time, I defined a set of design requirements, making design choices more defensible, predictable, and scalable. The main design changes were the addition of the clamping circuit for HV programming, TVS diodes and series resistors on all connections for EMI mitigation, improved local decoupling, and an updated voltage regulator.

One of the things I had always wanted to do is panel a PCB. Until then I had always relied on PCBWay to do this for me, but this time I created the panel myself. It proved less difficult than I expected. I installed KiKit, the most popular panelisation plugin for KiCad. I used the panels from the previous batch as a template for dimensions. To place tabs exactly where I wanted them, I used annotations in KiCad.

Once I was satisfied with the result, I automated panelisation using make. While doing so, I also added generation of all production files, similar to how the user manual is rendered.

The Phoenix Contact connector is quite an expensive component, accounting for roughly half of the BOM cost. I came across compatible connectors at a significantly lower price. Since the autostart module does not use the connector anywhere near its limits, I tested a few alternatives and selected one for the next production batch.

Based on the previous production run, where I had no spare parts, I ordered an additional 2% of each component. These spares are intended to cover assembly losses and occasional repairs.

As I was satisfied with both pricing and service, I obtained the entire BOM again from Shenzhen Nanfeng Quancheng Electronics.

Assembly was again done on the kitchen table. The v1.1 PCB design has 19 parts per unit, mostly smaller, and a few more than the v1.0, which had 12. It took two people six hours to assemble the SMD component and reflow solder the ten panels - 100 units total - plus additional time for the through-hole connectors and depaneling.

To be honest, I do not think I want to assemble at this scale in-house again.

I had purchased 10 g of solder paste before the first batch, and used the same supply for the second. There is still roughly a third remaining. I had not appreciated just how far 10 g goes in practice.

At the start of the first production batch I validated modules manually. This is time-consuming, error-prone, doesn't scale, and I dislike repetitive work. Once time allowed, I started automating the process and building a test rig.

Writing hardware tests is similar to writing unit tests: first set up fixtures (PSU, multimeter, relays), then perform measurements, and finally assert the results. The voltage regulator output is measured first; if it is within specification, testing continues, otherwise PyTest aborts immediately. Next, RS-485 bus levels are verified, followed by AVR programming and a full communication test. Each module is programmed and tested within approximately two minutes. All modules passed, even as tests became progressively more stringent, which increased confidence in real-world reliability.

For the second production batch I added a Rigol DP832 programmable power supply from Eleshop. This is an analogue power supply with digital control, combining the best of both worlds. It provides much faster transient response than firmware-only solutions. It includes Ethernet and USB interfaces and supports SCPI, allowing integration with PyTest.

The Owon multimeter I had previously purchased proved disappointing. Measurements were slow to stabilise, and the SCPI implementation was unreliable. After all, you get what you pay for. To obtain a more suitable instrument, I acquired two used HP (Agilent, Keysight) 34401A multimeters. Although older, these are excellent multimeters, and have none of the problems the cheap one had. They provide serial and GPIB interfaces and integrate well with PyTest.

As USB serial port numbering can change between reboots, I used udev to create persistent device links, allowing devices to be referenced as /dev/dmm1 rather than /dev/ttyUSBnn. Devices are typically identified by vendor ID and serial number, but several devices turned out to use identical CH341 USB-to-serial converters with matching serial numbers. As a result, they can only be distinguished by USB path, so each was connected to a fixed port on the USB hub.

A programmable load, an arbitrary waveform generator, and several additional instruments remain on the wish list. Once the entire production batch is sold, I can afford some of these, and intend to expand the test rig further for more rigorous validation for the next production batch.