Fremont Micro Devices - microcontroller programming

[socram]

Hello, good evening everyone.

I'm creating this thread to discuss about programming Fremont Micro Device's series of PIC clones, available at LCSC for prices roughly the same of the awesome Padauk microcontroller lineup. For example, the FT60F211 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. 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, 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€.
  
  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:
  
  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:

Code: [Select]

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:

Code: [Select]

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.

Code: [Select]

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.

Code: [Select]

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.

Code: [Select]

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

Code: [Select]

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

Code: [Select]

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

Code: [Select]

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!

[jmelson]

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

[socram]

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.

[socram]

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.

[rameshd]

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 (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

[socram]

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

[amyk]

PIC programming specifications are readily available - take a look and see if you can find any similarities.

[socram]

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.

[ali_asadzadeh]

Nice 8-bit CPU wars at low prices

[rameshd]

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.

[spth]

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.

[spth]

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.

[spth]

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.

[socram]

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.

[spth]

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?

[retiredfeline]

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?

[spth]

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.

[tim_]

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)

[danymogh]

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 ?

[tim_]

Your list does not exactly reveal why the FMD devices would be superior   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.

[danymogh]

Your list does not exactly reveal why the FMD devices would be superior   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.

[danymogh]

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!

[danymogh]

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.

[LovelyA72]

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?

[tim_]

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.