Develop a QCA7000 board?

[quentin42]

I need your help please.
I have a 4.1 focci, with the fixed on PP: 330ohm pull up + 47k
Flash STM et ESP32 : OK
Communication with the QCA chip seems ok: opmode = 100, and the rgb button is solid green.
I plugged into an Ionity terminal, but nothing happened. The charger did not detect the connection.
opmode remained at 100.
I checked everything, I don't know what else I can test.

[dougyip]

Thanks johu and uhi22 for your quick response. I am not aware of a separate QCA-Thread. You're right though, separating board/software development and use of Focci/Clara would be a good idea.

[uhi22]

I plugged into an Ionity terminal, but nothing happened. The charger did not detect the connection.
opmode remained at 100.
I checked everything, I don't know what else I can test.

For trouble shooting it is recommended to create a log file of the serial output. You need a serial-to-usb converter and connect it to the UART TX line and ground. For recording, you can use e.g. Putty on windows or any console program.
Additionally, you could check in the web interface whether the 5% PWM are detected. And measure with a multimeter, whether you see the 12V on CP as long as Foccci is completely removed.

[Edit]

I have a 4.1 focci, with the fixed on PP: 330ohm pull up + 47k

The 4.1 has the issue with the shortened receive inputs. If you ordered it in the shop or got it from me, this issue is solved by removing L5 and L7 as discussed here: viewtopic.php?p=64235#p64235 and here https://github.com/uhi22/foccci#v41-2023-10-25 . If you ordered by your own, you need to apply this patch.

[quentin42]

Thank you so much,

This allowed me to detect that my CP was disconnected, I had a micro cut on the PCB. I tested with my granny EVSE, and the PWM was detected.

I deleted L5 and L7 which were present, but perhaps too quickly, because on the last diagram, it was still present. My card comes from the focci repo at the end of December (after 4.1 but before 4.2), the real fix may have already been applied ?

[uhi22]

The commit history on github shows that at 18.12. the issue was fixed. But it does not matter if you removed L5 and L7.

[uhi22]

image.png

image.png

The laptop power supply had no problem with the DC current.

[quentin42]

I went back to ionity.
CP is ok, PWM is detected at 5%

But no communication.

Here are the oscilloscope tests

CP :

PXL_20240404_113026572.jpg

Input Modem RF (Test to R25 resistor) :

PXL_20240404_112743419.jpg

RX_N / RX_P / RXIN_N / RXIN_P : 0V
TX_N / TX_P / TXOUT_N / TXOUT_P : ~1.2V constant

Log SM32 :

Test_Ionity.txt

[edit]

The QCA log is strange. The version is not "normal".

Code: Select all

