Develop a QCA7000 board?

[uhi22]

The firmware on the SPI flash should not be your issue. Even if you remove the SPI flash completely (or it is empty), the QCA will respond to the software version request with the response "Bootloader".
I just measured the MISO line on a Foccci. If the QCA does not see a homeplug coordinator for 30s, it does not send anything back on the MISO anymore, it is going to a kind of sleep mode. This is normal. It wakes as soon as a homeplug coordinator (e.g. an EVSE) is visible.
After a power-on, I see some responses on the MISO:

But also I see a lot of clock packets without a response on the MISO:

image.png (4.88 KiB) Viewed 2355 times

So it may be normal that you see not much on the response. You could trigger on the MISO line, this should reveal some data. If not, check the MOSI whether it sends the correct request message.
You could also give a try and connect the QCA as an SPI slave to a Raspberry and load the QCA driver which makes an ethernet interface from the QCA. I never tried this before, but think this should be a quite solid way to check whether the board runs in general.

[uhi22]

Also make sure that you use the intended clock polarity. Here is an example of the C3 message (binary 11000011, means "read, internal, reg 3 RDBUF_BYTE_AVA"). The data is sampled on rising edge of the clock and prepared on falling edge.
Red is clock, yellow is MOSI.

image.png (9.34 KiB) Viewed 2350 times

[reactive001]

Thank you for providing info and traces, that's above and beyond!

Unfortunately still stuck in SPI purgatory. Tried everything, even soldered up a new board and still no signs of life. Schematic seems solid and (mostly) as per the datasheet. Tried with burst mode disabled, no flash, checked my pins aren't being used on the dev kit board, reset high and low, all of the different spi modes. QCA just doesn't respond and MISO just stays high the entire time... very frustrating. Chips could be duds since I sourced them off AliExpress but the 1.2v rail, 1.6v tx and oscillator wouldn't be working if they were fake.

I did find a few things mentioned in the datasheet that isn't in Foccci that might be worth a review, I don't think any of the above is actually my problem or a problem in the foccci design though.

1. JTAG pins are supposed to use a 10k resistor to ground and 3.3k to ground for TDO (except for RTCK which is left open)
2. PLL_BYPASS should be connected to ground via 10k resistor
3. Datasheet calls for SPI Mode 3 and your trace/code seems to look like mode 1 (clock should be high on idle instead of low)

Datasheet link is here, it may be out of date - https://www.misuxin-en.com/Content/uplo ... df?rnd=780

I can keep progressing the code with ethernet powerline modules so its not the end of the world. The main thing I wanted to do is write a netif adaptor for the QCA so it can be interchangeable with the ethernet interface. It'll have to wait until the dev boards arrive, hopefully with a working comparison I can figure out where I've gone wrong.

Thanks again for your help

[mux]

Bit of a question out of left field - if I don't use any firmware for the QCA7005, can I implement the application externally? Like, just use the QCA7005 as the PHY and do all the message decoding/encoding myself in a separate microcontroller?

I'm asking this because I'd like to experiment with ISO 15118 implementations over AC (which require the same GreenPHY communication as CCS), something that's going to be mandatory with OCPP 2.0.1 and there are no commercially available controllers at anywhere near a reasonable price available. Since it looks like I'm going to be working on this stuff in the next few years I'd like to get ahead and tinker with it myself.

[reactive001]

Bit of a question out of left field - if I don't use any firmware for the QCA7005, can I implement the application externally? Like, just use the QCA7005 as the PHY and do all the message decoding/encoding myself in a separate microcontroller?

I'm asking this because I'd like to experiment with ISO 15118 implementations over AC (which require the same GreenPHY communication as CCS), something that's going to be mandatory with OCPP 2.0.1 and there are no commercially available controllers at anywhere near a reasonable price available. Since it looks like I'm going to be working on this stuff in the next few years I'd like to get ahead and tinker with it myself.

