On this new episode of the Mainboard update, nothing too exciting. Alexis did the final touches on the PCB, made the silkscreen and we should be good to go. Only thing left to do was create the Bill Of Material. I had to fill up a spreadsheet with the components, distributor and number of unit in stock to check whether they would be available when needed.
Some errors were found as well as some components that weren’t distributed anymore but nothing major.
We now can focus on the other PCBs and get them ready as well.
The issue that can prove quite difficult is that due to health and safety concerns with the spread of the corona virus, PCB manufacturing has been halted in China and Europpean manufacturers therefore have massive delays.… Read more
We are still waiting for our test PCB, so on Monday I create a HAL file with STM32CubeMX for the test PCB, merge it with Ilan’s code and I will wait that we receive the PCB to check if the merge was ok or not.
Today I’m in Telecom, so I will try to finish the box (I did not have a plastic plank last time) and to begin the box for the final devices.
Last week Sibille and I moved our bare-metal code for the processor-PCB (which so far was directly inserted in RAM by the GDB debugger) into the Flash memory proper, and wrote code that will execute from Flash to copy everything in RAM and continue execution from there.
However, we soon noticed a strange bug: the GDB debugger now ignored every breakpoint we tried to set in RAM (breakpoints to parts of the code executed in Flash before the copy to RAM still worked fine). After a lengthy debug session, Alexis determine that it‘s a bug from the GDB debugger and not from our code.… Read more
As I wrote in my previous posts, the ESP, the STM and the server were working together to receive images or animations depending of what the user wants. Now it’s time for the STM to become the sender.
We want the devices to be able to received images from the server but we also want to establish a connection between Touchs to send images from one to the other. On top of that at the end we want to have a communication between both devices in both ways. But as you may know chi va piano va sano. So first things firts, we implemented the emitting part for the first device.… Read more
On the Aries MCV, the MMC pins of the HPS are already used to control the MMC flash. However, we need an SD card. So, we decided to add a µSD card on the SPI1 interface because SD cards can be controlled in SPI. So, I added the µSD card to the SPI1 interface like this:
Before testing on the MCV, we realize tests on the DE1-SoC. Something to notice, we already built the Linux kernel for the DE1-SoC and it booted correctly without the SD card on the SPI interface.… Read more
Yesterday evening, the whole groupe work together to test the power transmission through the ball bearings. Those tests are significant to determine if we need to add a 5V-regulator on the main board, and which regulator we choose for the bottom PCB to account for the tension drop.
On Wednesday, I finished the PCB. I used one trick that found Alexis on our test PCB. We have two VCC, one for the coils and the other for all the other components. So, I create a two-parts plan. The VCC is in green and the VCC_COIL is in yellow.
I also have to route all the components. I found a way to make the routing easier, by enforcing a simple rule. When the route is horizontal, it must be on the top face, and when it is vertical, it must be on the bottom face. I also have to change the pins of the multiplexers in order to route them easily.… Read more
Today, Sibille and I ran the final tests for the led-driving PCBs software using Vlaya’s SPI generation code. We wanted to make sure that if the main board sends an entire SPI frame (24 LED configuration instructions and a “TOP” command), the CPU managed to configure all the LEDs and turn them on. It does 🙂
On the nucleo devboard, we can observe 20 out of 24 timers. Have a look at the outputs we measured with the logic analyser :