Update July 2017: Dead-ends but Progress!

It’s been a crazy month. I was on “vacation” and also trying to work and I didn’t get much work done. But when I have been able to get work done, I have made good progress. So far, the migration from the Arduino/Atmel ecosystem to STM32 has gone really really well and is pretty much complete. I’ve written libraries to use almost all the peripherals that I need and confirmed that they do work as intended (at least independently). So far, I have written libraries¬† and verified correct operations for: DMA controller, GPIO, EXTI Interrupts, SPI, I2C, Timers, UART, and ADC. All I have left is the USB.

Back in April/May, I did some calculations for how much memory I would need given the new features I wanted to implement. At the time, I came up with 2 GB of memory so I looked towards SD cards as an option. I have been working on writing a library for the SD card interface using the FatFs by Elm-chan and writing my own SPI procedures since then. I was able to write a working initialization sequence and even handle the command-response handshake for reading data from the card, but writing data has proven far more difficult. I’ve gotten myself to a place where brute force debugging is becoming tedious. The two cards that I have are becoming non-responsive after I upload some code and debug to check the procedure is working. After one attempt, the card either stops responding or responds with 0x00 for infinity. Both cards now require a power down reset in order to try again. This caused me to re-evaluate the memory calculations I had done months ago. I don’t even have the paper where I did the calculations anymore (bad mistake!) but when I re-did the calculations late last week, it turned out that I needed closer to 640 KB than 2 GB. I wish I had the paper to see what happened… But, anyways, once I realized that I didn’t need the SD card as a storage medium and went back to the I2C EEPROM that I already know how to use (just upgrading the EEPROM from 32K/chip to 1 Mb/chip.

I also had quite a scare a few days ago while I was double checking that my encoder library was working correctly. I initialized some free pins as GPIO inputs with external interrupts but for some reason it was not working correctly. I started debugging the code found a bug in my GPIO library. When I set the GPIO mode, I was using a bitwise-OR to change the bits, and if that GPIO pin was previously something else, the mode would not update to input “00”. I was trying to use these pins that were configured as outputs. I thought, “that’s weird, I wonder why those pins are configured like that when I didn’t configure them. Oh well.” and went ahead and wrote the code to change the pin modes to INPUT. I started debugging and immediately OpenOCD crashed and gave me an error “signal 0: received a 0”. I have no idea what this means and can’t find much online so I ignore it, comment out the code. and try again to make sure the code is what caused the problem. I start up the debugger again and OpenOCD immediately crashes. Oh no. Alarms are starting to go off, this isn’t good. I open up the ST-LINK utility used to interact with the dev board… “Cannot connect”…. oh no. Now I can’t even talk to my board??? This isn’t good. I’m thinking it must be a USB thing because that was a major pain in the butt just to get it working the first time. I open up my USB driver tool and change the USB driver. Now, its even more broken than before. I panic. I uninstall the ST-LINK utility and re-install. Nothing. I can’t even install the required updates. All I get is the circular logic of “Please connect board” -> “Cannot connect to board”. Now I am in full blown emergency mode as everything has fallen apart and I’ve wasted a whole day on this. I turn to my last best hope: the system restore. After the system restore, I try again and at least this time, I can upload a hello world program to my board Thats good! But trying to run the RN-9090 code causes the board to brick. At least now I can “reset” the board by uploading the hello world program. Finally, I figure out that the reason the board gets bricked with the debugger is that I am trying to change the pins that are being used by the JTAG debugging! So, once I realized those pins are off-limits, everything got back on track. It was quite a lesson though. I panicked and made things 10x worse and instead I should have stepped away and thought about it clearly instead of just diving into a “solution”.

So, with all the peripherals confirmed to be working. I’ve started integrating everything together and begun design on the PCBs for the prototype. I will have three PCBs. One for the main board that has all the logic circuitry, one for the encoders, and one for the potentiometers. I have already finished designs for the encoders and pots boards and am about 75% complete on the main board PCB. I’m always a bit weary about submitting a PCB order for manufacturing as I want to get everything right, so I probably won’t be ordering the PCBs just yet. But they are ready… I hope to be ready to put the order in for manufacturing by the end of next week once I have triple checked the schematics and layouts.

Once the boards arrive, I will complete the migration and begin full on prototype debugging. And once, that’s done, I will be ready to do a small run of prototypes.

I will be back soon with more updates!