External MCU and SOC Power Scheme

---

REVISION HISTORY

Revision No.	Description	Date
1.0	Initial release	06/07/2024

---

1 Overview

This document is used to explain the system abnormality and solution caused by the power-on event triggered when the SOC is not completely powered off. It mainly introduces the SOC power-on and power-off process, the cause of the problem, and the solution.

2 SOC power on and off process

Figure 1: SOC power on and off process

1. SOC suspend state: At this time, the SOC is in a power-off state, and the RTCIO 0/1 and RTC ALARM events triggering can wake up the SOC.
2. SOC power-on process: This stage is the SOC hardware power-on process. After the RTCIO 0/1 and RTC ALARM events are triggered, RTCIO4 will be raised and then wake up the SOC.
3. SOC resume process: This stage is the SOC software resume process
4. SOC alive status: SOC normal working stage
5. SOC suspend process: This stage is the software suspend process
6. SOC power-off process: This stage is the SOC hardware power-off process. By operating the software, RTCIO4 is pulled down, and the SOC enters the power-down process.At the end of this stage, the RTC event can wake up the SOC normally.

3 Problems

1. SOC has strict timing requirements for power-on. When the RTCIO0/1 event is triggered when the SOC is in the hardware power-off process (Phase 6 in Figure 1), the SOC will not be completely powered off but will have to go through the power-on process, which will eventually lead to abnormal power-on timing.
2. Since the RTC wakeup node will only be updated after RTCIO4 is pulled high, the RTCIO0/1 event triggered in the stage where RTCIO4 is HIGH (stage 2 / 3 / 5) cannot be obtained by AOV demo, resulting in the loss of RTCIO0/1 (pir/wifi) events.
3. RTC is used over 80,000 times a day. Is it reliable? How to prevent mistakes?

4 Solution

4.1 Solution 1 (current implementation plan)

Figure 2: Flowchart of events for Scheme 1

Figure 3: SOC hardware modification plan

The hardware needs to be modified according to Figure 3. The hardware modification plan is as follows:

1. 3.3V_GPIO: Select any GPIO with 3.3V and default internal PU from the SSC30XXE chip
2. PQ1: Enhanced NMOS, it is recommended that the VthGS be as small as possible
3. MCU_INT: MCU external event interrupt output pin
4. RTC_IO1: It has built-in button anti-shake function. It will pull up RTC_IO4 only when there is 8ms delay.
5. R3: The resistance value is adjusted according to the MCU IO output characteristics.

Basic principle : When Vg is greater than VthGS, NMOS remains turned on, and RTC_IO1 remains at a low level, which is equivalent to shielding the signal of MCU_INT. When Vg is less than VthGS, NMOS remains turned off, and RTC_IO1 is equivalent to directly connecting to MCU_INT, and can receive MCU interrupts normally. Whenever MCU_INT is pulled high, it can only be responded to by RTC_IO1 at this stage. After 8ms of response, the internal POC module will pull up RTC_IO4. The hardware has 8ms to give the system more power-off time, and at the same time it can also ensure the normal secondary power-on timing.

Change the input source of RTC IO0 from RTC ALARM to MCU timer, and change the input source of RTC_IO1 as follows

Figure 4: Schematic diagram of hardware connection for solution 1

Principle : When the gpio2 level is HIGH, according to the CMOS principle, even if the MCU pulls up RTC_IO1 at this time, the SOC cannot respond to the RTC_IO1 rising edge interrupt. According to the CMOS tube characteristics (the on-voltage is 0.7v), the voltage of the gpio2 falling edge in the figure is 0.7v. In addition, due to the anti-shake measures of RTCIO1 (RTCIO4 will be pulled up after pulling up RTCIO1 in 8ms), it must be safe to pull up RTCIO1 after the falling edge of gpio 2. The rising edge event of gpio2 is pulled up when the SOC software resumes it, and the falling edge event of gpio2 is triggered by the voltage of the GPIO power domain being pulled down in the SOC hardware power-off process.

Specific implementation flow :

1. MCU wakes up SOC through timer, MCU alive, at any stage thereafter, if PIR & WiFi events occur, MCU will raise gpio1 high, and then directly pull up RTCIO1.

2. SOC is powered on and starts to stage 2. When gpio2 rises, MCU pulls up RTCIO1. At this time, since gpio2 is LOW, SOC will respond, but since RTCIO4 is already high, SOC will not respond.

3. When the SOC starts up and is in the stage from the rising edge of gpio2 to the falling edge of gpio2, gpio2 is HIGH. Due to CMOS, even if the MCU pulls up RTCIO1, the RTCIO1 seen by the SOC is still low.

   SOC starts to stage 4, and checks the gpio1 level status to confirm whether PIR & WiFi events occur. If yes, switch to high frame mode, and then modify the gpio3 status (such as multiple consecutive rising edges) to inform MCU that the event has been queried. After MCU obtains the gpio3 status, it pulls gpio 1 low

   After that, the SOC will continue to poll the MCU gpio1 level status in stage 4 to respond to the Pir & WiFi events that occur in stage 4.

4. SOC starts to the falling edge of gpio2 to stage 1. At this time, gpio2 is LOW. After MCU pulls up RTCIO1, RTCIO1 will actually pull up RTCIO4 after 8ms (8ms is enough for gpio2 to power down from 0.7v to zero). At this time, SOC will be directly awakened.

Note :

1. If there are multiple external wake-up events, the function of gpio1 needs to be implemented by multiple gpio roots.

2. Use gpio3 to inform the MCU that the status has been obtained. It can also be implemented by business logic. This is just an example of using gpio.

4.2 Solution 2

Figure 5: Flowchart of event in scheme 2

