clang-17, lto and aggressive optimisations

Lately, i updated lnDSO150 to v2.3, in particular its build system to be in sync with how i do things nowadays.

The main goal is to easily switch between GCC and CLANG-17 (  arm or riscv )

The lnDSO150 has one variant (the FNIRSI one) with less flash ( only 64 kB), so i could use every flash gain possible

Using clang + lto DID provide a nice size reduction (final size was ~ 50 kB for the fnirsi build) and at first it seemed to work alright.

At first.


Then, i realized that it made some underlying problem appear due its aggressive optimization.

In other words, the bugs were there since day one, but hidden because the software was losing the race against the hardware every time.


A couple of examples :

- On the DSO150, some of the screen GPIO are reprogrammed as input to scan if  buttons have been pressed. If you flip the gpio too quickly, the button MAY keep the last state it was when used as output, causing random fake key pressed. Adding a couple of nops fixed the issue.

- Similarly, the flash driver was racing against the flash hw. Adding a couple of nops fixed the issue, probably not the right fix.


It is human to first assume clang+lto is a buggy compiler. That's not the case, it was buggy code.





Comments

Post a Comment

Popular posts from this blog

Component tester with STM32 : Part 1 ADC, Resistor

Image
I was always  fascinated by the so call "transistor testers" that identify and report pin out, features of pretty much whatever you throw at it. They are based on Atmel 328p chip, the same as arduino nano. So why not do the same thing with a STM32/Bluepill ? The STM32 is faster, has a better ADC accuracy, more memory, can do float etc... and is not more expensive. Warning : I'm doing this for fun & to learn, it might contain error & plain misunderstanding So, i watched a couple of video on the general principle on how they work. This is not a "port" but a rewrite from ~ scratch. When something is weird, i check what the original one does for comparison. Measuring resistance So first thing first :  Resistance & Capacitance. These 2 will unlock the other ones. So how do we measure resistance ? What we do is a resistor divider with a know resistance value: Measure = Vcc*(RtoTest/(RtoTest+Rknown)) As far as the ADC goes, it means ADC=...
Read more

Fixing the INA3221

Image
It 's not too complicated to change the board we have seen  previously . You 'll need to cut some tracks, i did it with a dremel and i'm not very handy, so you'll do better. Red =Cut tracks Blue = Add wire 1- You'll need to separate the bottom connector from the ground, cut the 3 connectors BOTH SIDES. 2- Remove the small red area below the middle resistor to isolate each channels from each other Last, connect right side of each connector to the now isolated pad. Mine looks like this after the operation (ugly i know): Be wary of the small track on the left connector that leads to the left side of channel3 resistor. I cut it while isolating the right pad. Now it works, we can go back to the charger.
Read more

INA3221, weird wiring

Image
Continuing my "smart" battery charger, i've finally received the INA3221 module. It is the purple one you can find on ebay for ~ 5 bucks I soldered a couple of pins to be able to connect it so that i could test it and something immediately caught my attention. It is supposed to be a high side current/voltage sensor, typically in a setup like that : So you can measure the voltage supplied to the load, and the current going through it. Now, let's have a look at the module, look at the top of the following pic, where the sense connectors are. CH3/GND/CH2/GND/CH1/GND ? Wait ? What ? Yes, all the IN- pins are connected to ground, so it is a bottom current only sensor. Additionally, the - side of the shunts are ALSO connected to the ground, no only the connectors. The actual layout is like that : That raises two problems :  The voltage is meaningless as we are only measuring Current x ShuntValue, not the supply volt...
Read more