Dear NXP engineers and community experts,
I am currently developing with the MFS2323BMBA5EP Safety SBC and have encountered a significant conflict between my configuration files and datasheet reports regarding the OTP factory configuration. I would greatly appreciate your expertise in clarifying this.
The Configuration Conflict:
1. Evidence from the .cfg file:
In my FS2320_BA5_CONFIG_Rev_A.cfg file, there is a direct register value:
0x30 : 0x00
According to the FS23 datasheet (Table 229, OTP_MAIN_SYS_I2C_CFGBit 4 (SPI_EN_OTP): 0 means I2C is enabled, SPI is disabled; 1 means SPI is enabled.
Bit 3~0 (I2CDEVADDR_OTP): 0000 means the I2C slave address is 0x20.
This clearly suggests the chip is factory-configured for I2C mode.
2. Evidence from the Configuration Report PDF:
However, in my R_MFS2323BMBA5_Rev_A_test.pdf document, under Table 2. Device OTP configuration, the report explicitly states:
SPI Enable: SPI pins are enabled.
This suggests the hardware pins are locked to SPI mode.
My Actual Hardware Test Results:
When I configured my MCU (S32K344) as an SPI Master to communicate with this PMIC:
The MISO pin stays at a constant 0.3V (indicating high-impedance with internal weak pull-down, meaning the slave is not driving the line).
The SCK pin on the PMIC side was actually outputting clock signals on its own.
I suspect the chip might be locked in OTP Emulation mode or configured as an I2C slave, which is causing the SPI communication to completely fail.
My Specific Questions:
Could you please confirm the actual factory OTP configuration for the MFS2323BMBA5EP? Is it SPI or I2C?
When there is a conflict between the .cfg register file (0x30 : 0x00) and the PDF configuration report, which one should be considered the absolute hardware truth? Is there a possibility that the PDF report contains a documentation error?
(I have attached the FS2320_BA5_CONFIG_Rev_A.cfg and the R_MFS2323BMBA5_Rev_A_test.pdf to this post for reference).
Thank you in advance for your help!
Which company are you from? Currently, you're using your own email address, which is considered a low-priority (C-level) customer.
This requires checking your schematic and a series of things related to the CRC driver.
I suggest you submit a ticket using your company email address.
Currently, it's not possible. I'm communicating in DEBUG mode. I've tested the SCK and MOSI waveforms on the 344 pin separately, and they can transmit the data I write. However, because the FS23's SCK pin is also sending a signal, when these two are connected together, the SCK signal sent by the MCU is pulled low by the FS23. The responses I send to the FS23 are all 0s. I've also configured CRC.
The purple line represents the SCK signal after the top.
Yellow indicates data signals.
The scale is 5V.
The data sent is {0x02, 0x00, 0x00, CRC}
If you forcefully interpret the SCK waveform as a normal waveform, you can see that the data is correct; the first bit is 2, followed by 00 and CRC.
Can you successfully communicate using SPI?
I uploaded the .cfg file to Mirror via the GUI. The register indicates SPI mode.