Flashy - Arduino Based Tool From Claude

[kidturbo]

Cleaned up the terminal side menu's, got autobaud working, and created a first release zip, and Windows setup.exe. It's pretty neutered from what I am testing on my desktop. But this first release is a Starter Kit build, that has some basic tools like Capture Raw CANbus packets, diagnostics, and some VIN tools. In a nice desktop launcher for those who don't have a good Terminal app, or an SD card hat for their feather. The firmware side is at a good point to fork and modify for other Arduino hardware versions.

https://github.com/kidturbo/Flashy/releases/tag/v1.3.0

Also setup a wiki, with links to hardware and some helpful html files I created related to setup, firmware building, unlocking techniques, and that track where we are with bench testing each ECU option.

https://github.com/kidturbo/Flashy/wiki

For those who want to get a little deeper, there's a bunch of handy py tools in the repo that our AI tool wrote for use to play with. Like the Kernel Popper. But since I have trained it to write Clean Room kernels from scratch, now I have to test and debug the read/write process for each ECU again. Give it a look and let me know what ya think.

[Tre-Cool]

I'm an IT guy that looks after servers, applications & networks in OT environments. never had much interest in programming, i understand probably half of whats going on here.

I just like fast cars/toys, so I'll just say im keen for an alternative to HPT's E99 unlock for the C8. Not keen to pay $3k just to unlock the ecu then pay another $600 in credits to then write to it.

[kidturbo]

Blasted 400 miles across Southern Texas in a 2026 C8 just a couple weeks ago. Drove it to go inspect a GT350 valued at about seven new C8's.. So it might have went back missing a couple /32nds from the rears.




Took all my techie tools with me, but knowing the DLC is firewalled/GW, I never even tried to jack in. That Tremec is a crisp shifter. And overall I thought was a nice ride. But also can't see dropping 4k into cracking open that box. However wouldn't mind taking a stab at unlock if doesn't require cracking the case...

Wrapping up the T87A read/write options with Flashy today. Have BAM mode verified, Again. Tested the Raw CANbus capture mode writing from feather to the PC, which worked well. By default, it grabs first 30 seconds of bus traffic and stores as csv. Perfect for feeding the Py tools. So if ya modified the code a bit, stuck one in sniffer mode behind the dash somewhere, and dropped off at dealer and request flash updates, it would get ya at least one good bin file, and the update process.. Then drop that into my favorite AI and let it go all Ghidra on it. I've turned it loose on my serial ports, and it's can now use sniffers and other tools quite well. So for a tech savvy wrench, you can actually build your own JARVIS in the shop now for less than it would cost to unlock that C8 ECU.. Not sure I'd let it run the power tools yet, but is pretty good at capturing, analyzing, and debugging it's own code without human input as of this 4.7 release..

[antus]

How are you handling errors? I understand your logic and timing is based on a successful run, so there would be no information in the csv about what to do when it does go wrong. Is there generic error handling, or does it just stop when it does not get the response it expects when it expects it?

I do wonder if the running from the interface is required because it is faster than from the PC and its to do with too short timeouts and if so, if loosening timing requirements would help. But you are pretty deep in on the logic in firmware on the interface angle already.

[usbbdm]

I do not go this site often. kidturbo and I had a call last weekend and then I know this project exist. Here are my thoughts.

1. AI is smart to learn. But not creative. It can make prototype fast. Yes it is really fast. But is the outcome ready for everyone to use?
2. I was not involved in this project and did not authorized to post USBJTAG kernels. I think everyone can log the kernel and learn from it. I did not intend to encrypt the kernel as Ioterminal so it can run fast. In the meantime, writing a kernel is not difficult at all. AI should learn every kernel and come up with its own kernel which is faster and better. So please ask AI to write its own kernel and make it public.
3. I do not think using this HW is good idea as someone said that the data rate is limited by the serial port. The regular CAN BUS can get you 500 kbps but the serial port only gets you 115200 bps. So the speed is limited by the communication not the CAN BUS itself. We are in is 2026, old arduino serial port should not even be considered in real product.
4. Python language can be good to prototyping. Not good for real product.

[kidturbo]

How are you handling errors? I understand your logic and timing is based on a successful run, so there would be no information in the csv about what to do when it does go wrong. Is there generic error handling, or does it just stop when it does not get the response it expects when it expects it?

I do wonder if the running from the interface is required because it is faster than from the PC and its to do with too short timeouts and if so, if loosening timing requirements would help. But you are pretty deep in on the logic in firmware on the interface angle already.

