Foccci wakeup/sleep discussions

[uhi22]

Goal of this thread:

Find out, align and consolidate the requirement for the QCA7000 CCS charger controller ("Foccci"), regarding power down, power-up, wakeup capabilities.

Initial discussion started here: viewtopic.php?p=61045#p61045
Some ideas here: viewtopic.php?p=64221#p64221
Github issue here: https://github.com/uhi22/foccci/issues/2

Out of the current discussions, the following use cases pop up:
Usecase 1: no sleep or wakeup necessary. The foccci is powered by a switch from 12V, and the user is responsible to turn this on or off as needed.
Usecase 2: The foccci is permanently at 12V and shall NOT draw any current. If the user plugs-in a charger, the foccci shall detect this, wakeup, wakeup others (like BMS). The detection can be based on the PP or CP.
Usecase 3: Long-term-AC charging. E.g. the vehicle is plugged-in the complete week at a AC wallbox, which is solar-driven and only charges if there is sufficient energy. The Foccci shall be able to wakeup and charge if the wallbox requests this, and shall not draw much current in the times in between, to avoid draining the 12V battery.
Usecase 4: Drive protection. The charger is plugged in. The driver wants to drive away. The vehicle shall forbid driving and indicate a warning "remove charge plug before driving". For this use case, the foccci shall detect the PP and inform the vehicle via discrete signal or/and CAN signal.

(...most likely more situations to be considered...)

[tom91]

Usecase 2, PP detecation can be used to wake, but CP needs to be plausible before waking up the rest of the car.

I would say the Charge Port interface needs to be awake when the car is awake, for safety checks during driving. So an 12V ignition or CAN based wake would be required.

The BMW LIM uses a wake up on the charge port door so the LEDs can be on before inserting the plug. Which might be a nice to have feature, not something very crucial though.

If you want to get really fancy, Scheduled charging managed by the Focci. I would not really care about this as you can get smart wall boxes that can do this for you and this makes more sense due to why you would want to schedule charging.

[johu]

Lets see which is hardware, which is software

Hardware
- switch that closes when PP is pulled to GND by charging cable - I use a P-MOS pulled to permanent 12V with 4k7. The existing pull-up to 3V3 would need to be removed and the voltage into the MCU pin limited to about 3V3. Also the unpowered MCU mustn't pull down PP - high value resistor between pin and PP
- The output of the switch powers up the foccci simply by supplying it with 12V
- Foccci may wake up or power components with a switchable 12V output - Say another P-MOS that can safely conduct about 5A.
- A 12V "ignition" input powers up Foccci when the car is turned on for status reports if you so wish. Super fancy alternative: use above output also as wakeup input (bidirectional wakeup bus)
- So we need 1 or 2 more pins on the Deutsch connector, there are 3 n.c.

Software
- When powered up Foccci checks for valid CP
- If valid, turn on or pulse the 5A P-MOS to wake up required components - we could also delay the charge start that way
- When charging is done, as per the state machine, remember stuff such as error messages in flash. I'd assume there will be enough time to write to flash between exiting the charge session and pulling out the cable (and thus loosing power from PP)
- When turned on via ignition simply do error reporting

[celeron55]

You could add a way for software to keep the board powered as long as the program decides to, after it has woken up using the hardware based method. Basically just parallel another input to the P-MOS, driven by an output from the mcu, but make sure it doesn't backfeed into PP. This would allow staying up after charging for any logging or cleanup operations, for however long the software needs to.

[johu]

I have finished up the schematic for full wakeup functionality

I have added a bidirectional WAKEUP signal to B7. When pulled high it will turn on the 5V reg and thereby the controller. The uC on the other hand can pull high the wakeup signal itself (TRIGGER_WAKEUP) e.g. when woken via PP. The P-MOS isn't particularly strong but wanted to stick with a basic part for now.

I didn't add an extra uC pin for the wakeup signal, instead the uC can read the PP level to decide whether it's a PP or WAKEUP wakeup

The uC can also choose to keep running after wakeup or PP are gone by pulling KEEP_POWER_ON high

