# How to compile the FW16 EC from open source code **URL:** \ **Category:** Linux\ **Tags:** ubuntu\ **Created:** [May 3, 2026, 3:14pm UTC](https://community.frame.work/t/how-to-compile-the-fw16-ec-from-open-source-code/82342 "2026-05-03T15:14:59Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![James3](https://avatars.discourse-cdn.com/v4/letter/j/b5e925/32.png) [@James3](https://community.frame.work/u/James3)\ **Post date:** [May 6, 2026, 6:51pm UTC](https://community.frame.work/t/how-to-compile-the-fw16-ec-from-open-source-code/82342/2 "2026-05-06T18:51:08Z")
Well, I have tracked down and fixed another EC bug. > > > It turns out that splitting the i2c into multiple i2c\_transfer messages is unrel…iable. > Where possible, gather them up into a single i2c\_transfer containing multiple struct i2c\_msg msg\[\] > This is more reliable. > > Signed-off-by: James Courtier-Dutton \ > > > This makes i2c sb\_rmi\_mailbox\_xfer comms more reliable. > > Signed-off-by: James Co…urtier-Dutton \ It was a really difficult one to track down. The initial symptom was that in some rare cases, the power adapter plug/unplug would not be detected. Investigating that, resulted in seeing that the Make/Model names/strings being read from the smart battery were missing characters. This led to the wrong battery profile being used, that then led to AC on/off state transitions not working. So, this was the first hint that something was not right with the I2C transfers. The EC i2c\_transfer() transactions were unreliable. This resulting in, for example, the symptom of the UCSI PPM\_RESET failing and other odd behavior. Its a guess, but it might also be causing some of the stuck in 544 Mhz problems. The reason it was so difficult to track down is because some transactions worked and some did not. They just silently fail. No indication of failed transaction. The problematic ones were the block writes. The write was happening, but the cypd USB PD chip was not seeing the transaction. I had to then go looking for something on the cypd USB PD chip i2c that I could use as a scratchpad. I could write to it, and then read it back to see if the write worked. There is no documentation on the cypd USB PD chip api, but I eventually found a scratchpad, and then a solution, as one can see from the patch linked to above. The problem turned out to be split i2c\_transfer(). If one does half the transaction in one call to i2c\_transfer() with START set, and then the second half of the transaction in another call to i2c\_transfer() with STOP set. It is unreliable. Putting both parts into i2c\_msg msg[] and then doing a single i2c\_transfer() is 100% reliable. It also seems to mainly be a problem associated with i2c writes. It seems that doing i2c reads, and splitting them across i2c\_transfer() does not cause so many problems. I think if the EC needs to do more reliable i2c transactions writes. It should also do a i2c transaction read, to double check that the data sent, arrived OK at the destination. The I2C ACKs are supposed to help with making i2c more reliable, but it appears the EC code has no way, currently, of detecting the errors. There might be a i2c\_transfer() callback, that may exist, but is not currently being used. Here is another i2c function that I have fixed. It had the same problem of spliting the START and STOP i2c\_transfer(). ```auto static int platform_ec_i2c_write(const int port, const uint16_t addr_flags, const uint8_t *out, int out_size) ``` This function is used to update the EC → APU/CPU with the new PMF settings. e.g. “PMF: SPL 45000mW, sPPT 54000mW, fPPT 65000mW, p3T 227000mW, ao\_sppt 0mW” If it fails, it will result in the settings not being successfully sent to the APU. This is separate from APU SMU hang problems, that are caused by problems on the APU side. --- _[View the full topic](https://community.frame.work/t/how-to-compile-the-fw16-ec-from-open-source-code/82342)._