Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Custom firmware development

I finally managed to run some custom code on my Da Vinci printer. Note that doing this will erase your printer serial number and calibration data. So after you flash your printer back to FW 1.1.I you will need to use DAVSSN command to restore the serial, and then recalibrate the platform.

I did this on my Mac. So my instructions could be wrong/incomplete for the Windows users. I.e. you might need to install additional drivers, etc.

Anyway here is what you need to repeat my experiments:
1 ) Install Arduino IDE1.5.6-r2 BETA (which supports Arduino DUE, same CPU as DaVinci XYZ 1.0)
2 ) Start Arduino IDE, copy/paste my sketch into IDE window (see bellow).
3 ) Turn your printer off, shorten jumper JP4 (ERASE), turn the printer back on. Wait a second. Turn it off again, remove the jumper, turn back on.
4 ) At this point you printer is in erased state, so it will look exactly like erased Arduino Due. Windows users might need to install Atmel SAM-BA drivers.
On Mac the port will be recognized as an USB modem.
5 ) From IDE set Tools->Board to "Arduino DUE (native USB port)", Tools->Port to your printer's serial port.
6 ) Run the sketch, your printer should start blinking with the inside light every second or so.
7 ) Open the serial monitor window in IDE (the button in the top right sketch window corner), you should see "LED ON" and "LED OFF" messages coming from the printer.
8 ) If you set baud rate to 1200 and close the monitor window, the printer's flash will be erased (there is special code in Arduino libs that ensure that). If the rate is not 1200 the flash will stay. You can always re-open it again and set to 1200 if you need flash erased for the next steps (or you could repeat step 3).

9) To restore the stock firmware back you will need the original F10_20140417_FW_V1.1.I_RELEASE.bin file. It should be available somewhere on this forum.
10) You will also need the bossac binary, it should be somewhere in the Arduino IDE subfolders. On Mac it's in
From console/cmd prompt issue the following command (replace tty.usbmodemXXX with your port name)
bossac -p tty.usbmodemXXX  -R -e -w -v -b F10_20140417_FW_V1.1.I_RELEASE.bin
10) Your printer should restart and work normally.
11) Restore you serial number, using the same Arduino IDE serial window.
Send "XYZ_@3D:0"
Your MCH_ID should look like MCH_ID:3DP01Pˇˇˇˇˇˇˇˇˇˇˇˇ
Send "DAVSSN_XXXXXXXXXXXXXXXXXX" replace X's with your serial number (see sticker inside the printer)
Send "XYZ_@3D:0" again to verify that the serial number is set
12) Recalibrate the bed.


