Timing the flashes, the end for now

A false issue

In our previous post, Vlaya and I said that when a full rotation completion triggers an interrupt simultaneously with a flash interrupt, the order in which the HAL API IRQ Handler checks and handles each source of the interruption (both share the same IRQ line to the processor, and they set flags that the IRQ Handler must inspect to determine what happened) made it so that the rotation was handled first, delaying the flash handling.

To solve this, we decided to check the flags for the flash directly in the rotation callback, and trigger the flash before handling the rotation completion if they were set.… Read more

Timing the flashes, Act 2

Since our last post on Monday, Vlaya and I have been writing code to trigger flashes when the Phyllo is at precise angular positions.

Flashing via SPI

As mentioned here, to flash the LEDs we need to send a SPI frame “FLASH” from the main board to all the led-driving PCBs signaling them to turn their LEDs on right now and for how long.

Checking the timings

On top of sending a SPI frame, we also set the Timer channel we use to trigger the flashes in output mode “Toggle”. Using a Saleae Logic analyzer to  monitor all these outputs allows us to export the precise timings of both the moment the Timer channel is toggled and the moment the SPI frame is sent.… Read more

GDBug and other glitches

Executing our code from flash

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

Random GDB behavior

We just got a new dev board: a Nucleo144 STM32H743ZI. We will use it for all the code which will run on the STM32H743VIT6 processor of the main board.

Before anything else, does anyone know why I keep getting “Program received signal SIGTRAP, Trace/breakpoint trap 0xfffffffe in ?? ()” half of the time after I flash a simple “hello world” program on the STM32H743 and execute it on gdb (using continue) ? The other half of the time it works just fine.

Anyway, back to the article. After carefully memorizing all of the 3289 pages of the reference manual (as would any good ROSE student do), I started coding the module which will send SPI frames to the processor PCBs (see the Software Architecture post).… Read more


Yesterday, Xavier and I went through the STM32F207 documentation to finish preparing the code for the LED-driving processors. As we explained on Thursday, we would like to go bare-metal on this one.

Reminder of the SPI protocol

As Vlaya already explained, the LED configurations are 16-bits frames (8 address bits and 8 data bits)  send by the main board on a SPI bus. By looking at the firsts bits of the frame, the processor determines whether the following 8 bits configuration concerns it (configuration for one of its LEDs or “TOP” to turn on the LEDs) or not. 

  • If so, it retrieves the following 8 bits on the SPI bus and uses it to configure one of its LEDs or start the flash. 
Read more

Catchin’ up with the posts

To hell those marbles

Last friday I mainly worked on getting the new marbles (the ones that hadn’t undergone any heating process) to the desired magnetic field values. Remember, on this post I had already manage to have the marbles we already heated at the desired value. It needed a heating time around 5 min, so I instinctively thought that for marbles that had undergone no heating, it would need a longer time. I was wrong. And not slightly wrong, but more like completely wrong.

So I started heating at 300°C for 6 mins, it was too much and the magnetic field almost completely disappeared (barely noticeable).… Read more

Who am I talking to ?

Today, I came across a problem regarding the information exchange between the STM32 and ESP32 of the main_pcb. What makes the situation a bit special is that not only can the STM32 want to talk to the ESP32, it can also send it information meant for another device. The latter case is about responding to a shell command which must be forwarded through WiFi. Thus the ESP32 here acts a little like a router.

The problem was the following. How can we know if a given byte is meant to be forwarded or not ? As we planned not only an UART connection but also an SPI connection between the STM32 and the STM32, we can use one for each type.… Read more

SPI protocol to light all the LEDs

We started looking into how to implement the SPI communication between the main board and the processor PCBs with Sibille, Xavier and me.

Et each turn of the motor, we need to light up all the 78 RGB LEDs during around 100us at the same time. The motor can spin from 11 RPS to 30 RPS. We have 3 SPI buses leaving the main board, and each SPI bus gets split into at most 5 processor PCB (the top PCB can be counted as processor PCB), and each processor PCB has at most 24 colored LEDs.

SPI frame

Every SPI frame has 16 bits, and we decided to use the first 3 bits as PCB processor addresses, the following 5 bits as colored LED addresses, and the last 8 bits to encode a color.… Read more