openinverter forum

Jack Bauer wrote: ↑Sun Jun 20, 2021 12:44 pm Sayyyy something like this :

Six figures in your favorite currency sound good?

Did you try giving it the 5% PWM while looking at the SPI?

That's the plan for tomorrow:)

EV_Builder wrote: ↑Sun Jun 13, 2021 8:23 pm SimpleGenerator_v1_0.PNG

Ok lets start first with a Simple 2D one.

GUI app is done.

Now the C++ Class which will be fed with this data .

This can be used for all sort of mappings/tune-ings not only charging so i kept it Universal. (so maybe a move to the VCU section is better?).

GUI App updated. See VCU thread for more updates.
Will be posting this over there only.

No spi comms on 5% pilot.

That's odd. Even if they were using UART mode it uses the same pins so you'd expect to see something if you manage to get your state machine far enough.

Looking at your PCB picture it looks awfully like an SPI EEPROM footprint. You've not got the SPI Master (config) bus rather than the SPI Slave (host) connection?

oookay. I'm on pins 3 , 65,66 and 67 with are ....wait for it ..... SPI master! Now I just gotta find the RIGHT spi .... gaahhh

reading the datasheet, looks like it can be configred to get its firmware from the SPI slave bus.
SPI slave functions are on page 22, boot modes on page 18

Yep based on pin 22 am now on Serial IO 0 to 4. Few state changes at powerup. Nothing constant and nothing on 5% pilot

Seems odd - looks like it needs a firmware load, and unlikely it could detect GP carrier without. the QCA7000 has sleep modes so doesn't seem like there is a reason to delay intialising it. The Kona module's flash has about 400K of code, so a firmware load over SPI should be pretty obvious.

I assume you were looking for SPI both at powerup and after you'd thrown some initial CAN at it?

Have you looked at what the reset pin is doing - I'd expect the MCU to do a reset first, then load the firmware

No data of any sort at any time on that bus other that the few pulses pictured above. Guess I better try it at a ccs station.

Just back from my local services where they have Ionity/ABB and Efcaec QC45 stations.

All tests done with same VCU firmware as had been used previously (works on Efcaec, not Ionity or Circontrol).

2014 LIM with Saleae logic on the spi bus.

Ionity first : https://github.com/damienmaguire/BMW-i3 ... .logicdata
Exact same behaviour as before. Connects, starts talking, station reports it needs to wait for power to be available then times out.
20 second capture done as follows, Open cp door, authenticate station with app, start logic analyser, plug in.

Efcaec: Lots of logs. Start, full power then at tail end (approx 45A current).
All on the repo : https://github.com/damienmaguire/BMW-i3 ... n/SPI_Caps

Few quick observations : Looks like a 2MHz clock. Only difference between 2014 and 2017 Lims in terms of bahariour was when I command 0 amps the 2017 sits there until I terminate charge but the 2014 terminates.

edit : Saleae software available free here for all platforms : https://www.saleae.com/downloads/

So nobody spotted my deliberate mistake? Mosi on the wrong test pad? No? It's ok, I went back for a second round :
https://github.com/damienmaguire/BMW-i3 ... Caps/Part2

Note these .logicdata files are for Saleae Logic 1, not the V2 on the page linked above
https://support.saleae.com/logic-softwa ... load-links

Update from my Keysight guy. I'm being put in touch with the project manager for that sexy test box thingy I posted about earlier. Probably nothing will come of it but what the hell....

Oh yeah sorry meant to add that thanks Mike. I'm too poor to get a V2:)
Also channel list :
0-CS
1-CLK
2-MISO
3-MOSI
4-IRQ from qca7005

You mean I have to stop lounging in the sun and do something? One moment...

Once you've set up SPI decode in Seleae Logic, You can export a CSV of the decoded SPI bytes.
Not ideal as it doesn't packetise them but could be a useful step in analysis. It does include timestamps so that could be used to group packets to some extent

Yipee! Got the SPI decoded and I've found the MAC address of the unit F0:7F:0C:00:8D:09 in the data stream from the LIM so I think we've got Ethernet packets. I have an ugly hacky idea for how to decode this just need to put together some python to try it.

The data looks very plausible - here's a snippet.
This document is helpful for making sense of the SPI data https://in-tech-smartcharging.com/asset ... 4_rev5.pdf

MAC prefix F0:7F:0C looks plausible https://www.kostal.com/en-gb/
and 00:01:87 is I2SE GmbH , who we've encountered before with CCS stuff
I'll leave the full decoding to others....

Quick warning - don't trust the Seleae Logic SPI decodes. Seems it can't handle sampling on different edges for MOSI and MISO.
Looking at the MAC addresses, when the host is sending to the QCA, the MAC is showing as F0 7F 0C 00 8D 0A, but when receiving, it's F0 7F 0C 00 8D 09
Can't immediately see a way to make it decode both correctly

Correction - looks like the decode is correct, but why is the MAC LSbit changing from Tx to Rx ?
Signal integrity issue from capture?

OK I think the issue is just the edge selection in the SPI capture - needs to be set as "valid on trailing edge", otherwise the receive data from the QCA is sometimes wrong.
I think the actual MACs are
Efcaec : 00:01:87:05:6D:21
Ionity : 54:10:EC:A5:0B:D1 (UUID 5410EC is Microchip!)
LIM : F0:7F:0C:00:8D:0A

Wow you guys are working fast! LIM mac attached.

Kostal have a manufacturing plant in Galway. I'm fairly sure they manufacture the LIM there so that part of the MAC makes sense.