Fighting with zephyr

I'm really struggling with writing this damn DAC driver, especially with the build system part, the actual C code isn't that hard, but all the surrounding tooling is killing me. It took me 2.5h to include my driver in my main application, make intellisense work and add it to the device tree.

Mentioning the device tree, I also added the LDO for the dac:

I also continued to write the actual code part of the DAC driver, I'm still at the configuration function, but now I kinda understand how zephyr handles stuff. Also, TI has excellent datasheets, with examples on how to get a working config, which I'm using as reference:

P.S. I wrote those comments, not ai

Started writitng the custom DAC driver

Turns out that writing a good driver in zephyr is really hard. There are literary no docs on how you should implement an audio driver, so you have to comb through other drivers to learn how you should write your own.

Also turns out that the DAC driver only configures the DAC, and you have to manage playback over i2s in your application code.

I started to write the initialization function, this sets up what audio format should the dac expect, what word length etc.

Created a new repo for the driver, and then I used zephyr's package manager to include it in my workspace. This is really fire because both my application code and driver code is in the same place, but in separate repos. The driver repo needed to be a zephyr module, so that took some time to figure out.

Without copilot/gemeni I couldn't have gotten this far, the docs are so ass 😭

Switched to a west workspace

Since I have to write my own driver for my DAC, switching to a west workspace is one of the easiest ways to separate out the driver into a separate repo, so other people can also use it, this also comes with the added benefit of the project managing what dependencies it needs, just like NPM, but for C.

This took some time, because the container that I was developing in just snapped out of existence, so I had to set that up again, I had made an image, but I didn't update that with my changes, so it was easier to just make a new one.

Also, the west workspace broke some stuff, like the build system not picking up my board definitions and zephyr not finding some libraries.

Copilot comes in clutch with decoding the 1000+ line error messages

Ordered a new display and capacitors

I ordered a new e ink display,so that I can be sure that my PCB was at fault, and new 4.7uF caps that are actually rated for 25V. They are already at the airport.

After I ordered them, I realized that I also messed up the inductor
value for the display, as in the inductance is correct, but the saturation current isn't, I used a 170mA inductance one instead of a 500mA inductance one. But I'm going to order this with the new hardware grant in the shop

READING!!!!

I started to dive into how zephyr handels device drives, because I need to write a driver for my DAC (TAD5212). Without Nordic's courses, I would be cooked, zephyr has ass docs.

I also started looking into how the TAD handles registers. Bad news there are like 250 of them💀

I also read how zephyr handles DFU, and multi threading on a more advanced level, and read some parts of the ble course

SD card works

I used a bunch of example from Nordic to get this working. I formatted the SD card to use the FAT file system, and put a simple text file onto it. And then used the sd_card_list_files function to get the files on the card. But nothing showed up, so I spent a lil bit of time debugging the firmware, and still nothing. Turns out the file system on the SD card got corrupted, so I formatted it again, put another file on there, and now it worked.

I think I should buy a book on zephyr, because there are a lot of universal APIs that are not explained really well, but are really powerful, and a good book would solve this, if it even exists.

Got the hall sensor working

Luckily zephyr already had a driver for this IC, but it can't read the output pin of the sensor , only read the i2c register, so I will have to rewrite this later. But it was pretty easy to implement, it uses zephyr's standardized sensor API

Display is really flaky

Right after I made the journal entry about the display working, it started to show the exact same behavior

After a lot of changing around small stuff in the code, I realized that I messed up a value of a cap in the boost converter section of the display's supporting circuitry, I used a 1uF/10V cap instead of a 4.7uF/25V cap. Luckily I had 4.7uF caps from Meko V1. So I took off the 0603 1uF cap and soldered in its place a 4.7uF cap (It's the one between the transistor and a diode):

But just after I soldered it one, I checked if the voltage rating was above 25V. It wasn't...
So I checked both the designs of Meko V1 and my split keyboard, if I used 1uF or 4.7uF caps that were rated above 25V. I didn't :yay:

Just for testing, I powered on the PCB a few times, and one time it worked, but then right after it returned to being borked:

Also I tested if prevgh and prevgl were the right voltage, the were at -+19V, which is in range. Shout out to MPK for suggesting this test.

But there is still a chance that my display is broken, so I will buy another one just in case.

But for now, I will continue work on other part's of the firmware

The EPD works

