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 9940 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 9936 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.

[kt1412kn]

Hello, I am a beginner with PLC and QCA7000. I plan to implement PLC communication on EVSE. However, I saw that before using the QCA7000, it requires flashing the firmware and PIB file. I found that some people use an SPI to Ethernet adapter to connect it to a computer, and then let the computer recognize it as an Ethernet port in order to download the firmware and PIB files. However, I feel that using an SPI to Ethernet adapter is a bit complex. Is there another way to flash the firmware and PIB file? If not, could you tell me how to implement the SPI to Ethernet adapter?

Additionally, I have an idea. Would it be possible to write the contents of the first software package into a storage chip and then connect the storage chip directly to the QCA7000? Is this feasible? But I feel that in the end, I will still need to connect it to a computer for testing.

Really looking forward to your reply！

[uhi22]

A possible way to connect the QCA7000 to a linux machine is, to use the SPI of a Raspberry. Search with google for "QCA7000 raspberry". For example: https://raspberrypi.stackexchange.com/q ... erry-pi-4b
Then you have a eth1, which you can use to read/write the PIB using the Qualcom tools.

When you write PIB or write a new firmware to the QCA7000 using the above method, the QCA will store both into its SPI flash memory. This means: Yes, if you have one SPI flash with the intended configuration, you could read it out, and flash the image to an other device, to have a perfect clone.
The method to read/write the SPI flash is described here: https://github.com/uhi22/foccci#program ... -spi-flash
This means, one we have an image of the SPI flash, everybody could use it to programm the own flash, and there is no need anymore for PIB handling via the Qualcom tools.

[Gabriel]

Hi everyone,

I'm working with the QCA7005 and noticed an unusual waveform on its oscillator. Has anyone encountered this kind of behavior?

Also, I observed that the internal 1.2 V regulator is not regulating properly — it's rising to around 1.6 V.
I'm not sure if this is causing the oscillator issue, or if it's the other way around, but I’m worried it could potentially damage the chip.

Despite this behavior, SPI communication works correctly, however, the TX signals do not send RF packet on the output.

I'm following the reference design of the v4.2 board.

Any insights would be appreciated.

[uhi22]

I also have seen cases where the 1.2V got higher then intended. These were solder issues, like missing ground on certain pins or missing ground on center pad. The good news is: all my QCAs survived these situations and work perfect after proper soldering .

[Gabriel]

Thanks, that's something good to hear!
I'll double-check the soldering, especially the center pad and ground pins — fingers crossed that's all it is!
Appreciate you sharing this!

[Gabriel]

Guys. I'm having trouble getting my QCA7000 board to work, so I'm looking for documents and projects that might give me some clues about what to do. I found a git file with files that might help everybody with the QCA7000 design. Here's the link: https://gitcode.com/open-source-toolkit/3c2616 and the attached file.

My problem is that I can't generate the proper RF signal. The signal intensity is too low and I can barely read it with an oscilloscope. The oscillator is ok, the 1.2 V signal is ok. The board communicates with SPI.

I'm attaching photos of the poorly formed signal and a well-formed signal that I read on a REDBEET board.

Does anyone have any tips on what to try?

[uhi22]

Usually this is the result of soldering issues, like shortcut or open circuirt in the RF path. Some voltages and resistances to be checked are mentioned in the trouble shooting guide https://github.com/uhi22/foccci#no-comm ... r-possible
On some V5 boards we have seen shortcuts under the RF transformer.

[Gabriel]

Thanks. I'll check these points.

Anyway, I'm more suspicious of a systematic error, since I have 5 cards and they all behave the same way.

[johu]

Yes, systematic soldering error - had these, too! Uhi fixed 5 of my boards.

[uhi22]

I have 5 cards and they all behave the same way

This could also point to wrong components, e.g. C10 with 220nF instead of 220pF or something similar. You could compare the signals directly on the TXOUT_P and TXOUT_N, with the signal on the C10 and the signal on the CP line. And if nothing helps, remove the D3, 4, 6, 7, and C10. The TXOUT_N and _P should provide inverted signals with >1V amplitude.

And important pitfall: The QCA will stop sending packets at ~30s from power-on, if it does not see a homeplug coordinator (EVSE). So it may be normal, that you do not see packets.

[Gabriel]

Wow, I hope I don't have the same soldering problem on the 5 boards! That would be quite frustrating, I always check the soldering on the side pads with a microscope and they seem ok.

Thanks, uhi22. I'm using the board with the FLASH memory firmware as EVSE. I checked and the C10 is at an adequate value.

I'm continuing to investigate and do new tests, if I make any progress I'll let everyone know here.

[uhi22]

Maybe the flash image contains a configuration with very small transmit power? Would it help that you share the image, so we can give a try with our boards?

[Gabriel]

I don't think it's related to the flash image. I got the .bin from: viewtopic.php?p=33730#p33730

[uhi22]

Thanks, I missed this.
Measured the transmit amplitudes using a Foccci 1.0 board, with the aliexpress EVSE_1 and 2, and the Ioniq configuration, which we use on Foccci normally.
The aliexpress configuration has lower transmit power, but still very well visible on oscilloscope.

Summary: each transmit line has 2V (peak-peak, in the preamble) for the Ioniq PEV, and 0.6V for the aliexpress EVSE.

Details here: https://github.com/uhi22/pyPLC/blob/mas ... of-the-qca

[Gabriel]

Great work! Thanks.

So far no progress. I will compare each part of the circuit and components with the REBBEET module. I am suspicious of the quality of the QCAs purchased from Aliexpress. Has anyone had a similar problem?