trying to make this work with innovis 500d

[bezmi]

I have inherited an old innovis 500d and I'm trying to get my version of this PCB (created to use whatever microcontrollers I had lying around) working with the machine. My PCB uses a teensy 3.5 to program the same sst39 flash chip.

After flashing image.bin from this repository onto the flash chip and plugging into the card slot, nothing happens. I noticed that on my machine's card reader PCB, the PRE_TOP pin is connected to GND. Booting up with JP1 bridged, I get "This embroidery card cannot be used in this machine" when trying to access the menu. I have also tried generating my own image.bin via PED-basic and your cracker.py script which outputs a ~64KB image.bin. I get the same error when trying to use this file. I have also tried the teddy bear putty.txt which you posted on the EEVBlog forum, same message.

I am fairly certain that this machine should be working with the 100x100mm hoop size in PED-basic with a 4M card, so kind of lost with what to try next. Thought I'd raise an issue here before going through the wait for a 2nd hand card to arrive via ebay for reverse engineering purposes. Any ideas?

[bezmi]

Thought I'd update with a clarification of the behaviour I'm seeing with cracker.py. It always seems to generate a 64KB image.bin, no matter how many designs are selected. After the "please wait a while..." progress bar when clicking the write to card button. PED-Basic closes. I have attached the output from cracker.py which is printed in the terminal. I have also attached the image.bin that is generated for the "assortment.pes" built-in pattern. If you could test this on your machine to confirm whether it is detected correctly, that would be a great help in ruling out the software side of things for me.
image_bin.txt
cracker_output.txt

[bezmi]

Just an update. I was able to get the kirby image.bin uploaded and recognised, however, the images using cracker.py were still not working. I changed the value on line 70 to 0x80000 to get a 512KB file. I then overwrote the header (offsets 0x000 to 0x180) with the one from the kirby file and the files show up.

I noticed that the 'b' in the 'brother_sewing' (offset 0x100) part of the header was 0xFF instead of 0x62 for 'b', so I made that change and the files show up.

[jridey]

I noticed that the 'b' in the 'brother_sewing' (offset 0x100) part of the header was 0xFF instead of 0x62 for 'b', so I made that change and the files show

Glad to hear that you got it working!

0x80000 to get a 512KB file. I then overwrote the header (offsets 0x000 to 0x180) with the one from the kirby file and the files show up.

I'm surprised that this works, the current patches assumes that the card is the smallest size and so they skip over some checking code and pick the smallest card size to take that code execution path.
When I get some time, I'll see if I can harden the cracker.py file up a little and maybe add options for card size and loop size.

[bezmi]

I'm surprised that this works

Yeah that makes two of us. The image I made with two of the default patterns contains data out to 1B5E0 and then FF for the remainder.

Any idea why the header would be mangled in the first place? I tried to get into the guts of the dll but didn't get too far.

I would like to take a crack at writing a script to generate the image from a PES file without the dll. You mentioned on the eevblog thread that you were able to read out stitch data after adding an offset, so that part shouldn't be too difficult, do you know whether there is metadata about the files stored in the flash - such as size, number of files, etc? Is it just reading the whole thing at boot and calculating it that way? The short header at the start also seems to have some data in it.

[AeroX2]

I would like to take a crack at writing a script to generate the image from a PES file without the dll.

Yeah I would love for this to happen as well, just when I was browsing around the decompiled code it seemed quite complicated with a lot of moving parts (plus I'm quite a novice when it comes to reverse engineering), so I eventually took the route of just hooking into the DLL.

do you know whether there is metadata about the files stored in the flash - such as size, number of files, etc?

There were some references to size and number of files but I couldn't really follow the logic on where it places it and how, probably just needs more eyes to look at it.

[bezmi]

I have been taking a look at the generated files themselves. Take a look at my repo. The experiments.ipynb notebook contains some code to go through the files and plot the data as a bitmap. You can see that there are a lot of UI elements stored on the card along with the thumbnails from the PEC file before the stitch data.

[bezmi]

Hey mate, I have taken a bit of time to trawl through and understand the structure of the binaries. See my notes here. I think this should (probably) be enough to get started on testing with an image writer program. I'm waiting on a replacement FFC cable after I broke the last one by taking the machine apart too many times - once that's done I'll make a start on the software.