Develop a QCA7000 board?

[johu]

Here it is at Arrow: https://www.arrow.com/en/products/qca70 ... e=octopart

[uhi22]

The parts which I have are organized by projectgus from an Chinese source (taobao or so), around 12 Euros including shipping. More details on page 1 of this thread.

[uhi22]

Small progress: Today is transformers day

The core is a RIK10 from https://www.reichelt.de/index.html?ACTI ... =1&q=rik10. Each of the three coils windings has 5 windings turns.
One coil winding connects to MODEM_RF and ground. Second coil winding connects to TX_P and TX_N, and the third to RX_P and RX_N.

The mechanical solution is not really good, in terms of mechanical strength. There is the risk that something breaks in long-term use due to vibrations. The core should be fixed by something, maybe hot-melt-glue or something similar.

[johu]

Very nice. They look different to whats on my board with 3 windings?

I finally got around to running pyPLC as EVSE and have it communicate with Clara. No hardware behind it, so I'm in this endless loop:

pyPLC:

Code: Select all

[627025ms] [EVSE] {
"msgName": "CurrentDemandReq",
"info": "34 bytes to convert", 
"error": "",
"result": "",
"schema": "DIN",
"g_errn": "0",
"header.SessionID": "0102030405060708",
"header.Notification_isUsed": "0",
"header.Signature_isUsed": "0",
"DC_EVStatus.EVReady": "1",
"DC_EVStatus.EVErrorCode": "0",
"DC_EVErrorCodeText": "NO_ERROR",
"DC_EVStatus.EVRESSSOC": "0",
"EVTargetCurrent.Multiplier": "0",
"EVTargetCurrent.Value": "0",
"EVTargetCurrent.Unit": "A",
"EVMaximumVoltageLimit_isUsed": "0",
"EVMaximumCurrentLimit_isUsed": "0",
"EVMaximumPowerLimit_isUsed": "0",
"ChargingComplete": "0",
"EVTargetVoltage.Multiplier": "0",
"EVTargetVoltage.Value": "0",
"EVTargetVoltage.Unit": "V",
"debug": "Line9057Line9260Line436"
}
[627025ms] [EVSE] EV wants EVTargetVoltage 0.0
Received SoC status from CurrentDemandReq.
    Remaining 0% 
    Full at -1%
    Bulk at -1%

Clara

Code: Select all

[203674] TCP received
[203675] In state WaitForCurrentDemandRes, received:
 (35 bytes): 01 fe 80 01 00 00 00 1b 80 9a 02 00 40 80 c1 01 41 81 c2 10 e0 00 40 80 00 01 82 80 08 18 18 00 84 00 c0 [203675] step1 35
[203677] step2 0 27

Not sure why Target voltage is 0 at his point, should be 222V.

https://github.com/jsphuebner/ccs32clar ... liboi-port

BTW do you want me to PR the OI port?

[uhi22]

Very nice. They look different to whats on my board with 3 windings?

Yes, on the first boards I used the minimal approach, just shorted RX_N to TX_N and RX_P to TX_P. And used a core which I just had in my "Bastelkiste", and measured how many windings turns lead to a good signal. For the current boards I go the more official way.

BTW do you want me to PR the OI port?

Sooner or later, yes, of course. But no hurry, let's stabilize the things first a little bit.

[xvyDFatih]

A duty of 5% signals PLC so would mean likely DC charging but could also be a Tesla AC EVSE.

I have tried with IND message. when the cp signal was %5 pwm duty, If we didnt receive IND message through 5sn, I decided AC charge

[johu]

Trip to the charger with Clara

Result: I charged!
Result 2: just briefly

I tried 2 times and after like 30s or 0.12 kWh the charging session stopped. Log attached.

I noticed as soon as we're talking EXI CPU usage is indicated as 150%. Not sure what's up with that.

EDIT: checked the CPU usage calculation and it seems legit. It means it executes longer than 30 ms. I'm afraid we're only running every other round of the 30 ms task so it becomes a 60 ms task or something.

EDIT: read the code a bit, apparently it's a timeout because it goes to state 99 PEV_STATE_SequenceTimeout. But the timeout is 5s. Strange.

I'm experimenting with DMA for SPI transfers. No improvement so far because now it just waits until the request is complete

[uhi22]

Good progress, but also still some work to do
One major missing point is the missing TCP retry. If a single frame is lost on the line (which is likely in a noisy environment), we run into timeout. The TCP is intended to repeat, but this is not yet implemented.

If guessing does not help, I'd propose to make a SPI trace (using Saleae), this reveals the complete traffic and should show why it aborts.


I'm soldering the QCAs, with mixed success, need a lot of rework. One of the new boards is talking now. For the guys who are on the reservation list: Which way do you prefer for later software updates? Is STlink fine, or shall I flash johus variant with CAN bootloader so that flashing via CAN works?

[johu]

