openinverter forum

Just remove all components which are connected to the TX lines of the QCA, and measurse both TX lines with oscilloscope.

The problem was the Flash memory, which recorded normally, but erased after some time. I don't know why yet. The memory is W25Q16.

Thanks for the tips.

Do you know, whether in this case the software version of the modem was reported with "Bootloader" on the serial console?

So it seems like I have (at least partially) killed my Foccci with over voltage.
I recently added the changeover relay between stationary battery and EVSE connected one.
I am currently travelling and the relay was connected to the stationary battery. That means the small HV source hasn't got anything to work against that stops the voltage from going sky high. I wouldn't be surprised if it reaches multiple kV with the way I have it set up right now.

My wife decided to plug in the car because it was quite sunny. I saw the state machine reach Precharge and then it dropped back to off. After that I could not get any communication going anymore. plctools still find the EVSE modem so that seems fine.

My wife then drove to the shop and reported the EPC signal was blinking. That is very unusual as the EPC light reacts to the P-FET that is switched on when PP goes low.

So not 100% sure what is damaged and why. Maybe the high voltage somehow made it over to the PFET and killed it on some weird way that it now blinks? Or it traveled through the temperature sensors that have good thermal connection to the HV pins.

This is an old revision Foccci with no protection on PP. So this might not have any implications for current revisions. Quite sure I need to swap the board though

Following up on that it turned out Foccci is fine, only the FET haf failed. So I replaced it and now it broke again on our long road trip

Worked fine in the morning then broke during handshake on the next charge stop.

Replacing it with a physical switch so we can drive on. Will probably swap in a fresh Foccci when back home

There was an interesting DEFCON talk about vulnerabilities in the QCA7000 and general hacking around CCS EV chargers:

Summary:
- They demonstrated clearly, that choosing power line communication as basis for public charging infrastructure was a bad idea, from security point of view.
- They opened the door to write custom firmware for the QCA chip (even running DOOM at 37:25).

I followed the presentation at a high level, but there's a lot I don't know, so I ask:

1) Is the current FOCCCI implementation (on the vehicle side) vulnerable to an attack? Around 22:40 the presenters mention that some OEMs are "host booting" the modem at powerup, with (firmware? PIB?) loaded from a vehicle's host controller rather than flash storage, at every bootup as a way to avoid a successful attack being permanent (ie bricking the modem).

2) If the modem becomes bricked through malicious means, such that the ethernet and PCL interfaces are disabled, can it be un-bricked via SPI?

Ah well, stupid decisions (as in using PLC) have stupid consequences.

I do believe Foccci is vulnerable. Uhi is checking whether said write protect flag is active, but even if, I understood this could be circumvented with a factory reset command.

The hardware write protection is turned off via the shortest possible path Only way to patch this would be lifting and grounding Pin 3. On the plus side GND is right next to it. Also on the plus side we could run the Foccci host firmware directly on the QCA chip and forego the STM32. Theoretically

Just made some tests, to confirm that Foccci/Clara is affected by the "remote write configuration" issue. It is possible to read and write the modem configuration in the vehicle, by using the qualcomms open-plc-utils on charger side, while the connection is established. Details here: https://github.com/uhi22/Ioniq28Investi ... b-remotely

Possible attack scenarios:
1. An attacker connects a CCS plug to your car, changes the modem parameters and therefore bricks the Foccci. Recovery is possible by re-flashing the SPI-Flash, which can be done using a raspberry pi and some wires.
2. A charging station was prepared with malicious firmware, which writes the PIBs of each car which was connected. Recovery as above.

My thoughts:
For attack 1: If the attacker has physical access, there are many other methods to brick the car (mechanical, electrical), so I think one more special software issue does not add much risk.
For attack 2: Possible, but not very likely. No need to bring a patch within a week. We can think about what we can improve for the next hardware. Need to test the consequence of write-protected flash.

What do you think about the ground attack, i.e. connecting to wheel nuts or some other metal part? In Touran it wouldn't matter because Foccci is completely off without PP. But maybe not in all cars?

That aside I also think it's highly unlikely that someone tries to brick cars like that. But whatever we can easily accomplish we should do. I think I'll do something about that write protect signal in the next HW release.

Mines always on as I've not upgraded to a sleeping version of foccci yet but I think it'll be such a rare attack and it's not like they can achieve a financial gain, so probably not worth their effort.

asavage wrote: ↑Wed Sep 17, 2025 12:49 am 1) Is the current FOCCCI implementation (on the vehicle side) vulnerable to an attack? Around 22:40 the presenters mention that some OEMs are "host booting" the modem at powerup, with (firmware? PIB?) loaded from a vehicle's host controller rather than flash storage, at every bootup as a way to avoid a successful attack being permanent (ie bricking the modem).

