BQ35100: Inconsistent command behavior to ManufacturerAccessControl

I am just starting to work with the BQ35100 and am trying to get several pieces of data off of the gauge to make sure I can read information correctly.

Some of the data I am trying to get off the device are: device type, operation config A, device name, and control status. I'm programming a host MCU to communicate with the BQ35100 and right now that's the only interface I have with the gauge.

I have a couple of wrapper functions to facilitate the i2c communications:

i2c_wrapper_write(uint8_t address, uint8_t *data, uint8_t data_length, bool send_stop);
i2c_wrapper_read(uint8_t address, uint8_t *data, uint8_t data_length);

Now to grab device type I would do the following (assume some uint16_t called data exists):

i2c_wrapper_write(0x55, {0x3e, 0x01, 0x00}, 3, true); // set MAC command to 0x0001
i2c_wrapper_write(0x55, {0x40}, 1, false); // Set address to MACData
i2c_wrapper_read(0x55, (uint8_t*)&data, 2); // Read back into data variable

data now correctly has 0x100.

Next for operation config A I would do the following:

i2c_wrapper_write(0x55, {0x3e, 0xb1, 0x41}, 3, true); // Set command to operation config A
i2c_wrapper_write(0x55, {0x40}, 1, false); // Set address to MACData
i2c_wrapper_read(0x55, &cfg, 1); // Read data into cfg variable

cfg now strangely has 0xf3. I see that the default value for 0x41b2 (alert config) is 0xf3 so I assume its reading that?

Instead I now have to issue another write/read to 0x40 to get 0x80 (expected default config).

Similarly to get the device name (expected bq35100) I would do the following:

i2c_wrapper_write(0x55, {0x3e, 0x60, 0x40}, 3, true); // Set command to get device name
i2c_wrapper_write(0x55, {0x40}, 1, false); // Set address to MACData
i2c_wrapper_read(0x55, &name, 7); // Expect 7 chars for bq35100

Now this correctly populates name with: {0x62, 0x71, 0x33, 0x35, 0x31, 0x30, 0x30} (bq35100 in ascii).

However, if I try the same procedure that I did for the operation config A (issuing another write/read to 0x40) name instead now has {0x07, 0x62, 0x71, 0x33, 0x35, 0x31, 0x30}. I would need to do an 8 byte read to get the last ASCII "0". I am not sure why the first byte is now suddenly 0x07.

Finally to get control status I do the following:

i2c_wrapper_write(0x55, {0x00}, 1, true); // set address to control
i2c_wrapper_read(0x55, (uint8_t*)&status, 2); // read back register data

This gives me back 0x2080 which should be expected (INITCOMP set and security mode in FULL ACCESS).
I would also expect to be able to do the following to grab control status:

i2c_wrapper_write(0x55, {0x3e, 0x00, 0x00}, 3, true); // Set command to get control status
i2c_wrapper_write(0x55, {0x40}, 1, false); // Set address to MACData
i2c_wrapper_read(0x55, (uint8_t*)&status, 2);

I'm basically sending the 0x0000 command to MAC and then reading the data from MACData. This instead populates status with 0xf340 and I'm not sure where that comes from. Doing a reread doesn't change much.

I've also tried reading more bytes, starting from 0x3e to be able to verify the command (2 bytes should give me the active command) but it is also inconsistent between commands.

As an example for operation config A:

i2c_wrapper_write(0x55, {0x3e, 0b1, 0x41}, 3, true); // set command to op config a
i2c_wrapper_write(0x55, {0x3e}, 1, false); // set addr to MAC (to be able to read back command)
i2c_wrapper_read(0x55, (uint8_t*)&cmd, 2); // expect 0x41b1 (actually getting 0x09f3)
i2c_wrapper_write(0x55, {0x3e}, 1, false); // set addr to MAC (to be able to read back command)
i2c_wrapper_read(0x55, (uint8_t*)&cmd, 2); // expect 0x41b1 (now correctly getting 0x41b1)

I've been using the following 3 docs in my development: i2c reference, technical reference, data sheet.

Could I get some clarification around what's expected behavior regarding these commands (and others).