UPDATE: that was easy! It's the trace outputs that slow it down! Upped speed to 1 MBit which makes them unreadable (maybe uart4 doesn't like high speed?) but now runtime is normal and CPU usage 50%.
Will work on that.

I think I will give two boards to a local company so they solder the difficult parts.

Anyway, I did some runtime analysis (thanks for all the test points!). As expected the overall runtime is 60 ms:

And the main processing time is spent in spiQCA7000checkForReceivedData()

and of course the state machine

Will look into it deeper. If it is the exi decoding then there is nothing we can do I guess. Would 60 ms still be acceptable or will chargers dislike that?
I will look into making data exchange with the QCA more efficient but that only saves 10ms at most.

[crasbe]

Will look into it deeper. If it is the exi decoding then there is nothing we can do I guess.

You could use a faster controller. A quick look into STM32CubeMX showed a couple of candidates that should be pin compatible with the F103.
The F2 series runs at 120MHz and the F4 series runs at 168MHz, especially the F205 and F405 stand out as promising candidates. (Even though I didn't check all the pins with the Alternate Functions).

Even though the other controllers are somewhat more pricey, it's probably better to start with too much processing power and get into optimization later.

[johu]

No need to. Got cpu usage down to 3%

A faster controller doesn't help when waiting for a UART to finish sending stuff

I've removed the in-place traces and now spit out the current PEV state in the idle task. Might add more debug info there.

[uhi22]

It's a little bit spooky: Why can you read my thoughts? While riding bicycle the following came into my mind: It is slow because of the serial debug output. Just comment it out, and it will be much faster. Obviously, you knew this solution
Also using a toggle-pin to measure the run time would have been my proposal, very nice.

Regarding the response time: There is plenty of time which the charger gives the car to send a message. Do not have the exact number in mind, but something like 300ms during the charging loop if I remember correctly. And the exi decoder is impressive fast, also do not remember the exact time, but much below 1ms. I see no need for
* using an different SPI handling (DMA or such things)
* using a faster controller
* cutting the debug output much

Instead, it may be even better to add additional serial debug data (the complete ethernet frames), to be able to understand what is going on in case of connection loss.

[crasbe]

I assume UART4 is used for debugging? The code sets it to 115200 baud, maybe it would be easiest to increase that? By A LOT?
The STM32F103 datasheet specifies that all UARTs can run up to 2.25MBit/s.

That would instantly decrease the time it takes to transfer all the debugging data.

[uhi22]

That's worth a try, of course the receiver on the other end may be the limiting factor.

BTW: It might even make sense to reduce the clock frequency of the controller so as not to waste energy unnecessarily. The controller consumes surprising current (something around 50 or 60mA) and heats up significantly (10 to 15 degree above environment).

[crasbe]

Every FTDI USB to Serial converter should handle (at least) 921600 baud without any problem and that would be an 8x increase already. You just have to keep the peripheral clock frequency above 16MHz (preferrably more, with 16MHz the baudrate error is quite high with 2.12%).

Even though you said you don't want a different controller... the F1 series is somewhat "old" and not really the ideal choice for saving power. The STM32L family is much more optimized for low power consumption.

But speaking of peripheral clock.. you can try to reduce that and leave the core frequency high (STM32CubeMX has the ABP1 and ABP2 prescalers in the clocktree). That might result in some savings already.
But in my opinion that counts as "optimization", which you shouldn't start too early with

[johu]

I'm not too worried about the power consumption of a device that is mostly asleep. In my application I'd only fire it up when PP is active.
The 115k is actually sufficient to dump out a lot of data, it just mustn't be run by the real time tasks. For some reason when I set UART4 to 921k I only received garbage. On UART3 (on the inverter boards) it works flawlessly.

More importantly I have now successfully charged for 5 minutes:

One thing that held me up briefly was the economizer as my port relays already have one. So I'll make that configurable.

EDIT: before I go to test on the ABB charger, we changed something in the state machine to make that work. Is that necessary with this code as well?

[uhi22]

The ABB workaround is this: https://github.com/uhi22/pyPLC/commit/5 ... b43ddcfa4f Need to check whether it is in the Clara already...

Edit: The Clara does not care for the ResponseCode in the SessionSetupResponse. No change needed.

[tom91]

Johu's video triggered me to look at this awesome development again.

I reviewed the Github and noticed that in the possible wake up sources there is nog Ignition input or something like it, a 12V input or CAN activity should ideally wake the controller so it can start to report that everything is okay and the charge port is unplugged.

Also looking at the outputs there seems to be no dedicated charge request output, to power on the rest of the system. Having this be a simple grounding output to control a relay to power 12V feeds to things like the BMS will be required. This could be done via CAN if devices can wake up over CAN wake but will make the integration limited and not possible with Zombieverter at this stage.

[johu]

There are 3 pins left

So besides "ignition" 12V there could be a permanent 12V input. One pin used.
Then PP could be pulled up to these permanent 12V with 10k resistor and trigger for example a beefy P-MOS when it is pulled low by the PP resistor. The output of this P-MOS could be connected to a pin and used to power up some stuff - directly or via relay. Another pin used.

Already like that a slick system is possible where the CCS-controller turns on required components. They must be separated from the ignition 12V with diodes to not turn the entire car on. Example: VCU, BMS and coolant pump of battery cooling.

The last remaining pin could be used for the more advanced wakeup-pulse that switches on all devices on the wakeup bus and then they can decide to stay on or not in software.

Also since the CCS controller is then powered while driving it can explicitly tell the VCU that no cable is plugged in. Also it can report error conditions such as unexpected voltage on the charge port aka relays welded.

[tom91]

Then PP could be pulled up to these permanent 12V with 10k resistor and trigger for example a beefy P-MOS when it is pulled low by the PP resistor. The output of this P-MOS could be connected to a pin and used to power up some stuff - directly or via relay. Another pin used.

No do not make this a direct wake up, the controller then needs to decide if its okay and a plausible insertion to wake the car up. No point waking the car is there is not going to be any charging (CP in correct states and responds as it should).

[johu]

No do not make this a direct wake up, the controller then needs to decide if its okay and a plausible insertion to wake the car up. No point waking the car is there is not going to be any charging (CP in correct states and responds as it should).

You'd have the choice of 2 outputs. Directly from PMOS pin or fancy from wakeup pin. I'd choose the former for now as not all my stuff is prepared for the wakeup pulse.

That said the wakeup pulse could also come from a beefy PMOS and you can configure in software if it's a pulse or permanent. One pin saved.

[johu]

I went to a small charger round. First the well known Compleo just to confirm I start with a good software. Then 3 ABB chargers. The first two started charging for a few seconds then stopped. The last one worked.
Which data should I dump to the console for debugging?
How hard would it be to implement TCP?

[uhi22]

Progress with the boards. Finally all five are talking to my "demo evse" (aka pyPLC with AR4720). The most interesting finding is a bug in the schematic, that was not detected with the older boards, because I never populated the RF filter components. With the filter populated, the QCA is nearly deaf, it does not hear the evse, only by chance. All five boards with the same symptoms, so it must be a systematical issue. And it is. The receiver inputs of the QCA are biased to around 1.6V. But my "bugfixed" circuit pulls them to ground, and the receiver input does not process the signal without the bias. As workaround, removed the L5 and L7, and now everything is fine. The original millisman design did not have this ground in the middle, and I considered this as bug, so I "corrected" it quite in the beginning. Will roll this back.

Need to test the peripheral functions (temperature sensing, voltage sensing, connector lock, ...) in the next days, but at least the hardest part is done now.

[uhi22]

I went to a small charger round. First the well known Compleo just to confirm I start with a good software. Then 3 ABB chargers. The first two started charging for a few seconds then stopped. The last one worked.

Great, thanks for testing. It confirms, that the thing is quite instable at the moment. I guess it is just random behavior, not really related to certain chargers.

Would data should I dump to the console for debugging?

In best case the complete received and transmitted ethernet traffic. ( I'm still dreaming to have a device which just listens to the homeplug and allows to make a trace in wireshark, but nobody has an idea how to enable the "transparent mode" of the homeplug modems, so that all traffic is routed. Somehow this must be possible, because there are commercial sniffers, like https://www.vector.com/de/de/produkte/p ... e/vh5110a/# )

How hard would it be to implement TCP?

Should be not too complicated, f0ld already had a look, not sure about the results.

[f0ld]

I went to a small charger round. First the well known Compleo just to confirm I start with a good software. Then 3 ABB chargers. The first two started charging for a few seconds then stopped. The last one worked.
Would data should I dump to the console for debugging?
How hard would it be to implement TCP?

I´m currently working on implementing the TCP features.

On of my problems is that I dont have hardware to test my code against. Thanks to uhi this will change in the future
Also I have one course at university where I have to program in assembler and another one where I have to program OOP in C++. So my brain is a little bit rusty when it comes to C-programming

For someone experienced as you are this should not take to long. At least a basic prototype of the TCP retry. In the current stack there are already some things that could be refactored for performance. But in my opinion, performance is not relevant at this stage. Better get it working properly and then it can be improved.
So if you want to have a try, feel free

There are still a lot of open ToDos in the Clara Repo like taking over the latest state-machine from pyPLC. So I personally would try to resolve this before extensivly test focci against real chargers. That way we wouldnt go through the debugging of the same stuff that you already did on pyPLC. But uhi is propably more qualified then me to judge this

Additionally I want to mention that it is really motivating to see that there is so much development and drive in this thread. I wish I had more time at the moment to participate but this is great!
Excited to catch up in detail on what happend in the last weeks