PIC18F1320 in a Raman Spectrometer

[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]

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?

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.

[planc]

I mean. Old devices like the 68HC11 or even the PIC18F132 uses internal EEPROM inside the chip as memory (with no other addtional external memory). I found out the PC program can alter some of the chip internal memory while running it for example to store channel 1 or channel 2 in EEPROM location B645. In purely flash based MCU like the MSP430. Can you store and do you store single byte memory inside the flash (within the chip)? Or do you use entirely use external EEPROM even for a few single byte variables or data? 

[ataradov]

PIC18F132 uses flash for program storage. It has small EEPROM for data storage, but it can't run the code from it. PC program connected though what interface? If it is just a serial port and the firmware executes commands, then the extent of what you can do depends on the commands. An actual programmer can do whatever it wants, but it would be highly vendor-specific.

If you are talking about data storage, then whether you can use internal flash like EEPROM depends on the flash controller. Often you can program erased locations (0xff) to any value where bits are cleared, but not set . But in order to write logical "1" into bits, you have to erase a bigger sector. You can read the data into SRAM, modify it, and write the whole buffer back.

On modern MCUs flash is very often used for data storage like this. After MCUs gained ability to erase the flash outside of the external programmer (integrated charge pumps to generate high programming voltages), integrated EEPROMs disappeared because they are a huge pain to manufacture in the same process as flash.

[planc]

Have you not actually used the ancient 68HC11 before?



Main program is written into internal 512 Bytes EEPROM. The PC software communicates to the HC11 via RS-232 serial port. It runs the firmware by using call function (for example Call B620). This outputs the ADC data right at the serial port.

HC11 was all I was familiar with because I was trying it out for 3 months late last year after the latest PC software meant for newer hardware altered the memory location B632 and changing opcodes bricking the firmware. And I recovered it after figuring out the missing opcodes.

The HC11 has internal resident BUFFALO Program. I can just access the EEPROM memory by typing simple commands. I don't know what would happen if there was no BUFFALO. One has to include subroutines in the firmware to access the EEPROM controller and read it?



This part of your sentence is puzzling "If you are talking about data storage, then whether you can use internal flash like EEPROM depends on the flash controller." What would be the use of built-in EEPROM in any MCU if it can't be used for data storage?? therefore all MCU with EEPROM should have flash controller that can use it as data storage. Isn't it.


Lastly, Have you worked with modern MCU that has no internal EEPROM for data storage and you don't use any external EEPROM either. But by reading the original written flash data into SRAM, modify it and write the whole buffer back as you described? I'm asking because if I'd use the MSP430 without any internal EEPROM and no external EEPROM. Where will you store the data?  Thanks.

[ataradov]

Have you not actually used the ancient 68HC11 before?

No, I did not and I never made any claims about it. I don't really care about stuff from 40 year ago.

What would be the use of built-in EEPROM in any MCU if it can't be used for data storage??

None of the modern MCUs have true EEPROM. EEPROM is hard to manufacture on the same die as flash.

therefore all MCU with EEPROM should have flash controller that can use it as data storage. Isn't it.

EEPROM and flash are two completely unrelated technologies.

Of whatever device you are talking about has EEPROM, it can be used for storage. But if you have a device that has only flash, this flash may or may not be used for dynamic data storage. This depends on the design of the flash controller.

Lastly, Have you worked with modern MCU that has no internal EEPROM for data storage and you don't use any external EEPROM either.

Yes, all the time. Here is appnote written by me on the subject https://ww1.microchip.com/downloads/en/DeviceDoc/EEPROM_Emulation_for_Flash-Only_Devices_DS90003222A.pdf and here is a practical implementation in a real project https://github.com/ataradov/open-5012h/blob/master/config.c

But this appnote is for robust implementation tolerant to power failures while writes are happening. In the simplest case you can just erase the block and write the data. The details depends on the MCU being used.

[planc]

I owned 2 EEG devices. One made in 1999 based on the HC11. The second one was made in 2010 based on the MSP430. The first one was bricked by running the 2nd EEG PC software. But I managed to restore the firmware and in learning it able to JTAG download the firmware of the MSP430 based for backup. However, I couldn't back up the EEPROM connected to the MSP430 shown in the above (see violet arrow). How you back up the EEPROM too?




They didn't implement your EEPROM less approach. But in the external EEPROM used in the MSP430 (see 93LC46CI spec). Is this EEPROM also commonly used in other MCUs? Or what other EEPROMs they use?

I connected to the MSP430 JTAG pins by tapping the 4 pins at the pcb (lower left of photo) above.
After downloading the PIC18F1320 datasheet above at https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/30009605G.pdf