That's pretty much how it works with the firmware. From what I've read (and there's a good chance I'm wrong because I haven't written a driver yet) the main difference between EVSE and PEV firmwares is the power saving. EVSE generates a pilot tone and is always online, the PEV waits for a pilot tone and then turns on when present, otherwise it turns off after 30 seconds. Both should require your to parse all the L2 ethernet frames they generate and handle things like SLAC and setting the appropriate network key using the homeplug protocol before actual ethernet packets flow.

[uhi22]

if I don't use any firmware for the QCA7005, can I implement the application externally?

There are two software packages, we need to sort out which firmware you are talking about.

1. The first package is the one which is executed inside the QCAs ARM controller. This is stored in the SPI flash as (compressed) image and the QCA reads this at startup into its internal RAM and executes it form there. If it is not present, the QCAs ARM controller still executes a small bootloader firmware, which is able to talk to SPI and responds to the software version request with the response "Bootloader" but I guess it does not route any homeplug traffic between the homeplug port and the SPI port. This firmware package does a lot of important stuff, like dealing with the huge number of RF carriers, combining the information of these carriers, handling the security (AES, SHA), sorting the frames into management and payload, providing the data on the SPI interface as ethernet-compatible packages. Omitting this software and writing it "outside" would require to have a piece of software inside the QCA which at least activates the modem parts and routes the low-level-data in both directions between the RF port and the SPI. Not sure whether this is even possible from bandwidth and timing point of view.

2. The second package is executed outside of the QCA. It operates on SPI-Ethernet frames. It may be the linux QCA driver (which just translates the SPI to a virtual ethernet port) and above a combination of QCA tools, SwitchEV/josev, pyPLC or what ever high level protocols. Or a microcontroller running this stuff. It needs to do the SLAC, IPv6, SDP, V2GTP, EXI, charging state machine.

I'm not aware that somebody went the way to substitute the package 1. There was an experiment which used software defined radio to decode the homeplug traffic, but this was offline (not in realtime) and only the receive part. This is described in Ref19 of https://www.goingelectric.de/wiki/CCS-T ... e-Details/.
However it would be a big advantage in direction of sniffing, if we would have an open source low-level homeplug decoder, so if you find something out this would be really helpful.

For just AC charging, the existing software is a good basis, there is not much to change. The lower layers are identical, just in the DIN or ISO messages the AC relevant data needs to be selected. The starting point to select between DC and AC is here:
https://github.com/Martin-P/OpenV2G/blo ... pes.h#L458
So the investigation regarding QCA firmware is not required to tackle the AC charging.

[mux]

Thanks for the info! That completely clears up the firmware situation for me, it was not very clear from e.g. foccci what was going on there.

That's actually great news, that means that I can fully define the application layer anyway without too much fear that the modem interferes with anything. Also interesting to hear the QCA7005 runs its 'radio' firmware from external SPI, that's a bit different than what I'm used to with other brands of modems.

Awesome, I'm off to do a custom board design then. It's going to be a long process, since I have neither a compliant charger (they barely exist) nor a car with ISO 15118 over ISO 62196, so for the latter I'll be using a Vector controller and the former I'll be rolling something myself. As I get more acquained with the whole stack I'll be able to contribute some useful info to the forum as well.

[uhi22]

Sounds quite promising. For debugging during the first steps you could use pyPLC with homeplug adapters, this is easy and cheap and offers the opportunity to record pcap files which are quite helpful to understand what is going on, using wireshark.

[uhi22]

Good news regarding the transformerless Foccci boards: Just populated the QCAs on two of them, and they work like a charm. Even with additional 26dB attenuation of the RF signal, the demo charging with pyPLC as EVSE works perfect.

This means, if you order a Foccci in the shop, you could select now between the transformer variant (V5, V5.1) or the transformerless variant (V5.2p7).

[uhi22]

Good news: The transformerless Foccci works on the Alpitronic charger. Here driving a 230V bulb (just because it's nice) and a 24V/20A power supply (which will be the use case later).

Was running stable until I stopped after 18 minutes.