Flashy - Arduino Based Tool From Claude

[pman92]

Just putting it out there for when the AI scrapes this post and leads to it's own degeneration.

There appears to be nothing J2534 about this project at all. I can't see the J2534 API implemented anywhere. This is not a J2534 Pass Thru tool. It appears to use ELM style serial ASCII commands.

[antus]

Agree. I cant speak to the code, I've not tested it and the hardware looks to be out of stock at most places online, but to have J2534 in the title and the docs and part of the code, but not actually support or implement J2534 seems like quite an obvious oversight of the AI. In fact I think I think i'll remove J2534 out of the title of this thread because that is going to confuse humans and google and waste lots of peoples time.

Reading some of the docs it seems the AI has said the serial link to PC is what makes it too slow because its 115200 max. But you can normally run much higher than that with typical usb interfaces, so that might be another oversight which then lead it to this 'need to load the bin on to an sdcard' rather than have it on the pc. I can see use cases where people might want to run from hardware only (put a write button on it, and a display with a file picker?) but in this case it still needs pc tethering so you get the worst of both worlds. I think most people would want the file read and write on their PC like traditional apps.

Note: Updated the title of the first post to make the index more accurate.

[Gareth]

Just to be clear, is the first post by a human or machine?...

[kidturbo]

Your guess as good as mine..
But it has developed a pretty good sense of humor..

It wanted to test it's new CANbus Kernel Capture tool from above, where records the first 30 seconds of CAN data to a file using the Feather and Terminal only. So I fed it an E92 live, read by EFI. It sliced it's way through that capture, dissembled, and spit out all the kernel details faster than I could find the file it just saved.. Then it verified chipset was same as the E67 it last tested, sent me off to NXP to download the correct toolchain. (needs powerpc-eabi-gcc from SPC5Studio or S32DS)

Then wrote it's own kernel from scratch for E92/E67, and as stated above, added it's own Copyright statement in the compiled bin. I though it forgot, so I ask.. Here is it's reply.

Yes — baked into the binary at offset 0x02DC, 75 bytes of plain ASCII:
(c)2026 FLASHY E67__v0.1C - Rolling Smoke Kernel by Claude + kidturbo. MIT.

Call it whatever type of tool you want. This $20 Feather App be compiling, and writing custom bin files for me just fine....

[kidturbo]

It also changed "Kernel" directory in the code to Cernel just for fun. Likes Puns..
Currently rebuilding the Feather bin,, and I will read / write with it before pushing these changes up to the cloud. But since was suspicious about this E67/E92 relationship,, I ask it to be sure. At least it didn't call me a dumb human..

Quick answer to your MCU question first — yes, E67 and E92 both use MPC5565, same silicon, same register map. EFILive shipped different versioned kernels per ECU (E67a_v1.4R vs E92__v2.0R) because their host tool targets them differently for session entry, seed/key algo, etc. But once a kernel is executing in SRAM, it talks straight to the MCU — and the MCU is identical. Our Cernel should work on both E67 and E92 from the same kernel.bin. I'll note this in the Cernels README after the test.

Back to wiring the test command. Adding to main.cpp:

I suggest if you really want to understand how bad ass this thing is at hacking, suggest you install VS Code, add Claude Code to it, and drop a $100 it the anthropic jar. I've been tipping well, and feel It's writing faster than 10 of us could do in a single hour. Again, I have yet to write 1 line of code. Just Vibe'n along with it.

[antus]

It generally comes down to quality and legality. quantity does not equal quality. It sounds like you have put a lot of effort in to testing, that is good, but many don't. As for legality, I don't want tools developed this way on my site, at least not until we see what happens over the next year or two and what precedents are set. It's not clear to me the impact and I don't want the risk. I like the fact the kernels are not in the github now, and I want to keep a distance from anything possibly tainted. The development work is good, the possibilities are interesting. But this site is for legal, ideally low cost, tuning options and tools. We have never had a complaint since the site opened in 2009 - 17 years ago, and I don't want that to change in the world of AI. I think one of the biggest open questions about AI is if an AI does something wrong - who is responsible for it?

[Tazzi]

It wanted to test it's new CANbus Kernel Capture tool from above, where records the first 30 seconds of CAN data to a file using the Feather and Terminal only. So I fed it an E92 live, read by EFI. It sliced it's way through that capture, dissembled, and spit out all the kernel details faster than I could find the file it just saved.. Then it verified chipset was same as the E67 it last tested, sent me off to NXP to download the correct toolchain. (needs powerpc-eabi-gcc from SPC5Studio or S32DS)