[10] [CONNMGR] 165 0 0 0 0 0 0 --> 0
[10] ETH rx HP: ffffffffffff00b05200000188e10062a000b05204000000000000000000000000000000000000000000000000000000000000000000000000000000
[10] [CONNMGR] ConnectionLevel changed from 0 to 5.
[10] ETH will transmit: ffffffffffff02342666164388e10000a000b05200000000000000000000000000000000000000000000000000000000000000000000000000000000
[70] ETH rx HP: 02342666164300b05200000188e10001a000b05200060b426f6f744c6f61646572000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007c581b0000000000010000003f00000000000000
[70] [PEVSLAC] received GET_SW.CNF
For MAC 00:b0:52:00:00:01 software version BootLoader 
[550] [CONNMGR] ConnectionLevel changed from 5 to 10.
[550] [PEVSLAC] from 0 entering 2
[580] [PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ.

Why version is "Bootloader" ?


[edit2]

I am searching QC7000 + version Bootloader, and i am found a interesting code on github/open-plc-utils.

i have perhaps a particilar chip serial ?

Extract from https://github.com/qca/open-plc-utils/b ... set.c#L432:

Code: Select all

	if (! strcmp (confirm->MVERSION, "BootLoader"))
	{
		for (chip = 0; chip < SIZEOF (bootrom); chip++)
		{
			if (bootrom [chip].CLASS != confirm->MDEVICE_CLASS)
			{
				continue;
			}
			if (bootrom [chip].STRAP != LE32TOH (chipinfo->STRAP))
			{
				continue;
			}
			confirm->MDEVICE_CLASS = bootrom [chip].DEVICE;
			* ident = LE32TOH (chipinfo->STRAP);
			return;
		}
	}
	else
	{

[johu]

I'm testing the latest revision now (https://github.com/jsphuebner/foccci/tree/wakeup)

The wakeup now (almost) works as expected. I found the 10k pull-up on the button is too high. With the 100k+22k divider for the uC sense pin it sits like 0.7V below supply voltage and that is already enough to trigger the mosfet and activate the 5V regulator. So I lowered it to 1k for now and that fixes it. Maybe 4k7 or 3k3 would also work, haven't tried. Same goes for the PP pull-up.

Wakeup via CP works beautifully, as long as I keep the PWM running Foccci stays on, 10s after I stop PWM it shuts itself down. All the other wakeup also react as expected.

The new contactor driver works well but you have to keep in mind it forms a boost converter:

Gescanntes Dokument.png

Safer to run the relays to GND. Otherwise it's just the TVS limiting the voltage and it failed to do so once when I tested with a higher value inductor - 5V regulator was fried. I think the reason why the TVS didn't limit effectively is the thin trace going to it and also trace inductance.

I also think running the contactors at 100% duty for 1s when starting is a bit long. Usually it will have pulled in after 50ms or so.

[johu]

I have split Dougs latest question to a new "user thread" viewtopic.php?t=4889

[uhi22]

I do not see the boost converter in the picture. As long as the lower switch is on, the current through the L rises. If the lower switch is off, the current keeps running via the upper diode or upper switch, the voltage is only rised by the forward voltage of the upper diode in worst case. Everything perfect, what is missing?

[johu]

argh, the picture is wrong. The relay is connected before the reverse polarity diode.
I saw it on the scope that while the relay was on supply voltage (behind the diode) had risen from 12 to 20V!

[uhi22]

RX_N / RX_P / RXIN_N / RXIN_P : 0V
TX_N / TX_P / TXOUT_N / TXOUT_P : ~1.2V constant

[70] [PEVSLAC] received GET_SW.CNF
For MAC 00:b0:52:00:00:01 software version BootLoader

If the QCA reports "Bootloader" as software version, it was not able to load its firmware from the SPI flash. I've never seen this before, but just tried: De-solder the SPI-flash, and I get the same message. Added into the trouble shooting hints: https://github.com/uhi22/foccci#clara-s ... tis-normal

Also you voltages on RX and TX look strange. Directly on the QCA, I measure around 1.6V on TX and RX pins. Added this into https://github.com/uhi22/foccci#no-comm ... r-possible

[johu]

If the QCA reports "Bootloader" as software version, it was not able to load its firmware from the SPI flash

Coincidentally I just had that exact symptom. Turns out the QCA had some bad solder joints. Quite intuitively on the side pointing towards the flash. Also the SPI flash itself had an unsoldered pin. Not sure if that was part of the issue as the flash programmed fine.

[quentin42]

SO,
U1 was not flashed, it's a big mistake on my part. I had seen the documentation, but I thought it was an old procedure for flashing the STM32.
After the flash, the QCA was recognized. RX/TX were at 1.6V.
I was also able to get pyplc to work in EVSE mode.
Next step, return to ionity....
Thank you so much.

For powering your laptop, it's cool; so a simple usb chargeur should be able to recharge the powerbank (or a internal battery).

[johu]

Another milestone reached today. I ordered 10 QCA7005 chips to JLCPCBs factory and can now select it for assembly

They are a bit expensive at 28€ a piece but that is better than loosing chips to nasty soldering, let alone the time this consumes.

So this quantity will appear in the shop in about 2 weeks.

[catphish]

Another milestone reached today. I ordered 10 QCA7005 chips to JLCPCBs factory and can now select it for assembly

This is fantastic news, and the price is perfectly reasonable considering the value of the finished board! Looking forward to seeing some "v1" boards.

[johu]

Yes indeed. It's 28€ just for the QCA chip and like 20€ for the remaining board

Order went wrong. Went through till payment, then suddenly jumped to order history. Cart and history empty Couldn't start over because the QCAs are now stuck in the zombie order. Meh, they'll figure it out. I have yet to find a time when nobody responds on their chat thingy. I don't know how they do it, it's quite amazing.

[johu]

The order has gone through now, I'm excited!

On another note I wanted your input on this. Here is the current pinout:

focci_pinout.jpg

The two contactor outputs are on different plugs. The LEDs and button are not on the plug that is more charge port oriented but on the car oriented one. Now I thought it would be more stringent to arrange like so:

focci_pinout-mod.jpg

That way all wires going towards the charge port are in one common harness and so are the ones going to the car. I'd assume the voltage sense board to be mounted with the charge port contactors.

[celeron55]

That new pin ordering makes a lot of sense. The contactors and the voltage monitor are likely to be located in a junction box that is very much a "car side" thing. Are all of the pins other than LOCK_MOT1 and LOCK_MOT2 referenced to ground? This would mean the only signal you need to bring to the charge port in addition to the "charge port side" pins would be ground, which is reasonable enough.

[johu]

Are all of the pins other than LOCK_MOT1 and LOCK_MOT2 referenced to ground?

Yes exactly. PE should be solidly connected to the chassis not far away from the charge port so that would serve as a ground reference for the signals

I guess the design is still young enough for shuffling pins

[uhi22]

At the moment, Foccci/Clara only support the DIN schema for the high level communication (din:70121:2012). This is fine for most use cases. However, the limitation of the DIN is, that the maximum voltage is 500V, reported by the charger. To use higher voltages, we need to step to the ISO15118, which should support up to 1000V.
The initial discussion of this topic is here: viewtopic.php?p=70690#p70690
The try, to integrate the ISO2 (aka ISO15118:2:2016), resulted in massive memory overflow (ROM and RAM), due to the needs of the OpenV2G EXI decoder. Even with some optimizations, it is unlikely that this fits into the available 512K ROM and 64K RAM. A bigger controller would be necessary.
Luckily, there is also a ISO1 variant (aka iso 15118:2:2013) of the EXI decoder, and this consumes less ressources. It should contain everything which is necessary, also the KIA EV6 uses this schema.
An experimental software is in work, still untested and some open todos. https://github.com/uhi22/ccs32clara/tree/iso-test

[johu]

Nice, so will this work with all chargers out there, even old ones?

[uhi22]

The plan is that Clara announces both, DIN and ISO2013, and the charger selects what it likes. I do not plan to remove the DIN support. For testing, there is a parameter to force DIN or ISO, but in the end the "both" setting will be the usual way.

[serh270]

Nice, so will this work with all chargers out there, even old ones?

Upon completion, this will exist simply as a firmware update then?

[uhi22]

This is the plan.