I also did some BOM optimization to use more basic parts. Hope uhi agrees with all that.

https://github.com/uhi22/foccci/pull/3

[uhi22]

Two questions:
1. Where does the pull-up of the PP get the voltage from? For the use case, that everything sleeps (5V is off), and the user plugs the plug in, do we wakeup?
2. While the plug is connected, no sleep is possible, right? For the use case, that the car is parked for days with plug connected, this would drain the battery. Right?

[johu]

"24=" for the hand-populated boards, or "H24" for the jlc populated boards.

Fortunately I took a photo of the board. They are 24=
Makes me wonder where my Tesla issues came from. The wrong PP voltage perhaps, at least that's what cured it.

1. Where does the pull-up of the PP get the voltage from? For the use case, that everything sleeps (5V is off), and the user plugs the plug in, do we wakeup?

In that case it gets it from 12V_P via 6k2 which must be permanent 12V. There are solder bridges to choose between 12V and 5V on PP

2. While the plug is connected, no sleep is possible, right? For the use case, that the car is parked for days with plug connected, this would drain the battery. Right?

Right. The TRIGGER_WAKEUP can be kept low to at least not wake up other components but apart from that I don't see how to put the 5V reg to sleep. The most we can do is put QCA and STM to some low power mode.

To overcome this the PP signal would have to be artificially made momentary, like with capacitive coupling. Would save that for a later revision

EDIT: I should also mention that I greatly downsized the 12V bulk capacity. It was 680uF but for a maximum 6A PWM I think it can be less (power inverters have that sort of capacity). They are now 3x22uF film caps where one is placed right next to the motor driver IC.
Also on the 3V3 rail no elcap is needed in my opinion. So now the design is elcap-free

EDIT2: I just submitted a test order. Because I'm a cheapskate I chose the STM32F103RCT6 that I'm also using on the boards I'm testing with. Then I realized that those only have 48k of RAM. I wonder why it runs ok - maybe it actually has 64k

[celeron55]

If you make sure the STM32 can put everything on the board into shutdown/standby and that the regulator setup is efficient at currents in the range of 1mA, then I don't think it's a problem if the STM32 is always powered when plugged in. Managing the sleep states and wakeups of course takes some effort but it's doable.

If you want to go as far as stop the main oscillator, check if the STM32 in question has an internal RTC oscillator that can be used as a timed wake-up source, or whether you have to add an external RTC crystal for that.

But, if you use CAN transceivers without a standby pin, a wasteful regulator or something of that nature, you'll of course easily end up consuming tens of mAs even while the STM32 is taking microamps. Making electronics is one thing, but making low power electronics is a whole another level of effort.

Then again, of course, just using a series capacitor in line with the PP wakeup signal probably works just fine and you'll get to skip all the annoying sleep state management and the replacing of components with standby-capable ones.

[uhi22]

If the PP pullup is at 12V, and the 12V is variable between 10 and 15V, this makes the PP resistence measurement inaccurate. Would need to measure the 12V, too.

[johu]

Then again, of course, just using a series capacitor in line with the PP wakeup signal probably works just fine

Yes it just needs to bias the CJ431 reference input long enough for the uC to run through the boot loader and enable the KEEP_POWER_ON pin.

If the PP pullup is at 12V, and the 12V is variable between 10 and 15V, this makes the PP resistence measurement inaccurate

Oh, didn't think of that. Well then we can either deploy an aux 5V reg (they consume like 2 uA) for PP or indeed measure "12V" also

[uhi22]

And yet another use case: The connector is locked, charging is finished, everything sleeps. User unlocks the car, and wants to pull the plug. How does the wakeup work in this case? Usually a wakeup over CAN, but this requires an other tranceiver circuit.

[uhi22]

Small findings:
- The hardware version resistor R62 with C22790 has 0805 footprint, but 0603 component. Hopefully it fits nevertheless
- The p-channel-FET Q11 does not have a jlc part number.
- The 22uF have C12891, which are 1206, but the footprint is 1210. Well, should not hurt.

[johu]

