DaVinci Junior cartridge reset (Page 12 of 58)

A decent disassembler could still cope with parts of it, and I don't think a stock check should be hard to circumvent, given we have a proeprly disassembled firmware.

On the other hand the bin file does seem to be encrypted. It contains some repeating 16 byte segments, so I guess AES with ECB. Haven't tried to check whether it uses the "classic" password used in encrypting the 3w files yet though

To get the repetier port working on this thing we need a pin trace on the mainboard. If anyone can help out with that it'd be great. I was working a bit on it - got 1 pin traced before my wife found out what I was doing and made a scene about "Jeez! I got you that printer just a couple weeks ago and already you're taking it apart!?" I tried explaining, but, well, the long and short of it is, I'm out for now.

On the upside, the board is only double-sided - no multi-layer. So that should make it slightly easier. If someone has the ability to sniff the chip in-situ while it's running I think it'd go a lot faster than just a visual trace. Depending on the situation, I'll probably be able to get back to tracing in a few weeks (fingers crossed).

Anyway, thanks for all you guys are doing! Hope this thing can get licked soon!

Just a note to all your guys trying to save your so called warranty.. I have said this before but speaking from an experience. In the off chance something happens to your printer that is beyond your ability to repair or acquire parts for XYZ will make you ship the entire printer back to Taiwan at your expense for a warranty claim. Then they will simply send you another one that has been half way repaired like they will do yours when they receive yours.

There is a reason for their low cost. That is low quality and low overhead as they do not stock extra parts for repair. The only parts you can get without an act of congress and a month long chain of emails are those that ore listed on their store.

So seriously consider if such a warranty is even worth the hassle of saving when you are deciding to mod or explore.

Another new user jumping into this effort!

Picked up my Jr right after the holidays with an open box discount.  Fortunately, it appears nothing important was removed from the box.  Since this is my first effort into 3D printing, I was interested in getting the least expensive equipment that was reasonably proven (i.e. I wouldn't have to build/debug myself).  From reading on the subject, there's a LOT to working through the details of successful 3D printing even when the hardware is otherwise doing what it's told.  And, after a few weeks, I can confirm that's the case! 

I'm very impressed with the large amount of progress in a short time.  I too have Arduino sheilds and Saleae hardware ordered and, if you believe them, "in the mail".  I'm interested to see if I can repeat the previous steps of recording the password information and re-writing the NFC card.  Like a previous poster, that's the first thing I'd like to nail down before looking into updating the firmware.  This should open up the ability to choose from an array of different filament colors.  And, at a cheaper cost. 

c4pt1n54n0, the mini sounds like a neat machine.  But, I wouldn't put money on the fact they're getting rid of the drm.  XYZ appears to have/want this as their basis of operation.  I noticed none of the press releases for those machines indicated one way or the other.  Guessing that means business-as-usual.  Also, if we can find ways to upgrade the existing Jr models, how nice would it be to find deeply discounted "old Jrs" as people upgraded to the new ones.

By chance, has anyone backed up the stock firmware from their Jr? I did the update when I first started it up and now would like to try and put it back to what it came with.

Not sure if we knew this or not, but there is an  NXP LPC115F MCU (ARM Cortex M0) that connects physically to the NFC header. The NFC header's data pins do not connect to the Atmel MCU as far as i can tell.

So this little NXP MCU is probably whats handling all of the NFC stuff. The firmware might contain code for both MCU's, which is why it might look weird. If both images are in a single bin, we are looking for a 64K image. It's also possible that this chip is hard coded and the firmware does not write to it.

Regardless i think we could easily sniff the traffic between the NXP chip and the Atmel chip and could reprogram the NXP chip to always repond in a specific way.

Just a theory.

EDIT: Did some more research... First grab one of these https://www.adafruit.com/products/1369

Then dump the NXP chips memory contents, should be able to get RAM and Flash with the J-Link. Next look for spots that are sending / reviving data out of the memory addresses associated with the pins connecting the LCP to the Atmel chip. I wonder if XYZ is encrypting traffic between the two chips or just sending raw bytes.

If it's raw bytes just use the J-Link to program the NXP chip to always return 100. In fact this would make a lot of sense as to why you cant upgrade the firmware from the SD slot and that the firmware doesn't count decimals. The NXP chip is probably limited to one byte responses, so no decimals and 255 would be the highest.

Not dumb, but it is not greatly different than just writing the captured data back to the RFC in the spool.

You are still going to have to sniff the password for the NFC chip off the I2C buss, use that password to unlock and dump the RFC data to your computer, then use that data to program the Amiiqo, then replace the Jr's NFC chip with the Amiiqo.

I think that is one step further than just writing the data back to the Jr's RFC chip.

But if we could decode how the password is generated from the static unprotected data on the Jr NFC then the Amiiqo would become much more useful.

-Cecil

Disabling it is not the way, as others have shown that locked chips are bounced.  It seems to write to the chip, and do a compare in the 'drawing' of the part.

What the best way does is let it write to the chip normally, and the tell the chip that is is back where it started after the whole printing is done.  The software does what ever it wants to.  We just tell the chip to be what it was before the print started.

I have been following this thread with interest, and I am grateful for all the time and effort you are putting forth to free up the Jr.

Regarding the advanced mode, can someone tell me if it is available in the Macintosh version of XYZWare, and, if so, how to access it?

Thanks.

Just some thoughts. Can be chips  s/n be a password?

I understand that, but where is it generated. Does it already exist on a new chip or does it get created when a chip is used? How does the firmware know each password if it is already on the chip?