I found an example on how to configure RTT logging properly with the Segger Jlink, and when I applied these changes the screen turned black, which means it was working???? IDK what's the connection between logging and the screen driver, but I'm really happy that it works. I still had to mess around a bit, and learn how LVGL actually works, because at first as mentioned, the EPD turned fully black, I had to actually check if I could output text to the display.

In conclusion, if you do your configuration right with zephyr, everything works like a charm, but if you mess something up, you are up for a ride.

The next low hanging fruit is the hall effect sensor, and then the SD card, but it should be pretty easy to check if they are working.

Also, bad news, it turns out that there is no zephyr driver for my DAC. So I started researching on other implementations of this driver, that are not for zephyr. The first result that came up was from the Linux kernel, so that might be worth investing further. But other than that, the rest of the results were not as useful.

Got my pmic working

Got my PMIC up and running, I can communicate with it, control the regulators, control the LEDs, etc. It was pretty easy

On another note, I got a reply on the EPD support ticket, so I will have to try out what the agent said.

On another another note, turns out my vibration motor was sucking a lot of power, so I literally turned my DC 3V3 rail into a 2.5-3v3 AC line 💀 So I thought that's why my EPD stopped working, so I tried turning of the motor, and using the EPD, still nothing, and no response from the screen. So it's still dead

This epd is killing me

It turns out that I got that weird error because my epd (e-paper display) wasn't actually connected to my PCB, and that causes an error in the TF-M core, in a thousand years wouldn't have I thought that that could have been the cause. Now that I could run code with the display driver not messing with things, so I tried using LVGL to put a simple line of text on the screen. This sounds simple, but the universe hates me IG and if I tried to interact with the display my program just crashed in an unknown place :yay: One time though It put some random dots on the screen, see image. After like 4 hours of debugging and changing/checking my code line by line, I might have broken my display, because code that worked previously just doesn't work. Also, there was a side quest where zephyr didn't print to the console, so that was fun, and I still don't know the full cause, life is fun isn't it.

I will try some new stuff tomorrow to see if I actually killed the screen, but w'ill see.

Also, I continued to read the Nordic zephyr guide

Finshed lesson 7 on nordic dev academy

In this lesson I learned how zephyr handles basic multithreaded applications, the basics of how the scheduler works, and when and how to use work queues to not starve other threads.

Started implementing the npm1300 pmic

The situation is very similar to other drivers in zephyr, no docs, I made a kinda ok device tree structure, ̶b̶u̶t̶ ̶I̶ ̶c̶a̶n̶'̶t̶ ̶s̶e̶e̶m̶ ̶t̶o̶ ̶f̶i̶n̶d̶ ̶h̶o̶w̶ ̶t̶o̶ ̶u̶s̶e̶ ̶t̶h̶e̶ ̶l̶o̶a̶d̶ ̶s̶w̶i̶t̶c̶h̶ ̶f̶e̶a̶t̶u̶r̶e̶ ̶o̶f̶ ̶t̶h̶e̶ ̶n̶p̶m̶1̶3̶0̶0̶ so I made a support ticket for this issue as well, this service of nordic is awesome!!!

EDIT: Found the option

I think I'm going to jump off a bridge

With the vibration motor working, I wanted to tackle something bigger, so I started implementing the e-ink display. It turned out that zephyr already had a driver implementation for my display :yay: . This meant that I didn't have to muck around with implementing the driver myself. The problem was that zephyr doesn't have that great of a documentation for drivers, almost literally none, so I spent a long time figuring out how the device tree node worked and what was needed to get LVGL working with my display. After 4 hours, I had a minimal device tree setup, and I went to flash the new firmware to my PCB.

After I flashed it, the vibration motor didn't start vibrating, which it was supposed to do, WTF. I flashed it again, but in debug mode, to see what was happening:

An exception was thrown in the TF-M side of the firmware (on modern arm SoCs there is a feature called Trust Zone which splits up your firmware into two parts, a secure one, where sensitive info and cryptography lives, and an unsecure one, where your application code, RTOS and BLE stack lives, this is the recommended way to build firmware, TF-M is the zephyr implementation of Trust Zone).

When this happened, I didn't know anything about TF-M or WTF was happening, so it took me a really long time to understand all TS. The most likely cause of this is that the display node in my device tree messes with the application configuration, and the stack sizes, or causes a stack overflow, TBH IDK, I submitted a ticket on Nordic's support platform.

I also tried to build without TF-M, but that also didn't work, but IDK if I messed something up while I configured this new build.

