Use ESP32 Web interface also as GVRET CAN device?

[RetroZero]

So I tried to simply flash the ESP32-S3-Pico using Arduino with the https://github.com/uhi22/wifican code, but there is an error message regarding Flags when I verify the code before flashing.
Has something changed in the code?
Here is the message - Compilation error: redefinition of 'int esp_intr_flags_to_level(int)'
Thanks in advance for checking.

[uhi22]

To find out the changes of the code, there is the commit history in github. https://github.com/uhi22/wifican/commits/main/
This shows, that there are no changes since two months.
I can only guess, maybe an incompatible library or board was installed.

[RetroZero]

Thanks, I'll erase everything and start again.

[RetroZero]

Spend a few hours erasing everything Arduino and installing fresh one. I can download from examples, like checking chip details, but same error message when compiling wifican. This has got me stumped.

[uhi22]

Is the error message still the same "Compilation error: redefinition of 'int esp_intr_flags_to_level(int)'"?
This would mean, that something in the Arduino IDE or in the board support for the ESP changed, so that this function is now visible twice to the compiler. One instance is in the project code, in esp_intr_alloc.h. You could try two things:

1. Completely delete the following part of esp_intr_alloc.h
static inline int esp_intr_flags_to_level(int flags)
{
return __builtin_ffs((flags & ESP_INTR_FLAG_LEVELMASK) >> 1) + 1;
}
and try to compile again. If now the error message is "esp_intr_flags_to_level not found" or similar, then the next step is to assure that the function is visible only once, by adding a check whether it is already defined:

#ifndef esp_intr_flags_to_level
...here is the original function ....
#endif

[RetroZero]

Thanks, I'll try that. There has been upgrades in Arduino lately. Might be that.

[RetroZero]

For info, I have even more error messages. I'll try again to uninstall all Arduino files and folders today.

[RetroZero]

Really dissapointed with my setup (and lack of fundamental knowledge) . I 'gave up' on trying to setup a second board, as I can't even get the original wifican scketch to upload without error messages. Numerous Arduino uninstallations etc etc. The CanCrocodile will have to wait.

Now, things seem to have gotten worse. The original ESP32/Wifican setup runs great with direct connection CanH and CanL sniffing an instrument cluster on my desk. Even can make the Rev counter move to various positions.
To feel like I am 'moving forward', I decided to connect it to my Golf 6 Comfort Can Bus. Guess what, no data is being captured. I tried connecting after the Diag socket (the front door junction and the Body Control Unit) - nothing. Swapped CanH and CanL around, even the RX and TX.
I tried various speeds - nothing.
Is it possible that I need to remove/shunt the SN65HVD230 onboard 120 Ohm resitor?
In the meantime, the VW charger and Charger flap sit waiting gathering dust.

[uhi22]

There are multiple CAN busses in this car. You write "after the diag socket", this sounds like the diag CAN, and this is silent if you did not connect a diagnostic tester to the OBD socket. The komfort CAN you find eg in the front doors.

[RetroZero]

It's the comfort can in the front door. I also tried at the body controle unit (comfort).

[uhi22]

Some ideas:
1. check whether you found a CAN bus. While disconnected the battery, use an ohm-meter to check the resistance between CANH and CANL. Should be around 60ohms, because the CAN is nominally terminated with 120ohms at each end. May be ok to see something between 120ohms and 50ohms.
2. using a two-channel-oscilloscope, check the CANH and CANL while the car is turned on. You should see both lines on the same level (around 2 to 3V) very often ("recessive state"), and should see the CANH going at least 1V up and in parallel going CANL 1V down ("dominant state"). The width of the pulses should be multiples of 2µs in case of the usual 500kBaud.
3. check the CANRX of the transceiver. Using a two-channel-oscilloscope, one channel on CANL, one channel on CANRX. The CANRX should show the same signal as CANL, but with higher amplitude (0V dominant, 3.3 or 5V recessive).
4. check whether the CAN controller sends an ACK bit: Using two-channel-oscilloscope, one channel on CANRX, one channel on CANTX. Most of the time the CANTX should be at high level (3.3 or 5V). At the end of a message on CANRX, the CANTX should have a single low-pulse (2µs in case of 500kBaud). This is the ACK bit. If this is visible, the CAN controller is correctly configured with the correct baud rate.

[Jacobsmess]

not sure if this is the right place of not but a Q on the wifican by Uhi, will it support FT-CAN (125kbps) in it's previous (April 2024 commit) form? I tried sniffing the canbus on my 2005 VW T5 yesterday and I only got data on the powertrain CAN netowrk which is 500kbps, whereas the BCM CAN is 125kbps I'm told.
It may be that I just need to try the lower speed in SavvyCAN

[Doig5710]

Maybe or find some different canbus wires in the vehicle, try at the heater module or back of radio

[uhi22]

will it support FT-CAN (125kbps) in it's previous (April 2024 commit) form?

I cannot tell, I only used 500kbaud. The baud rate setting is quite messy, there are good chances that it does not work to change the baud rate via SavvyCAN. You could compare the latest and the april version to find out, which places I changed to change the baud rate. But I'm not even sure, whether all these places make sense. Sorry, quite a mess.