Limit od evaluation board MEZS7-SharedPowerBank

We have now started testing the MEZS7-SharedPowerBank with our 1S pouch cell and, overall, the system is progressing. However, during the latest bench tests we observed two points on which we would appreciate your support.

The first one concerns the charging current.
The pouch cell was approximately at 50% state of charge and its voltage was well above the pre-charge region. We used a 5 V external power supply.
With the board at its default settings, the input current limit is set to 500 mA and the fast charge current to 1000 mA. Nevertheless, the current drawn from the 5 V source remains around 0.10 A, with a maximum of approximately 0.15 A.
The current actually delivered to the pouch is only slightly higher, as expected due to the voltage conversion, but therefore still far below the programmed 1 A charge current.

Could you please advise what could be limiting the charging current in this condition?

In particular, we would like to understand whether this behaviour could be related to the input source detection / D+ and D- interface, VIN regulation, input current regulation, NTC/JEITA conditions, or any other internal limiting loop.

If using a laboratory power supply, is it preferable to connect the 5 V source directly to VIN/GND rather than through the micro-USB input? Also, is there a specific status/register that we should monitor in order to identify which control loop is actually limiting the current?

The second point concerns GUI programming.
When we change one of the charging parameters in the left-hand section of the MP2696A GUI, after approximately one second the displayed value returns to the original/default value.
We would therefore like to confirm the correct programming sequence.
Does changing a value in the GUI only modify the local GUI field until “Write All” is executed? Could the “Auto Monitor Register” function be reading the registers back every second and therefore restoring the displayed value?

We would also like to understand whether the onboard MCU can rewrite the MP2696A registers with its default configuration.
For direct control through the USB-to-I2C interface, should JP2 and JP3 both remain removed in order to prevent any interaction from the onboard MCU?
On our side we have already successfully established the I2C connection and verified basic register read/write operation, so we would mainly like to understand the correct operating procedure and the reason for the low charging current observed during the actual charging test.
The 5 V power supply was connected directly to VIN (TP3) and GND (TP4), not through the micro-USB connector.
The battery voltage was approximately 3.7 V, therefore well above the expected pre-charge region.
Under these conditions, the measured charging current remained approximately 0.15 A.
As an additional check, we repeated the test using a higher-power laboratory supply, although the previous supply was already sufficiently rated. The result remained essentially unchanged, with the charging current still around 0.1–0.15 A.
Regarding I2C control, JP2 and JP3 were removed before tests and have remained removed during all the tests, according to the EV board instructions.
For this reason, we believe the next useful step would be to understand which internal control condition is actually limiting the charging current.
One point that caught our attention is that approximately 150 mA is also the default pre-charge current value. Since the battery voltage is around 3.7 V, could you please confirm whether there is any condition that could keep the MP2696A in pre-charge mode even at this battery voltage?
Could you please indicate which registers/status bits we should monitor to determine whether the device is operating in:
pre-charge mode,
fast-charge mode,
input current regulation,
input voltage regulation,
NTC/JEITA limitation,
or any other current-limiting condition?
If useful, we can provide screenshots of the GUI status during the test and measured VIN/BATT values directly at the board test points.
Regarding the second issue, the GUI parameters returning to their previous values after approximately one second, JP2 and JP3 are already removed. Could you please clarify whether changing a value in the GUI must always be followed by “Write All”, and whether any automatic register refresh/readback can overwrite the value displayed in the GUI?
We would appreciate your guidance on the next diagnostic step, as the basic setup checks have already been completed.