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. He found a workaround: if we first set a breakpoint at address 0x08000258, everything works fine afterwards ! It is the address of __main_veener, the linker generated veneer for the jump to the main function in RAM.

A fight against SPI

Last week, we adapted the code for the processor-PCB to the top-PCB 

Today, our team had planned to quickly verify that everything (flash, SPI and timers) was working as a whole for both. This week-end, Sibille made sure the timers were configured correctly and were generating adequate PWM frames. Meanwhile Vlaya and I were having some troubles with the SPI communication : the frames received ont STM32F207 were either totally different or shifted by one bit compared to the frames sent (we observed the signals with the logic analyser during the communication and it was correct). We didn’t have any issue with this code before, and didn’t understand how the fact that the code execution started into the flash could have any influence on the SPI communication.

Vlaya, Sibille and I continue to pull out our hair today on the same bug. It is the kind of bug that could occur if the SPI sender and the receiver have different clock polarity and clock phase configurations, but we made sure we had the same. At the end of a laborious afternoon, we understood that the issue was due to a contact failure on one of the STM32F207 devboard. Once we changed the devboard and all the wires, we eventually could test the LEDs of the top PCB and fortunately, everything works fine :

PCB newscast

After discussion with Alexis, contrary to what we suggested here, we will directly send the 16V from the battery through the ball bearings – after motor tests under an almost-full load, we chose a 5S LiPo battery to be on the safe side. We’ll then have a 16V to 5V switching regulator on the main board to provide the 5V needed by the LEDs.

This week-end, while reading over BouLED posts and schematics, we also anticipated another issue with the ESP32:

As things stand, when we reflash the ESP32 we could put some of the GPIOs connected to the STM32 in high-state while the STM32 isn’t powered. Doing that might damaged the STM32.

To avoid this, Alexis advises us to use a bus switch to protect the STM32.

Next steps

We now have operational firmware for all the led-driving PCB 🙂 

In the coming days, Sibille and I will focus on coding the PID for the bottom PCB and tests it using the hall effect sensor (and potentially the optical sensor too, if we manage to build a viable setup with the breadboard). In parallel, the team will continue to work on the main board software.

Leave a Reply

Your email address will not be published. Required fields are marked *