CY8CMBR3110 lost configuration

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
GiPe_4640606
Level 1
Level 1

Dear all,

we had problems with some board that mount the device in the object. The boards work as touch panels on a coffee machine. The problem was that the touch panels don't work because all the capacities read by the device were 0 (tested with Ez_Click). Appling again the configuration file with Ez_Click on the board solve the problem. It seem that the device lost the configuration. Is there a way to investigate what's happen on this device? Could you suggest us somenthing to do to understand the possible cause?

Thanks

Best regards

Gianni Perugini

0 Likes
1 Solution

Hi GiPe_4640606​,

MBR3 device never writes to the CONFIG_CRC register. This register is always written by the host (i2c master). The host (EzClick/ host controller) calculates the CRC for the first 126 bytes of config data and writes to the CONFIG_CRC register.

MBR3 uses the CONFIG_CRC register to validate the integrity of the register map. Only if the two bytes in the CONFIG_CRC matches with the CRC calculated by MBR3 for the first 126 bytes of config data, the MBR3 writes this data to the Non volatile memory. Otherwise, it load the previous valid register map or the factory default values.

Therefore, I suspect that the issue is with the configuration data itself initially written to MBR3 and not with MBR3. Since the CRC of the incorrect config data matches with CONFIG_CRC, this has come from an external master(EzClick).

Please note that we do not recommend EzClick for production programming. We recommend using a third-party programmer from RPM Systems Corporation. To configure the CY8CMBR3xxx controller using the third-party programmer, use the hex file of the configuration generated by EZ-Click. Contact RPM Systems Corporation for further information.

If possible, kindly recheck the initial configuration written by the EZCLICK software.

Regards,

Bragadeesh

Regards,
Bragadeesh

View solution in original post

0 Likes
9 Replies
VenkataD_41
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi Gianni,

Yes. You can debug the project.

1. First of all please ensure that the project doesn't have any coniguration issues. You can test the project on the development kit and confirm if it is wroking. If possible, please attach the Ez-Click project to the case.

2. There may a short circuit in the CapSense sensor buttons with VDD or ground. You can check the design files once. If possible, please attach the schematic and gerbers of the MBR3 section.

3. If the Miniprog 3 is accessible from the Coffe machine you can connect it to the I2C serial port and check the raw counts of sensors as well as the Short circuit test from the Ez-Click GUI.

4. Please also note that the sensors will not work if the self capacitance exceeds more than 45pF. You can find this information also in Ez-Click user guide. Please go through Ez-Click user guide from the link below:

https://www.cypress.com/system/files/document/files/EZ-Click%20User%20Guide_001-90407_C_0.pdf

Thanks

Ganesh

0 Likes
GiPe_4640606
Level 1
Level 1

Hi Ganesh,

many thanks for your reply.

We read the configuration registers using the host board and we found that the SENSOR_EN register was 0. Now the question is: How is it possible that the register changes to 0? Our touch panel has 4 buttons and 4 leds (2 leds are driven by CY8CMBR...).

Our host board send periodically (in the main loop) the GPO_OUTPUT_STATE to change the led status.

Note that if we read the configuration registers with host board on a new touch panel board the SENSOR_EN register is set correctly.

How can attach the configuration file?

Waiting for your kind reply,

Thanks

Best regards

Gianni Perugini

0 Likes
GiPe_4640606
Level 1
Level 1

Dear Ganesh,

you can find the configuration file from the link below:

https://we.tl/t-3a0s52WPA6

Thanks

br

Gianni Perugini

0 Likes

Hi GiPe_4640606​,

1. The CY8CMBR3xxx devices feature a safe register map update mechanism to overcome configuration data corruption, which can occur due to power failure during execution of "Save" command or any other spurious events. If the configuration data is corrupted when the device is saving data, on the next reset, the devices reconfigure themselves to the last known valid configuration. If there is no valid configuration saved by user, the devices load the factory default configuration as specified in Register TRM.

2. Check for SYSTEM_STATUS register (0x8a). This indicates whether factory default configuration is loaded or some other configuration is loaded.

3. Compare the factory default values provided in the device TRM and check whether it is matching with the configuration values in the "not working" devices.

4. Sensors are disabled from scanning if any of the system diagnostic tests fails. Ensure that none of the tests are failing.

pastedImage_12.png

5. System diagnostics can be enabled using DEVICE_CFG1 register (0x4e)

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes

Dear BragadeeshV_41,

we check the SYSTEM_STATUS register that is 0. The DEVICE_CFG1 register is 1 and all other registers (total_working_sns, sns_cp_high, ...) are 0. Only the SENSOR_EN register is set to 0 while we programmed to 1000010011.

Could you suggest us somenthing else to understand what's happens?

Waiting for your kind reply,

Thanks

Best regards

Gianni Perugini

0 Likes

Dear BragadeeshV_41,

we made a deep investigation on configuration registers. We read all the configuration registers on the failed touch panel. We found that in addition to SENSOR_EN, others registers like TOGGLE_EN, LED_ON_EN and the CRC are different from loaded configuration.

Have you got some more suggestion?

Thanks in advance

Best regards

Gianni Perugini

0 Likes

