Monday, 31 December 2018

Resetting the Page Count on a Samsung Laserjet (MLT-R116 Drum)

Our Samsung M2835 printer's drum unit (MLT-R116, not toner, the drum unit) finally hit its software-programmed end-of-life of 10,000 pages.  This is annoying for several reasons:

  • Page 9,999 was perfectly fine
  • I disagree with business practices involving software-enforced obsolescence 
  • Other printers (Brother and HP) provide an option to reset the page count
After some research, it turns out drum unit uses the same technique as toner cartridges to enforce end-of-life.  It uses a small 4Kbit i2c EEPROM to store the page count.  

There are some great resources for resetting almost the same EEPROM on toner cartridges on Samsung printers.  I used and adapted these to reset the drum counter.

Here's the Chip with contacts soldered to it so I can plug it into my raspberry Pi.

And here's the chip by itself:

And here's the connection to the RPI:

So once connected, dumping and re-writing the ROM is easy.  Use the above links to enable i2c on the RPI and then:

  • python -b 0x50.bin --addr 0x50
  • python -b 0x51.bin --addr 0x51
  • bvi 0x50.bin
    • Change offset 0x0C to 00 00 00 00  # See Note Below!
  • python -r 0x50.bin --addr 0x50
Now the drum counter reports 0 and the printer will print again.  Note: from what I have been reading, some versions of the firmware require modifications to other offsets too.  It's probably easiest to take a snapshot of the eeprom, save it somewhere safe, and then reload the eeprom 5 years later when the page counter is too high.

Note: Thanks to Joe Cooper, you may also, or instead, have to reset bytes of the 0x50.bin starting at 0x26 to 00 00, and at 0x2E to 00 00.    It's possible different printer models/firmware are storing the page count at different offsets.


  1. I followed this guide, but the counter kept resetting back to 27 10 every time, which means 10,000 in decimal, which is the page count.

    I looked through the data dump some more and found another 27 10 at 0x46 and 0x47. However, each time my printer resets this back to 27 10 and still says end of life. If anyone has working dumps, please can you share?

    Oh and a little tip, don't solder the cables to the chip, you can tape them to card board and just push them against the chip. Getting them the wrong way around wont fry it as long as you don't do it for long!

    1. I was using gator clips and cardboard but got tired of disconnecting the chip and putting it back into the printer to see what happened... i soldered the wires on and put the whole thing back in the printer.. i have 4 wires sticking out of my printer now that i can connect to my RPI and reprogram the drum anytime :)

  2. Aha! Ignore the 27 10... Look for 23 28 which means 9000 pages. I had it twice in 0x50. After setting to 00 00, it works again! Now to reset the toner...

  3. That is fantastic. I will check my offsets later too, which offsets did you find 23 28 at? Was your drum at 9000? Or 10000?

  4. Ah soldering them to be able to access outside is a good idea!

    The page count is a bit weird. The printers counter now says 10,003. But the counter I had to reset in the imaging unit was at 9,000 when it stopped. The offsets were 0x26 / 0x27 and 0x2E / 0x2F. (both were 23 / 28).

  5. Interesting. In wonder if different printers use different offsets to store different things. On my original 0x50 image, 0x26/27 was 03 e9 when it stopped printing, and 0x2E/2F was FF FF. I didn't touch either to reset it.

    My original at 0x0C was 00 00 27 12, which is close to the 27 10 you quoted. This I reset to 00 00 00 00 and the pages reset.

    1. This comment has been removed by the author.

  6. Hello, thanks for this article.

    I followed it but i don't succeed yet.

    I have succesfuly read my eeprom, and i have 00 00 27 10 in 0x0C.
    i have changed it to 00 00 00 00 but when i put it back on the printer, the printer doesn't want to print :/ After that, i checked and 0x0C was reset to 00 00 27 10.

    I have double check, i succesfuly write on the eeprom.

    Do you have any idea ? Maybe you can share you backup with me ?

    there is a screen capture of 0x50 :

    I have read the comments of Joe Cooper but 0x2E is ff ff and 0x26 is 03e8 in my case, i have tried to put 0x26 to 00 00 but it don't solve my problem :/


    1. Hello,

      I tried a few things and tried to understand the organization by doing reverse engineering, and I found a solution to my problem.

      0x51 is the place which contains all the information of the unit (serial number, brand, date of manufacture etc ...), it contains in particular, the max capacity of the unit!
      0x51 is never changed by the printer.

      0x50 is the part that is changed by the printer each print.

      By parsing byte by byte, in 0x50:
      we have from 0x00 to 0x03 the date of first use
      0x04 to 0x07 the date of last use
      from 0x0c to 0x0F the page number counter.
      from 0xB0 to 0xBF the serial number of the printer

      In 0x51:
      from 0x05 to 0x0F we have the serial number of the unit
      from 0x15 to 0x1E we have the brand of the unit (Samsung export in my case)
      from 0x24 to 0x27 and 0x2C to 0x2F: 00 00 23 28, which is effectively 9000 and is directly linked to the capacity of the unit.

      I think Joe Cooper's solution is in 0x51 and not 0x50

      My M2825ND printer have protection in the current firmware, if I modify 0x0c for 00 00 00 00, the printer resets to the previous value. I was in the same situation as Joe Cooper.

      2 solutions:

      First solution,:

      So I put 0 the 2 places where 9000 appears (0x51.bin) and it works (as Joe Cooper said), I printed the detailed sheet and in fact it passes the capacity to 0 which breaks the verification on the number of page.
      However my printer continued to advert me that the drum was almost full but I could continue to print.

      Instead i tried to go from 9000 to 900000, it works well, the maximum capacity of the drum is simply increased. No more printer warning. This solution is interesting because we will never again have any restrictions on printing because we will never have reached the maximum capacity.

      Second solution, make a complete reset of the unit:

      As in the article, we offset 0x0C in 0x50.bin to 00 00 00 00 (if we only do that, certain printers including mine will reset to the real value of the counter).
      The trick is to modify the serial number of the drum by modifying in 0x51.bin a random number (offset 0x05 to 0x0F) for example in 0x0D. Which makes the printer think it's a new drum.

      So that's what I found, I hope it will be useful to other people.
      Thanks for the article

    2. Thanks Gelchup, that's fantastic and useful info, I'll update the article shortly. With both your solutions I could probably fork the code and add an option to automatically fix the drum count, or submit a change back to the author so can fix both the toner and the drum.

      Thinking back, changing only 0x0C on mine may not have actually worked, but I was swapping back and forth between two drums, so that may have tricked it at one point (reset page count to 0, swap drum, swap back and with the serial number change the printer accepts the 0 page count).

      Neat stuff, thanks so much for all your work with this!

  7. Hi guys,

    thanks for your help. I have MLT-116R and the solution of the problem is simple:

    If you want to reset drum, set all parts of 0x50 to 0. After reboot it will be 100% and parts of 0x51 will be modified automaticaly.

    If you want do more, you can modify 0x51.

    Here is link to modified 0x50.bin and 0x51.bin, which gives you 900K pages and drum is reset.


    In speer you have to send command:
    sudo python -r 0x50erased.bin --addr 0x50
    sudo python -r 0x51modified.bin --addr 0x51

    Hope it helps!