[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8},"actionData","errors","root",{"_83":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96},"routes/blogs.$blogHandle._index",{"_9":10,"_11":12},"blog",{"_27":28,"_29":30,"_31":32,"_33":34},"authors",[13,14,15,16],{"_17":25,"_19":26},{"_17":23,"_19":24},{"_17":21,"_19":22},{"_17":18,"_19":20},"slug","digilog-electronics","name","Digilog Electronics","digilog-engineering","Digilog Engineering","naeem-ahmad","Naeem Ahmad","irfan-ahmad","IRFAN AHMAD","title","News","handle","news","seo",{"_27":-5,"_82":-5},"articles",{"_35":36,"_37":38},"nodes",[47,48],"pageInfo",{"_39":40,"_41":42,"_43":44,"_45":46},"hasPreviousPage",true,"hasNextPage",false,"endCursor","eyJsYXN0X2lkIjo2ODY4MjE3MDM5NTgsImxhc3RfdmFsdWUiOjY4NjgyMTcwMzk1OCwib2Zmc2V0IjoyMX0=","startCursor","eyJsYXN0X2lkIjo2ODU3Njk2NTQ1NTAsImxhc3RfdmFsdWUiOjY4NTc2OTY1NDU1MCwib2Zmc2V0IjoyMH0=",{"_49":70,"_51":71,"_29":72,"_54":73,"_56":74,"_58":75,"_27":76,"_9":77},{"_49":50,"_51":52,"_29":53,"_54":55,"_56":57,"_58":59,"_27":60,"_9":61},"author",{"_19":20},"contentHtml","

$\"Raspberry$

\n\n

For years, mobile repair technicians in Pakistan have relied on expensive, closed-box tools for chip-level diagnostics, flashing, and boot-mode work. A $5 microcontroller board is quietly changing that. The Raspberry Pi Pico 2, built on the new RP2350 chip, has become one of the most talked-about tools in the hardware-security and phone-repair community — and for good reason.

\n\n

In this guide we break down what makes the RP2350 special, why it landed at the center of the famous USBliter8 iPhone DFU exploit and the RP2350 hacking challenge, how to write your first code on it, and how repair professionals can put this board to legitimate, everyday use on the workbench.

\n\n

What Is the Raspberry Pi Pico 2 (RP2350)?

\n\n

The Raspberry Pi Pico 2 is the second-generation Pico board from the Raspberry Pi Foundation, replacing the original RP2040-based Pico. At its heart is the RP2350 — a dual-core, dual-architecture microcontroller that is far more capable than its price suggests.

\n\n

RP2350 Key Specifications

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Feature	RP2350 / Pico 2
CPU cores	2× Arm Cortex-M33 or 2× Hazard3 RISC-V (switchable)
Clock speed	150 MHz
SRAM	520 KB (nearly double the original Pico)
On-board flash	4 MB QSPI
PIO	12 programmable I/O state machines (3 PIO blocks)
USB	USB 1.1 controller + PHY, host and device support
Security	Arm TrustZone, signed secure boot, OTP key storage, SHA-256 accelerator, glitch detectors
Price	From about $5

\n\n

The single most important feature for repair and security work is PIO — Programmable I/O. Ordinary microcontrollers force you to use fixed hardware peripherals (a fixed UART, a fixed SPI block, and so on). The RP2350's 12 PIO state machines let you build your own communication protocols in software, with cycle-accurate, nanosecond-level timing on the physical pins. That is exactly what makes this tiny board behave like equipment that used to cost hundreds of dollars.

\n\n

Getting Started: Your First Code on the Pico 2

\n\n

You do not need any programmer or extra hardware to start. The Pico 2 shows up as a USB drive, and you can code it in MicroPython (easiest) or C/C++. Here is the quick flow:

\n\n

Download the MicroPython .uf2 file for the Pico 2 (RP2350) from the official Raspberry Pi site.
Hold the BOOTSEL button while plugging the board into USB — it appears as a drive called RP2350.
Drag the .uf2 file onto that drive. The board reboots, ready for code.
Install Thonny IDE, then choose Tools > Options > Interpreter > MicroPython (Raspberry Pi Pico).

\n\n

1. Blink the On-board LED (Hello World)

\n\n

This confirms your board and toolchain are working:

\n\n

from machine import Pin\nfrom time import sleep\n\n# The Pico 2 has a built-in LED\nled = Pin(\"LED\", Pin.OUT)\n\nwhile True:\n    led.toggle()      # flip the LED on/off\n    sleep(0.5)        # wait half a second\n

\n\n

2. Read Serial Logs From a Device (Repair Diagnostics)

\n\n

A common repair task is reading the boot log / UART console of a faulty board. The Pico 2 makes an excellent, cheap USB-to-serial sniffer. Wire the target's TX to GP1 (RX) and share a common ground:

\n\n

from machine import UART, Pin\n\n# UART0: TX=GP0, RX=GP1 - adjust baud to match the device\nuart = UART(0, baudrate=115200, tx=Pin(0), rx=Pin(1))\n\nprint(\"Listening for serial data...\")\nwhile True:\n    if uart.any():\n        data = uart.read()\n        if data:\n            print(data.decode(\"utf-8\", \"ignore\"), end=\"\")\n

\n\n

From here you can build bigger tools — SPI/I2C flash readers, SWD debuggers, or PIO-based logic analyzers — all on the same board.

\n\n

Why Mobile Repair Technicians Are Paying Attention

\n\n

Modern phones lock everything down at the hardware level — secure boot, signed firmware, encrypted storage. To diagnose, flash, or research these devices, you often need precise control of the raw data lines, not a polite standards-compliant USB port. This is where the RP2350 shines, and it is why the board suddenly appeared in tools that made headlines.

\n\n

The USBliter8 iPhone DFU Exploit (checkm8's Successor)

\n\n

Security researchers have described USBliter8 as the first public, hardware-level iPhone exploit since the well-known checkm8. It targets a flaw in Apple's SecureROM (the BootROM) that is burned into the silicon during manufacturing — meaning it cannot be patched with a software update.

\n\n

\nAffected chips: Apple A12, A13, S4 and S5 — roughly iPhone XR/XS/11 and SE (2nd gen), several iPads, Apple Watch Series 4–5, HomePod mini and Apple TV 4K (2nd gen).
\nNot affected: A11 and older, and A14 and newer chips, which have hardened protections.
\nWhy the Pico 2 is required: the attack needs the device put into DFU mode and then demands cycle-accurate control that intentionally “bends” the USB specification — something a normal USB controller will not allow. The RP2350's PIO can act as a software-defined USB engine and run the payload in seconds.

\n\n

An important honesty note: this class of exploit breaks early boot verification only. It does not unlock a user's data, and it does not bypass iCloud Activation Lock, because that is protected by the separate Secure Enclave. In other words, it is a research and boot-level tool — not a magic key for locked or stolen phones. Always work only on devices you own or are formally authorized to repair.

\n\n

Watch: RP2350 Pico 2 & USBliteR8 Guide (Hindi/Urdu)

\n\n

This short walkthrough shows the RP2350 Pico 2 being used for an A12+ DFU screen-lock reset with the USBliteR8 exploit — a good visual introduction for repair technicians:

\n\n

For a beginner-friendly primer in Hindi, this popular TechChip tutorial shows how to program a Raspberry Pi Pico as a DIY “Bad USB” security tool — a great way to understand how these boards can emulate and control USB devices:

\n\n

The RP2350 Hacking Challenge

\n\n

What really cemented the RP2350's reputation was Raspberry Pi's own move: instead of hiding its security, the company put money on the table and invited the world to break it. The RP2350 Hacking Challenge asked researchers to extract a 128-bit secret hidden in the chip's OTP (one-time-programmable) memory, protected by secure boot.

\n\n

Several teams succeeded, using serious hardware-attack techniques — and the results are a fascinating map of how modern chip security is really tested:

\n\n

\nVoltage glitching — timing a power fault to corrupt security configuration reads.
\nSupply-voltage / fault injection — skipping a single instruction in the USB bootloader to bypass signature checks.
\nLaser fault injection — firing a laser at the exposed silicon during the secure-boot hash to slip past signature verification.
\nElectromagnetic fault injection (EMFI) — a precisely timed “double fault” that defeated the OTP lock.
\nFocused ion beam (FIB) — physically reading antifuse memory.

\n\n

Raspberry Pi paid out the full prize to the winning teams and said the weaknesses would likely be addressed in a future revision of the chip — a model it calls “security through transparency.” For technicians, the takeaway is simple: the RP2350 is now one of the best-documented chips on earth for learning how hardware security, secure boot, and fault injection actually work.

\n\n

Legitimate Everyday Uses on the Repair Bench

\n\n

Exploits grab the headlines, but the real day-to-day value of the Pico 2 for a repair shop is as a cheap, flexible diagnostic and flashing tool. Because you can program its pins to speak almost any protocol, one board can replace several single-purpose gadgets.

\n\n

\nSWD / JTAG debugging — probe and reflash microcontrollers and sub-boards.
\nUART / serial diagnostics — read boot logs and error output from device consoles.
\nSPI / I2C flash and EEPROM reading — dump and rewrite memory chips during board repair.
\nLogic analyzer — PIO's fast sampling turns the Pico 2 into a budget signal analyzer for tracing faults.
\nCustom test jigs — build go/no-go testers for repeat repairs and quality checks.
\nLearning platform — the safest, cheapest way to actually understand DFU mode, secure boot, and chip-level security.

\n\n

Ready to add one to your toolkit? Get the Raspberry Pi Pico 2 (RP2350) here. If you are just getting started, the Raspberry Pi Pico W and the classic Raspberry Pi Pico (RP2040) are also excellent, low-cost boards to learn PIO and microcontroller basics.

\n\n

A Word on Ethics and the Law

\n\n

Tools like the Pico 2 are powerful dual-use devices. Used correctly they are a legitimate part of repair, education, and security research. Used wrongly they can cross legal lines. Keep it simple and professional:

\n\n

Only work on devices you own or are authorized in writing to service.
Never use boot-level exploits to access, resell, or unlock lost or stolen phones.
Remember these techniques do not bypass iCloud/Activation Lock or decrypt user data.

\n\n

Frequently Asked Questions

\n\n

What is the difference between the Raspberry Pi Pico and Pico 2?

The Pico 2 uses the newer RP2350 chip with dual Arm Cortex-M33 or RISC-V cores, 520 KB of SRAM, 4 MB of flash, and built-in security features like secure boot and TrustZone. The original Pico uses the RP2040 with less RAM and no dedicated security hardware.

\n\n

Can the Raspberry Pi Pico 2 really bypass an iPhone?

The RP2350's programmable I/O lets it run BootROM-level research exploits such as USBliter8 on certain older Apple chips (A12–A13). However, this only affects the boot stage — it does not unlock user data or remove iCloud Activation Lock, and it should only ever be used on devices you own or are authorized to repair.

\n\n

Why is programmable I/O (PIO) so important?

PIO lets you create custom, precisely timed communication protocols in software. This means one Pico 2 can act as a logic analyzer, a flash reader, a JTAG/SWD debugger, or a specialized USB engine — jobs that normally need several separate tools.

\n\n

Is the Pico 2 good for beginners in mobile repair?

Yes. It is inexpensive, well-documented, and programmable in both C/C++ and MicroPython. It is one of the most affordable ways to learn chip-level diagnostics, secure boot, and hardware security before investing in professional repair equipment.

\n\n

Final Thoughts

\n\n

The Raspberry Pi Pico 2 and its RP2350 chip prove that serious hardware capability no longer requires a serious budget. Between its programmable I/O, dual-architecture cores, and transparent security design, it has become a genuine tool of interest for mobile repair technicians, students, and security researchers alike in Pakistan.

\n\n

Whether you want to learn PIO, build your own flashing and diagnostic jigs, or simply understand how modern device security really works, the Pico family is the perfect starting point. Get your Raspberry Pi Pico 2 (RP2350) from Digilog.pk and start building your repair toolkit today.

","raspberry-pi-pico-2-rp2350-mobile-repair-tool","id","gid://shopify/Article/686821703958","image",{"_54":62,"_63":64,"_65":66,"_67":68,"_69":68},"publishedAt","2026-08-02T15:45:29Z","Raspberry Pi Pico 2 (RP2350): The New Hardware Tool for Mobile Repair",{"_29":30},"gid://shopify/ArticleImage/281658392854","altText","Raspberry Pi Pico 2 RP2350 microcontroller board for mobile repair and hardware security","url","https://cdn.shopify.com/s/files/1/0744/0764/1366/articles/image_36be348c-4828-41af-828f-03477c668683.png?v=1785685924","width",500,"height",{"_19":22},"

The MDT10F684 is a popular low-cost clone of Microchip's PIC16F684, widely available in Pakistan's electronics markets at a fraction of the original's price. The datasheet says it is fully code-compatible — and that is true. What the datasheet does not tell you is that the configuration is completely different, and that popular C compilers can silently sabotage one of its best features.

At Digilog, we recently ported a working PIC16F684 solar boost-converter design (360V output, 20 kHz PWM) to the MDT10F684. The same HEX file that ran perfectly on the genuine PIC failed on the clone. It took a full day of systematic debugging — datasheet comparison, register-level tests, and a serial diagnostic — to find every difference.

This guide documents every trap we hit, so you can avoid them in minutes instead of days.

Why Your PIC16F684 Code Fails on the MDT10F684

First, the good news. The two chips are genuinely compatible where it matters:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Feature	PIC16F684	MDT10F684
Program Flash	2048 × 14-bit words	2048 × 14-bit words
SRAM / EEPROM	128 B / 256 B	128 B / 256 B
Instruction set	35 instructions	Compatible
ADC, timers, ECCP PWM	10-bit, 8-ch	Same peripherals

So if your program worked on the PIC, the logic will work on the MDT. The failures come from three places: fuse configuration, the oscillator setting, and the ADC reference. Let's take them one by one.

$\"\"$

Trap 1: The Config Word at 0x2007 Is Ignored

On a genuine PIC16F684, your compiler's #fuses line (CCS) or __CONFIG directive is stored at address 0x2007 inside the HEX file, and the programmer writes it to the chip automatically.

The MDT10F684 does not use address 0x2007 at all. Its configuration lives in two separate registers at 0x1200 and 0x1201, with a completely different bit layout. When you load your HEX into the MDT programmer (typically YS-Writer Pro), the 0x2007 word is simply discarded.

What this means in practice:

Your #fuses INTRC_IO, NOWDT, PUT, NOMCLR, NOBROWNOUT line does nothing on the MDT.
Every fuse must be set manually in the YS-Writer \"Edit Option\" dialog.
The dialog is the only source of truth. If the chip misbehaves, check the dialog first — not your code.

The upside: the 0x2007 word cannot corrupt anything either. The MDT's flash is only 0x000–0x7FF, so the stray config word lands nowhere.

Trap 2: \"HF\" Does NOT Mean Internal Oscillator

This one cost us the most time, and it will catch anyone coming from Microchip's naming.

On genuine PICs, the internal oscillator block is called HFINTOSC — so when you see \"HF\" in YS-Writer's OSC Type dropdown, it feels like the internal oscillator. It is not. In MDT naming:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

YS-Writer option	Actual meaning
HF	High-speed external crystal on PA4/PA5
XT / LF	External crystal (standard / low-power)
EC	External clock input
RC / RC+IO	External resistor-capacitor oscillator
IRC+IO	\nInternal RC oscillator, both pins free as I/O ✅
IRC	Internal RC, CLKOUT on PA4

If your code uses INTRC_IO (CCS) or FOSC_INTOSCIO, the correct YS-Writer setting is IRC+IO. Select HF by mistake and the chip waits for a crystal that doesn't exist — nothing runs, or it limps along erratically.

Once set correctly, the MDT's internal oscillator is surprisingly good: we measured it within 0.5% of nominal using the serial test below — accurate enough for bit-banged UART at 9600 baud.

Trap 3: Default Fuses That Reset Your Chip Randomly

Three more dialog options ship with dangerous defaults. Match them to your PIC code:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

YS-Writer option	Common default	Should be (typical)	Symptom if wrong
WDT	Enable	\nDisable (if code has `NOWDT`)	Chip resets every ~2 s — code appears to \"restart randomly\"
\nLVR (brownout)	Always On @ 3.8V	\nDisable (if code has `NOBROWNOUT`)	Random resets whenever 5V rail dips — fatal on switching-converter boards
MCLRE	MCLR enabled	\nPA3 (if code has `NOMCLR`)	Floating MCLR pin picks up noise → resets, or chip held in reset
PWRTE	Disable	\nEnable (if code has `PUT`)	Unstable start on slow-rising supplies

A watchdog that your code never clears, plus a brownout detector on a noisy board, produces the classic clone complaint: \"it starts, blinks once, then goes mad.\" It isn't the silicon — it's the fuses.

Trap 4: The ADC 2V Reference — and the Compiler That Sabotages It

The MDT10F684 has a feature the original PIC lacks: a selectable internal ADC reference of 2V, 3V or 4V, independent of the supply rail. Local engineers prefer it — several told us the ADC is more stable on the internal 2V reference than on the noisy 5V VDD.

But there is a hidden conflict. The reference is selected by the ADVRS bits (bits 6–5 of register ADS0, address 0x1F):

\n00 = VDD reference
\n10 = external reference on PA1
\nx1 = internal reference (2/3/4V chosen by the \"ADC Vref\" fuse)

Here's the trap: on a genuine PIC16F684, bit 5 of ADCON0 is unimplemented. CCS C's library functions (setup_adc_ports(), set_adc_channel(), read_adc()) were written for the genuine PIC, so they write bit 5 as 0 — every single time. Result: you set \"ADC Vref: 2V\" in the programmer, but your compiled code silently switches the reference back to VDD at runtime. Your ADC scale is wrong and you'll never see why in your C source.

We proved this on real silicon with a register read-back test: the CCS library cleared ADVRS0 on every ADC call.

The fix: bypass the library. Drive the registers directly. This driver is verified working:

// ---- MDT10F684 ADC registers ----\n#byte ADS0    = 0x1F      // ADFM | ADVRS1 ADVRS0 | CHS2 CHS1 CHS0 | GO | ADON\n#byte ADS1    = 0x9F      // ADRVO | ADCS2 ADCS1 ADCS0 | ----\n#byte ADRESH  = 0x1E\n#byte ADRESL  = 0x9E\n#byte ANSEL_R = 0x91\n#byte TRISA_R = 0x85\n#bit  GO_BIT  = ADS0.1\n\n// ADFM=1, ADVRS=01 (internal ref per fuse), CHS=010 (AN2), ADON=1\n#define ADS0_VAL   0b10101001    // 0xA9\n\nvoid adc_init(void) {\n    TRISA_R |= 0b00000100;   // RA2 = input\n    ANSEL_R  = 0b00000100;   // AN2 analog, rest digital\n    ADS1     = 0b01010000;   // ADCS=101 -> FOSC/16 (2us TAD @ 8MHz)\n    ADS0     = ADS0_VAL;\n}\n\nint16 adc_read(void) {\n    ADS0 = ADS0_VAL;         // re-assert config before EVERY read\n    delay_us(20);            // let the sample/hold capacitor settle\n    GO_BIT = 1;\n    while (GO_BIT);          // hardware clears GO when done\n    return ((int16)ADRESH << 8) | ADRESL;\n}

Two details matter:

\nRe-write ADS0 before every conversion. Even if some library call touches the register, the config is guaranteed correct 20 µs before each read.
\nKeep the \"ADC Vref\" fuse and the code in agreement. The ADVRS bits say use the internal reference; the fuse says which voltage it is. If someone later reprograms the chip with the fuse at 4V, all your ADC thresholds silently shift.

And remember to rescale your constants. A threshold computed for a 5V reference reads 2.5× higher on a 2V reference. Recalculate every ADC compare value: ADC = (Vin / Vref) × 1023.

How to Verify Everything: The Serial Test Method

Before trusting the chip in a real product, run this 10-minute test. It verifies the oscillator and the ADC simultaneously, using only a potentiometer and a USB-TTL adapter (the MDT10F684 has no hardware UART, so we bit-bang serial — which is itself an oscillator test: if the clock is off, the output is garbage).

Setup: pot across VDD–GND, wiper → AN2 (pin 11); TX = RC0 (pin 10) → USB-TTL RX; terminal at 9600 8N1.

void main() {\n   int16 raw, vpin_mv;\n   int16 seconds = 0;\n   adc_init();\n   delay_ms(50);\n   printf(\"MDT10F684 TEST - ADS0=%X (want A9)\\r\\n\", ADS0);\n   while(TRUE) {\n      raw     = adc_read();\n      vpin_mv = (int16)(((int32)raw * 2000L) / 1023);  // 2V ref\n      seconds++;\n      printf(\"T=%lu s  ADC=%lu  Vpin=%lu mV\\r\\n\", seconds, raw, vpin_mv);\n      delay_ms(955);   // ~1s per line incl. transmit time\n   }\n}

Reading the results:

\nClean, readable text → oscillator is close to 8 MHz. Garbage → wrong OSC fuse.
\nT= counter tracks a stopwatch (compare at T=60) → oscillator accuracy confirmed. Actual frequency = 8 MHz × T ÷ stopwatch seconds.
\nADC sweeps 0→1023 smoothly as you turn the pot → converter linear.
\nWhere it rails at 1023 reveals the true reference: at ~2.0V = internal 2V active ✅; at ~5V = your code is still forcing VDD (the CCS trap above).
\nADS0=A9 in the printout proves the reference bits latched.

On our chip this test showed the oscillator within 0.5% and a perfectly linear ADC — after which the full solar converter ran exactly as it did on the genuine PIC.

Quick-Reference: Correct YS-Writer Settings for CCS-Style Code

For code written with #fuses INTRC_IO, NOWDT, PUT, NOMCLR, NOBROWNOUT:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Option	Setting
OSC Type	IRC+IO
IESO / FCMEN	Disable
MCLRE	\nPA3 (MCLR off)
RD PORT	RD Pins
PWRTE	Enable
WDT	Disable
LVR	Disable
Security / EE Security	Disable (while developing)
ADC Vref	2V (if using internal reference — must match code)

Frequently Asked Questions

Is the MDT10F684 a drop-in replacement for the PIC16F684?

The silicon is code-compatible — same memory, instructions and peripherals. But it is not drop-in for your workflow: fuses must be set in the MDT programmer dialog (not the HEX), and compiler ADC libraries need the manual driver above if you use the internal reference.

Why does my PICkit not detect the MDT10F684?

The clone reports a different device ID and uses different config addresses, so Microchip tools reject it. Use the MDT-compatible programmer (YS-Writer Pro with the AP07 adapter) instead.

My MDT10F684 keeps resetting every couple of seconds. Why?

Almost always the WDT fuse defaulted to Enable in YS-Writer while your code never clears the watchdog. Set WDT = Disable. If resets correlate with load switching, also disable LVR (brownout) and turn MCLRE off.

Which ADC reference should I use — VDD or internal 2V?

If your 5V rail is clean and well-decoupled, VDD reference works and needs no special code. On noisy boards (SMPS, motor drivers), the internal 2V reference is independent of rail sag — but requires the manual register driver above, because compiler libraries overwrite the selection bits.

Can I use 115200-baud serial on the MDT10F684?

Not reliably. There is no hardware UART, and at 8 MHz a bit-banged UART only has ~17 instruction cycles per bit at 115200. Stick to 9600–38400 baud on the internal RC oscillator.

Conclusion

The MDT10F684 is a genuinely capable PIC16F684 clone — our converter now runs on it with an oscillator accurate to half a percent and a rock-stable ADC. Every problem we hit traced back to configuration differences, not bad silicon: fuses live in the programmer dialog, \"HF\" means external crystal, the watchdog defaults on, and C-compiler ADC libraries fight the reference selection.

Set the fuses from the table above, use the manual ADC driver if you want the internal reference, and validate with the serial test before deploying — and this chip will save you real money on production runs.

Need the parts? Digilog stocks microcontrollers, programmers, USB-TTL serial adapters and everything else used in this guide. Browse our Microcontrollers collection and STM32 & Microchip (PIC) MCUs .

Here is complete test code

///////////////////////////////////////////////////////////////////////////////
// MDT10F684 - ADC DIAGNOSTIC TEST - INTERNAL 2V REFERENCE
// Fully manual ADC driver (no CCS ADC library - nothing can clobber ADVRS)
//
// Hardware:
// - Pot across VDD-GND, wiper -> AN2 (RA2, pin 11)
// - Serial TX = RC0 (pin 10) -> RX of USB-TTL adapter, 9600 8N1, common GND
//
// YS-Writer fuses:
// OSC=IRC+IO, IESO=Dis, FCMEN=Dis, MCLRE=PA3(off), RD PORT=RD Pins,
// PWRTE=En, WDT=Dis, LVR=Dis, Security=Dis, EE Sec=Dis, ADC Vref=2V
//
// Output line: T=12 s ADC=1023 Vpin=2000 mV W=A9 A=A9
// W = ADS0 immediately after write (did the bit latch?)
// A = ADS0 after conversion (did it survive?)
//
// Decode:
// W=A9 A=A9 ADC rails 1023 @2.5V -> 2V internal ref WORKING
// W=A9 A=89 -> HW clears bit during conversion
// W=89 A=89 -> ADVRS0 not implemented -> plan B (TL431)
// W=A9 A=A9 but ADC=512 @2.5V -> register lies, silicon ignores -> plan B
///////////////////////////////////////////////////////////////////////////////
#include <16F684.h>
#device adc=10

// NOTE: MDT writer IGNORES these #fuses - set everything in YS-Writer dialog.
#fuses INTRC_IO, NOWDT, PUT, NOMCLR, NOBROWNOUT
#use delay(internal=8MHz)
#use rs232(baud=9600, xmit=PIN_C0, parity=N, bits=8, stream=DBG)

// ---- MDT10F684 ADC registers (CCS handles bank switching) ------------------
#byte ADS0 = 0x1F // ADFM | ADVRS1 ADVRS0 | CHS2 CHS1 CHS0 | GO | ADON
#byte ADS1 = 0x9F // ADRVO | ADCS2 ADCS1 ADCS0 | ----
#byte ADRESH = 0x1E // result high
#byte ADRESL = 0x9E // result low
#byte ANSEL_R = 0x91 // ANINS: analog pin select
#byte TRISA_R = 0x85 // CPIOA: 1 = input

#bit GO_BIT = ADS0.1

// ADS0: ADFM=1 (right-justified), ADVRS=01 (internal ref, 2V per fuse),
// CHS=010 (AN2), GO=0, ADON=1
#define ADS0_VAL 0b10101001 // 0xA9

#define VREF_MV 2000L // internal 2V reference, in millivolts
#define LOOP_MS 1000
#define TX_COMP_MS 45 // ADC + serial TX time compensation

// ---- diagnostics ------------------------------------------------------------
int8 reg_before; // ADS0 right after write, before conversion
int8 reg_after; // ADS0 right after conversion completes

// ---- manual ADC driver ------------------------------------------------------
void my_adc_init(void) {
TRISA_R |= 0b00000100; // RA2/PA2 = input
ANSEL_R = 0b00000100; // AN2 analog, everything else digital
ADS1 = 0b01010000; // ADCS=101 -> FOSC/16 (2us TAD @8MHz), ADRVO=0
ADS0 = ADS0_VAL; // reference + channel + ADC on
}

int16 my_read_adc(void) {
ADS0 = ADS0_VAL; // re-assert full config before EVERY read
reg_before = ADS0; // SNAPSHOT 1: did the write latch?
delay_us(20); // acquisition: let S/H cap settle
GO_BIT = 1; // start conversion
while (GO_BIT); // hardware clears GO when done
reg_after = ADS0; // SNAPSHOT 2: did config survive conversion?
return ((int16)ADRESH << 8) | ADRESL;
}

// ---- test program -----------------------------------------------------------
void main() {
int16 raw, vpin_mv;
int16 seconds = 0;

my_adc_init();
delay_ms(50);

printf(\"\\r\\nMDT10F684 MANUAL-ADC TEST, INTERNAL 2V REF\\r\\n\");
printf(\"ADS0 after init = %X (want A9)\\r\\n\", ADS0);

while(TRUE) {
raw = my_read_adc();
vpin_mv = (int16)(((int32)raw * VREF_MV) / 1023);

seconds++;
printf(\"T=%lu s ADC=%lu Vpin=%lu mV W=%X A=%X\\r\\n\",
seconds, raw, vpin_mv, reg_before, reg_after);

delay_ms(LOOP_MS - TX_COMP_MS);
}
}

","mdt10f684-pic16f684-clone-problems-fixes-guide","gid://shopify/Article/685769654550",{"_54":78,"_63":-5,"_65":79,"_67":80,"_69":81},"2026-07-08T17:58:11Z","MDT10F684 (PIC16F684 Clone): Problems, Fixes & Beginner's Guide",{"_29":30},"gid://shopify/ArticleImage/281279201558","https://cdn.shopify.com/s/files/1/0744/0764/1366/articles/MDT10F6848-bitMicrocontroller_DIP-14_2KFlash_128BEEPROM_64BRAM_20MHz_ADC_PWM_Low-PowerMCU_41564276-8876-49ba-8c67-92ce39cb66a6.jpg?v=1783535878",300,255,"description","cart",["P",84],"isLoggedIn",["P",86],"header",{"_93":163,"_164":165},"designConfig",{"_105":106,"_107":108,"_109":110,"_111":-5,"_112":113,"_114":115,"_116":117,"_118":119,"_120":121,"_122":123},"publicStoreDomain","digilogpk.myshopify.com","shop",["P",94],"consent",{"_97":-7,"_98":99,"_100":42,"_101":102,"_103":104},"checkoutDomain","storefrontAccessToken","5eefa6eb1e320f2ed4df08fe1a022a68","withPrivacyBanner","country","US","language","EN","brandName","Electronics Products Arduino ESP32 Nodemcu Raspberry pi","colors",{"_157":158,"_159":160,"_161":162},"fontGoogleUrl","https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&display=swap","logoUrl","socialLinks",{"_152":-5,"_153":-5,"_154":-5,"_155":-5,"_156":-5},"hero",{"_144":145,"_146":147,"_148":149,"_150":151},"featuredProductsHeading","Featured Products","featureHighlightsHeading","Why Shop With Us","featureHighlights",[133,134,135,136],"homepageSections",[124,125,126,127],{"_128":114,"_130":40},{"_128":132,"_130":40},{"_128":131,"_130":40},{"_128":129,"_130":40},"key","recommendedProducts","enabled","imageWithText","featuredCollectionGrid",{"_27":143,"_138":139,"_140":-5},{"_27":142,"_138":139,"_140":-5},{"_27":141,"_138":139,"_140":-5},{"_27":137,"_138":139,"_140":-5},"Feature Four","text","Replace with real copy about this store's products or service.","imageUrl","Feature Three","Feature Two","Feature One","heading","Welcome to My Store","subheading","Replace this with your own hero copy in the design dashboard.","buttonText","Shop Now","buttonLink","#featured-collection-heading","facebook","instagram","youtube","tiktok","linkedin","primary","#2563eb","primaryDark","#1d4ed8","accent","#3b82f6",{"_54":187,"_19":188,"_82":189,"_190":191,"_192":193},"menu",{"_54":166,"_167":168},"gid://shopify/Menu/224598589718","items",[169,170],{"_54":180,"_172":181,"_173":182,"_27":183,"_176":184,"_65":185,"_167":186},{"_54":171,"_172":-5,"_173":174,"_27":175,"_176":177,"_65":178,"_167":179},"gid://shopify/MenuItem/587846844694","resourceId","tags",[],"Track Your Order","type","HTTP","https://digilog.pk/apps/tracking",[],"gid://shopify/MenuItem/587846811926","gid://shopify/Page/114912723222",[],"Contact Us","PAGE","https://digilog.pk/pages/contact-us",[],"gid://shopify/Shop/74407641366","digilog.pk","Shop Arduino boards (UNO, Nano, Mega), ESP32 modules, sensors, and accessories at Digilog.pk. Find breakout boards, shields, and IoT components. Visit us at Mall Road Opposite of Hall Road, Lahore, or shop online for high-quality electronics at the best prices. Perfect for hobbyists, students, and professionals!","primaryDomain",{"_65":198},"brand",{"_194":195},"logo",{"_56":196},{"_65":197},"https://cdn.shopify.com/s/files/1/0744/0764/1366/files/digilog.pk_1.png?v=1680948031","https://digilog.pk"]