dsPIC30F6013 Code Extraction: CodeGuard, 132 KB and Two CAN Modules

The dsPIC30F6013 is not a PIC18 with more pins, and recoveries that assume it is one go wrong at the first step. It is a 16-bit digital signal controller: 24-bit wide instructions on a 16-bit data path, running at up to 30 MIPS. DS70117 — the dsPIC30F6011/6012/6013/6014 data sheet — gives the 80-pin, general-purpose member of that quartet as 132 KB of program memory (44K instruction words), 6,144 bytes of SRAM, and 2,048 bytes of data EEPROM. Around the core: two CAN 2.0B modules, a 12-bit A/D converter sampling 16 channels at 200 ksps, five 16-bit timers, eight output-compare channels, two UARTs and two SPI ports. Note the trap in the family table: the 6012 and 6014 are the 144 KB parts — the 6013 is 132 KB, despite what many part listings claim.

A Different Protection Model

PIC18 parts protect flash with CP bits — a gate, uniform per block. The dsPIC30F family adds CodeGuard Security, which partitions program memory into a boot segment and a secure segment with separate configuration, restricting what code in one region may read or write in another. On a locked 6013 the practical result at the read is similar — protected regions return constants while the device stays programmable — but the report is different, because the boot segment’s boundaries are configured values that must be recorded alongside the image. A rebuilt unit needs those boundaries to match, or the firmware’s own region checks fail. The copy protection scheme overview explains the gate model; this part extends it.

Sizes and File Shape

132 KB at 24 bits per instruction is 44K words, and the two counting conventions differ by more than usual: an Intel HEX dump of the program space spans byte addresses 0x000000 to 0x01FFFF for a 24-bit-instruction part, with each instruction occupying three bytes in the file. Erased reads 0xFFFFFF. The 2,048-byte EEPROM at the data space is read separately and twice — at 100,000 erase/write cycles minimum, it is where this controller’s calibration and setpoints typically live, and it is the region most often worn to marginality in long-service industrial units.

The CAN Pair and What Survives

Two independent CAN 2.0B modules make this part common in industrial gateways. The acceptance filters, masks and buffer configuration are written by the firmware at start-up, so they are inside the image; the message traffic the product handled is not, and neither is the network identity the customer may need preserved. Say so before the read, not after: identities sometimes live in the EEPROM, sometimes in an external serial device, and once in a while only on a second unit.

What DSP Firmware Looks Like in a Dump

Signal-processing code has a texture of its own. Multiply-accumulate loops, modulo addressing through circular buffers and bit-reversed table walks produce dumps with large, evenly structured constant regions — filter coefficients, sine tables, window functions — that are unlike anything a PIC18 image contains. Those regions are the quickest completeness indicator on this part: a full 44K-word image shows them spread through the array, and their regular spacing makes corruption obvious at a glance. The eight output-compare channels and the five 16-bit timers, meanwhile, mean the vector table is broadly populated; large empty stretches in it are another truncation hint.

One family note worth recording: the quartet splits on the codec interface. The 6012 and 6014 carry the audio codec port supporting common protocols; the 6011 and 6013 do not. An image that exercises codec protocols therefore does not belong to this part, whatever the marking says — audio products should be checked against the 6012/6014 notes instead.

The EEPROM Wears First

The 2,048-byte data store deserves its own paragraph because on this family it ages visibly. Rated for a hundred thousand erase cycles minimum against the program flash’s ten thousand, it ends up written far more often than either — DSP applications log, accumulate and re-derive constantly, and industrial gateways with two CAN interfaces never sleep. After years in service the busiest region returns marginal reads between passes: the two-pass rule applies with emphasis here, and a third pass arbitrates where the first two disagree. Averages are never taken, because an averaged coefficient passes bench validation and fails under load in ways that look like a firmware bug rather than a worn cell.

Where a gateway’s network identity — node addresses, the customer’s CAN configuration — lives in that store, the delivery isolates it as its own section. Identities are the one thing a rebuild cannot derive from code and the one thing most likely to be needed on day one.

Verification

Two independent program-space passes compared byte for byte, EEPROM as a separate region, CodeGuard segment boundaries recorded, reset vector resolved to real instructions, the tail scanned for holes, and the silicon revision reconciled with the marking — the 6013 was revised to the 6013A, and the dsPIC30F6013A is a distinct device with its own errata sheet. Chip extraction analysis covers the review; reading the program memory the two-pass standard.

The services page lists deliverables; contact us with the marking photograph and what the board does for a specific device.