Electronics > Microcontrollers

PIC18F1320 in a Raman Spectrometer

(1/14) > >>

planc:


Is anyone familiar with the PIC18F1320 MCU? This is the MCU inside a $15,000 Raman Spectrometer. Is the PCB Evaluation board some kind of Evaluation board that you can buy elsewhere?

Also I can't seem to find anything about JTAG security blown feature in that MCU. Doesn't it have any copy protection?

I want to copy it and sell stuff like that. Are there laws that says reverse engineering is a crime? or reading firmware is a crime?

eutectique:

--- Quote from: planc on January 25, 2023, 03:33:34 pm ---I want to copy it and sell stuff like that. Are there laws that says reverse engineering is a crime? or reading firmware is a crime?

--- End quote ---

LMGTFY

ataradov:
The MCU has code protection enabled in the configuration bits.

There are definitely laws against copying stuff. The firmware binary is intellectual property and is protected. But how are you going to copy it if you can't find the eval board or the obvious information in the datasheet?

At 4K instructions and 256 bytes of SRAM, it is not going to do anything hard or important. It is likely jsut simple control functions. You can just figure out what it does functionally and re-implement it yourself avoiding IP issues at least in this part. Other design elements may be protected too.

planc:
If MCU can have code protection enabled in the configuration bits. Why do some MCUs like the MSP430 have JTAG fuses that can be blown?
Why not just use code protection enabled in the configuration bits?  In the market, how may percentage of MCUs have JTAG fuses that can be blown?

A few weeks ago I downloaded a 27K firmware from an MSP430 device with the JTAG fuse intact. It was used for backup because an old device I owned (based on the HC11) bought in the 1900s got the firmware bricked after the latest PC software just overwritten the original opcodes at certain memory. It took me so much time just tracing what it has altered by means of Serial Port Monitor. So in some cases, reading firmware for backup is important.

I noticed also that in MCU with EEPROM, the variables data were written directly to the EEPROM because you can change a byte at a time, like changing opcode 86 to 7E. That's why EEPROM based MCUs can be bricked by incompatible PC software. But with new flash based MCUs where the entire segment has to be erased. All of them uses external EEPROM to put variables or other data, right?  Or you have you used the flash to just alter a few data like one byte (for example, one byte written in a certain MCU flash memory if 1 channel chosen, another different byte if 2 channel chosen).

ataradov:
Configuration bits, fuses, lock bits - it is the same thing, different vendors use different names. The idea is the same - prevent further access to the device. Sometimes the change is permanent, sometimes the device can be unlocked after the firmware is erased. Some recent devices use unlock key, which you set while locking it. It makes it hard to unlock for cloning, but possible to unlock for failure analysis and debugging.

I don't understand the EEPROM part. MCUs use complicated flash controllers that are vendor-specific. What you can and can't change depends on the specific flash controller. Completely incompatible PC software would not even be able to start interaction with the flash controller in the MCU.

Navigation

[0] Message Index

[#] Next page