I'm putting the e-ink screen on pause for now, and starting to implement my power management IC

Got zephyr up and running

Containers, Containers, and Containers

Turns out that in Bazzite if you want to do anything, you have to use a container, I know about this, but didn't know that it would go to this extent. When I first tried to install the nRF connect SDK, not in a container, it just gave me an error, this is because Bazzite is immutable. The solution: Run an Ubuntu container in which you install all the dependencies of your project, and forward the USB programmer to the container.

In hindsight this may sound simple, but I spent 2.5 hours figuring this out, along the way I learned what podman is, it's like docker just a lil bit different, and Bazzite runs on TS.

The zephyr experience

Zephyr is HARD, I had to reread the docs soooo many times, but once you understand it, it's GOATed. The nRF connect SDK is amazing, "it just works" TM. It has a bunch of devtools, and you can visualize your device tree:

Getting the vibration motor and buttons working

Now with my new-found knowledge of zephyr, it was time to do some testing, so I got the vibration motor working. This was a huge win for me, this was the first time I put my own code on my own custom PCB!

THE PCB ARRIVED!!!

The only thing I needed to do now is test it out! I needed to solder the 5x2 SWD programming header. But there is a problem, the pitch is 1.27mm, which is minuscule, so I did a few practice runs on the non assembled PCBs:

All of them I failed. There was always some tiny speck of solder connecting two pins. The solution: Don't solder the header.

I put the header in the JLink cable, and put that in the holes in my PCB, and twisted it, so there was some tension, so all the pins connected with the pads.

I downloaded the JLink software again (switched to Bazzite from Fedora), and tried to connect to my MCU.

Connection failed...

Turns out I didn't apply enough tension to make good contact with all the pins. And now... Successful connection

Realized that I dont know C

While I continued to read the Nordic dev academy course, I realized that I don't know C. I know a bit of C++, but it turns out that they do a lot of things very differently in C, so I started to watch a C course. I'm currently watching it a 1.75x speed 💀 because the guide goes over very beginner stuff as well.

The guy mentioned the natural logarihum function, so I also learned what e is, and what the natural logarithm is, and then went deeper in the rabbit hole and learned what Euler's identity is.

3D printed the case for visualization

So far I have only seen the case on a computer screen, so I quickly 3D printed one on my FDM printer. The tolerances aren't quite there, but this is expected.The final part will be resin printed

