T1000 Development Log
I'm going to try and put as much here as I can over time to show the development process for this iteration. Selfishly it should also make writing my ENEE499L reports much easier. During debugging & adding features I'm going to try and track issues using the issues feature in this repository and will hopefully link them here consistently.
This revision included two boards. The T1000 Digital Board and the T1000 Cutdown Power Board.
I want better names for these boards, I think I'm going to try T1000-M4F for the digital board (M4F processor). Still a WIP.
This board builds off of experience with BITSv5.x but with changes. Below I describe what's on the board and some of the why behind these selections.
-
STM32L4
- Very low power, ballpark estimate is 10mA consumption for this application
- Hardware floating point unit, will want fast floating point computations for running PI loop
- Super small package, 36 ball wafer scale package is I think the smallest I could possibly get for this board and fab process I chose
-
U-blox MIA-M10
- The smallest M10 GPS they make
- U-blox products have excellent flight heritage which justifies $30 per piece cost
-
MB85RS1MT FRAM
- Simple, non-volatile, byte-addressable memory for storing data and logging events
- More complicated than an SD card but at much lower power and size
-
MS5607 Pressure/Temperature Sensor - simple sensor that happens to be properly rated for the environment unlike Bosch offerings commonly used
-
SX1262
- Same radio used in modules used on other designs
- Integrated based on a very simple reference design, lower total output power (~17 dBm if I had to guess) due to wanting to run the system at 1.8V for absolutely minimal power consumption
- May have to relay through a more powerful radio (i.e. BITS) at times but should still be able to receive line-of-sight commands
-
Power - Not much to talk about, 1.8V from a battery and a 1S LiPo charger for convenience, produces 3.3V from USB power, both 3.3V and 1.8V are fed through and ideal ORing diode IC which just supplies the higher voltage to the system
This board was fabbed on JLCPCB's 6-layer process. It was cheap at the time of ordering because of a special offer. Critically, this process offers a free via-in-pad process which allows me to use the atrociously small STM32L4 package I picked. It's not truly necessary but it helps reduce total board size at the end of the day.
In terms of the layout, it could be more optimal and dense. My first priority with this revision was to design it fast so that I could start figuring out what worked and what didn't. Given the time I'd like to experiment with different layouts to further optimize the density.
I chose to produce this as a different board for two reasons.
- The 6-layer board process I chose was only cheap for designs under 50 x 50 mm. Integrating both of these boards in one 50 x 50 mm board would be difficult (see the inductor I chose for this board)
- I wanted to be able to change this part of the T1000 design without changing or building more Digital boards. Given the number of components on the Digital board it takes quite awhile to assemble by hand. I've never done a power stage like the one found on the Cutdown board so I split them up to make my life easier.
A benefit to this approach is that the Cudown board can be produced as a 4-layer or probably even 2-layer board.
As for what is actually on this board, there's not much. You'll note that the ICs are both Analog Devices products. Although expensive, they were chosen specifically because they are available in LTSpice. I wanted to do as much simulation of this system as possible before committing a design to a board and I'm very comfortable with LTSpice at this point.
- LTC1751 Charge Pump - attempts to produce 10V from the supplied voltage at the battery terminal. This is critical since driving power mosfets like the ones used requires voltages in the neighborhood of 10V to switch them properly. The actual amount of energy used for this process is fairly low so I chose to use a charge pump to save on space.
- LTC7061 FET Driver - is what actually drives the FETs. This makes it very easy to drive a half-bridge FET configuration with extra safety features to prevent short circuiting the voltage supply to ground.
Did first pass assembly of the digital board on 9/25/2024. Took about 4 hours which was longer than I had hoped. That being said there are 98 footprints on the board, not all of them were placed but 90 probably were.
Since I did it in Terrapin Works, I got some lovely pictures with their fancy microscope. Some touch-up work will be required.
- I'm very pleased with the alignment of U3, will need to check for bridging before I power it up but it looks good.
- USB connector bridging like it does every time, my paste application wasn't very great this time around so that might be the issue, need to investigate better methods for paste application.
Stencil from OSH Stencils, only ordered the one I needed for the Digital board since I can throw the cutdown board together without one.
Batteries from HobbyKing. Not my favorite vendor but I needed a small capacity 1S LiPo that could dump 3A and they had some cells that claimed to do this, for much less than $30 a pop.
Everything else was from these two DigiKey lists, one for each board. There's purposeful overlap between to two where components can be the same (capacitors mostly).
https://www.digikey.com/en/mylists/list/FE2V6D2R7P
https://www.digikey.com/en/mylists/list/F9UPXKBF5G
I threw together the cutdown board as an LTSpice sim to play around with it before ordering. You'll note that it's absurdly basic.
There is no modeling of parasitics and the PI loop is essentially analog and ideal.
This is because I'm not particularly knowledge of how to model those things, and the amount of power and cost involved here means that it's faster to just try the design in the lab since it's not particularly expensive or dangerous if it fails miserably.
Nonetheless, the result from this sim shows a very damped response which is pretty much what I want since there's no load transients involved (it's just a resistor).
A sim can only be so good though so hopefully the real thing behaves how I think it will.
This is once again a new adventure. New MCU = new software :)
I won't repeat all of the info you can find in Firmware/gen_proj/README.md but I will talk about it some.
First and foremost I don't like vendor IDEs. While they sometimes include really nice conveniences and features that make development easier, I find myself often wasting time trying to understand what's happening behind the scenes when debugging something.
In true C purist fashion, just give me a Makefile
So here's what I did, I pulled the basic main.c, syscalls.c, and sysmem.c out of a generated STM32CubeIDE project and dumped them into my own project with the help of Google. I also stole the CubeIDE generated linker script.
I then downloaded the ARM CMSIS and STM32L4 CMSIS components, along with the STM32L4 HAL and Low Layer (LL) drivers. All of these things are included as submodules so that they can be updated and versioned easily.
The CMSIS components give basic startup logic and system configuration. syscalls and sysmem are needed to get compilation to work properly, I'm not entirely sure why but I don't think it matters for this application.
Most critically, the LL drivers in particular make using peripherals easier. The ST HAL is also available but it seems like more than is necessary for this application. It seems to border on being an RTOS which I don't want right now.
I then took a fancy Makefile from the internet and updated it to compile all the source files from the relevant directories and link them together into the needed .elf file.
This approaches means that I shouldn't need the CubeIDE for this project. At the worst, I made use it to generate some of the special blackmagic that is needed on some occasions. Hopefully that won't be necessary though
I have yet to really write demo software yet though because of other work.
The first thing I have started working on is SPI because being able to log data to FRAM is crucial. I now have the beginnings of working SPI, I can read the device ID of an FRAM breakout I have. Now that I have worked out some of the issues with my development setup and familiarized myself with ST's LL drivers, the rest should go more quickly.
10/12/2024 - SPI reading and writing working correctly now, lifted code (link in function comment) from an example online to get it negotiating the buffers correctly (both tx, then rx, every access).
Originally tried to port FatFS. Unfortunately FAT requires at least 128 blocks with minimum 512 byte size. This isn't possible on the FRAM I'm going to be using so I had to pivot to littleFS.
I had originally looked into porting littleFS a while ago but something just wouldn't click in my brain with it. Wahtever that was, it's no longer an issue and the port was mostly pain free. Now the boot_count example works so after a little more testing it looks like I'll have filesystem/logging pretty much done.
Now that I have something assembled in a reasonable fashion I can start making sure it works at the hardware level. This stuff is all be tracked as issues so I can check them off when completed and track the steps to fix.
-
First thing I figured out that I did wrong: This SKU only has one comparator. Not the end of the world but a mistake nonetheless.
-
USB DFU does not appear to be working.
-
I got a connection with an ST-Link that appeared to be fully working for a couple of minutes. It stopped working now but I think that's because my connections are a very quick bodge job.
10/11/2024 - I made a quick board revision to clean up a few issues and switch the MCU to a QFN package. The wafer level package has merits but being able to visually verify most of the connections is more important right now.