EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: socram on December 12, 2020, 05:16:52 pm
-
Hello, good evening everyone.
I'm creating this thread to discuss about programming Fremont Micro Device's series of PIC clones, available at LCSC (https://lcsc.com/products/Other-Processors-and-Microcontrollers-MCUs_11116.html?brand=11443) for prices roughly the same of the awesome Padauk (https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/) microcontroller lineup. For example, the FT60F211 (https://lcsc.com/product-detail/Other-Processors-and-Microcontrollers-MCUs_FMD-Fremont-Micro-Devices-FT60F211-RB_C708779.html) offers 1 Kword flash, 64 byte SRAM, 128 byte EEPROM for about 5 cents each by buying 150 units.
These microcontrollers, just like Padauk's, have absolutely zero public documentation on how programming these work, and the manufacturer expects you to program them with either their standalone which isn't available on LCSC or any other reputable provider I've looked for, and goes for about 40€ on AliExpress (https://www.aliexpress.com/item/4000603331628.html). I think, just as we did for the Padauk, we can do better.
Now that we have fully reverse engineered Padauk's inner workings, have them supported in SDCC, and being cheaper than FMD's, one might wonder - what's the point?. Well, there's one advantage that FMD seems to offer vs Padauk's - how simple the programmer can get.
After spending a couple hours looking online, I found the following valuable resources:
- Thanks to FMD's official programming manual (https://www.fremontmicro.com/en/down/slq/index.aspx), I found that these devices require only four wires: VCC, GND, clock and data. Unlike Padauk, there's no provisioning for Vpp that is complex to generate.
- Further looking online, I found that there are also what FMD calls "Link Bridge": a smaller, cheaper in-circuit programmer, which is available on AliExpress for 30€ (https://www.aliexpress.com/item/32998498638.html).
[attach=1][attach=2]
This gets more interesting - not only we can clearly see that are no coils for elevating the voltage, but we can also see in one of the pictures the very IC they are using: an off-the-shelf STM32F103RB6T. - Finally, looking deeper in FMD's programmer software, I found three files which looked suspiciously like ARM bytecode. These were:
- Ver1/AppUpdate.bin
- Ver3/AppUpdate.bin (load address 0x08008000)
- Ver3in1/AppUpdate.bin (load address 0x08004000)
Thanks to the previous picture, I tried loading them under IDA using the asumption that they were STM32 firmwares and... oh boy they were:
[attach=3]
There are no debugging symbols. However, they're only about 50KB and are not obfuscated, meaning I've managed to manually and painstakingly decompile a good chunk of them.
Thanks to all these sources, I'm glad to announce that I've found out how to:
- Enter the programming mode
- Read part of the flash contents
And the best thing of all: I've done it using an Arduino, with absolutely no extra hardware.
Signals
FMD devices use four wires during programming:
- VCC, inside their normal operating range
- ICSPDAT, the data pin
- ICSPCLK, the clock pin
- GND
If you have worked previously on Padauk, the signaling is pretty similar: the programmer always generates the clocking signal, and the data pin is shared and changes direction implicitly depending on the operation and the step they're into.
For instance, sending 0xA3 would look like:
Sample: V V V V V V V V
___ ___ ___ ___ ___ ___ ___ ___
Clock: | | | | | | | | | | | | | | | |
___| |___| |___| |___| |___| |___| |___| |___| |____
_______________ _______ _______
Data: | | | | | |
_| |_______________________| |_______| |__
Data is sent and received least significant first, and is sampled at the falling edge of the clock signal.
Entering programming mode
For entering programming mode, all microcontrollers follow the same procedure:
def enter_prog():
vcc_on()
serial_write(data=0x1CA3, bits=16)
delay_ms(70)
There is no acknowledgement - the microcontroller will not reply with anything, and the only way to know it has entered successfully programming mode is to execute a command and check its return value.
Programming opcodes
The programming protocol uses three different kind of opcodes:
Implicit opcode
They consist of a bare 5-bit opcode.
def op_execute(opcode):
# Send opcode
serial_write(data=opcode, bits=5)
Known such commands so far are:
- 0x01: unknown meaning
- 0x02: unknown meaning
- 0x04: reset address counter
- 0x05: increment address counter
- 0x06: unknown meaning
- 0x07: unknown meaning
Write opcode
They consist of a 5-bit opcode, a 8-bit parameter, and an extra dummy 0 bit.
def op_write(opcode, parameter):
# Send opcode
serial_write(data=opcode, bits=5)
# Send the parameter
serial_write(data=parameter, bits=8)
# Dummy cycle
serial_write(data=0, bits=1)
Known such commands so far are:
- 0x08: store parameter into LSB latch?
- 0x09: store parameter into MSB latch?
- 0x0A: change mode?
Read opcode
They consist of a 5-bit opcode, and the device replies with an 8-bit response, plus a dummy bit during which the device frees the data pin.
def op_read(opcode):
# Send opcode
serial_write(data=opcode, bits=5)
# Read response
response = serial_read(bits=8)
# Dummy cycle
serial_read(bits=1)
return response
Known such commands so far are:
- 0x0C: read LSB from current position?
- 0x0D: read MSB from current position?
Programming sequences
Using the opcodes explained above, the programmer defines the following sequences for programming the devices:
Program memory read
def prog_read(word_count):
# Set mode to 0x20, program flash read
op_write(0xA, 0x20)
# Reset address counter
op_execute(0x4)
words = []
for i in range(word_count):
# Read MSB and LSB. These two can be used in either order
msb = op_read(0xD) & 0x7F
lsb = op_read(0xC) & 0x7F
words.append(msb << 7 | lsb)
# Increment address counter
op_execute(0x5)
return words
Program memory write
def prog_write(words):
# ???
op_write(0xA, 0x56);
op_write(0xA, 0x20);
op_write(0xA, 0x24);
op_write(0x9, 0x1A);
op_write(0x8, 0x00);
op_execute(0x6);
# Reset address pointer
op_execute(0x4);
# Iterate through words and write each one
for word in words:
# Set into programming mode?
op_write(0xA, 0x30)
# Latch MSB and LSB
op_write(0x9, (word >> 7) & 0x7F)
op_write(0x8, word& 0x7F)
# ???
op_execute(0x1)
op_execute(0x6)
# Wait until the word is written
delay_us(1500)
# ???
op_execute(0x7)
# Increment address pointer
op_execute(0x5);
Program memory erase
def prog_erase(words):
# ???
op_write(0xA, 0x20)
op_write(0xA, 0x25)
op_write(0x9, 0x1A)
op_write(0x8, 0x08)
op_execute(0x6)
op_execute(0x4)
op_write(0xA, 0x31)
op_execute(0x2)
# Wait until memory is erased
delay_ms(50)
# ???
op_execute(0x7)
TO-DO
- Figure out configuration flash commands
- Try to make sense of the opcodes, maybe?
Any help is welcome!
-
Data is:
- Sent least significant first, and is sampled at the falling edge of the clock signal.
- Received most significant first, and is sampled at the falling edge of the clock signal.
This is impossible, unless there is a bit-order reversing chip placed in the middle. It has to be one or the other.
Jon
-
You are right, data is always sent LSB.
I also found out how to read, write and erase main program memory. I'll edit the post once I got it fully understood and documented.
-
I have just updated the main post with how to erase, write and read the main program memory. There is still a considerable amount of work, though.
-
More Info:
From the demo code we see that the FT60Fxx and FT62Fxx are PIC compatible with 16F684 or 16F685 and use the H-Tech C compiler version 9.83 which is actually XC8 1.00 Microchip compiler.
Versions of Hi-Tech C are available on the Microchip site, but require an account signin. Older versions of XC8 are available on the same page:
hxxps://www.microchip.com/development-tools/pic-and-dspic-downloads-archive
Following the link on the programmer board, we see that the company www.origin-gd.com (http://www.origin-gd.com) (Shenzhen Origin Tech Co.) produces similar chips and in fact their MS80Fxx and MS81Fxx are exactly the same as the Fremont Micro above named parts(Probably the other parts are also the same).
Origin Tech has lot more documenttation including the IDE as well as demo video showing the PIC compatibility of their chips. They actually Use MPLAB to program their chips.
Origin Tech's online shopping pointer page has lot more interesting info, where are they are claiming the PIC compatibility and the corresponding PIC parts.
See: hxxps://yueyd.world.taobao.com/
In the demo examples, we see the compatible PIC chip numbes.
We see that the MDT part MS80F0801A, claiming same as 12F508/509, is priced at 0.21 yuan(about 3 cents).
Also on the Origin Tech's site, they list MDT as their associate site. MDT's parts, available on LCSC, are not as cheap but still around $0.10 to 0.20.
MDT's HMC1509 (~ same as 12F509) is listed at 0.30 yuan on Taobao.
MDT also claim compatibility with the older PIC chips.
@socram: If you own the red programmer board, could you post a hi-res version image of the front and the back.
Ramesh
-
From the demo code we see that the FT60Fxx and FT62Fxx are PIC compatible with 16F684 or 16F685 and use the H-Tech C compiler version 9.83 which is actually XC8 1.00 Microchip compiler.
Now that's pretty interesting, good find. I tried looking for the equivalent parts but I couldn't find anything.
For scientific research, I tried programming the Fremont parts using my MiniPro programmer and it failed with an overcurrent protection error. I have no clue about what is the original programming protocol in Microchip PICs, so I don't know if it resembles this one and it's just failing because MiniPro uses the high-voltage mode and these only support programming in low voltage mode, or if they are entirely different beasts.
@socram: If you own the red programmer board, could you post a hi-res version image of the front and the back.
Hello Rameshd. I do not own those programmers sadly. The pictures are from Taobao listings I found.
Marcos
-
PIC programming specifications are readily available - take a look and see if you can find any similarities.
-
http://ww1.microchip.com/downloads/en/DeviceDoc/40001204J.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/40001204J.pdf)
Doesn't seem to be compatible. Microchip uses 6-bit commands with optional 14-bit parameters, while these Fremont devices use 5-bit commands with optional 8-bit parameters.
-
Nice 8-bit CPU wars at low prices >:D
-
Programming the FMD devices is not straightforward. I assumed you had already seen some related docs.
Here are two Google translated docs. There is some info in those.
NOTE: The second is from origin-GD, but the programmer is the same.
-
SDCC does support PIC. But the PIC backends are currently unmaintained, and not in the best state (clearly worse than pdk, stm8, z80, mcs51, etc). Any help would be welcome.
-
SDCC does support PIC. But the PIC backends are currently unmaintained, and not in the best state (clearly worse than pdk, stm8, z80, mcs51, etc). Any help would be welcome.
Also, SDCC uses gputils assembler / linker for the PIC backends. gputils is AFAIK also unmaintained. And the Debian package also hasn't been updated in a while (the packaged gputils version is 1.4.0 from 2014, while there were some releases after that, the latest being 1.5.0 in 2016).
So there is plenty of work for someone wanting to keep the free toolchain for PIC working.
-
http://ww1.microchip.com/downloads/en/DeviceDoc/40001204J.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/40001204J.pdf)
Doesn't seem to be compatible. Microchip uses 6-bit commands with optional 14-bit parameters, while these Fremont devices use 5-bit commands with optional 8-bit parameters.
Wikipedia says ELAN Microelectronics also makes PIC-"clones" with 13-bit istructions, some of which (e.g. addlw and retlw) fit your description:
https://en.wikipedia.org/wiki/PIC_instruction_listings
Though that page also claims that Padauk are PIC-like, which IMO, they aren't.
-
Wikipedia says ELAN Microelectronics also makes PIC-"clones" with 13-bit istructions, some of which (e.g. addlw and retlw) fit your description:
https://en.wikipedia.org/wiki/PIC_instruction_listings
Though that page also claims that Padauk are PIC-like, which IMO, they aren't.
No no, I was talking about the programming commands, the ones sent to the device via the ISP. The device themselves do seem to use standard 14-bit PIC instructions, which would make it possible to run a 1:1 PIC program in one of these.
-
Wikipedia says ELAN Microelectronics also makes PIC-"clones" with 13-bit istructions, some of which (e.g. addlw and retlw) fit your description:
https://en.wikipedia.org/wiki/PIC_instruction_listings
Though that page also claims that Padauk are PIC-like, which IMO, they aren't.
No no, I was talking about the programming commands, the ones sent to the device via the ISP. The device themselves do seem to use standard 14-bit PIC instructions, which would make it possible to run a 1:1 PIC program in one of these.
Ok, so it looks we can just use the existing SDCC/gputils toolchain. How about the I/O? Is it the same as some PIC? Will we need new headers for these devices?
-
Also, SDCC uses gputils assembler / linker for the PIC backends. gputils is AFAIK also unmaintained. And the Debian package also hasn't been updated in a while (the packaged gputils version is 1.4.0 from 2014, while there were some releases after that, the latest being 1.5.0 in 2016).
Was there a reason why gputils was chosen instead of aspic from the asxxxx family? Aspic came after the choice was made?
-
Also, SDCC uses gputils assembler / linker for the PIC backends. gputils is AFAIK also unmaintained. And the Debian package also hasn't been updated in a while (the packaged gputils version is 1.4.0 from 2014, while there were some releases after that, the latest being 1.5.0 in 2016).
Was there a reason why gputils was chosen instead of aspic from the asxxxx family? Aspic came after the choice was made?
I don't know. AFAIK, the pic ports existed before any of the current SDCC developers joined the project.
-
This is quite interesting. I am a bit confused about your examples. They seem to use python pseudocode, yet you state that you use an Arduino? How does your set up work?
Were you able to successfully write a device? I received some from LCSC now, still not sure what to do with them :)
(Btw, the 6 pin FT60F210-URT is now also available)
-
I've been monitoring the PDK and then found this thread.
I was looking for an extremely cheap MCU with almost 1k flash and 128 bytes RAM and EEPROM.
first I found PDK and it looked fantastic, however, there was a problem and that was their IDE which doesn't support ANSI C. after a while I found out about free-PDK and then SDCC. so it all seemed to be coming together. I build the Free-Paduak programmer with no problem and was about to start the development that I found out that the SDCC doesn't fully support pdk13 yet and also it's buggy and doesn't fully support ANSI-C (yes there are some restrictions)
I had read about other low cents MCUs like the MS80 that are pic clones however when I asked a distributer he said they are not 1:1 compatible until I read this post. I think It all makes sense now.
IMO the FMD and MS80s (origin-gd) are way more superior than the PDK now because of the following:
Feature ----------------------- PDK -------- FMD(other PIC clones)
=============================================
Price ---------- >0.05$ ----- >0.05$
Core ------------ FPPA -------- PIC
EEPROM ------------- NO -------- YES
Standard Compiler ------------- NO --------- YES
cheap programmer ------------ YES --------- NO (not yet!)
I first thought that by PIC-clone they meant only the CORE is cloned and other peripherals might be different. but now I see that there are some series that are actually a clone and a 1:1 binary clone is possible. the only problem so far is the programmer which is a bit expensive. even that uses STM32 and it seems @socram has already got a dump of it. so why build another programmer and have the hassle of the PDK programmer? i think it's way easier and cheaper to just clone the existing programmer!
the IDE is HI-TECH compiler and I believe for the 1:1 chips we can even use MP-LAB and the XC8 compilers already!
does anyone have a dump of the STM32 on the programmer?
also why isn't there any file in the IDE section of FMD ?
-
Your list does not exactly reveal why the FMD devices would be superior :D The older PICs are still a horrible architecture, PDK14/15 is much nicher to be honest. Also consider that Microchip may object cloning of their devices. They actually sued MDT for doing the same.
However, being able to program the FMD devices with a low voltage programmer would be a huge plus. I have not been able to look into this myself so far, I am hoping there will be some progress on that.
-
Your list does not exactly reveal why the FMD devices would be superior :D The older PICs are still a horrible architecture, PDK14/15 is much nicer to be honest. Also consider that Microchip may object cloning of their devices. They actually sued MDT for doing the same.
However, being able to program the FMD devices with a low voltage programmer would be a huge plus. I have not been able to look into this myself so far, I am hoping there will be some progress on that.
superior in the sense of low-end MCUs. I have never heard that the older PICs were horrible. I'm not talking about the technology of the MCU core, I'm talking about its robustness. PIC core was designed by a US company and it has been in the market long enough. It's correct they may sue for cloning their IP but hey it's china! the worst that can happen to them is being added to the list of sanctions. but they'd still be able to sell their product one way or another.
another important aspect is the compiler. SDCC is not mature while HI-TECH and XC8 are heavily maintained. the EEPROM is also another plus which non of the PDK series have. to interface an external EEPROM at least 1 pin is needed, let alone the burden of code to read and write to it! in small flash size, such things are very important.
-
I just tried compiling the same program for a PMS154C and MS80F0801A MCU
the results are interesting:
apart from device-specific startup code and initialization the rest of the program was the same. since my code doesn't fit for the PDK I now have to switch to the MS80.
Device PMS154C MS80F0801A
===============================
Flash Size 2KW 1KW
Flash usage >2KW 736 byteswords!
RAM (bytes) 124 56
Compiler SDCC HI-TECH
let alone the fact that MS80 has 128 bytes of EEPROM which I need and the pdk doesn't have any.
the major difference for me is the RAM usage! that is a huge difference! my program only has 32 bytes of global data and the rest are the variables for functions that should go on the stack. I have no idea why SDCC gobbles that much memory. once again the PIC core is more robust and the compilers are way more mature.
edit: according to HI-TECH manual the only Divergence from ANSI C it has is the lack of support for reentrant functions whereas SDCC has a lot more limitations!
-
I have just updated the main post with how to erase, write and read the main program memory. There is still a considerable amount of work, though.
There are 3 update .bin files inside the Origin writer folder:
Ver3in1
Ver3
Ver1
have you figured out which file is for which programmer?
I think 1 should be for the one with the LCD which is used for batch programming.
another one should be for the Link Bridge programmer.
I suppose there is another programmer out there? BTW both programmers are much cheaper on taobao.
-
I am getting a Fremont ICE and programmer (they're not expensive so I picked them up while purchasing my padauk ICE and writer). I can provide some high res photos and capture some programming sequences with my FX2LP logic analyzer. Do you guys want to see a specific IC's sequence or any IC will do?
-
I am getting a Fremont ICE and programmer (they're not expensive so I picked them up while purchasing my padauk ICE and writer). I can provide some high res photos and capture some programming sequences with my FX2LP logic analyzer. Do you guys want to see a specific IC's sequence or any IC will do?
Maybe some of the cheaper ones like FT60F211 or FT60F210.
-
Btw, it looks like the programmer uses an STM32F103 and only few additional devices. Are the schematics available anywhere and the firmware? Maybe it is easily possible to clone the programmer with a bluepill.
-
Btw, it looks like the programmer uses an STM32F103 and only few additional devices. Are the schematics available anywhere and the firmware? Maybe it is easily possible to clone the programmer with a bluepill.
Unfortunately, the sch is not available anywhere. The firmware is available with their IDE or writer software.
-
I am in possession of both programmers now.
I tested the MCUs and boy they get the job done! much better than the Padauk.
another interesting fact is that there's also another company named hqwtech.com that has another series of these MCUs with different part numbers. in my opinion, there should be a parent company that is selling the chips to the other companies and they just rebrand them. the architecture is all the same. my MS80x doesn't have any print on them while the FMDs do. FMD has its own IDE which is a clone of origin-gd IDE
There are 2 types of programmers for these MCUs.
one that is the red board and is called the bridge (mine [bought from hqwtech] has a black solder mask and is versioned 2.6 and the components are a little different) and works with all the IDEs of the companies. it's capable of debugging and programming via the IDE only.
the other programmer is used for batch programming and doesn't do debugging. can be run offline and has a couple of features like burning FLASH, EEPROM, OSC calibration, checking, rolling code (where part of the EEPROM is modified and the value is incremented sequentially which I believe is mostly used for serial numbering and HCS3xx cloning). also has a Rx,Tx interface where you can send commands to the programmer via serial for things like flash and EEPROM modification on the fly for every MCU before programming it.
-
update:
the FMD IDE and ORIGIN IDE are basically the same. you can burn and load HEX files produced by both IDES to both chips.
if you look at the datasheets of MS8x and FMD you'll see that they're basically the same, (on page 8 of the MS81x series datasheet you'll see that Origin even forgot to change some FMD register names! )
however the unlike the PICs it's not possible to put "#pragma config xxx" and it seems that the IDE doesn't let you config them by code and it put's it's own special coding in the HEX file. hence there's some kind of obfuscation involved. if you see the HEX file produced by the IDE and you look at the one before the last line you'll see the config options there. as opposed to what says in the datasheet, the config is written starting at address 0x4000 (instead of 0x2000), and I think the programmer will detect that and apply the correct address when programming.
I wanted to test the features the config options provide, and to my surprise, the EEPROM section has no protection and there's no config to protect it. since these chips are clones of the PICs, I thought the manufacturer might be hiding some features but looking at the fusebits of PICs, I noticed that the UCFG0 mapping is different. however, some bitfields are left as preserved while they could actually do something that's not stated in the datasheet, (like the case in padauk MCUs). Chinese datasheets are very horrible and usually, there are always some parts left out and not explained.
long story short, to test the preserved bits in the config (UCFGx) section, the HEX file must be edited manually but it's not a straightforward process and it seems some additional work is required.
in case anyone's interested here is my finding on the cryptic config options that the IDE produces.
in the HEX file you'll see something like this. on the one before the last line which is the standard intel HEX format.
+-----+------+------+-----------------------------------+----------+
| len | addr | type | data | checksum |
+-----+------+------+-----------------------------------+----------+
| 0D | 4000 | 00 | D4 03 E0 09 F6 05 FF 0D0102000108 | E0 |
+-----+------+------+-----------------------------------+----------+
the data part changes according to the options you select in the IDE, this option also includes the ones in the project -> properties menu like number of programming , etc. the bytes are scattered like this:
+-------+------+-------+------+-------+------+------------------+
| UCFG0 | UNK0 | UCFG1 | UNK1 | UCFG2 | UNK2 | rest of data |
+-------+------+-------+------+-------+------+------------------+
| D4 | 03 | E0 | 09 | F6 | 05 | FF 0D0102000108 |
+-------+------+-------+------+-------+------+------------------+
I could only observe that the UCFG0-2 positions like the table above and the other parts remain unknown and also if the UCFG0 part changes some other part may change as well so it's not possible to manually modify the UCFG's and try out different options because the programmer will detect this as error (not tested).
the UNK0 and UNK1 seem to remain constant on all mixture of configurations but UNK2 changes. also the UNK values differ in each MS8x or FT6x series. the above table is for MS81 series.
if anyone has any clue I'm interested to try things out.
-
Hi everyone,
I replied on this topic (But I don't understand why I'm banned. Sorry if I doing something wrong, please let me know if I'm wrong).
I found this MCU MS80F0601A on the Taobao. But I'm confusing about which programmer should I have to buy?
I found a board (https://item.taobao.com/item.htm?spm=a312a.7700824.w4002-23880832492.12.2acb352bTN8AkK&id=544475222638), but I'm not sure that it correctly what I want.
And I have another question, this MCU can be re-programming?
Thank all.
-
Hello friends. I can't find the FMD-IDE software. Can you help me? Thanks
-
How can I find out the compatibility of FMD chips with PIC chips? Does anyone have a table?
-
Interestig thread on wrong subforum, should be moved here:
https://www.eevblog.com/forum/microcontrollers/ (https://www.eevblog.com/forum/microcontrollers/)
-
Btw, it looks like the programmer uses an STM32F103 and only few additional devices. Are the schematics available anywhere and the firmware? Maybe it is easily possible to clone the programmer with a bluepill.
The board bluepill uses a chip STM32F103C8T6 - the programmer needs STM32F103RB...
-
Hi socram. Is your Arduino code available somewhere? I'm trying to identify an MCU with erased markings that might be from Fremont Micro.
Thanks!
-
The peripherals look the same. There one thing they differ on is the interrupt handling. It seems they use a single interrupt in which you must decide what causes the interrupt. I am still pulling the Chinese data sheets through google translate.
-
Programmer need bootloader
-
Hi,
anyone knows how FMD MCUs with flash protection enabled behave? I'm playing with FT61F043* (probably, no part number printed on IC, but pinout suggests it) used in some power meter. When I read IC ID, it responses with seemingly correct data:
0444 3F12 030A 3F12 010A 0510 194A 29D0 18B1 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF
(the programmer firmware checks the fist byte to 0x04 to validate it)
But when I reading the flash memory the data seems somehow scrambled:
1F9F 3F9F 0F9F 0F9F 0FFF 0F9F 0FFF 0F9F 0FFF 1F9F 3F9F 1F9F 3F9F 2FBF 1F9F 3F9F
1F9F 0FBF 3FFF 1F9F 0FBF 3FFF 1F9F 0FBF 3FFF 1F9F 0FBF 2FFF 1F9F 0FDF 2F9F 0FDF
...
I guess the reason is enabled flash protection, although I expected reading just 0x0000 or 0x3FFF in such case.
-
Did you manage to download the Fremont IDE gashtaan? It seems the download is disabled...
-
Link for FMD IDE 3.0.9E:
https://we.tl/t-BWLkoqhfch
-
Thanks a lot! May I ask you how did you get it?
-
No problem, it was posted here:
https://www.eevblog.com/forum/microcontrollers/fmd-ide-(fremont-micro-devices)-i-cant-find-and-download-it/msg4569175/#msg4569175 (https://www.eevblog.com/forum/microcontrollers/fmd-ide-(fremont-micro-devices)-i-cant-find-and-download-it/msg4569175/#msg4569175)
-
One more question: have you (or anybody else) figured out how to read the FMD chips markings?
My FT60F211-RB read "B2H7CKH"...
-
Did you manage to download the Fremont IDE gashtaan? It seems the download is disabled...
No, I looked only into the programmer firmware and that is free to download.
-
Hi,
anyone knows how FMD MCUs with flash protection enabled behave? I'm playing with FT61F043* (probably, no part number printed on IC, but pinout suggests it) used in some power meter. When I read IC ID, it responses with seemingly correct data:
0444 3F12 030A 3F12 010A 0510 194A 29D0 18B1 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF
(the programmer firmware checks the fist byte to 0x04 to validate it)
But when I reading the flash memory the data seems somehow scrambled:
1F9F 3F9F 0F9F 0F9F 0FFF 0F9F 0FFF 0F9F 0FFF 1F9F 3F9F 1F9F 3F9F 2FBF 1F9F 3F9F
1F9F 0FBF 3FFF 1F9F 0FBF 3FFF 1F9F 0FBF 3FFF 1F9F 0FBF 2FFF 1F9F 0FDF 2F9F 0FDF
...
I guess the reason is enabled flash protection, although I expected reading just 0x0000 or 0x3FFF in such case.
if I enable Flash protection the programmer reads 0xFFF for all bytes. so maybe you have faulty wiring? or some other setup or chips?
could you enable EEPROM protection by any chance?
-
if I enable Flash protection the programmer reads 0xFFF for all bytes. so maybe you have faulty wiring? or some other setup or chips?
could you enable EEPROM protection by any chance?
Are you sure it reads 0xFFF not 0x3FFF?
I doubt the faulty wiring is the problem. I would expect some randomness it such case, but I got the same data every time, even for various clock timing (15ns vs 150ns).
The problem is that I have no clue what data should I expect to be read. Here are other readings:
UCFG data:
09A4 07D2 02F3 03C0 0508 02FF 02FF 07F8 0FFF 0FFF 00FF 00FF 3FFF 3FFF 3FFF 3FFF
...
EEPROM:
40 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
Attaching scope photo of one sequence of reading data from flash (0x0D command, read value, 0x0C command, read value, 0x05 command). Blue signal is the data, green the clock and yellow is just to show, when the data are transmitted from the FMD.
-
Data, clock and... ?
-
Data, clock and... ?
Yellow is generated by me for clarity, its high when I set ISPDAT to input, the blue data signal is generated by FMD at that time.
-
I realized only now you're using your own programmer. Am I right?
Would you mind sharing the code?
-
Would you mind sharing the code?
Sure, later when it'll be actually working code I'll put it to github :)
-
Are you using an Arduino like the original poster did?
It would be actually interesting to see the unfinished code but I understand your desire to clean before publishing.
Just don't delete everything by mistake. As I did...
-
Are you using an Arduino like the original poster did?
It would be actually interesting to see the unfinished code but I understand your desire to clean before publishing.
Just don't delete everything by mistake. As I did...
Yes, I chose Arduino Nano for this project, but it doesn't really matter.
Even if I did delete the code, it's just few lines of the code, it wouldn't be a irreversible loss. Reverse engineering is the hard job here, so many thanks to @socram for valuable inspiration.
-
Yes I did the same. My code seemed to work at first but I have some problem reading the eprom. I'm eager to see your code (and use it too)
-
Would you mind sharing the code?
Sure, later when it'll be actually working code I'll put it to github :)
Hi gashtaan, did you manage to solve the issue?
-
Hi gashtaan, did you manage to solve the issue?
Not yet. I've ordered some FMD to experiment with, but it was from AliExpress, so this project is postponed for some weeks or even months... if I'm lucky and it'll be actually working IC.
-
@gashtan
I don't have my programmer right now to check for the flash readout protection.
Could you by any chance discover if it's possible to protect the EEPROM as well?
I can't find any info on this anywhere. I'm only making assumptions they forgot to implement such protection.
Also, what is the difference between FT61F021 and FT61FC21?
their datasheet is almost identical besides very small differences in electrical characteristics.
On their new website, FMD also has a new part number (the E series) such as FT60E021 which is again identical to the F series. The only visible difference is the DROM (EEPROM) data endurance which is 100k compared to 1000k of F series. This is very strange, why did they manufacture a new product with less endurance?
I'm planning to manufacture large quantities of a small device for some time now and I need the EEPROM but still can't make a decision if the FMD is a good choice or not. Their price is super competitive.
-
@gashtan
I don't have my programmer right now to check for the flash readout protection.
Hi danymogh, would you be so kind (whenever you are again in possession of your programmer) to post here a logic analyzer capture of the signals? (I'm assuming you have one...)
I have this strong feeling that the information provided in this thread is missing something crucial, since at least 2 of use have already tried and failed at replicating the results of the original poster.
That would be nice indeed!
-
https://oshwhub.com/kktun/PICjian-rong-dan-pian-ji-xue-xi-
This is worked!
-
https://oshwhub.com/kktun/PICjian-rong-dan-pian-ji-xue-xi-
This is worked!
Interesting, but I can't download without registering, and cannot register without giving away my phone number. LOL
-
https://oshwhub.com/kktun/PICjian-rong-dan-pian-ji-xue-xi-
This is worked!
This looks very good and very cheap to make. Such a shame our Chinese friends always restrict their content. you can't even signup using another country's phone number!
however, looking at just the screenshots of the PC software. it's a programmer-only version and does not have debugging features enabled. Yet it's very cheap (the PCB and components won't cost more than 3$) and nice to have.
I'm mainly interested in the .Net program. It'll help a lot in analyzing the programming sequence.
@buttim
I have 2 programmers. they are the old series. the yellow one is for batch production and does not support debugging.
the black one (Link) is used for programming and debugging however it doesn't support batch programming for production.
both work with FMD and Origin IDE.
I do not have a logic analyzer, unfortunately. (the only missing tool in my arsenal!)
I've been in possession of both for about 2 years now and let me tell you one thing. even though the ICs are super cheap and well-suited for small applications, the support, documentation, and everything else is a headache!
if you encounter a problem, it's highly unlikely you'll find documentation or help other than what is already available. also, keep in mind that the silicon of the ICs have had several revisions in just 3 years to fix whatever they messed up in previous revisions. This means unreliable production.
I've tried contacting FMD via email or even suppliers to ask for support and never got a response back! they even don't publish the IDE on their website and you'll have to get it from suppliers manually! the compiler is XC8 in the heart but they rebranded it as GCC! These are a lot of red flags in engineering, however, because of the cheap price people still consider them.
-
since at least 2 of use have already tried and failed at replicating the results of the original poster.
The FMD programmer support 73 distinct MCU types with various differences in communication. If one works OK it doesn't mean the other will work too. You should find out what type are ICs you are interested in (Setting.bd file) and look into the firmware code for details.
-
I do not have a logic analyzer, unfortunately. (the only missing tool in my arsenal!)
Do yourself a favor and buy a "24MHz 8 channels logic analyzer". They're dirty cheap and good enough for most tasks. For example: https://it.aliexpress.com/item/1005005357814678.html (https://it.aliexpress.com/item/1005005357814678.html)
I've been in possession of both for about 2 years now and let me tell you one thing. even though the ICs are super cheap and well-suited for small applications, the support, documentation, and everything else is a headache!
if you encounter a problem, it's highly unlikely you'll find documentation or help other than what is already available. also, keep in mind that the silicon of the ICs have had several revisions in just 3 years to fix whatever they messed up in previous revisions. This means unreliable production.
I've tried contacting FMD via email or even suppliers to ask for support and never got a response back! they even don't publish the IDE on their website and you'll have to get it from suppliers manually! the compiler is XC8 in the heart but they rebranded it as GCC! These are a lot of red flags in engineering, however, because of the cheap price people still consider them.
I know... I also tried to contact FMD to no avail. I'm mostly interested in reverse engineering and maybe rewriting firmware for devices containing an FMD MCU, not designing things. I think a very simple programmer would do.
The FMD programmer support 73 distinct MCU types with various differences in communication. If one works OK it doesn't mean the other will work too. You should find out what type are ICs you are interested in (Setting.bd file) and look into the firmware code for details.
The original poster did the heavy lifting. I think we're just missing some tiny (but important!) detail. Restarting the original reverse engineering is overkill for me. If some of our chinese friends here wants to upload the CH552 firmware and .Net code, that would be great. Otherwise I'll just do something else
-
I'm mostly interested in reverse engineering and maybe rewriting firmware.
Restarting the original reverse engineering is overkill for me.
The programmer firmware is few kB of simple and straightforward code, the most of the know-how to begin with is already here. It just doesn't make a sense that you are interested in reverse engineering but at the same time you refuse to do any.
-
The programmer firmware is few kB of simple and straightforward code, the most of the know-how to begin with is already here. It just doesn't make a sense that you are interested in reverse engineering but at the same time you refuse to do any.
With your consent... It's me who decides what makes sense to do for me or not. I have no intention of reverse engineering the firmware of the devices (which would probably be protected anyway), but the hardware for eventually writing some alternative code. Reverse engineering the programmer (and the PC software controlling the programmer) is probably behind my capabilities and sure enough beyond my motivation.
If it was such a simple task it's so strange you equally failed at writing a programmer.
-
With your consent... It's me who decides what makes sense to do for me or not.
Sorry, it's up to you of course. But just to clarify, I have no need to write a programmer. I just wanted to download the firmware to reverse engineer some communication between FMD MCU and other IC, I failed to do it, because it's protected... but this is a completely different story. Though I did some changes to EEPROM, programming or erasing the flash is not much different.
-
But when I reading the flash memory the data seems somehow scrambled:
1F9F 3F9F 0F9F 0F9F 0FFF 0F9F 0FFF 0F9F 0FFF 1F9F 3F9F 1F9F 3F9F 2FBF 1F9F 3F9F
1F9F 0FBF 3FFF 1F9F 0FBF 3FFF 1F9F 0FBF 3FFF 1F9F 0FBF 2FFF 1F9F 0FDF 2F9F 0FDF
It's really some kind of flash memory protection. I finally got some spare FMD MCU, so I played with it a bit. When I erase it and then flash it, I read the same data as I wrote to it, so my communication with the chip is definitely OK. Although I don't yet know how to disable CPB bit of UCGF0 register to test it further... any thoughts where these bits are placed and/or how to change them?
-
I get it for you
https://www.123pan.com/s/kEQbVv-KzSsH.html (https://www.123pan.com/s/kEQbVv-KzSsH.html)
提取码:bXgN
-
I found that this fmd（ft6x）is not as cheap as that PDK（padauk），PFS122 just $0.04 ...
PFS122
1 adc 12bit x 12ch io14 rom 2KW ram 128 -- 8bit x 2 CMP x 1 R-ADC
padauk-programmer here
https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering (https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering)
-
Although I don't yet know how to disable CPB bit of UCGF0 register to test it further... any thoughts where these bits are placed and/or how to change them?
Found it. When I enable flash protection with mentioned bit, it doesn't return all 0x3FFF, but data where almost all bits are set to 1 with few of them preserved. I guess in these MCUs the instructions are encoded in 12bits instead of all 14bits.
Original data:
2040 2244 2448 264C 2850 2A54 2C58 2E5C 3060 3264 3468 366C 3870 3A74 3C78 3E7C
0000 0204 0408 060C 0810 0A14 0C18 0E1C 1020 1224 1428 162C 1830 1A34 1C38 1E3C
Protected data:
2FDF 2FDF 2FDF 2FDF 2FDF 2FDF 2FDF 2FDF 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF
0F9F 0F9F 0F9F 0F9F 0F9F 0F9F 0F9F 0F9F 1FBF 1FBF 1FBF 1FBF 1FBF 1FBF 1FBF 1FBF
-
Which was the solution for writing UCFG0?
-
Unsurprisingly, UCFG0 is stored in first word of PROM block like it's mentioned in datasheets. What is not mentioned is that there are also stored upper 4-bits of the flash checksum, so it's a bit misleading.
According the datasheet, this PROM content is copied to somewhere else after every reset, so I guess it could be prone to glitching... but I'm not going any further with these MCUs.
-
Unsurprisingly, UCFG0 is stored in first word of PROM block like it's mentioned in datasheets. What is not mentioned is that there are also stored upper 4-bits of the flash checksum, so it's a bit misleading.
And how can you read at a specified address? Socram only describes a "reset address pointer" operation, so that you always have to read the whole address space.
-
I get it for you
https://www.123pan.com/s/kEQbVv-KzSsH.html (https://www.123pan.com/s/kEQbVv-KzSsH.html)
提取码:bXgN
The link is broken. can you reupload it, please?
Unsurprisingly, UCFG0 is stored in first word of PROM block like it's mentioned in datasheets. What is not mentioned is that there are also stored upper 4-bits of the flash checksum, so it's a bit misleading.
According the datasheet, this PROM content is copied to somewhere else after every reset, so I guess it could be prone to glitching... but I'm not going any further with these MCUs.
to make sense of the UCFG register , I think you need to reverse the IDE. if you pay attention to the address register and values generated by the IDE , you'll see that part is sort of obfuscated.
-
I think you need to reverse the IDE
I wanted to but all links to download it were already dead.
-
https://www.123pan.com/s/kEQbVv-X3lsH.html (https://www.123pan.com/s/kEQbVv-X3lsH.html)提取码:gVis
-
https://www.123pan.com/s/kEQbVv-X3lsH.html (https://www.123pan.com/s/kEQbVv-X3lsH.html)提取码:gVis
*** WARNING! ***
Both Google and Microsoft report malware in the downloaded file. Beware
-
Misjudgment.
You can run in sandbox .
-
instead of posting theses kind of link can some one download it and share it elsewhere ???
-
https://www.123pan.com/s/kEQbVv-X3lsH.html (https://www.123pan.com/s/kEQbVv-X3lsH.html)提取码:gVis
can it flash FT61 series chips ?
-
is there a english version of this app?
-
latest FMD IDE 3.1.1.3
https://mega.nz/file/hx50XK6A#I1PEoT1RJTD9Ifqt290umfxOprflcOLVQWQSgMdT3NM
-
https://www.123pan.com/s/kEQbVv-X3lsH.html (https://www.123pan.com/s/kEQbVv-X3lsH.html)提取码:gVis
The link is broken. can you reupload it, please?
-
Hi, guys
Can anyone send me a good quality photo of the back side of this board?
Very much so grateful !
(https://www.eevblog.com/forum/projects/fremont-micro-devices-microcontroller-programming/?action=dlattach;attach=1129934;image)
-
is it possible to test code of FMD using proteus?
I want to use FT60E211 to measure pulse width range between 200us ~ 30ms
how to do it?