- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have 2 CY8CMBR3116-LQXI on the same I2C bus. Using the reset pin, I was able to program them with individual I2C addresses and had my unit working really well.
One day, something happened that caused the chips to loose the configuration which caused the I2C addresses to go back to 0x37.
What could cause the configuration to be lost?
How can I prevent it?
Is there a way to lock the configuration?
Solved! Go to Solution.
- Labels:
-
Sensing Technologies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @af36
No, it is not recommended to connect the XRES or any other pin to VDD while the device is powered off. This will back power the device and is not recommended. If you are going through a design change, I will highly recommend replacing the XRES circuit as well.
How easy is it to reproduce the issue? Is it occurring frequently if you jerk the connecting wires? Can you try the same without the XRES supply?
Also, can you share your current schematic?
Best regards,
Hari
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is most likely caused by an error while configuring which corrupts the configuration in MBR3. 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 the user, the devices load the factory default configuration.
You can prevent this by making sure the power supply is stable while a reconfiguration is happening.
Best regards,
Hari
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, for some reason I never got a notification of this reply.
The configuration was saved successfully on both chips and I was using it for a good 4 months. I don't save to the configuration registers after the chip is programmed.
I only read the status when an interrupt occurs to see which key was touched.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have the same issue. I have 12 CY8CMBR3116-LQXI boards daisy-chained together using a FFC cable bus. Each one was successfully configured months ago without issue, and persisted over multiple power cycles/resets. I do not normally have anything connected to their I2C connections (which are not part of the FFC cable), and rely on the digital outputs to detect status changes.
Then recently one day, 7 of the 12 boards had lost their configuration and were reset to defaults.
I was able to recreate the issue today by accidentally wiggling/bumping the FFC cables while the boards were energized, and 2 of the 12 boards lost their configuration. I have XRES, CS15/SH/HI, 5Vdc, and GND daisy-chained on the FFC cable, so I suspect it is related to a short on one or more of these pins.
Any update from Cypress on this?
Thanks much.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @af36, @RoIm_4475046 ,
Configuration stored to MBR3 are permanent. It only defaults to the factory value if something causes a corruption of the registers, leading to a CRC mismatch.
Is the host writing to any config register or are you only reading the touch status?
Can you check the integrity of the power supply, VDD connections and reset? Make sure that there is no possibility of an accidental short.
As stated in this thread - https://community.cypress.com/t5/Sensing-Technologies/CY8CMBR3110-lost-configuration/m-p/115533 - can you check the CRC data of the initial Ez_Click configuration?
Best regards,
Hari
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Hari,
Can you point me to where I would check the CRC in EZ-Click? We do not have a host I2C device, only the initial connection and configuration using MiniProg3 and EZ-Click. After that, the MiniProg3 is removed and the "host" is only reading the digital GPO outputs for touch status. Again, the configuration was successfully maintained over several months and many many power cycles before this problem occurred.
Can you elaborate on the below?
Can you check the integrity of the power supply, VDD connections and reset? Make sure that there is no possibility of an accidental short.
What should I be looking for? VDD is currently supplied from a current-limited benchtop supply. There certainly have been opportunities for the following shorts to have occurred while people adjust the energized equipment, and may accidentally bump the FFC cables:
- VDD to VSS
- XRES to active 5V or 0V outputs (660 Ohm resistor in series with XRES pin)
- CS15/SH/HI (configured as HI) to active 5V or 0V outputs
There is also a possibility in our current system for VDD to be OFF (or passive) while XRES is 5V. I'm not sure if this would be problematic or not, as I do not see a max voltage for the XRES pin in the datasheet.
Would any of these conditions cause the configuration to reset to default?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello @af36
You can check the 16-bit CCITT CRC16 checksum in the register address 0x7E.
Since you do not have any host configuration, this is not likely to happen.
However, we need to test if the device is still functional.
So, can you check the following -
1. Using any I2C master, read the register address 0x8A. This tells if the factory default value is loaded. 0 indicates a custom config and 1 indicates factory default config. This will help us understand if the data was indeed reset.
2. Try to load your project again to any of the controllers and see if it is operational still. It could malfunction due to a variety of issues such as the device itself being damaged, ClassB error such as sensor short to ground/VDD, sensor Cp out of range, etc. If you are able to configure the device, go to Ez-Click -> System Diagnostic tab and see if it reports any issues.
Best regards,
Hari
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Hari,
The devices are still functional; I was able to reload the configuration on 2/25 and it has persisted over the past 2 days and multiple power cycles. On the most recent 2 boards to have lost the configuration, I checked the EZ-Click --> System Diagnostic tab and it does not report any issues.
None of the controllers are currently in the default state since I restored them most recently 2 days ago, so I have nothing else to check at the moment unless I try and replicate the issue.
Long-term, we are changing our mechanical design and layout to prevent the accidental shorts I mentioned in my previous post. But I guess I would feel more comfortable knowing that those shorts could have caused the flash to be reset to default, to make sure something else isn't happening.
Further, is it OK to have a voltage present at XRES while VDD is off?
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @af36
No, it is not recommended to connect the XRES or any other pin to VDD while the device is powered off. This will back power the device and is not recommended. If you are going through a design change, I will highly recommend replacing the XRES circuit as well.
How easy is it to reproduce the issue? Is it occurring frequently if you jerk the connecting wires? Can you try the same without the XRES supply?
Also, can you share your current schematic?
Best regards,
Hari
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Hari,
Can I privately share my schematic somehow? I can send you a Box.com link if you can provide your email.
Understood on the XRES to VDD back powering concern.
As for how easy it is to reproduce the issue... it's only happened twice in the past ~ 6 months, but both times were accidental/inadvertent. I have never intentionally tried to cause it. These boards are adhered into a non-reworkable assembly so if they were to become damaged, we'd have the scrap several parts. For that reason, I don't really want to try and experiment with reproducing it. Is there any other way we can try and prove the shorts or XRES are at fault?
Thanks for the support.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have had another one that lost its configurations.
I do not write to registers after initial configuration is loaded with EZ-Click. I only read the status register to find out which button was touched. My reset pins are floating. Could that cause any factory reset somehow?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, that could cause the issue if there are any glitches on the reset pin. We recommend connecting a 0.1uF decoupling cap to filter out any glitches in the line.
Best regards,
Hari
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The NVM is locked after programming in the sense that we need to issue specific I2C commands to change the values in the flash. This is also followed by a checksum calculation and all these help in preventing unnecessary writes into the flash. But the issue here could be the random resets during startup or during normal system access, where the data is retrieved from the flash for program execution.
This is the reason we have a decoupling cap on the XRES line to prevent any unwanted resets of the device.
Best regards,
Hari