Develop a QCA7000 board?

[uhi22]

Created https://github.com/uhi22/ccs32clara/issues/17 regarding missing stack pointer initialization, which is one reason that Clara crashes on the iso-test branch. Any hint welcome.

[Edit] The missing stack pointer initialization is solved now on the iso-test branch. DIN works again, ISO not yet tested and some open todos to resolve.

[evMacGyver]

Slightly off-topic, but does anyone have spare QCA7005 chip to sell, 1-2pcs?

[osch]

Hello,

after reading until the end of this and other QCA7000 threads it is time to get my hands dirty and kick start my project to upgrade my Nissan Leaf for CCS charging...

One question I have is what is currently the latest release of FOCCI? Looking at GitHub it states 4.2, if you go to the shop it states 4.5 and of course earlier in this thread you read about 4.3. It seems to me GitHub is a bit behind and I wonder if there are plans to keep the versioning kind of in line?
Lastly how far away is the migration of the wakeup branch Johu is working on?

[uhi22]

Slightly off-topic, but does anyone have spare QCA7005 chip to sell, 1-2pcs?

Good question, did anybody find a reasonable priced source in the meanwhile? (I'm dreaming of below 10€)

Regarding the versioning: The latest version is on johus wakeup branch. If further tests are turning out that this is stable, we should bring this back to the main.

[lalithroshan]

Hi,
This is my first post and I'm sorry if I'm not adhering to any forum guidelines.

I'm developing a CCS Charger using QCA7005 with STM32F4 microcontroller. I used the Qualcomm PLC utils toolkit.

I'm able to establish an AVLN network after successful completion of SLAC messages (upto SLAC_MATCH_CONF). I'm also able to receive SDP request from the EV car, but I'm not able to get the TCP request as expected. As I'm not using a linux system, I wasn't able to get trace message as shown in previous post. I'll give a few details below and please let me know if you need anything else apart from this

Code: Select all

NMK D3 E4 93 3F 85 5B 70 40 78 4D F8 15 AA 8D 87
NID B0 F2 E6 95 66 6B 03
PLCC MAC ID 00 B0 0A 0B 17 05

The SDP response payload that my controller sends after receiving the SDP request is as follows

Code: Select all

start: AAAAAAAA
 length: 5A00
 temp: 0000
 ODA: 38 1F 26 30 25 48
 OSA: 00 B0 0A 0B 17 05
 MTYPE: 86 DD
 IP Headers:
 Version, Traffic Class, Flow label: 60 00 00 00
 Payload length: 00 24
 Next header: 11
 Hop limit: 40
 IPv6 Src addr: FE80 : 0000 : 0000 : 0000 : 02B0 : 0AFF : FE0B : 1705
 IPv6 Dest addr: FE80 : 0000 : 0000 : 0000 : 3A1F : 26FF : FE30 : 2548
 Src port: 3B 0E
 Dest port: C0 01
 UDP payload length: 00 24
 Checksum: DC 96
 SDP headers
 Protocol ver: 01
 Protocol inv ver: FE
 Payload type: 9001
 Payload length: 14
 Payload: 
 IP addr: FE 80 00 00 00 02 B0 0A FF FE 0B 17 05
 port: C051
 Security: 10
 Transport protocol: 00
End: 55 55

Requesting you to help me with this issue

[johu]

I'll give a few details below and please let me know if you need anything else apart from this

Hi, is this open source?

[uhi22]

As I'm not using a linux system, I wasn't able to get trace message

I recommend to record the SPI traffic, and convert the SPI data into a pcap file, which can be inspected e.g. using wireshark. The workflow is described here: https://github.com/uhi22/Ioniq28Investi ... i-analysis

I'll give a few details below and please let me know if you need anything else apart from this

I think I do not need anything. If you want to give something to the community then you are invited to share your experiences. (Sorry for the clear statement. Maybe it's just a bad translation. The message I got is, that you need support and ask me whether I need information to do your work.)

[asavage]

my project to upgrade my Nissan Leaf for CCS charging...

As opposed to one of the off-the-shelf CCS->CHAdeMO adapters?

[johu]

Finally got around to re-assigning the connector pins and made the flash SPI easier to access. Moved some components around to reflect the new placement also. I'm calling it 4.5b as it is electrically identical to 4.5. Didn't want to burn up another version resistor. Does that make sense?

Here is the new assignment

I've "padded" the unused pins with GND. That way, both the contactors + and - lead can be inserted into the Deutsch connector

EDIT: now that I look at it I could swap 5V with GND so contactor pins can be adjacent.... DONE
https://github.com/jsphuebner/foccci/tr ... assignment

[osch]

That is fantastic Johu....!!!

Finally got around to re-assigning the connector pins and made the flash SPI easier to access. Moved some components around to reflect the new placement also. I'm calling it 4.5b as it is electrically identical to 4.5. Didn't want to burn up another version resistor. Does that make sense?

Think it depends if this board will be sold through the shop. Rearranging connector pins is a breaking change if you ask me. It makes it incompatible with previous versions and can cause issues if you are not taking care and double check before using it.

Padding the unused pins is always a good idea and may be best practice?

I'm happy to give this new design a shot and share the ones I don't need. Let me know otherwise...

[osch]

As opposed to one of the off-the-shelf CCS->CHAdeMO adapters?

Right, I'm aware about these devices. Was thinking about getting one but they are still a bit pricy and if you look at comments from users who have bought them they aren't fully compatible. You rely on what they provide and have to wait for updates from the vendor.

Believe this solution / project is a few steps further down the road and you have the freedom in getting fixing issues on your own or getting help much faster. Of course it requires to mod your car but given my one is more than 5 years old there is no warranty anymore.

Lastly it is more fun this way

[axiv]

Hello everyone.
Tell me, I'm faced with the following not very good situation. When connecting the board to the charger, at the moment the QCA wakes up, there is some kind of surge on the line (or CP or CE) on the side of the charger, such that the controller is reset. Maybe someone has encountered it? What protection options were considered? Has anyone tried to enable TVS protection on the CP-CE line?

[uhi22]

Do you have the chance to measure this "surge" with an oscilloscope? We need to understand, where it comes from and where it harms, to fix it. And: You write "controller is reset". You mean the STM32 is reset? This cannot be caused by anything on CP, PP or PE. This would mean that the 3.3V line drops, which is quite unlikely, no matter what is applied on the CP or PP or PE from outside. More likely is power drop on the 12V.
Also it would be interesting when exactly the reset happens. A log of Focccis serial output could help.

Regarding implemented protection measures:
- The 12V power is protected with a TVS against overvoltage.
- The 12V power is protected with a diode against wrong polarity.
- The PLC modem is protected by diode network against high-frequency energy on CP.
- The PLC modem is protected by transformer against low frequency pulses on CP.
- The controller is protected by 47k and 100nF against voltage spikes on PP.
- The controller is protected by D14, R58, D16 against high voltage on CP.

Which additional protections do you intend to add?

[johu]

I have added a thread for everyone who integrated Foccci into the car: viewtopic.php?t=5077