Vida CEM swapping

[rkam]

He tried to enable it in carconfig, and then get a reload at the dealer to make it work, but the reload removed the config change.
The project was adding four-c to a V70 from an S60R, so it will probably be easier on a car that is already prepared for it.

[ZRimaZ]

He tried to enable it in carconfig, and then get a reload at the dealer to make it work, but the reload removed the config change.
The project was adding four-c to a V70 from an S60R, so it will probably be easier on a car that is already prepared for it.

That's natural - reload at dealer writes back original config, therefore it has been removed after reload.

[dikidera]

Thanks to our friend Olaf I am nearly there in enabling myself to use VIDA via Raspberry Pi. I just needed a proxy(written in python) between the j2534 dll and RPI with mcp2515 controller. Well, with some refactoring of the Sardine code to work over wifi, which is another can of worms.

I am hoping some of you can provide me with logs from VIDA in which DICE or some j2534 device, replies with data from the cb,50,b9,fb or cb,40,b9,fb command, so I can spoof the results.

Well after finding a vida dump, I noticed that if messages flow too fast from my python server, sardine can't handle them as the socket buffer sometimes contains multiple messages that sardine cannot parse. Easy fix. I would simply try to parse them all, but this has another caveat, if messages saturate and exceed the buffer, the socket buffer will be incomplete. There will be chunks of data missing causing some of the messages to be incomplete. I could always go back and read some more data, but in that time I could waste the timeout and fail anyway.

I am not sure if my changes caused all of this, I keep wondering how it is that he managed to get a stable connection between VIDA and the Arduino as VIDA expects messages within said timeout, if you don't deliver, it also fails. So how is it that he managed to find the golden zone where his Arduino responded in just the right time, for VIDA to request and find at least one message.
From my observation, Arduino would send one message, that Sardine DLL would process and add to the rx buffer to satisfy VIDA's requirements of the 60 millisecond time out.

Or perhaps my changes exposed a design flaw. I mean I am no great programmer, but there are some design choices that are a bit questionable in the code base, and I may have to fix them in due time. Or, it is me who introduced the design flaw.

[lihgong]

1. I guess you may use some kind of Python-CAN to process the incoming packet, and forward to another place
In my experience, that's a bit slow than just using raw SocketCAN interface
The test below tried to do packet forwarding from CAN0 to CAN1, and I measured the latency
With Python-CAN, the latency is ~1920us while coding with C is ~570us
https://hackingvolvoxc60.blogspot.com/2 ... lysis.html

2. I used following commands to set proper txqueuelen in my RPi, but it seems doesn't offer rxqueuelen. Anyway, have a try
ip link set can0 type can bitrate 500000 restart-ms 100
ip link set can1 type can bitrate 125000 restart-ms 100

ip link set can0 txqueuelen 4096
ip link set can1 txqueuelen 4096

3. I guess you used double MCP2515 SPI receiver on Pi. That's theoretically... similar speed like USB (12Mbits). I gave up SPI-based devices eventually and switched to USB-CAN devices. Maybe that doesn't resolve your problem, but check it
https://github.com/candle-usb/candleLight_fw
ps. DIY this thing with STM32F042 board is not hard (use Google Translate or just check pictures)
http://lihgong.blogspot.com/2021/03/can ... n-diy.html

Thanks to our friend Olaf I am nearly there in enabling myself to use VIDA via Raspberry Pi. I just needed a proxy(written in python) between the j2534 dll and RPI with mcp2515 controller. Well, with some refactoring of the Sardine code to work over wifi, which is another can of worms.

I am hoping some of you can provide me with logs from VIDA in which DICE or some j2534 device, replies with data from the cb,50,b9,fb or cb,40,b9,fb command, so I can spoof the results.