Note the chip package is not the same as in the Raman chip photo in first message. But I just want to have idea what pins are equivalent to the 4 JTAG pins where one can download the firmware? The Raman spectrometer is connected to PC USB. Does Microchip have standard USB BSL access to the chip? In PIC, is there mass erase if wrong password entered in the BSL? Thanks!

[ataradov]

Please don't hijack threads. And there is no need to attach so many screenshots. I'm not an expert on any of those devices. I have no idea how to dump them.

[planc]

Please don't hijack threads. And there is no need to attach so many screenshots. I'm not an expert on any of those devices. I have no idea how to dump them.

How can I hijack my own thread? But many thanks for all the ideas. Modern day MCUs are just so difficult to use. So I guess my last MCU I'd ever use would be the HC11. Even with the HC11 I spent many late nights just figuring out how it works (there is no debugging mode because I don't have any evaluation board).

I already returned the Raman spectrometer I borrowed. A year ago, I thought Microcontroller meant something like a USB or standard interface that controls peripherals. I didn't know an MCU is like a computer. That was why I opened up the borrowed spectrometer thinking one can just replace the whole circuit by getting device that can control(ler). The pc software bricking the HC11 is blessing in disguise, for I learnt what a Microcontroller meant For after that. I never opened the spectrometer again before I returned to the lab. Had I destroy it, I had to pay for it. So I won't attempt to read the firmware anymore. Thanks for your warning.

[ataradov]

How can I hijack my own thread?

My bad, I thought this was someone else thread.

Modern day MCUs are just so difficult to use.

They are not. But you need to be methodical about it and not expect immediate results. And things like Arduino make it even easier.

(there is no debugging mode because I don't have any evaluation board).

This is where modern MCUs have a huge advantage. Developer tools for them are something they would not imagine in the wildest dreams 40 years ago.

[JPortici]

Note the chip package is not the same as in the Raman chip photo in first message. But I just want to have idea what pins are equivalent to the 4 JTAG pins where one can download the firmware? The Raman spectrometer is connected to PC USB. Does Microchip have standard USB BSL access to the chip? In PIC, is there mass erase if wrong password entered in the BSL? Thanks!

what are you talking about? the PIC in the first picture is the PIC18F1320-I/SO, which is the SOIC version. It's clearly SOIC, it's clearly 18pin, and the markings on the chip say so.

PIC microcontrollers don't use JTAG for programming, nor have integrated bootloaders. If Raman had programmed in there a bootloader which require access and deletes everything if wrong access, who knows? (THEM, of course)

The device programming pins they are /MCLR, PGC, PGD. If you take for example the pickit manual there you will see how to connect to them. But i have no doubts that it will be code protected so you can't read, only erase and write

[ozcar]

I guess my last MCU I'd ever use would be the HC11. Even with the HC11 I spent many late nights just figuring out how it works (there is no debugging mode because I don't have any evaluation board).

Above you showed "Buffalo" output. That was how most people used to debug HC11 code. At least that is what I did, and I also used similar tools on 6800 and 6809.

But it is not clear to me if what you showed there was from Buffalo running on the actual HC11 that you have.

[planc]

I guess my last MCU I'd ever use would be the HC11. Even with the HC11 I spent many late nights just figuring out how it works (there is no debugging mode because I don't have any evaluation board).

Above you showed "Buffalo" output. That was how most people used to debug HC11 code. At least that is what I did, and I also used similar tools on 6800 and 6809.

But it is not clear to me if what you showed there was from Buffalo running on the actual HC11 that you have.

Too late. Just when I was about to sell the old EEG unit, which I bought in 1999 but never used. I tried to enable its debugging mode  when I saw your message. You see. Even though the 68HC11 MCU it used has Buffalo in it. The debugging mode was disabled because it is not an evaluation board, but one that used the chip with Buffalo and custom board.






So I had to put a jumper (the black wire) in between the XIRQ and PA3 pin and holes tracks. I didn't try it before because I didn't want to experiment and ruin the unit before I could figure out how they could display 2 channels in one serial stream (I found out at last it used synchronization characters). I spent a month trying to understand the firmware after learning Assembly from scratch and figuring out the missing code the manufacturer bricked on purpose with their latest software (I used paper writing all the registers and loops and using THRSim1 simulator). A while ago. I used the trace function in Buffalo for the first time. It worked so nice. Didn't know the unit could really do that. But I noticed that whenever it passed through an interrupt enable (for example the CLI which enabled the Real Time Interrupt) . The trace got stuck on the next instruction. See:



Since you are one of the last few HC11 users. Let me ask you these questions:

1. Why did it get stuck after passing through instruction that enabled the interrupt? How do you proceed after it got stuck?

2. Have you encountered any commercial product with Buffalo in it? Is this the first time you see Buffalo in a finished product?