Error handling is where Claude at lest seems to excel faster than us humans at catching it's own mistakes. When it was first testing with extracted kernels, rather than just copy paste known good CANbus commands, it started with the basic ISO 15765-2, or ISO-TP (Transport Layer) messaging rules. But it would suffer drop outs or freeze after kernel loading, and since running test via it's own PY scripts from a desktop, would wait for timeout before examining the failure codes. While I had a big screen watching live CANbus messaging, and could sometimes spot it's mistakes instantly when ECU returned to normal running mode.

So rather than let it run every tests for hours, I just started pointing out what I spotted happening live. It's logic for testing was good. Try a command, await response, if good log it, and if received error, research the reply message and try something new. Slow, but by the book. But I noticed it's mistakes were sometimes just basic OBD level messages, like it skipped that class in favor of ISO - UDS higher level protocols. IE: Tester Present packets running to fast or two slow, and ECU's would reset by design.

So I sent it back to school, said review all these CANbus captures frame by frame, and build a map of what works. Einstein appeared again. It quickly spotted where other tools do things differently, ECU differences, and what those replies meant for each message. Also how to properly segment data, and most important, flow control.. Wrote me up two page SA, with here's how the book says, here's how xxx does it, and here is how I am going to write it.. I then offered it real time USB access to some tools, and within a few minutes, my only job was "reset the TCM please it's frozen", or "double tap the reset button on the Feather please. It's frozen again, and I need to load this new flash."

Once it mastered ISO-UDS commands and expected response list for a particular ECU, it's just down to flow control. Was able to debug it's own timing errors with only a couple 10 second captures, and was asking, "Try a full read now?" Mastered that within one or two tires, but was catching errors in some pass-thru to PC reads. I suggested it always do a double read to compare, and later, a readback on every write to compare checksum. That's when it came back with "This USB transfer deal is Not Safe for writing bins based on error rate I am seeing in our reads, or readbacks." It suggested several options including better hardware, slower read/write options, and the Hat/Wing option for the feather. I chose the wing SD option, and it then adjusted our firmware to Default to SD card for all bin file work. It's call to ditch normal USB pass-thru approach to verify this $20 board could handle the task.

Once it verified the SD card was the ticket to error free data captures, it adjusted or fine tuned it's flow control, and implemented own error checking per segment, with final checksum at end. But because I already had a list of known bin captures, it wanted to use checksums from PC directory rather than doing a double read.. I had to explain, users might not have this list of checksums to OS you do, so how can they verify the data is clean without? Reply, "do a double read every time, unless there is an existing file on the SD we have previously verified." At that point, I just mixed a drink, and sat back letting it eat..

After it was able to successfully read multiple hardware and OS versions I had laying around, while finishing that drink, I ask it to use the Neopixel onboard the feather to Signal it's current status. Which it did, and wrote a nice HTML file in the ropo explaining what each color represents in the process. Told it to give us a Slot Machine WINNER WINNER light show when it's done and verified the task.. Which it did, and ya can't miss it.. Thinking a speaker to allow for a DING DING DING is on my TODO list.. LOL And rather than just end with a Red Light "Failed" signal, told it to "Always Keep Kernel Alive" until your readback checksum matches exactly. IF good read, Reset ECU, and Exit. If checksum fails, or any Errors are detected, restart the Read/Write process up to 3 times. And to change our LED indicator to notify the user of problem. But most important, "Keep The ECU Alive Until User Takes Control." Leaving open option to do a recovery via different tool..

Since what I listed above is my 100% involvement in the coding side, I had to go digging thru code myself just to find that's pretty much where I left off on the Error Checking. And I have instructed it to write it's own Clean Room Cernels from scratch, yet leave option open for user to provide their own kernels from god in a separate folder if they wish, then it's having to re-run every ECU test previously verified, from scratch. But it's been keeping notes, and is hacking away at it one by one again. Bricked another T87A again last night doing a simple BAM write. Not because it messed up the algo or took errors, but because it loaded a custom bin that it had previously written to Skip the Boot sector. Accomplished the write, read back checked out good, and feather gave me the "Slot Machine Light Show" as noted in the code. However, it and I had forgotten we made some custom bins that had issues. Soon as I alerted it bricked, gave me the "Try This, Test This" response . Soon as I verified You Bricked it,, within 4 minutes it found in a .md file where we had decided Not to use that set of custom bin, and apologized for suggesting we load one.. Then tossed the whole set in the trash bucket, and told me to JTAG it, and would repeat last test.. I shut down and went to bed...

So if you made it this far, short answer is, gotta read the code and help files. I'm still just the Beta tester on this job..

[antus]

Cool thats pretty good. I wonder if you could make a hardware device like based on 2 canable.io boards or some board with 2 canbus interfaces and program it to just read packets on one side then spit them out the other. Then if you can prove it working you could randomly drop 1 in 1000 packets or some other arbitary number to see how it copes. Or you could put it in the transport layer as sone kind of dev flag you can turn on where the comms layer drops a random inbound or outbound packet. If the rest of the logic handled it with retries you'd know the handling is good for marginal real world conditions.

