WiCAN Pro Wireless J2534 Pass-Thru Driver - Custom Firmware & DLL

[nightjoker7]

Hey everyone,

I've been working on a custom J2534 Pass-Thru driver and firmware for the **WiCAN Pro** device. Wanted to share what I've built and get some feedback from the community.

### **What is it?**
A fully wireless J2534-1 compliant Pass-Thru interface using the WiCAN Pro hardware. No USB cables needed - connects over WiFi to your laptop while plugged into the OBD-II port.

### **Hardware**
- **WiCAN Pro** - ESP32-S3 based with 8MB PSRAM
- Built-in STN OBD chip for legacy protocol support
- WiFi AP mode (creates its own network) or Station mode (connects to your network)

### **Supported Protocols**
| Protocol | Status |
|----------|--------|
| CAN (ISO 15765) | Working |
| ISO 15765 (UDS) | Working |
| J1850 VPW (GM) | Via STN chip |
| J1850 PWM (Ford) | Via STN chip |
| ISO9141 (K-line) | Via STN chip |
| ISO14230 (KWP2000) | Via STN chip |

### **Key Features**

**Performance Optimizations:**
- **PSRAM buffers** - 128 message RX queue, 8KB ISO-TP buffer (vs typical 32 msg / 4KB)
- **TCP_NODELAY** - Disables Nagle's algorithm for lower latency
- **64KB socket buffers** - Handles WiFi latency variations without blocking
- **Write batching** - Consecutive frames sent as single TCP packet (critical for ECU reprogramming)

**J2534-2 Extended Protocol Support:**
- CAN_PS, SW_CAN_PS, CAN_CH1, CAN_CH2
- ISO15765_PS, SW_ISO15765_PS
- All mapped to base protocols automatically

**Other Features:**
- Periodic message support (TesterPresent, etc.)
- Flow control filter support
- Functional addressing (0x7DF broadcast with response collection)
- TX echo with proper RxStatus flags for subnet discovery

### **Current Status**
- Basic diagnostics: Working
- Reading DTCs: Working
- ECU identification: Working
- Flashing/reprogramming: Testing in progress

### **Known Limitations**
j1850 vpw 1x only

### **Download / Source**
GitHub: https://github.com/nightjoker7/wican-fw ... a-04-j2534

Includes:
- Custom firmware (.bin)
- Windows DLL (32-bit and 64-bit)
- Install script and registry entries

### **Why Wireless?**
For those wondering - being able to sit in the car with laptop on your lap, no cables running to the OBD port, is genuinely useful. Especially for testing while driving or when the OBD port location makes cables awkward.

Let me know if you have questions or want to try it out!

[antus]

Hi, thanks for posting. An interesting project. I am interested in the VPW support. I see that it only has 1x due to STN chip being used. That is less than ideal, but it's still functional. I am considering PCMHammer for VPW PCM reprogramming over VPW. That will use up to 4k VPW packets. Also, it does not support WIFI. However it does support J2534. I had a look at the driver, so I expect one would install that, then select this device as J2534 in pcmhammer, then proceed to communicate as through it is a streaming J2534 device. And the J2534 driver would take care of the wifi communication layer. How does this work when the underlaying driver is a polling STN device? Does the firmware / J2534 driver translate between J2534 and the OBDLink proprietary protocol for large packet sizes? Can it listen without transmit like J2534 supports?

[nightjoker7]

Thanks for the interest! Let me answer your questions:

How it works:
You install the J2534 DLL, select "WiCAN" in PCMHammer, and the driver handles all WiFi/TCP communication transparently.

For CAN-based protocols, the ESP32's native TWAI peripheral handles CAN directly - fast and efficient. For legacy protocols like J1850 VPW, the ESP32 translates J2534 commands to STN AT commands for the OBD chip.

Large VPW packets (4K):
The firmware implements USDT multi-frame handling for large J1850 messages, similar to how ISO-TP works for CAN. I've successfully tested ISO-TP with CAN-based ECU programming (4K+ transfers work fine). The J1850 USDT code follows the same pattern but hasn't been validated yet with actual VPW programming - just diagnostics so far.

Listen without transmit:
Yes, pass filters without flow control filters allow passive listening.

Limitations for VPW specifically:

Single channel - STN chip limitation
WiFi + STN polling adds latency
VPW programming is untested territory
If you try PCMHammer with VPW, I'd be interested in the results!

Screenshot 2026-01-02 085659.png

[antus]

