Develop a QCA7000 board?

[johu]

Sounds great
I will log the traffic to console as hex then, i.e. the contents of myethreceivebuffer and transmit also

At this point I want to ask again: can we continue the work on this port now, so there is less merging effort?

[uhi22]

Yes, I do not plan software updates on the main branch at the moment, so you are free to continue on your branch, and when yours is stable (and I have some more time to contribute), we bring everything to the main again.

[johu]

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

Can you quickly explain? So far it seems like TCP acks are not handled in tcp.cpp
I would sure like to give it a try and retest at those chargers.

[uhi22]

The received ACK is handled here: https://github.com/uhi22/ccs32clara/blo ... tcp.c#L114
What we need is:
1. When the tcp sends a data packet, then record the time stamp of the transmission.
2. In a cyclic task, measure the time between the sent packet and the current time.
3. If an ACK is received, forget this time handling.
4. If the measured time in step 2 is bigger than a certain time (lets say 100ms), then we know that we did not get an ACK, and the TCP should send again the last data package, with exactly the same content.
5. Usually, if the missing ACK happens multiple times in a row, the waiting time is increased (e.g. doubled in each step), to not flood the network with messages. Also after a certain number of retries without success (let's say 10 or 20), the retry can stop and the connection is treated as lost.

Basically we do not need to overcomplicate it, a simple https://en.wikipedia.org/wiki/Stop-and-wait_ARQ is sufficient. For bigger networks and high thoughput there are better mechanisms, but in our case we anyway have a simple ping-pong from application point of view, so just waiting for the ACK of the last sent packet is perfect and simple.

(I would have a deeper look, but at the moment a little bit blocked by other things, so my progress is nearly zero here. Hope better times will come again )

[johu]

Thanks, will try to do that.

On other new I managed to populate another foccci board I used solder paste (extremly thin film) and heat gun for fitting the QCA. I see the version info so it seems to be mostly working. HF parts and transformer still to do.

[johu]

And I'm stuck.

There's no communication going on and when I scope TX it looks completely silent. Terminal says various promising messages

Code: Select all

[100] [CONNMGR] 165 0 0 0 0 0 0 --> 5
software version MAC-QCA7005-1.1.0.730-04-20140815-CS
[151] [ModemFinder] Number of modems: 1
[154] [CONNMGR] ConnectionLevel changed from 5 to 10.
[154] [PEVSLAC] from 0 entering 2
[157] [PEVSLAC] from 2 entering 4

What are the typical issues?
I was a bit liberal with resistor values. One is supposed to be 2k5 and I used 2k7, one should be 6k2 and I combined 6k7. 1V2 and local 3V3 are ok.

[uhi22]

This is normal. As long as the pev does not see central coordinator packets, it does not transmit anything. On my board I see static 1.6V on the tx lines in this case. When connecting to the evse modem, the tx lines looks like this

Qca7005 tx line

The packets with the low amplitude are the ones from the evse, the strong ones come from the QCA.

[Edit] I see the following points to check:
1. Is the 1.2V present and stable. -> seems ok
2. Does the STM detect the modem. -> seems ok
3. Does the QCA go to sleep 30s after power-on. This is when the STM says "zero modems found".
4. Does the QCA stay awake longer than 30s when a central coordinator is present. If not, this means the QCA does not hear the central coordinator, so the RX path is deaf.
5. Are the RX and TX pins (4 in total) on the QCA at around 1.6V statically. If not, then check for short circuits.
6. Is the resistance between the RX pins around 500 ohms (measured when not powered)? If not, check for short circuits or bad soldered pads.
7. Is the resistance between the TX pins around 16kohms (measured when not powered)? If not, check for short circuits or bad soldered pads.
8. If evse (central coordinator) is connected, do you see packets on the RX pins? Using two osci channels, they should be invers on positive and negative RX pins.

If nothing helps: inspect, then inspect, and afterwards inspect. I had cases, when I searched a longer time for the root cause of a not working QCA, and finally it was simply too less tin on one pin, like this

image.png (39.25 KiB) Viewed 521125 times

( see https://github.com/uhi22/foccci/blob/ma ... lessons.md )

[johu]

We have liftoff

All your checks went ok. When I took this picture

I realized my mistake. One end of my funky crystal wasn't connected to its cap. With that fixed I reached the charging loop with pyPLC.

Apparently not much can go wrong with the transformer, check it out

Is it beneficial to have a winding ratio other than 1:1?

[johu]

Implemented TCP retry
https://github.com/jsphuebner/ccs32clar ... 2878a89632

I tested by removing the Ethernet cable from the powerline modem. It started retransmitting. As soon as the cable was plugged back in all went back to normal.

[uhi22]

Yeah, great, two reasons to celebrate

Really nice pictures of the crystal and the transformer

Is it beneficial to have a winding ratio other than 1:1?

No, 1:1 is fine. Regarding the number of turns, just measure the levels on one side and the other with scope. If there are too less turns, the transformer will damp, this should be avoided. The signals on both sides should look the same. If there are too many turns, this increases the risk that powerful pulses from outside (due to EMI, switching contactors and so on) could reach the QCA and kill it. So the goal with the transformer is: As less turns as possible, but as much as necessary.

[johu]

Yes, new phone is not bad at all

I also looked around at JLCPCB for SMD transformers. I don't know what sort of uH we're looking for. Most are 1:1 or 1:1 with middle tap.
https://jlcpcb.com/partdetail/Sumida-ES ... 0C/C596483

Here's one with 2 separate secondary coils:
https://jlcpcb.com/partdetail/Rlt-SMD09H1971R/C5358224

[uhi22]

Roughly estimated, we need at least 20µH to get 120 ohms at 1MHz. A little bit higher is better. The RIK10 with 5 turns has approx 44µH. This means, the https://jlcpcb.com/partdetail/Sumida-ES ... 0C/C596483 with 120µH looks good. Contra: It is not cheap (~1 EURO). Pro: It is automotive-qualified.
I would avoid the three-winding-version, and simply connect the TX and RX together on the QCA side of the transformer. This leads to not ideal in-phase-rejection between the TX and RX, but this does not matter, because we are not fighting with microvolt sensitivity requirements in this application. I used this simple approach in serveral try-out boards without issues.

Other alternatives welcome.

Edit: https://jlcpcb.com/partdetail/3170710-C ... 1/C2904734 costs 0.10 EURO and looks technically fine.

[johu]

Very nice and very cheap. As said in PM JLCPCB can populate parts from other suppliers too. It's probably more expensive but that way we could get the QCA7005 soldered in place.

On other news I went to that ABB charger that didn't work last time and now I charged flawlessly for about 10 minutes and dared going up to 88A

[johu]

And two other ABB chargers didn't work. I could see the slack going on but as soon as I tapped my card it went into error state. Also tried setting up the charge session first then plug in. Then, the moment I plugged in it showed an error message. Almost seems to be something lowlevel at that speed. The one ABB charger that didn't work stands right next to the one that did work and it is the same model.

UPDATE: went also to a Tesla SC and Ionity (Tritium) and couldn't see the SLAC starting as well. It didn't even detect that it's plugged in. I've now checked all the wiring and can't find an obvious fault. Also on the table it all works fine with pyPLC in evse mode.

[uhi22]

Trying to build the clara fork https://github.com/jsphuebner/ccs32clara, but this runs into error
$ mingw32-make
CPP obj/main.o
CPP obj/hwinit.o
In file included from libopencm3/include/libopencm3/cm3/nvic.h:147,
from src/hwinit.cpp:20:
libopencm3/include/libopencm3/dispatch/nvic.h:8:11: fatal error: libopencm3/stm32/f1/nvic.h: No such file or directory
8 | # include <libopencm3/stm32/f1/nvic.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
Makefile:112: recipe for target 'obj/hwinit.o' failed

And indeed, there is no file nvic.h in https://github.com/jsphuebner/libopencm ... 3/stm32/f1
Any idea how to resolve this?

[royhen99]

If there is no nvic.h then libopencm3 needs to be compiled. nvic.h is generated by a python script.
To install and compile libopencm3,
make get-deps

[uhi22]

Thanks, now all is compiling, but the linker says for several modules (e.g. terminal.o, canhardware.o): undefined reference to `__cxa_pure_virtual'.
I found https://stackoverflow.com/questions/920 ... re-virtual which proposes to define the missing function with an endless loop. But may this be a hint that indeed a pure virtual function is called, which would be unintended most likely?

[royhen99]

I remember Johannes mentioned it here viewtopic.php?p=61836&hilit=cxa_pure_virtua#p61836.
You may need to add in main.cpp,

extern "C" void __cxa_pure_virtual() { while (1); }

This is at my limit of understanding so hope it works.

[uhi22]

Progress: As workaround for the linker error, added in the main.cpp: extern "C" void __cxa_pure_virtual() { while (1); }
Now linking is fine, the stm32_ccs.hex is created. Tried to flash this with
$ ST-LINK_CLI -P stm32_ccs.hex -V
and it says that it is flashed and the verification is ok. But no reaction of the target. May it be that the bootloader needs to be flashed in addition? Where to find it?

[johu]

Boot loader is here: https://github.com/jsphuebner/stm32-CAN ... s/tag/v1.0 . You need it because it sits in the beginning of flash and firmware "behind" it.

Newer version of gcc don't have this linker error, that's why I never have this __cxa function defined.

[royhen99]

Deleted as johu beat me to it!

[johu]

Just happened to be around

I guess the generic OI project readme should target those bullet points as they come up often.

[uhi22]

Yes, I'm just collecting my lessons-learned, so we can bring it to a location where everybody will look on later.
Progress: Flashing of bootloader and application worked. I expected that it simply runs after flashing with

Code: Select all

$ ST-LINK_CLI -P stm32_canloader.hex -P stm32_ccs.hex -V

but I need a power-on afterwards. I tried the -Rst option, but this does not help.

[uhi22]

Just to be sure: Is it normal, that it sends just two messages on CAN at startup:

image.png (6.83 KiB) Viewed 520826 times

I guess all other CAN traffic needs to be configured in the CAN-mapping, right?

[johu]

Yes, these are the boot loader messages.

All else needs to be configured. Here is my CHAdeMO config

udcdivider is just a dummy. It is the CHAdeMO version 10 special for Touran (in offset)

On other news working on the connector lock code. The Nissan lock I have doesn't have a linear feedback but its feedback value jumps from 16k to 6k on the last turn of closed state