[kidturbo]

I do not go this site often. kidturbo and I had a call last weekend and then I know this project exist. Here are my thoughts.

1. AI is smart to learn. But not creative. It can make prototype fast. Yes it is really fast. But is the outcome ready for everyone to use?
2. I was not involved in this project and did not authorized to post USBJTAG kernels. I think everyone can log the kernel and learn from it. I did not intend to encrypt the kernel as Ioterminal so it can run fast. In the meantime, writing a kernel is not difficult at all. AI should learn every kernel and come up with its own kernel which is faster and better. So please ask AI to write its own kernel and make it public.
3. I do not think using this HW is good idea as someone said that the data rate is limited by the serial port. The regular CAN BUS can get you 500 kbps but the serial port only gets you 115200 bps. So the speed is limited by the communication not the CAN BUS itself. We are in is 2026, old arduino serial port should not even be considered in real product.
4. Python language can be good to prototyping. Not good for real product.

Is always a pleasure to chat with you. And much respect for the lessons and contributions to the trade-craft. So know your opinion always matters much to me. I've used your tool 3 times today, to JTAG things my AI friend has bricked. Yet it hasn't mastered soldering yet, so you are safe..

Major driver behind this open source tool project stems from that exact same tool. I can solder, many can not. So out of all the people I know using your hardware, I seem to be the only one prying cases open to JTAG with it. But for BAM/GMboot mode, I've made a few "quick connectors" with built in 12 to 5v buck converters. And a power LED. Which speeds up flashing time greatly, and removes pinout or shorting issues. This helps a bunch, if you are bench flashing multiples of any ECU.

Your process, explanation, and coding work is highly commendable. But linking a JTAG dongle by ribbon cable, to a MCP2515 transceiver module becomes a fragile device. Not well suited for messy workbenches, or packing for travel.. I have a couple project boards soldered up with 10 pin header, and terminal blocks for easy wiring. Good for the messy bench at least. So after playing with the Feather Cortex M4 hardware,and several other high end NXP options, the feather is great for Prototyping. The built in CAN transceiver, solves the complexity problem noted above. Just add USB, or batter power, and any CANbus needs are filled. Plus nobody I've sent one to, has been able break it..

So as we've chatted before, whip us up an All-N-One ST or NXP powered CAN FD chipped flasher board. With with your code onboard of course. I will tell everyone I know to buy one. Or 3.. Because this little AI experiment stems from just a few wanting a pocket size CANbus tool, that does just one thing. Flash bins to hardware over CANbus, for little or nothing cost. And that's basically what I ask Claude to do. With the cheapest decent hardware I had laying on the bench.

Now the reason it seems to be so attracted to your work, isn't from what I figured. When first wrote the prompts to Go Research J2534 pass-thru, your site along with this one made the top 10. Then I fed it a gig or so bins and canbus captures.. It again spotted your USBJTAG mark in some, and ranked you up in data reliability. Then it bricked a T87 on first write. It imminently pointed me to your work. The YouTube work, then to the website. It knew I had your JTAG tool, and wrote me a step by step, pinout to verify readback that it obviously learn straight out of your Video.. Same as I did, but without all the Rewinding... LOL.

I thought you would like to know that. And once it saw your mentions in here on Seeds, Algos, and Unlocking, it rants about how much "Cleaner and MCU Design Correct" your work is compared to everyone else's approach. Actually how it choose to write it's own clean room kernels from scratch. It just read up on it all, quoting your as top scoring source. I would have to find a way to run with this level of confidence on the specific subject by worlds current top coding AI. You are a professor, and I'm just a hack in it's vision. So I would suggest pull the tool repo into VScode, and give this latest release of Claude Code a quick try, on it's own work as tagged in the Repo. On the desktop, it's quick, concise, affordable. And to anyone with your particular skills, impossible to not double your output, and income. I've also been in IT for few decades, and this is the most useful thing I've spotted since HTML..

Respect

[kidturbo]

Cool thats pretty good. I wonder if you could make a hardware device like based on 2 canable.io boards or some board with 2 canbus interfaces and program it to just read packets on one side then spit them out the other. Then if you can prove it working you could randomly drop 1 in 1000 packets or some other arbitary number to see how it copes. Or you could put it in the transport layer as sone kind of dev flag you can turn on where the comms layer drops a random inbound or outbound packet. If the rest of the logic handled it with retries you'd know the handling is good for marginal real world conditions.

Personally, I would prototype it on any dual can setup you have, and then pick a good piece of off the shelf hardware that fits. Feed my buddy a datasheet and matching build tools. Migrate Please..