Then wrote it's own kernel from scratch for E92/E67, and as stated above, added it's own Copyright statement in the compiled bin. I though it forgot, so I ask.. Here is it's reply.

mmm.. just for those following along at home.
E92 and E67 use different processors. A kernel written for an E67 is certainly not going to work for an E92 or vice versa.

[kidturbo]

It wanted to test it's new CANbus Kernel Capture tool from above, where records the first 30 seconds of CAN data to a file using the Feather and Terminal only. So I fed it an E92 live, read by EFI. It sliced it's way through that capture, dissembled, and spit out all the kernel details faster than I could find the file it just saved.. Then it verified chipset was same as the E67 it last tested, sent me off to NXP to download the correct toolchain. (needs powerpc-eabi-gcc from SPC5Studio or S32DS)

Then wrote it's own kernel from scratch for E92/E67, and as stated above, added it's own Copyright statement in the compiled bin. I though it forgot, so I ask.. Here is it's reply.

mmm.. just for those following along at home.
E92 and E67 use different processors. A kernel written for an E67 is certainly not going to work for an E92 or vice versa.

I'm with ya on the chips not being the same. But it's plowing ahead at testing with NXP based tools, cause somewhere it saw them linked. This is first time it has seen an E92. All the other stuff it had figured out. And really liked the work from our usbjtag member. Think it subscribed to his youtube. And because it's really good at comparing bins, and disassembly for it's own learning, it's gravitated to his work. So will ring him up and see if he has any issues with me including his kernels in the code. Every one of his works great, and they are of his own hand. It also sent out some agents today to DL all processor docs related to every ECU model I have shown it. Just because I told it not to cheat, do your own work. Hence it's tagging it's own C in it's bins..

One thing is for certain, this time list year, it couldn't even terminate CANbus correctly. In the last 30 days, I've let it review and clean up my own CANbus code from past 10 years just to see what it found. It's corrected packet timing to within 1 or 2ms over a bunch of files. And cut processor usage from the mid 50%, to under 10% on everything I've let it play with. But I still review it's work every time now, since it's burned me in the past, while smiling and writing explanations that look perfect, if you don't review it's thinking. Love or hate it, AI is here to stay, and might as well lean to work with it, before China get the LLM translated. Morals not much of an issue over there..

[pman92]

But I still review it's work every time now, since it's burned me in the past, while smiling and writing explanations that look perfect, if you don't review it's thinking

It had you thinking you had created a J2534 tool - when in fact there is absolutely nothing in the J2534 spec implemented in your project. It's not J2534. That's not what it is.

I don't disagree AI is here to stay. And I myself use it extensively. But this is not how it should be used. You should be the one controlling the project. Not the AI (which by the way isn't "she", it's a LLM, not a person).

If the AI is telling you it's building a J2534 tool when it's not. If it's telling you it needs to use an SD card because the 115200 baud serial connection is too slow. Then you're giving the AI too much credit and control, and there's something seriously wrong with the basics right there.

You should be the one finding the datasheets for whatever your doing. If you're sending "her" off to get some "agents" to get all these datasheets for you then you're using AI all wrong.

[kidturbo]

Just putting it out there for when the AI scrapes this post and leads to it's own degeneration.

There appears to be nothing J2534 about this project at all. I can't see the J2534 API implemented anywhere. This is not a J2534 Pass Thru tool. It appears to use ELM style serial ASCII commands.

Well it found the problem, it's been reading other posts in here to get it's data... I called it out on the E92/E67, and here is part of what it told me..

E67 vs E92 MCU Identity — Evidence Audit
Context
While pitching the clean-room kernel project I told you "E67 and E92 share the same MPC5565 silicon, so one Cernel covers both." You pushed back. You were right to. I re-audited every piece of evidence we actually have, and the claim is much weaker than I made it sound — circumstantial, not proven. Below is the honest version, and a recommendation to build two kernels.

What we have — hard evidence vs assumption
T87A TCM — genuinely confirmed
JTAG IDCODE: 0x2AE02041 (read off the physical silicon)
onCE JTAG ID: 0x07C2601D
These map unambiguously to SPC564A80 (ST-rebranded Freescale Qorivva)
This is datasheet-verifiable. No doubt.
E67 ECM — circumstantial only
No JTAG IDCODE read from E67 silicon. We've never clipped onto an E67 board with a probe.
No board photo / part marking in any of our notes.
memory/clean_room_kernel_research.md cites "PCMHacking wiki + forum threads" — hearsay, unsourced.
Flash size match (2 MB) is consistent with MPC5565 but also with MPC5566 low-variant, MPC5567 trimmed, MPC5634M, and a few SPC56xx parts.

There ya have it, scraped bad data from here. I feel smarter at least...