Modify the input signal source of the RTCPOC module as shown below

Figure 6: Schematic diagram of hardware connection for solution 2

Change the input source of RTC IO0 from RTC ALARM to MCU timer, and change the input source of RTC_IO1 to Pir & WiFi.

Principle : When MCU wakes up SOC through timer, when SOC is in stage 2, 3, 4, 5, 6, MCU is also in ALIVE state. At this time, with the modification of 1fps control source, MCU can clearly know the power-on and power-off time points of SOC, and can save the Pir & WiFi events occurring in stage 2, 3, 5, 6 of Figure 4 inside MCU, and send the event status to SOC through serial port in stage 4.

Specific implementation flow :

1. MCU wakes up SOC through timer, and then waits for the suspend signal or inquiry signal sent by SOC through the serial port.

   Suspend signal: indicates that the SOC starts to power off

   Inquiry signal: Inquire MCU whether Pir & WiFi events occur in stages 2, 3, 5, and 6. The occurrence of events means that the SOC enters stage 4

2. SOC is powered on and starts to phases 2 and 3. If a PIR & WiFi event occurs, the MCU retains the event status and does not trigger the RTCIO0/1 event.

3. SOC starts to stage 4, sends a query signal to MCU through the serial port, and MCU replies yes or no through the serial port. If the MCU receives a PIR & WiFi event at this time, it switches to high frame mode

   After that, the SOC will continue to wait for the MCU serial port to send information in stage 4.

   Waiting to receive the information sent by the MCU serial port is to respond to the Pir & WiFi event that occurs in stage 4. When the Pir & WiFi event occurs in stage 4, it can be directly told to the SOC through the serial port.

   Before entering STR in SOC stage 4, tell MCU to prepare to power off through the serial port

4. SOC starts to stage 5 and 6. If Pir & WiFi events occur at this time, MCU retains the event status and does not trigger RTCIO0/1 events. In stage 6, after the voltage of the GPIO power domain is pulled down in the SOC hardware power-off process, GPIO will be pulled low, and the MCU will receive a falling edge interrupt.

5. After the MCU receives the falling edge interrupt, it delays for a time t until the SOC is completely powered off and enters phase 1.

   After the MCU is powered off, if there is a Pir & WiFi event trigger in SOC stage 5 or 6, wake up the SOC immediately. Return to step 2

Let the MCU know the time node when the current SOC is powered off, and then respond to the pir/wifi event to wake up the SOC after power off.

t = 𝒉𝒘 _ 𝒑𝒐𝒘𝒆𝒓𝒅𝒐𝒘𝒏
𝒉𝒘 _ 𝒑𝒐𝒘𝒆𝒓𝒅𝒐𝒘𝒏 : The hardware starts to power off (RTC_IO4 is 0) until the board is completely powered off

4.2.1 Pseudocode

4.2.1.1 SOC AOV demo part

Init phase: pull up the specified GPIO pin
    // Create a new thread to wait for receiving MCU serial port information
    create_new_thred( func)
    // Create a new thread to detect heartbeat packets
    create_new_thred( heart_beat )
    uart_recive_count = 0

Processing phase:
    uart_trans( Querying )
    uart_recive(event_flag)
    uart_recive_count++;
    if(event_flag==TRUE)
    {
        // Switch to high frame
        .
        .
        .
    }
    else
    {
        //Maintain the status
        .
        .
        .
    }

    // SOC ALIVE processing completed
    uart_trans( suspend )
    //Enter suspend

heart_beat()
{
   temp_count = uart_recive_count
   sleep( 500ms )
   if(uart_recive_count<=temp_count)
   {
       // MCU abnormality
    }
}

//Thread processing function
func()
{
    uart_recive()
    if (MCU has an event trigger)
    {
         // Check the current mode
         if (mode=lowframe)
        {
             //Switch to high frame rate
        } else {
            sleep()
        }

    } else {
        sleep()
    }
}

4.2.1.2 MCU demo part

init phase:
    // Create a new thread to wait for receiving SOC serial port information
    create_new_thred( func)
    // Create a new thread to detect heartbeat packets
    create_new_thred( heart_beat )
    Querying = false
    suspend = false
    uart_recive_count = 0

Processing phase:
send_pir_event_flag=true

    if(PIR || WIFI)
    {
        if(Querying=false )
        {
            // Save the event to a variable
            save_event()

        }
        else if(Querying=true&& suspend=false)
        {
           uart_trans(true)
        }
        else if(Querying=true&& suspend=true)
        {
           // Save the event to a variable
            save_event()
            sleep( t )
            pull_up(RTC_IO1)
        }
    }

heart_beat()
{
   temp_count = uart_recive_count
   sleep( 500ms )
   if(uart_recive_count<=temp_count)
   {
       // MCU abnormality
    }
}

//Thread processing function
 func()
 {
     while(uart_recive())
     {
          if(Querying)
         {
             uart_recive_count++
             if(PIR || WIFI)
             {
               uart_trans(true)
             }else
             {
                 uart_trans(false)
             }
             Querying=true
         }else if(suspend)
         {
             // Do not respond to IO0/1 events from now on
             suspend=true
             break;
         }
     }
 }

4.3 How to prevent RTC from being fooled

Solution 1 : Based on the above functional implementation, the inquiry signal or GPIO falling edge interrupt can be directly used as the SOC heartbeat packet. If the SOC heartbeat packet is not received within the specified time, it is considered that the SOC is abnormal.

Similarly, the reply information of the MCU to the inquiry signal is regarded as the heartbeat packet of the MCU. If the heartbeat packet of the MCU is not received within the specified time, it is considered that the MCU is abnormal.