Getting sponsored by JCL?? (and that's not a typo)

This all started when I asked for a design review on the r/PrintedCircuitBoard subreddit, and a Redditor replied in broken English that they will manufacture my PCB for free. (The mods have removed the comments since then)

I was really hesitant at first, they DMed me on Reddit, and asked for my phone number so we can continue on WhatsApp. Now I thought, this 100% must be a scam, but I continued. I didn't give them my phone number, just my email. In the email convo I found out that this is in fact a real company in China, and that they have an Alibaba store, and that they would give me free PCBs, assembly and shipping, I just needed to pay for the parts. They wanted my to use their Alibaba store to place an order, which was nice since if it was a scam, I could just ask for my money back.

So just a recap, someone in broken English replied to my Reddit post, and now I'm getting free pcbs??? WTF

This doesn't end here. My contact Elle, really nice person, offered me to do some design jobs, crazy. I declined these though, because the wage was really low.

Today they sent out the pcbs:

Learinig zephyr

Finished lesson 2 and 3. Zephyr seems really powerful, but it's really complex. I still have not grasped all the core concepts in the guide, the device tree is hard.

Learning zephyr

Started learning zephyr, to be more specific the nRF SDK, they have excellent docs, but it introduces a lot of new concepts, so I'm slowly reading through it.

Also, my J-LINK arrived. Thanks Niko from Segger for sending it out!!!!

Made new renders, removed some load caps

I updated the old renders, with the new pcb and case. Also realized that i could remove the load caps from my 32MHz crystal, because the nrf53 has ones built in. I also changed out the 32.878kHz crystal, to one that has a 7pF load capacitance, the prev one had 12pF, and the nrf53 only has 5pF, 7pF and 9pF internal load caps.

Reduced BOM, fixed clearance issue

While getting a quote at jlc, I noticed that the footprint for my motor was misleading, and its courtyard wasn't as big as it was supposed to be, so it interfered with a resistor, so i moved that.

Also switched out a bunch of passives from the extended lib to the basic library as requested. It reduced the BOM by 22$.

Removed nRF DK from bom

I removed the nRF DK from the BOM, because tools aren't allowed. I'm gonna be bankrupt after TS😭 But I hope that it will last a long time and I can use it in the future

Added missing links to bom

Added missing links to bom for the NRF54L15-DK from Digikey, and the IDC cable for SWD debugging and flashing from AliExpress, that I will connect to my PCB and the nrf dk.

Prepped for blueprint submition

Added LCSC part numbers, and updated outdated mrf part numbers. Updated the bom and readme. Changed out a few parts, like some inductors, and capacitors.

Modified case and pcb

I realized that I didnt place the power button and audio jack in the correct place, so i moved them. Updated the case with the new mouting hole, sd card, and jack positions.

Datasheet reading

Most of my was spent rereading all the datasheets. Along the way I found a small issue in the hall effect IC circuit, was a quick fix, just had to connect the 5v and 3v inputs. Also, someone pointed out that in the nrf53 reference pcb layout, there is a cutout in the GND plane beneath the feed line, turns out this is to make the feedline thicker, while keeping the impedance at 50 ohms. This is good to make the feedline thickness closer to the width of the pads of the matching components, so there is less impedance mismatch, also it reduces resistance. Also found out that the nrf53 has internal load capacitors for its crystals, so you can tune the values without needing to resolder the caps, which is nice for RF.

Finished routing traces pcb

I placed all the testpoints, added some 3d models. I still have to add the rest of the 3d models. I had to reroute some of the traces, cuz of the tespoints

Finished routing traces

Finished routing rest of the traces, changed recalculated the antenna trace impedance, still need to place testpoints and assign some 3d models, placed stiching vias

Routed more traces

Only 26 unrouted traces left, and placing the testpoints

Laid out the antenna, asked about on the kicad discord, discussing it right now, might have to move stuff around

bunch of routing

Did a bunch of routing. Redid the layout of the analog section for easier routing as well, routeated the dac 45 degrees so the two analog sides can be on the analog side of the via fence and the two digital on the digital side of the via fence.

Moved a bunch of pin assignments on the nrf for easier routing

Routed a bunch of traces

I routed a bunch of traces, including usb, microsd, and the display. I moved pins around on the mcu so it's easier to route.

Furthermore, I also choose the stack up, I'm going with a 6 layer board, the jlc basic one with two cores, so my stackup is sig/gnd/sig/gnd/gnd/sig, so every layer has a close GND layer.

I also turned on teardrops, and test the curvy traces plugin and it looks awesome

removed caps from software controlled buttons, placed jumper

I saw a video that said controlled buttons debouncing caps are useless at best and shorten the lifespan of your buttons at worst, so i removed all the caps from the software controlled buttons. Also laid out the rest of the jumpers, only the testpontints left, th
at I'm going to leave to the end

finished first pass of rough layout

i still need to add 3d models, and place all the testpoints, some jumpers and the swd connector

I will stay with this package i think, it will be fun to be able to use small vias like ts

Almost finished with basic layout

This is a rough layout, just to help me visualize how I should proceed

Still contemplating using a module for the nrf53, seems easier, and if i want to sell this later on i wouldn't have to get rf certification

Changed out the parts that were not avalibile on lcsc

I still had some parts that were not avalabile on lcsc from v1, so i looked for new parts, I changed out the usb port, display fpc port, vibration motor

Added a butt ton of testpoints

I also added a bunch of jumper pads on the i2c lines, so i can isolate one component if i want too. In the same way I also added jumper pads on the power of the chips, so i can just disconnect them

Im staying with the nrf53, because the nrf54l doesn't have audio pll, so small vias it is

I found a bug, I connected the i2c address pad of the dac to a gpio, now i have two options for and address

Rethinking how to make this prototype PCB

I was worried on the size of the pcb, make it as small as possible. With V1, this came to my demise. In v2 the main goal will be to be able to fix mistakes that I made, so I will leave spacing between components, put a bunch of test pints and bridgeable/cuttable test pads, and not worry myself about the size of the final product. If this prototype works, I will shrink everything down for production.

I'm also reconsidering the nrf54l, which is available in a qfn package, but most likely I will stay with the nrf53

Chat I might be cooked

My pmic is not available in a qfn package at lcsc, only in bga😭 First bga that I will use every, so I watched a bunch of altium academy videos about bga design. Also I need 0.2/(0.3)mm vias for both the pmic and the nrf53, so 5 PCBs will cost around 69$ (nice). I also checked how much would double sided PCBA will cost, it's around 210$ USD for two PCBs. So tier 1 here I come!

I'm pretty scared that this won't work like V1, so I'm putting extra effort in to quadruple-check everything. I will also place a frick ton of test points.

added leds to the pmic

Made final touches to the schematic, added leds to the pmic, double-checked everything one more time. Added some more testpoints, but i will add a lot more.

I'm debating doing double-sided pcba, but IDK if I will fit in the budget

Switched out DACs

I posted my design on the kicad discord for review, and the people there pointed me in the right direction about my DAC. The ESS DAC that I was using was expensive and hard to implement, I switched to the TI TAD5212 which has the same performance, and is a lot easier to implement, and has a bunch more features, and it's half the price at $5, and it's also available at lcsc, so I can get PCBA.

I spent a lot of time reading the datasheet

I also switched out some parts from v1 that were not available at lcsc that are available.

The schematic is almost done, the last thing i might add are some charging indicator LEDs to the pmic.

Many small changes

I went over the schematic again, fixed some stuff.

I used mouser for v1, and i plan to use lcsc for v2, so i replaced the parts that lcsc doesn't have, except my amp/dac, I will solder that to the PCB using hot air reflow. Furthermore, I also moved from an externally powered oscillator to a plain old crystal for my dac, it's just simpler this way. Changed footprints from 0402 to 0603 for better debugging

Finshed rough shematic

I finished the power train. Connected everything to the soc. Removed/separated a bunch of nets from v1, where I was in a shortage of pins, so i combined reset pins and similar things. Switched over to spi from sdio for the sd card. Made the schematic prettier

Reread the datasheet of my AMP/DAC chip

In v1 i used 1mm1mm power regulators for my audio chip, which were hell to debug/hand solder. SO this time I'm using almost the same regulator from TI, but in a 3mm3mm sot-23-5 footprint. I reread the datasheet of my audio chip, and realized that I don't actually need one of those regulators, so I'm now two regulators down, the other that I removed was my general 3.3v regulator, because the npm1300 has one built in.

Also, my hall effect sensor for my dial draws a lot of idle current, so I utilized one of the load switches of the npm1300(my beloved) to no give power to it when the device is in sleep mode

Started to redo schematic

Deleted a whole bunch of components. Added in the nrf5340 and all of its surrounding circuitry. Also added the npm1300, I'm so excited to use this bms btw (⁠≧⁠▽⁠≦⁠) removed the old BMS, some of the regulators, because the BMS has built in ones. IDK if I should use 1.8V logic or 3.3V logic though

Found my dream BMS

I just found out that Nordic makes BMSs specially for the nrf5 series, it's called the npm1300, so they have full example schematics of the two working tougher!! It also has fuel gauge functionality, and is able to monitor every voltage in the system. It has two voltage regulators built in, that you can also control with i2c. It has native support for USB power negotiation. It also seems pretty easy to implement.

Most of my devlogs so far have been doing research😭

Realized that the nrf5340 exists

Realized that nrf has much better documentation, more examples and a better rtos. It has less ram than the stm32, but it is much more power efficient.

I have worked with the nrf52840 before, and it is almost the same. I'm just worried about routing the second row/layer of pins on the package

Looking for an SoC that has bulilt in USB controller

V1 had a few issues, one of them that there had to be a whole separate chip to convert from usb to uart for the esp32 (gen 1), and in general it is kinda hard to flash a first gen esp32.

But the problem is that from my research the only SoC that has Bluetooth audio, and wifi is the first gen esp. So v2 probably won't have Wi-Fi, so no Spotify/other streaming. Which is kinda sad, but I rather have a less feature packed project, then a project that is not in a working condition like v1.

So far I have landed on the STM32WBA65CI, it has ble 6.0 and audio support, its beefy, has plenty of io, and most importantly an integrated usb controller. Maybe for a next version I will add an esp32c3 has a Wi-Fi module, but first this has to work

Also, some other stuff that I have been thinking on changing/leaving for v2:

• I will not use 0402 components, and other small components in general, it's just a pain to debug and work with, once I have a working prototype, I can do a version with small components
• Simplify the power and battery systems, I won't use a power path and a fuel gauge chip, just a tp bms and a voltage divider for the battery percentage
• I am leaving the DAC/AMP chip, and all the surrounding circuitry, except I'm using larger package sizes for the accompanying components