Yes, same as for OEM Hyundai Ioniq.
"Host booting" means, the both, the firmware and the PIB, is provided by the host processor, instead from the SPI flash chip used on Foccci. This would avoid the possibiliy of the QCA to modify anything, so indeed it would avoid the permanent-bricking.

asavage wrote: ↑Wed Sep 17, 2025 12:49 am 2) If the modem becomes bricked through malicious means, such that the ethernet and PCL interfaces are disabled, can it be un-bricked via SPI?

In theory it is possible on Foccci, that the STM would send via the SPI some commands which writes a fresh PIB into the SPI flash. Or more clear, the STM would write commands as ethernet-packets via SPI to the QCA, and the QCA would send flash-write-commands via the other SPI to the SPI flash chip. This would require to have the PIB inside clara software package (looks possible), and to implement the trigger and the protocol to write the PIB. Technically this looks feasable. But I'm not sure whether the risk is such high to judge the effort.

Somehow doesn't sound like pulling /WP low will write protect the flash as-is:

The Write Protect (/WP) pin can be used to prevent the Status Register from being written. Used in
conjunction with the Status Register’s Block Protect (CMP, SEC, TB, BP2, BP1 and BP0) bits and Status
Register Protect (SRP) bits, a portion as small as a 4KB sector or the entire memory array can be hardware
protected. The /WP pin is active low.

and reading on it is

After power-up the device is automatically placed in a write-disabled state with the Status Register Write
Enable Latch (WEL) set to a 0. A Write Enable instruction must be issued before a Page Program, Sector
Erase, Block Erase, Chip Erase or Write Status Register instruction will be accepted. After completing a
program, erase or write instruction the Write Enable Latch (WEL) is automatically cleared to a write-disabled
state of 0.

That should do it: Close JP4 after programming flash and see if we're still good. Maybe I'll try beforehand on an older board

Tested this all in reality today and simply pulling down /WP does nothing at all. It only prevents the ability to change the write protection, but the actual write protection itself takes place in the chip.

And that is good news, because it means: no HW change!

When programming the flash chip we simply issue the command Of course after programming the image.
I tried it by setting the USR string (defaults to YURA CCM SOP DEFAULT) to PEV and indeed the change is now rejected. Before it was possible.

Charging itself still works as before.

Maybe the QCA chip could be instructed to do the same and maybe the QCA chip can be instructed to remove write protection. In the latter case we'd indeed need to pull low the /WP pin. But this is already an improvement.

Dear colleagues, hello!

I have designed a PLC modem based on the QCA7000 as a separate mezzanine board, fully in accordance with the Foccсi schematic kindly provided by you, as well as the datasheet. I copied the contents of the flash memory chip from a working QCA7000 EVSE module purchased on AliExpress.

The problem is that the QCA chip does not start. Even the 25 MHz crystal oscillator does not start – I do not see any sine wave on the crystal pins.

Could you please advise what the reason for this might be? I am attaching the modem schematic.

Thank you in advance for your help.
https://drive.google.com/file/d/1dQVS1D ... drive_link

Hi and welcome to the forum.

Some things to be measured are described in the trouble shooting notes: https://github.com/uhi22/foccci#trouble-shooting--faq

I would start with analysis of the power supply. Use a lab power supply for the 3.3V, and increase its voltage slowly, starting from zero. Observe the supply current, and observe in parallel the voltage on the 1.2V rail. Stop increasing the voltage, if the current goes above 100mA or the voltage on the 1.2V rail goes above 1.3V.

If the 1.2V is fine but the xtal does not run, maybe you missed parts of the xtal circuit (you are not the first with this observation
Usually the simple root cause are soldering issues, so shortcuts between the pins or unsoldered pins. Even unsoldered ground pad was observed. Check the conductance between the corner metal of the QCA and the PCB ground.

uhi22 wrote: ↑Fri Sep 26, 2025 5:29 am Hi and welcome to the forum.

Many thanks for your response!

And check to make sure the crystal you used matches the pad connection layout in your board.

Hi,

I have been following your progress recently, but there is a small I still couldn't clear. As far as I know regarding PLC communication you would need a transformer on the Rx and Tx lines, I checked there were separate pins and a transformer in V4 but why did you removed them in V5?

Thanks.

Hello!
The thread has a search function, too
viewtopic.php?p=76150#p76150

uhi22 wrote: ↑Fri Oct 25, 2024 8:45 pm Is it possible that they can selectively control the amount of solder paste?

The solder mask (the area the solder can spread into, F.Mask) and the paste stencil (the area they actually apply the paste to, F.Paste) are separate files that you generate and upload. If you want less solder, just make the paste aperture (ie the area of the rectangle on the F.paste area) smaller. In kicad, you can adjust "clearance overrides" on the properties for a pad.