Ok cool. I dont have the hardware to test, but I do have the supported pcms and the ones were still working on. But if USDT is what I think it is for multi frame can packets its not going to work for vpw. That doesnt exist and the j2534 interface just sends long (up to 4112 bytes) single packets. All the PCMs use mode 36 to receive a flash kernel to run on the pcm from the pc, and some have a sub mode of 80 which is an execute bit. So those PCMs can load the kernel in multi part then execute on the last one. Other PCMs (P04) dont support that so we first send our own loader that does support it then enter the normal process. loader is ultra small to fit in one packet on the smallest devices which is the scantool with 512 bytes payload only. 2k plus header and checksum overhead is typical for most devices but 4112 is ideal.

[nightjoker7]

Thanks for the clarification - that helps a lot!

WiCAN's current J1850 VPW setup:

Buffer sizes: DLL handles up to 4128 bytes, firmware buffers up to 4096 bytes - should cover the 4112 byte requirement
STN chip limitation: Can't do 41.6k VPW (hardware limit). We intercept the $A1 speed-switch command and fake the $E1 response, so both WiCAN and ECU stay synchronized at 10.4k
The 4X workaround (untested):
The theory is: if we never forward $A1 to the ECU, both sides stay at 10.4k and communication remains valid - PCMHammer just thinks it's faster than it is. Whether this actually works with PCMHammer's timeouts and the much slower throughput... we don't know yet.

Questions for you:

Does PCMHammer have hardcoded timing assumptions based on 4X speed? (e.g., "kernel upload should complete in X seconds")
What's the largest single PassThruWriteMsgs() payload you've seen for VPW Mode $36 transfers?
For the P04 loader that fits in "one packet on smallest devices (512 bytes)" - is that 512 bytes of raw VPW payload, or does that include framing overhead?

[nightjoker7]

If anyone downloaded the code recently, please delete it and redownload it had to revert a few changes that broke anything using the stn chip.

[antus]

4k wont be enough for 4k payload because its 4k payload, 2 bytes additional block sum, plus priority+source+dest+mode+submode+3 bytes address+2 bytes length and the interface would generate vpw crc. EG 4k+12+interface generated and appended 8 bit CRC.

Havimg said that I think we limit j2534 to 2k payload because some other interfaces can only do 2k plus overhead and its better for compatability with marginal speed loss (1 extra packet overhead / turnaround time per 4k of data). Overheads at 512 bytes payload are the same.

You can build pcmhammer and look at the kernel / loader sizes yourself or grab the latest from the actions on github and look in the zip. There is no garuntee sizes wont change, but what is there is pretty stable. I do expect to add a few bytes to handle an ascii OSID for a new pcm in the next month or 2. will be about 15-20 bytes in the p05 kernel and future p11 kernel maybe.

I think the fake 4x will work. It might confuse users and will make it harder for us to support though. It'll be better if users toggle 4x off in the device setup. That is just a flag and it skips that step. There isnt timeing requirements in the app. At the moment it skips 4x for stn but its speaking stn ptotocol to that device and knows what it is, but it doesnt know what j2534 device its connected to.

Have you heard of the allpro adapter? That was open source hardware and we added 4x to it, but then the developer took it down. I think it was a hobby for him and he might have got too much interest from tuners. The code is still around, you could look at using that code / hardware and keep it all open and with 4x support. Its an NXP LPC chip. https://github.com/antuspcm/allpro/tree/4xj1850 https://hackaday.com/2016/03/27/open-so ... i-adapter/ Schematic in the PDF. Image from my archives, I am no longer using allpro as I don't want to be part of hardware manufacturing and there is no supplier. OBD XPro has that covered. I have other information saved away too if you want to consider allpro firmware based options. Others were critical of the circuit, but you are using your own off chip hardware anyway. Thinking about it some more, at least for VPW, you are probably better off implementing a streaming protocol more similar to J2534. Trying to fit a streaming type protocol in to a polling protocol is a mess, and it'll work much better if it's native J2534 and you pretty much have that to begin with. If you can bit bang it out a GPIO or have some small support IC that you can run your own firmware on, you don't even need to implement the elm/allpro/scantool protocols.

[nightjoker7]

making some progress using the 1x vpw
Loading kernel from MIC3624_v2.3.07.beta4\PcmHammer021.2\Kernel-P01.bin...
Kernel size: 7890 bytes

Requesting upload permission...
Actual size: 7890 bytes, Claimed size: 4096 bytes
Address: 0xFF8000
Sending: 34001000FF8000
Response: 6C F0 10 74 00 44 1E
SUCCESS: Upload permission granted!
Total blocks: 247

Uploading kernel (backwards, highest address first)...
Block 247/247: 0xFF9EC0 (18 bytes)
Block 197/247: 0xFF9880 (32 bytes)
Block 147/247: 0xFF9240 (32 bytes)
Block 97/247: 0xFF8C00 (32 bytes)
Block 47/247: 0xFF85C0 (32 bytes)
Block 1/247: 0xFF8000 (32 bytes) [EXECUTE]
All 247 blocks sent!

Verifying kernel is running...
Response: 6C F0 10 7D 00 01 03 05 01 1B
SUCCESS: Kernel is running!

Reading flash: 512KB starting at 0x000000
Reading 0x003C8C - 0x003E7F (3%, ETA: 650s)

[nightjoker7]

** MAJOR UPDATE: 4X VPW IS WORKING! **

I can't believe I'm typing this, but **we got 4X VPW working on the WiCAN Pro!**

After a marathon debugging session, I can confirm:
- 4X permission request (Mode $A0) - **ECM responds with $E0**
- 4X mode switch (Mode $A1) - **ECM switches to 41.6k**
- Interface baud switch (STPBR 41600) - **MIC3624 supports this!**
- Kernel upload at 4X speed
- **Full 512KB flash read at 4X speed**

### The Breakthrough

The WiCAN Pro uses a **custom MIC3624 chip from Jinxusolu** - this is NOT a standard STN chip. According to the OBDLink Family Reference Manual, the STPBR command on genuine STN chips states:

> *"Currently, only the ISO and CAN protocols allow baud rate switching."*

The MIC3624 extends this - **it supports STPBR for J1850 VPW as well**, including 41600 baud for 4X mode. This is a custom Jinxusolu feature not available on standard STN/ELM chips!

**The correct sequence (matching PcmHammer exactly):**
1. Unlock ECM at 1X (Mode $27)
2. Request 4X permission: `STPX H:6CFEF0, R:1, D:A0`
3. Begin 4X mode: `STPX H:6CFEF0, R:0, D:A1`
4. Switch interface: `STPBR 41600`
5. Upload kernel at 4X
6. Read flash at 4X

============================================================
SWITCHING TO 4X MODE
============================================================

Requesting 4X permission from all modules...
> Response: 6C F0 10 E0 AA 7F
SUCCESS: 4X permission granted!

Sending 4X begin command to all modules...
> Response: >

Switching interface to 4X (41600 baud)...
> Response: OK
Current baud: 41667
SUCCESS: Interface at 4X speed!

[...kernel upload at 4X...]

Reading flash at 4X: 512KB starting at 0x000000
Block size: 1024 bytes
Flash read complete! 524288 bytes in 195.1s
Speed: 2687 bytes/sec (21.5 kbps)

============================================================
SUCCESS! Flash read complete at 4X.
============================================================

### Key Technical Discoveries

1. **MIC3624's STPBR supports J1850 VPW** - Unlike standard STN chips (which only allow STPBR for ISO/CAN), the MIC3624 allows `STPBR 41600` for VPW 4X mode. This is the key capability that makes 4X possible.

2. **STPX command** - The MIC3624 has this powerful command: `STPX H:<header>, R:<responses>, D:<data>`. Much more reliable than ATSH+send for large messages with explicit header control.


### Speed Comparison

| Mode | Block Size | Read Time | Speed |
|------|------------|-----------|-------|
| 1X | 500 bytes | ~10+ min | ~5 kbps |
| **4X** | 1024 bytes | **3.25 min** | **21.5 kbps** |

### About the MIC3624

For those unfamiliar - the **MIC3624** is a custom OBD chip from Jinxusolu used in the WiCAN Pro. It presents as "ELM327 v2.3" but has extended capabilities beyond standard ELM/STN chips:

| Feature | ELM327 | Standard STN | **MIC3624** |
|---------|--------|--------------|-------------|
| STPX command | | | |
| STPBR for CAN/ISO | | | |
| **STPBR for J1850 VPW** | | | **** |
| Large message buffers | | | |

This is what makes 4X VPW possible on WiCAN Pro - a standard STN/ELM chip couldn't do this.

### Next Steps

Now that I've proven 4X works at the protocol level, I need to:
1. Update the J2534 DLL to properly support 4X VPW
2. Test with actual PcmHammer (not just my scripts)
3. Test write operations (flash programming)

@antus - The MIC3624's extended command set made this possible. Looking at the PcmHammer source helped immensely in understanding the exact protocol sequence needed. The discovery that STPBR works for J1850 on this chip (unlike standard STN) was the key breakthrough!

[kur4o]

Sounds like great progress. The other huge limitations with elm was multi responses handling, or pending 78 responses till positive 73 is received.

For example you upload code, it starts erasing flash chip and send a message for each sector, 78[wait more, still busy] when done send 73 success. it can take upto 10-15 seconds with 10-15 messages being send[in between 78 messages a 3f tester present message[each 2 seconds] should be sent to keep bus quiet. If that can be safely handled, sps programming with tis2000 should be opened.