You are correct that the P0.4 pin on x220xx footprints checks for FACTORY_TR pin state only at boot time and then switches to LP_STATUS behavior. However, no external pull-ups are required on this under normal circumstances. Here is the procedure:
- Power-on/XRES occurs
- P0.4 set as input, internally pulled HIGH through ~5.6 kOhm (functioning as FACTORY_TR)
- P0.4 logic state checked before EZ-Serial boots
- If P0.4 is HIGH, application boots normally; if LOW, boots to manufacturing test mode
- P0.4 changes to internally pulled LOW through ~5.6 kOhm (functioning as weak-strength LP_STATUS signal)
- "system_boot" event occurs and is transmitted out the UART port
- P0.4 begins switching between HIGH and LOW states (pulled, not strongly driven by default) depending on CPU sleep state
If you do not intend to use FACTORY_TR in conjunction with CYSPP in order to give the host an option to effect a factory reset via hardware, then you should leave P0.4 either floating or connected to a Hi-Z input on an external host device. Pulling it HIGH externally will cause a slight amount of extra leakage current while the CPU is awake (though this should have no impact on consumption when the module is asleep, since it will be internally pulled HIGH as well).
Is there any way to invoke a module power-on reset, capable of doing this hardware-based factory resetting control, by not using the XRES pin? I don't have control of XRES from the host.
1 of 1 people found this helpful
A "system_reboot" command will trigger a chipset reset also. If the FACTORY_TR and CYSPP pins are both externally asserted (LOW) when you do this, then it will cause a factory reset. However, you have already noted that your design doesn't give you access to the CYSPP pin, so this is not an option in your case.
Aside from this, the "system_factory_reset" command will cause a chipset reset and return to all factory default configuration settings. But sending this command requires working API communication over UART from the host.