3. I find MCU to be incredibly time consuming. I had to spend hours just studying very simple functions. So I wanna ask what kinds of people participate here? Are they students or engineers of electronics? Or hobbyists?

4. The HC11 may be the last MCU I'll ever used. I don't have any applications for MCU at all. I want to know how they handle debugging in modern software that encounters an Interrupt enable instruction. Do the debugging also freeze after it?

5. If you understand the HC11 assembly language. Can you also understand the assembly languages of modern MCUs? Or do you need to start from scratch. I don't know any C language and don't plan nor have time (or application) to learn it.

6. Lastly. Do you have any ideas (or anyone at all) what kind of MCUs they used in thermonuclear warheads?  Do they manufacture their own MCUs or used commercial MCUs like the MSP430 or PIC?  In a post nuclear war scenerio, the most valuable product and job would be the ability to hack (or JTAG read) the MCUs of the unexploded nukes as you reprogram the firmware to aim and detonate at cities still unscathed. So if you will be given to choice to choose just one modern MCU to learn, I wonder if it would be something that you should be familiar with in a possible coming dystopian future like in Mad Max.

7. Btw. What is that exact brand of your CH340G USB-serial converter that can do non-standard 125k baud? All your ideas worked including Audacity. You made me spend one day just doing all you asked. MCUs are indeed so time consuming thing or hobby to do that's I'm moving to other areas.

Thank you for all the tips.

[coromonadalix]

was the thread about PIC18F1320  loll

Sometimes the programmation pins are put on a header, keypad etc ....  put a programmer on it and try to read it, if not,  it's locked  and nothing can or could be done ...

[Ian.M]

Worse: if you can get at the programming pins, an 8 bit FLASH PIC will always *appear* to read OK with a programmer, but you wont know whether or not a good read till you look at the lock bits in the read back CONFIG words, and the program memory contents, which read back as NOPs if the chip is locked (apart from a few early FLASH PICs which scrambled the read-back program data).

[planc]

Are you guys sure there are no mass erase security feature in any PIC18F1320 chip? It would be easy to trace the pins you can see in the initial pic with the MCLR, PGC, PGD in the chip then plug in the PIC debugger.

Raman Spectrometer has MCU because it's mostly connected to PC with an app interacted with it. But does this deserve the $15,000 tag? Has anyone built one with good sensitivity? I plan to build one so as not to damage the main one. I need it to study the effects or changes in the molecular structures after they got altered by the likes of Dr. Manhattan. There are several in China.

[ataradov]

What is "mass erase security feature"? PIC can be locked from reading. This lock could be removed by erasing the device. This ensures that you can always put your own firmware in, but can't get the firmware from the locked device out.

And in the worst case scenario you can always replace the whole IC.

I assume electronics is not the most expensive part of the device. Mechanical and optical components would be way more expensive. And the market it limited, so the price is relatively high.

[planc]

In the MSP430 I copied the firmware for backup (since I had experience as I explained the manufacter latest pc software bricking the HC11).

There are 2 kinds of access in the MSP430F2617 version. One is via 4-in JTAG pins. If the fuse was blown. You can't read it. There would be no mass erased. If it's not blown, you can read the entire firmware.  The second access is via BSL, here you need the password which are the vectors around FFF0-FFFF. If not entered correctly. It mass erased.

The MSP430FFXX series may use lock just as you described but I don't have any experience with them. So is the PIC18F132  like the newer MSP430FFXX where there is lock when accessing the pins via debugger? Or is the lock only if BSL is accessed? If you directly connect the 3 pins to the debugger at the PIC18F132. Would there be lock too? Or just in the BSL? In the older MSP430F217. The JTAG can't be locked. It's either the fuse was blown or you can read it if not blown.

[ataradov]

MSP430 and PIC devices are very different. If you are interested in PIC, then MSP430 information does not apply.

No idea what BSL is. There is only one programming interface in PIC - MCLR/PGC/PGD. If firmware author implements some other way to access the device (bootloader or just a command), then it is up to them, there is nothing standard.

Programming interface is always accessible, but it will not return valid data for read commands if the security bit is set. You can still issue the erase command, which would also clear the lock bit and the device would be unlocked, but erased.

[planc]

Okay that's a big difference. In MSP430, there is a bootloader program in the chip rom that you can always access using a standard BSL pc software via USB even if the chip contents are totally erased. So in PIC18F1320, there is absolutely no standard BSL (Boot Strap Loader) in the rom for the pc program to connect via USB even if chip memory all erased?



I intercepted the following entries in Serial Port Monitor when the spectrometer was first booted up:

"ÿÿÿ.Ž.......¦ÿÿÿ............hL..........Ž.......¤ÿÿÿ........Ž.......¤ÿÿÿ........Ž.......¦ÿÿÿ‹.......ÿÿÿÿ€...................Ž.......¤ÿÿÿ.......ŸŽ.......¤ÿÿÿ‹.......ÿÿÿÿ€.......Ÿ.„.................‹.......ÿÿÿÿ.(.......,.....Ž.......†ÿÿÿŽ.......¦ÿÿÿ.,.....Ž.......†ÿÿÿŽ.......¦ÿÿÿ‹.......ÿÿÿÿ€............4..l(ßÑ.8......
.......Ž.......¦ÿÿÿ.$..@
........ÿÿ‹.......ÿÿÿÿ.(.......,......Ž.......†ÿÿÿŽ.......¦ÿÿÿ‹.......ÿÿÿÿ.(..|....,......Ž.......†ÿÿÿŽ.......¦ÿÿÿ............hL.......à..Ž.......¬ÿÿÿŽ.......¤ÿÿÿ................‹.......ÿÿÿÿ€.@.....................•...¶....@..............................................................¶...ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ............hL.......ÿ..Ž.......¬ÿÿÿŽ.......¤ÿÿÿ................‹.......ÿÿÿÿ€.@.....%¸±.y´.DÒm"(±.¨$]­4.7«8BOn˜×/E
.Ç$HÒþ/W&X‚5-:ú.dŒ5Íâ.}Ò‹UˈÇ붥AÄI.5›P7Jy„Iƒ.NRt³'_ˆ.ëXc¹ÙÿPÆ-¬.éé.êLP—´d‹jõ(Eº.°< ó&'©–.h@‘.S²K.Ò!NâUB¶–Í<÷}.’Ã..uB.*ØÉø¨—.HQÄÍ°{ug:üO×”—½ìÞ*¾&.Ì5..cƒÿ.³."Ífå.ú0.w÷…ºtÙO™|$nãê¥/æ*.9‡’IY!®É—TÞì!.Nù&2æmý¸ý..NN} .ž.ª³»+
....@..Ž.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿ.,...€..Ž.......†ÿÿÿŽ.......¦ÿÿÿ‹.......ÿÿÿÿ€.......ÿ...Ž........ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿ.,...€..Ž.......†ÿÿÿŽ.......¦ÿÿÿ‹.......ÿÿÿÿ€.......ÿ...Ž........ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿ.,...€..Ž.......†ÿÿÿŽ.......¦ÿÿÿ‹.......ÿÿÿÿ€.......ÿ...Ž........ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿŽ.......¦ÿÿÿ"

What are the ÿÿÿŽ? Recognize any of the format or sequence?

Usually are USB outputs from the PIC18F1320 read only?  Or if you can access the serial/USB via Tera Term and type all kinds of commands, can it somehow affect the PIC chip memory inside and ruin or brick the firmware??  Can it be programmed to accept inputs from the Terminal and change the memory inside? Just want to know so in case it's possible. I'd not use Tera Term to mess with it.

[ataradov]

There is no standard bootloader in PIC18F1320. There is not USB either. Programmers are stupid cheap nowadays. Bootloaders make no sense and add to the cost of the device.

This is just random garbage. Are you even sure you have correct baudrate setting?

PIC18F1320 supports self programming, so it is possible to make the firmware that would self destroy.

[planc]

How do you know it's random garbage? When the pc app was run, and the unit boots up, it can run spectra sample of say alcohol. How do non random data look like?

When I went to device manager. I saw the following. It has 921,600  baud. And uses FTDI driver (and chip?)







Besides FTDI. What other brands of USB chips for example do other MCUs use?


When I went to Ebay and enter "Pickit". I saw this:


https://www.ebay.com/itm/382100189837?hash=item58f6f2328d:g:8LgAAOSws5pZJoox&amdata=enc%3AAQAHAAAAoDOiH%2Bsd1BqU5tSenfVkvqQlAmQ2OCcqBHgdT%2FMdnZXucgjxoR0Kug2NZ7qEUaXmxAYCBQjMw4UsneX9Q%2BoLS1Ztg1Pv1QYiQtDJkWp7%2BwiH35Nvj4xHU%2BtSXiKv9%2BNqvTeubBvnqgx2AchHgSp5nDrSh%2FrZ%2Fpulslr%2BLuAdXfWIfOmFsKWc1Cw0%2BUkZqLKhqnDuJ%2ByE%2FuwoAjUFI%2FrPyWk%3D%7Ctkp%3ABk9SR5DJ4ru_YQ

It's made in china. Are the debugger unit really open source now and can be built by any company? Should I get PICkit2 or PICkit3?

Also since you work at Microchip (right?)? Why didn't you erase the entire chip if wrong configuration bits or passwords used? Why do you guys allow the users to try accessing the firmware hundreds or thousands of times (of all password combinations) without erasing it on wrong passwords?

You are encouraging me to buy the PICkit and attempt firmware reading without risk or fear of it being erased.