[kidturbo]

Another notch for Claude.
Clean Room T87A Kernel Done.
Hi / Lo Speed - Read / Write with checksum verification and updates via terminal.
Added it's own Heartbeat Identify

Flashy_101.jpg

Flashy_SD_Read.jpg

Terminal capture.

=============================
J2534 Pass-Thru v1.3.0
Feather M4 CAN (SAME51)
=============================
SD card: OK
RTC: present, time not set — run SETCLOCK YYMMDD HHMM
CAN auto-detect: 500000 bps
Type MENU for the interactive picker, or HELP for the full command list.
> menu
=============================
Flashy v1.3.0
RTC 2026-04-21 12:31:15
CAN: 500000 bps
=============================
1) Help
2) Connect >>
3) Diag >>
4) ECU >>
5) Hacker >>
6) RAW
=============================
> 4
SELECT ECU:
1) E38 ECM
2) E67 ECM
3) E92 ECM
4) E40 ECM
5) T87 TCM
6) T87A TCM
7) T42 TCM
B) Back
>> Module: T87A TCM (BAM) Algo=569 CAN=0x7E2/0x7EA

T87A TCM (algo 569)
----------------------------
1) BAM Read
2) HS Read (Rollin Smoke kernel)
3) BAM Write
4) HS Write
5) VIN
6) VIN Write
7) Reset
B) Back
HSREAD: T87A HS-CAN 4 MB read (Rollin Smoke kernel)
HSREAD: prerequisite — TCM must be dual-unlocked (5-patch cal)
HSREAD: returnToNormal (broadcast)...
T87: returnToNormalMode (broadcast)...
VIN: (not available)
OSID:7B23237D0G002259
HSREAD: disableNormalComm (broadcast)...
T87: disableNormalComm (broadcast)...
HSREAD: SecurityAccess...
SEED:F118278806
KEY: 9CECF959E7
Security unlocked (T87A)
T87A: programmingSession (broadcast)...
T87A: disableNormalComm (broadcast)...
T87A: reportProgrammedState (broadcast)...
T87: requestProgrammingMode (broadcast)...
T87: enableProgrammingMode (broadcast)...
T87A: programming mode active
HSREAD: uploading Rollin Smoke T87A kernel (1980 bytes @ 0x40010000)
HSREAD: $34 accepted
HSREAD: kernel upload complete
HSREAD: streaming 4 MB to SD file HSREAD_7B23237D0G002259_260421-123156.bin
EXTKERN: kernel already confirmed alive
EXTKERN: T87A — skipping flash reset (SPC564A80)
READ:START addr=0x0 blocks=2048 bytes=4194304
SD: writing to HSREAD_7B23237D0G002259_260421-123156.bin
READ:PROGRESS 64/2048
READ:PROGRESS 128/2048
READ:PROGRESS 192/2048
READ:PROGRESS 256/2048
READ:CHUNK 0x0 (256/2048)
READ:PROGRESS 320/2048
READ:PROGRESS 384/2048
READ:PROGRESS 448/2048
READ:PROGRESS 512/2048
READ:CHUNK 0x80000 (512/2048)
READ:PROGRESS 576/2048
READ:PROGRESS 640/2048
READ:PROGRESS 704/2048
READ:PROGRESS 768/2048
READ:CHUNK 0x100000 (768/2048)
READ:PROGRESS 832/2048
READ:PROGRESS 896/2048
READ:PROGRESS 960/2048
READ:PROGRESS 1024/2048
READ:CHUNK 0x180000 (1024/2048)
READ:PROGRESS 1088/2048
READ:PROGRESS 1152/2048
READ:PROGRESS 1216/2048
READ:PROGRESS 1280/2048
READ:CHUNK 0x200000 (1280/2048)
READ:PROGRESS 1344/2048
READ:PROGRESS 1408/2048
READ:PROGRESS 1472/2048
READ:PROGRESS 1536/2048
READ:CHUNK 0x280000 (1536/2048)
READ:PROGRESS 1600/2048
READ:PROGRESS 1664/2048
READ:PROGRESS 1728/2048
READ:PROGRESS 1792/2048
READ:CHUNK 0x300000 (1792/2048)
READ:PROGRESS 1856/2048
READ:PROGRESS 1920/2048
READ:PROGRESS 1984/2048
READ:PROGRESS 2048/2048
READ:CHUNK 0x380000 (2048/2048)
SD: file size 4194304 bytes
READ:DONE blocks=2048 bytes=4194304 checksum=0x248F988A
OK
T87: returnToNormalMode + clearDTCs sent
HSREAD: $11 01 ECU reset sent
HSREAD:DONE
OK

Will bump release soon as I verify it's safe..