LSM6DSOX MLC Fails to Initialize - MLC0_SRC always 0x00

[DianaFiuza]

Hi, ST Community, 

I am working with an LSM6DSOX on a custom board, using an ESP32S3 with the Arduino framework, and I'm unable to get the Machine Learning Core (MLC) to run.

The problem is that the output register MLC0_SRC (0x70) always reads 0x00. I am also monitoring the is_mlc_ok status bit in the EMB_FUNC_STATUS register (0x15), and it never gets set to 1. Basic communication (reading WHO_AM_I and raw accelerometer data) works perfectly.

I am not using a library and am writing directly to the registers. My initialization sequence is as follows:

1. Software Reset: Write 0x01 to CTRL3_C (0x12).
2. Wait: A 100ms delay to ensure the reset is complete.
3. Enable Embedded Functions Access: Write 0x80 to FUNC_CFG_ACCESS (0x01).
4. Load UCF Data: Write the entire .ucf file (288 bytes) byte-by-byte by setting the address in MLC_A_ADD (0x02) and writing the data to MLC_B_ADD (0x03). I have verified the data is being written.
5. Disable Embedded Functions Access: Write 0x00 to FUNC_CFG_ACCESS (0x01).
6. Enable MLC: Write 0x10 to EMB_FUNC_EN_A (0x04).
7. Enable Accelerometer: Write 0x20 to CTRL1_XL (0x10) to set the ODR to 26 Hz, which matches the .ucf configuration.

 

Has anyone else had this problem? Is there any command or register write missing that could explain why the MLC is not starting? Or do these symptoms strongly point towards a hardware-level issue?

Thank you for your time.

[Federica Bossi]

Hi @DianaFiuza ,

 

Could you do a software reset and then load the UCF, without any change, and let me know if you still have the issue?

[DianaFiuza]

Hi,

Thanks again for your suggestion.

I implemented exactly the sequence “software reset → load UCF → no extra changes” on my ESP32‑S3 (Arduino, I²C, no libraries), but the MLC still does not start: EMB_FUNC_STATUS stays 0x00 and MLC0_SRC stays 0x00.

 

Code used

Wire.begin(5, 6);

// 2) Software reset
writeReg(0x12, 0x01); // CTRL3_C = 0x01
delay(100);

// 3) Enable embedded access
writeReg(0x01, 0x80); // FUNC_CFG_ACCESS = 0x80

// 4) Load UCF from Unico (Ac XX YY -> (reg,val) array)
load_mlc_config();

// 5) Disable embedded access
writeReg(0x01, 0x00); // FUNC_CFG_ACCESS = 0x00

 

In the loop I only read:

uint8_t emb_status = readReg(0x15); // EMB_FUNC_STATUS
uint8_t mlc0 = readReg(0x70); // MLC0_SRC
uint8_t is_mlc_ok = (emb_status >> 1) & 0x01; // tentative bit position

 

Serial output:

Start
UCF loaded
WHO_AM_I = 0x6C
EMB_FUNC_STATUS = 0x0 is_mlc_ok = 0 MLC0_src=0x0

So even with this minimal flow, is_mlc_ok never becomes 1 and MLC0_SRC is always 0x00.

 

After loading a valid UCF this way, should the MLC start automatically, or is there any additional enable step required outside the UCF?

Is the is_mlc_ok bit indeed in EMB_FUNC_STATUS as I am reading it, or should I check a different bit/register?

Does this behaviour point more to a configuration issue or could it indicate a possible hardware problem?

About my workflow, I currently generate the decision tree in Unico, and then export the .ucf that I send from the ESP32‑S3 with Arduino IDE. Could this conversion chain cause any issue for the MLC startup?

Would you recommend, for debugging, that I instead use DFU mode and only the official ST tools/evaluation environment to load and test the same UCF, to rule out any problem coming from my ESP32‑S3 + Arduino implementation?

Thanks again for your help.