The sketch:
int ledPin = 85; // PB11 pin #129
void setup() {
  pinMode(ledPin, OUTPUT);

void loop() {
  int val = HIGH;
  while(true) {
    SerialUSB.write("LED ");
    SerialUSB.write(val ? "ON" : "OFF");
    digitalWrite(ledPin, val);
    val = !val;
Bgm, We should work together on discovery of the pinouts. As I mentioned in a few places I am working on pinouts to verify and implement custom firmware. Unfortunately This sketch doesn't get us closer. It is great you got that working, but it seems waste of time since I mentioned weeks ago that I had already done so. Maybe cooperation can avoid duplicate work and advance the projects?


Anyone capable, please add to this and confirm.

pin 15 = Y right
pin 17 = Bed Heater
pin 29 = Y Enable
pin 30 = X front
pin 66 = buzzer
pin 69 = X enable
pin 83 = Extrude Heater
pin 84 = Y left
pin 85 = L.E.D.
pin 88 = buzzer
pin 91 = buzzer

Yes, It seems odd that 3 lines control the buzzer, but those 3 pins will do exactly that.

I haven't finished, this is just what I have so far. I have not started looking for the temp sensors/limit switches yet. Hopefully I will get more time this weekend.

Not all the pins are reachable using standard Arduino Due board description. Sooner or later we'll have to create our own.
Also note that Due pins >= 79 are in fact pin masks, that could explain the buzzer behavior.
I merged your data with mine, see attached CSV.
Wow, clearly you are much farther ahead on this than I am.

Any idea why the pins wouldnt be reachable? Is it because it isnt a true Due? (As in, maybe the real Due is a 100 pin package vs 144?)
Physically, It seems most of the control pins do go back to the micro.

The Due board uses a limited number of CPU pins, so the Arduino guys only enumerated those that are actually wired on their board.
The Due board is described in hardware/arduino/sam/variants/arduino_due_x/variant.cpp. We can add another variant that will describe our particular board. I wonder if Duet ( guys had to do that too, may be we can learn from them.
As for the firmware, the choice seems to be between We need to pick one to concentrate on, the second one could be done lately.
The selection criteria would be:
- it is easy to port to new hardware?
- does it print well?
- what host software does it support?

Any suggestions?
#7 should help with the initial pinout testing still using Arduino Due board description.
I was just coming to post this, when I see you posted something similar. Wink

Seems we first need to finish the pinout ID. Regarding firmware, Have you played with repetier host yet? It seems pretty slick.

OT --- BGM - Can you contact me through youtube? (the video link is just to make it easy to find me.)

Ive a few things to share (somewhat related) that arent for public consumption yet. It involves the hardware.

I couldn't figure out that youtube thing Smile Email me bgm at

Well when we have a few more of the pins set-up I really think this will be the way to go with the firmware, maybe, maybe not. But considering XYZware is a closed propriety version of repietier I think it would be a good start and looks like it will be not to difficult. That being said , I really don't know, I do g code not c code, what little programming I do is all hack and slash and get a little lucky now and then.
Yep, repetier would be my choice, a lot going for it.

Maybe I'll get time over the next week to do a physical trace on the lcd and see what it really is.

I'm *slightly* hesitant to take to much apart, as xyz is wanting to exchange my printer for reasons I don't want to make public yet. Maybe they want to see what I've done to it. Lol Wink

Almost there. Updated pinout attached.

The Da Vinchi FW has nothing to do with Repetier as far as I can tell.
Repetier doesn't officially support SAM3X8E yet. RepRap does.
I think the amount of work with either firmware is comparable,
so it would make sense to pick the more promising one.
Well I am not sure if the firmware is repietier, but my guess it is derived from it.

I do know XYZwware is a form of repietier.. So I guess it only made sense to me they had a custom firmware made for it too.

As far as supporting the chip did you go to the link I put above and look and the board and pinout options? I just assumed this is the same chip used on the due, as the options are for due no board, due rads, due ramps-fd, and own layout defined in userpins.h ...

I could be misunderstanding something. that is the case on occasion.

Also for note after a pinout is fully worked out we can make our own hardware definition for the audrino software to allow for easy flashing and changing of things.

I will guess that to keep the pins as close to the existing shields as possible is allot of the reason for not having all the processor pins broke out to the header on the due.

Again I will be the first to admit most of this is speculation and guessing, but I do get lucky an awful lot.
Josh is correct - From XYZ executable:

Point is, since they used the front end there is no reason to think they didnt also use the back end. Repetier, from reading, has been made to work on the Due. I guess it could be based on Sprinter as ab alternative. Either way, unless I am missing something I believe the firmware should be open source since it is (again, assumptions) based on open source. At least when I made claim to them that is was based as such they did not deny it. Thoughts?

Kieth[Image: repetier.jpg]
Great progress guys!

Have you looked at Marlin Firmware ?
Looking at the sources, it should be fairly straightforward to adapt for different hardware.

I spent considerable amount of time reversing the firmware. I also spent quite some time studying RepRap and Repetier code. DA VINCI IS NOT BASED ON REPETIER FW. IT IS NOT BASED ON ANY KNOWN OPEN SOURCE FW. It might have used some bits and pieces from RepRap, because it can't correctly handle simultaneous XYZ, XZ or YZ movements, similar to RepRap no so long ago. But other than that it is completely different. It uses all the capabilities of the SAM3X8E including multitasking, SVC calls, native SD card controller. It even uses a static memory controller to map LCD data bus into CPU address space. No open source firmware does that, because they all maintain compatibility with older devices.

Having said that it does seem like Repetier would be a better choice for now. It supports more boards, so theoretically it would be easier to add support for one more.
Yes - When I said correct I was referring to the XYZware application, not specifically the firmware. Their use of repetier firmware was a best guess.

Its clear you are investing a lot of time. You efforts are appreciated. Smile I wish I had more time to put in this...

I finally got everything mapped. I didn't bother to create another Due variant yet. Just added the missing pin descriptors to the original variant.cpp.
I tested LEDs, LCD, buttons, motors, fan, end stops, extruder filament sensor, extruder and bed heaters and thermal sensors. Everything seems to be working just fine.
I still have few pins that are not accounted for, don't know if they are actually used, or just initialized in the firmware. Could be support for the second extruder, or some other features that were not implemented in the final product (like the front door sensor).
I'll provide the details later today. Just don't want anyone to waste their time on tracing and mapping.
SO FREAKING AWESOME. I am looking looking forward to seeing the final results.
My thinking was they are using near the same code and board for the 2.0 and 2.1 due to the un-populated bits on the board for another heater and driver and such bits for dual extrusion. I am really looking forward to being able to slow down the print in real time to reduce the extruder clicking issue. Seriously some good work. Would you be willing to give us all curious retards (me really) a brief overview of you process and how you came up with all the information you did.
Sounds like another hack-a-day post to me. I think we need to post onto slashdot as well. I think this must almost be a record for most hack a day spots in such a short period for one forum/site on one product. I am really grateful to Oliver for getting us started and setting this place up for us. I am also very happy I could be a part of this whole endeavor even if it is only for the moral support.

So um yeah in summary, WEEEE.

Forum Jump:

Users browsing this thread: 1 Guest(s)