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
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
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
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
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.
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