I have added the last few features to the project that I will bring to the career fair. These are the ADC "random" seeding and the five minute RTC delay. I have also figured out a solution for making the board portable.

The ADC seeding feature was not too hard to add. The registers were pretty easy to implement, and the process for getting data from the ADC wasn't bad either. I have followed the advice I heard online and sampled the last bit as it has the most noise and shifted it in to a virtual u256 that is then cast to an array of four u64s used to seed the PRNG. The two difficulties I ran into were a problem with the ADC conversion never finishing and casting the u256 to the [4]u64 array.

The former was caused by me triggering the ADC conversion using a software bit and how doing that interacts with a signal controlling the ADC sampling period. Normally, the ADC will sample for as long as the signal that tells it to start a conversion is asserted. Since I used a software register to start the conversion, the signal was not being asserted for long enough and the conversion never finished, leading to an infinite waiting loop. I had to change a setting in the ADC module to instead wait for a predetermined amount of clock cycles after an input pulse. This fixed the issue.

The next feature I needed to add was the five minute delay before resetting the board and moving on to the next step. I am doing this using the MCU's RTC module and LPM3.5, which is designed for this task. To enter it, you need to prepare the chip to enter by resetting/disabling modules, setting certain registers, and entering a normal sleep mode. Interestingly, you do not enable the global interrupt enable unlike other sleep modes. This feature was harder to add than the ADC. I kept running into lockup issues like I had in the past. I tried things like busy waiting instead of using an interrupt to wait for the display to finish and switching the clock to 2MHz to avoid a potential bug in the MCU itself. I ended up figuring out that it was likely the connection to the debugger itself that was causing the problems, as the code I was working on ran fine once I ran it without a debugger connected.

The next issue I ran into was that the clock source I am using is not the most accurate. Orginally, I had planned to use the dedicated 32kHz crystals on the Launchpads to clock the RTC module. I knew that on the MSP430FR2433 board that the crystal was not connected by default as it shared pins with digital I/O. However, this was also the case for the FR2476 board as well, which I am using for the demo. I could have enabled it by moving the zero ohm resistors over, but I didn't because I did not look to see if I could find some of the heat protection tape and I didn't want to try moving the resistors without the tape over the other components. This leaves the onboard VLO as the only other clock source that works during LPM3.5. According to the datasheet, it should have a 10kHz frequency. In reality, it likely varies based on manufacturing and environmental conditions. I found some values for the RTC counter that get times close to 5 minutes, and set them based on the CPU being built for.

The need to change values based on the CPU being used meant that I had to add a way to get the CPU being used to my code. This would also be useful for fixing another issue that I was running into. In the linker script for the MSP430FR2433, the section for the eUSCI interrupt handler is called __interrupt_vector_usci_b0, while in the linker script for the MSP430FR2476 it is called __interrupt_vector_eusci_b0. In the past I was just changing the value whenever I wanted to build for a different board, but that is a non-solution. I took a look at this example from the Zig website and borrowed it to add pass a variable to my project of the enum type I used to define the CPU types earlier. I then use switch statements to run code or execute values based on this enum.

In addition to finishing up the software part of the project for now, I also have a semi-presentable hardware solution. It's no business card like I had originally planned, but it will be good enough to give employers an idea. I ended up going with the plan of soldering the display connector directly to the MSP430FR2476 Launchpad. This gives me the benefit of having a built in coin cell battery holder.

I will admit that I had a lot of "help" (having it done for me) in actually unsoldering the headers that were already on the board. While I was trying to desolder the headers in UW-Madison's maker lab, I asked someone for help who pointed me to the desoldering irons they had at the lab. I had some success myself with the desoldering iron, but I didn't do a great job and ended up with a lot of semi-filled in through holes. I asked the person from earlier for help, who went to the wood shop and got an older man, likely a professor, who was an expert at this kind of thing. He patiently helped me by doing half of the headers for me. I did learn how to fix the errors I had made previously, so I did learn something. He taught me to remove solder using the desoldering iron that you sometimes have to add solder and flux first to give the desoldering iron enough to work with.

After this, I went over to Formula SAE's shop to do the other half of the headers myself with their equipment. I got started on using the desoldering iron at their shop, when the electrical lead Alex Quilliam saw me and had a better idea. He just got out the hot air gun and blasted the whole bank of header pins while I pulled the header out. This worked pretty well, leaving only two of the header contacts remaining. One was pretty easy to remove. The other was not. It was connected to a ground pin, which, according to the professor, didn't have proper thermal relief. This made it a pain to desolder. On Saturday I spent a lot of time trying to remove the solder from it, but to no avail. Coming to my aid yet again, Alex gave it a shot. It turns out that I was too reluctant to heat up the board. He held the iron on the through hole for a few tens of seconds with solder wick to finally remove it.

I took a header from a pack of JST headers I had ordered from Amazon, not knowing that the eInk came with one included in the box, cut its leads, and soldered them into the Launchpad. I will just glue or tape the e-Ink breakout to the back of the Launchpad and take that.