cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC 4 MCU

New Contributor II

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?

0 Likes
Reply
1 Solution
Anonymous
Not applicable

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:

   
        
  1. Power-on/XRES occurs
  2.     
  3. P0.4 set as input, internally pulled HIGH through ~5.6 kOhm (functioning as FACTORY_TR)
  4.     
  5. P0.4 logic state checked before EZ-Serial boots
  6.     
  7. If P0.4 is HIGH, application boots normally; if LOW, boots to manufacturing test mode
  8.     
  9. P0.4 changes to internally pulled LOW through ~5.6 kOhm (functioning as weak-strength LP_STATUS signal)
  10.     
  11. "system_boot" event occurs and is transmitted out the UART port
  12.     
  13. P0.4 begins switching between HIGH and LOW states (pulled, not strongly driven by default) depending on CPU sleep state
  14.    
   

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

View solution in original post

0 Likes
Reply
5 Replies
Honored Contributor II

I don't see that in the Data sheet which I am sending you.  What kit are you using?

0 Likes
Reply
New Contributor II

See page 206 of below:

   

http://www.cypress.com/file/333001/download

0 Likes
Reply
Anonymous
Not applicable

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:

   
        
  1. Power-on/XRES occurs
  2.     
  3. P0.4 set as input, internally pulled HIGH through ~5.6 kOhm (functioning as FACTORY_TR)
  4.     
  5. P0.4 logic state checked before EZ-Serial boots
  6.     
  7. If P0.4 is HIGH, application boots normally; if LOW, boots to manufacturing test mode
  8.     
  9. P0.4 changes to internally pulled LOW through ~5.6 kOhm (functioning as weak-strength LP_STATUS signal)
  10.     
  11. "system_boot" event occurs and is transmitted out the UART port
  12.     
  13. P0.4 begins switching between HIGH and LOW states (pulled, not strongly driven by default) depending on CPU sleep state
  14.    
   

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

View solution in original post

0 Likes
Reply
New Contributor II

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.

0 Likes
Reply
Anonymous
Not applicable

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.