Hi GiPe_4640606​,

Can you ensure that there wasn't any corruption while you are loading the configuration such as power failure or i2c noise issues?

How was the issue recovered? Did a power cycle help?

Did you try re configuring the device in field itself from the host instead of ezClick? Or how are the devices initially configured?

Were you able to identify any steps to reproduce this issue across other kits?

Can you read all the 126 bytes of configuration register and compare with the registers that you have configured. You had mentioned that CRC is also incorrect. Can you calculate the new CRC for the error config registers and check if they match.

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes

Dear Bragadeesh,

below you will find all the answers to your questions:

>Can you ensure that there wasn't any corruption while you are loading the configuration such as power failure or i2c noise issues?

Each touch panel has been programmed using Ez_Click. After that each assembly coffee machine has been tested. So if the touch panel didn't work the production operator noticed it.

>How was the issue recovered? Did a power cycle help?

We received 2 coffee machines (from our customer) with the same configuration changed issue (the configuration register was not the same for the 2 panels).

One touch panel has been re-programmed using Ez_Click and now it is working well again. The other has not been yet re-programmed to avoid to loose the issue.

>Did you try re configuring the device in field itself from the host instead of ezClick? 

Not yet. I've just finished to write the function on host device to check the configuration and re-program the cypress device.

>Or how are the devices initially configured?

This is the original configuration:

const unsigned char CY8CMBR3110_configuration[128] = {

    0x13u, 0x02u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u,

    0x00u, 0x00u, 0x00u, 0x00u, 0x80u, 0x80u, 0x7Fu, 0x7Fu,

    0x80u, 0x7Fu, 0x7Fu, 0x7Fu, 0x7Fu, 0x80u, 0x00u, 0x00u,

    0x00u, 0x00u, 0x00u, 0x00u, 0x03u, 0x00u, 0x00u, 0x00u,

    0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x80u,

    0x05u, 0x00u, 0x00u, 0x02u, 0x00u, 0x02u, 0x00u, 0x00u,

    0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x1Eu, 0x1Eu, 0x00u,

    0x00u, 0x1Eu, 0x1Eu, 0x00u, 0x00u, 0x00u, 0x01u, 0x01u,

    0x01u, 0xFFu, 0xFFu, 0xFFu, 0xFFu, 0xFFu, 0x00u, 0x00u,

    0x00u, 0x00u, 0x00u, 0x00u, 0x11u, 0x03u, 0x01u, 0x48u,

    0x00u, 0x37u, 0x01u, 0x00u, 0x00u, 0x0Au, 0x00u, 0x00u,

    0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u,

    0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u,

    0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u,

    0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u,

    0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x00u, 0x41u, 0xADu

};

>Were you able to identify any steps to reproduce this issue across other kits?

Not yet

>Can you read all the 126 bytes of configuration register and compare with the registers that you have configured. You had mentioned that CRC is also incorrect. Can you calculate the new CRC for the error config registers and check if they match.

This is the configuration read on the fail device.

    0x00 0x00 0x00 0x00 0x05 0x01 0x6E 0xAA

    0x00 0x00 0x00 0x00 0x80 0x80 0x7F 0x7F

    0x80 0x7F 0x7F 0x7F 0x7F 0x80 0x00 0x00

    0x00 0x00 0x00 0x00 0x03 0x00 0x00 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80

    0x05 0x00 0x00 0x02 0x00 0x02 0x00 0x00

    0x00 0x00 0x00 0x00 0x00 0x1E 0x1E 0x00

    0x00 0x1E 0x1E 0x00 0x00 0x00 0x01 0x01

    0x01 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x00

    0x00 0x00 0x00 0x00 0x11 0x03 0x01 0x48

    0x00 0x37 0x01 0x00 0x00 0x0A 0x00 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0xCC 0xD6

As you can see the CRC16 is 0xD6CC. I tried to calculate the CRC16 CCITT from byte 0 to 125 byte and the result is 0xD6CC.CRC16 CCITT Wrong configuration 2.png

Waiting for your kind help,

Many thanks

Best regards

Gianni Perugini

0 Likes

Hi GiPe_4640606​,

MBR3 device never writes to the CONFIG_CRC register. This register is always written by the host (i2c master). The host (EzClick/ host controller) calculates the CRC for the first 126 bytes of config data and writes to the CONFIG_CRC register.

MBR3 uses the CONFIG_CRC register to validate the integrity of the register map. Only if the two bytes in the CONFIG_CRC matches with the CRC calculated by MBR3 for the first 126 bytes of config data, the MBR3 writes this data to the Non volatile memory. Otherwise, it load the previous valid register map or the factory default values.

Therefore, I suspect that the issue is with the configuration data itself initially written to MBR3 and not with MBR3. Since the CRC of the incorrect config data matches with CONFIG_CRC, this has come from an external master(EzClick).

Please note that we do not recommend EzClick for production programming. We recommend using a third-party programmer from RPM Systems Corporation. To configure the CY8CMBR3xxx controller using the third-party programmer, use the hex file of the configuration generated by EZ-Click. Contact RPM Systems Corporation for further information.

If possible, kindly recheck the initial configuration written by the EZCLICK software.

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes