- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
P0.4 is specified for FACTORY_TR and LP_STATUS.
I assume the module starts up with P0.4 as input for FACTORY_TR and changes to LP_STATUS output.
Is there a way to determine when the I/O gender changes?
Also, is 10K pullup sufficient on this pin for 'normal' operation and will it go back to Hi-Z input when module is put to deep sleep?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Yashu,
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).
Jeff
- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Yashu,
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).
Jeff
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.