Here’s the build log for week ten of development for the open source function generator I’m trying to prototype and build.

Do you want to try one out? Head over to this page to get the download.

Each day’s entry represents an hour’s work per day - the hour before I leave for my job every weekday morning. (This is more accurately described now as “the hour before I start working on my real job every day” given the coronavirus lockdown situation.)

This is my log for the week ending April 10, 2020. Here’s links to the prior weeks’ logs:

The design doc for this project is available if you’re into design documents/philosophy.

All of my hardware and software source files are on GitHub. Check ‘em out!

April 10, 2020

Starting to dive into DFU boot loader Watching some training videos: https://www.youtube.com/watch?v=Kx7yWVi8kbU Download/install desktop software DFuSe (Windows) dfu-util (Linux) Create a .dfu file from a .hex file Included in the Dfuse download Connect STM32 to USB Connect the BOOT0 pin to VDD on the board to enable bootloader Reset the board Choose .dfu file in DfUsE programmer - hit “program” Disconnect BOOT0 from VDD; reset the board New program will be running after board is reset Following this guide and using Adafruit’s DFU guide seems to work just fine! https://learn.adafruit.com/adafruit-stm32f405-feather-express/dfu-bootloader-details This is as easy on Mac as using dfu-util (install it with Homebrew!) and calling: dfu-util -a 0 --dfuse-address 0x08000000 -D firmware.bin I was able to re-flash the firmware on a bFunc board - want to try it with an image that sets some default setting that I can check externally A blinking LED would be ideal but unfortunately I didn’t include this particular hardware line item on this board. (D’OH!!) Also want to figure out a way to do this entirely from SW. Designing a little external circuit to re-strap the BOOT0 pin sounds fun, but also challenging to perfect, and costs money. A SW reset into a boot loader mode would be ideal! This is a great description of a reset into the STM32 ROM bootloader: https://stackoverflow.com/a/36793779



April 9, 2020

GitHub Issue John Turner (@whinis) is seeing some sync issues. These appear to be a consequence of operating at a frequency that is close to the limits of what the bFunc board is capable of providing. It also appears to be a consequence of a lot of harmonic overtone junk that is making its way out of the signal generator. This looks like a job for - a 7th order elliptic lowpass filter!!

Dammit, my personal eval board decided to stop working!! I tried plugging it into my Mac this morning to get a reading of the harmonic content, and it won’t appear as a USB endpoint on my Mac. Does this when I plug it into a Windows machine. What’s going on here?!?!

Brainwave: maybe it’s the timer interrupt See if disabling the timer interrupt helps - rebuild with HAL_TIM_Base_Start_IT() commented out and see if the device is able to enumerate That was the problem - the chip was getting so spammed with timer interrupts that it couldn’t enumerate USB.



April 8, 2020

Can we at least start the timer interrupt firing? Turns out - yes! Tried to do this manually, but didn’t have an example to follow. There aren’t any interrupts in the code so far! So, instead, it’s back to STCubeMX. But even this had some missing pieces. Turns out I was missing the call to HAL_TIM_Base_Start_IT() - now I can see a nice toggling IO! The timing is a little different than I expected, however. Originally getting a 50kHz square wave out of the GPIOC_13. Reducing the timer set value by an order of magnitude only doubled the interrupt frequency, instead of increasing it 10x. Guessing that it’s trading off against other routines in the system.

Next step: generate a 1kHz sawtooth ramp! Use the state transitions from the timer to switch between phase0 and phase1



April 7, 2020

Finished the buildID feature! All we needed was a quick sprintf() to get integer into hex format for sending along the USB pipe. I did realize something interesting - there’s a small discrepancy between the build ID reported by arm-none-eabi-readelf and the one printed out from the build ID function on board. It seems like the arm-none-eabi-readelf command is missing a zero pad.

to get integer into hex format for sending along the USB pipe. Cleaned up git caching so that *.lst files aren’t tracked by git This should get me teed up to implement some proper version tracking in line with the Embedded Artistry post I mentioned yesterday. This StackOverflow post was most helpful in clearing that up.

files aren’t tracked by git I got my first bug filed!

Now, back to sawtooth waves After a bit of research it seems like the right way to do this is to call HAL_TIM_Base_Start_IT() when the sawtooth wave gets started. A nice first run of this would just be entering sawtooth mode and having it start toggling an LED IO and confirming the correct frequency. Also requires a call to HAL_TIM_Base_Stop_IT() when exiting sawtooth mode.



April 6, 2020

Very excited to be heading into Week 10 of bFunc development!

Started out trying to implement the scheme listed in the Embedded Artistry This turned into a lot deeper exercise than I anticipated In particular it includes a lot of trying to figure out what all of the git tag flags used meant. That, in turn, inspired a bunch of .gitignore edits coupled with git cache edits to make sure it removed all of the unnecessary .lst files from getting pushed into my git repo from git tag -a -f -m .

After I realized I spent about a half hour doing that, and not writing code, I switched gears implementing the build ID strings as guided by the Memfault blog The makefile and linker script edits went down super smoothly Converting a uint8_t intto a readable string is apparently something it is too early in the morning for me to reliably execute.



April 5, 2020