Too small footprint is not good, too large usually works Have added the part number locally, probably didn't commit

No idea how remote controls exactly operate in the car and whether there is a "wakeup bus" that you could tap into. In Touran the interior lights switch on when you unlock, not sure how that is achieved. Could tap off them

I have made some calculations about PP measurement and I don't think further optimization is needed as the values don't overlap at different "12V" levels:

image.png (14.54 KiB) Viewed 1068 times

If you find it too embarrassing to display inaccurate resistor values you could just look what interval you're in and then display the ideal resistance value

[celeron55]

I'd wire the ignition key via a diode to the wakeup line to allow the user to wake up the board. If you just want the key-on events then I suppose it's the good old series resistor again...

If course if there's any module on the system that's wired to both ignition and wakeup it can make the wakeup pulse.

If there were unused pins (which probably isn't the case) it could be added as a new input without external components needed

[asavage]

I assumed there will be a momentary-contact switch near the charge inlet, to do user-input things such as:

* discontinue charging
* turn on the charge port light (to aid in guiding the nozzle to the port)
* or whatever . . .

That user-input button is, in my mind, one of several wake-up triggers for foccci.

[johu]

That user-input button is, in my mind, one of several wake-up triggers for foccci.

Yes also thought about this. I would require the same modification as for PP - pull up the button to permanent 12V instead of 3.3V

On other news I ordered some boards along with other stuff and JLC complain about vias being right on the pads. They will populate anyway but the result may not be good.

[uhi22]

vias being right on the pads

Yes, this is bad design, I was told by experienced people. My last orders did not lead complaints on jlc, maybe they improved their checker in the meanwhile. Another todo item...

[crasbe]

Yes, this is bad design, I was told by experienced people.

The issue that can arise is that the solder flows into the via and not enough solder is left for the actual component. It's not much of an issue for hand soldering but it can lead to tombstoning in the reflow process.

[johu]

Funny thing is I thought uhi is probably on to something and also placed vias into the pads

[muehlpower]

I assumed there will be a momentary-contact switch near the charge inlet, to do user-input things such as:

That's pretty much what I've described here. I also prefer to keep the 330Ohm at 5V because of compatibility. The only thing that bothers me is that someone else can stop my charging. This could be prevented by double-clicking.
viewtopic.php?p=61051#p61051

[celeron55]

I assumed there will be a momentary-contact switch near the charge inlet, to do user-input things such as:
* discontinue charging
* turn on the charge port light (to aid in guiding the nozzle to the port)
* or whatever . . .

Personally I have this on the dash, and the only thing it does is force CP to state B and unlock the charge port. I wouldn't put any buttons on the actual charge port because there's no room and they'd only get destroyed over time unless you buy really bulky and expensive weatherproof ones that don't fit.

But I suppose if you have the room, the money, live in California and trust the people walking by, a button there can work.

[jrbe]

The issue that can arise is that the solder flows into the via and not enough solder is left for the actual component. It's not much of an issue for hand soldering but it can lead to tombstoning in the reflow process.

A quick video to illustrate this,

[tom91]

Two questions:
1. Where does the pull-up of the PP get the voltage from? For the use case, that everything sleeps (5V is off), and the user plugs the plug in, do we wakeup?
2. While the plug is connected, no sleep is possible, right? For the use case, that the car is parked for days with plug connected, this would drain the battery. Right?

1. 12V pull up, this is what I would recommend.
2. Plug connected not sleeping the charge controller is fine if it goes to a low power mode and does not wake anything in the car. Better would be if you could override it but that gets quite complicated with the hardware.

[uhi22]

What about not caring for the PP, and instead using the CP 12V to wake up? Let's say, with capacitive coupling, so that the edge 0V->12V during the plug-in wakes the controller, the controller may keep itself alive, and also decide to power down if nothing interesting is happening (e.g. the Wallbox sleeps and waits for sunrise, so that the PV provides energy). And if the Wallbox decides for readiness, it turns-on the PWM, and this wakes the controller.

[johu]

Do all DC chargers output 5% PWM right away?