Well after finding a vida dump, I noticed that if messages flow too fast from my python server, sardine can't handle them as the socket buffer sometimes contains multiple messages that sardine cannot parse. Easy fix. I would simply try to parse them all, but this has another caveat, if messages saturate and exceed the buffer, the socket buffer will be incomplete. There will be chunks of data missing causing some of the messages to be incomplete. I could always go back and read some more data, but in that time I could waste the timeout and fail anyway.

I am not sure if my changes caused all of this, I keep wondering how it is that he managed to get a stable connection between VIDA and the Arduino as VIDA expects messages within said timeout, if you don't deliver, it also fails. So how is it that he managed to find the golden zone where his Arduino responded in just the right time, for VIDA to request and find at least one message.
From my observation, Arduino would send one message, that Sardine DLL would process and add to the rx buffer to satisfy VIDA's requirements of the 60 millisecond time out.

Or perhaps my changes exposed a design flaw. I mean I am no great programmer, but there are some design choices that are a bit questionable in the code base, and I may have to fix them in due time. Or, it is me who introduced the design flaw.

[dikidera]

I actually got it to work after refactoring the sardine code a bit. I can't say anything about "performance" until I get my cables and connect to the actual car(then I'll have to debug again most likely). The RPI indeed has a problem with buffers saturating(because of the mcp2515 controller), I fixed that with txqueuelen..

I also got a bit more information. VIDA uses D2 protocol over CAN over J2534, the 0xCB byte(known as 0xC8 + leading bytes) commonly attributed to the DLC parameter was apparently false, and it's part of the D2 protocol for flow control. This is what I was told. On the bench, my ECU does not respond with 0xCB, I have to remove it, then it works.

While waiting for my cheap OBD cable to arrive, I plan to start experimenting the with a bootloader https://github.com/fenugrec/npkern and try to get it to work firstly, at least in some basic state. The Subaru/Nissan cars use SH7055 ECUs as well, with some differences, whereas our cars have a dedicated flash chip for maps, theirs do not. So they need to flash the SH7055 onboard ROM, whereas we need to erase and program the external memory, which is why this bootloader has no code for that. In addition they do not use CAN for communication, but Serial Interface. I have not installed the SH toolchain yet, so I have not actually compiled and tried it, if the voltages are within range of 3.3v-5v like they are for CAN and the RPI, why shouldn't it work?

The problem is programming the flash chip, 29LV200BC. If I am reading this right, the SH7055's bus state controller should enable me to write to the chip.

[5ft24]

Curious and following. Also, if you have timing issues with the pi, you will have to set GPU and SOC speeds in the config.txt. Some of the GPIO timing is affected by both. Pi4 is the most blatant "offender".

[dikidera]

Curious and following. Also, if you have timing issues with the pi, you will have to set GPU and SOC speeds in the config.txt. Some of the GPIO timing is affected by both. Pi4 is the most blatant "offender".

I am using the older and slower Pi 3B 1.2 rev, it is generally slower, but I've overclocked it to 1.2Ghz, lowered the GPU mem for maximum ram available to device and added zram module for some additional memory through sdcard.

[rkam]

Offtopic:
Nissan X-trail with SH7055 and SH7058 can be put into programming mode, receive and run software in RAM with the same commands as Volvo through CAN bus on the couch/sofa. I was not able to get any of the K-line programming tools to work on the X-trail.
Only K-line was available in the OBD connector.

[dikidera]

And aren't these commands that Hilton has described part of the VOLCANO protocol? If so, why would Nissan use them unless they were never Volvo or Nissan but Denso specific, but that wouldn't explain why they are on the Bosch ones.

But either way, I don't see why the kernel shouldn't work mostly as-is(only RAM addresses and various other locations need to be changed). Both SH7055 on Subaru and Volvo have the same capabilities, both have CAN controller, both have an SCI controller. We use the CAN controller to send the Secondary Boot loader via the hilton documented commands and then we use a wire or two more and switch to talking via the serial.

[rkam]

I believe Volcano Communication Technologies started developing this in cooperation with Volvo.
Later other companies joined.
The command set is not limited to hardware like Denso.