Hi All
Thought I’d have a bash at reverse engineering the .tft file format. Anyone made any progress on this?
Shabster!
Hello,
i did a try with just exchange the Bytes of a picture inside the TFT file without success.
Could not find out how (and where) the checksum is calculated.
Hi Alex
Thanks for the info - checksum is probably a CRC32 - easy enough to figure out when the time comes.
I’ve spent a few hours tinkering with the .tft in my trusty hex editor.
Havn’t spent any time looking for a TOC/DIR structure. It looks a little messy -
serialized without sizes e.t.c. Maybe I’m missing something - REing formats always starts like this tho 
this is what I’ve deduced so far:
Header? 00 00 ‘:NTE’
???
0x10000 STM32 Flash Image/Script Interpreter? - need to check this for arm/thumb asm
0x29BD2 Texture/Bitmap
0x??? Font
0x50000 Component Script
Down
Up
Unload (Exit)
Slide (Move)
1 Like
Finally got to grips with the .tft and have decide to start my own open source HMI format and
simple hardware spec.
Currently using a Pi Zero and a cheap 5" LCD with resistive touch (total cost 22quid).
If anyone is interested in this and helping just ask!
Shabster
I’d be happy to help figure out the tft file format. And an open source HMI would be great.
Do you gave a repo or where can I find/help with the project?
Hi fvanroie
What do you want to work on?
Yeah nextion .tft - it’s a dead end for me - I can see how tight the nextion system is now -
they’ve done some amazing work on that system pushing the stm32 to it’s limits. But I wanted more power and flexibilty - hence a open source system.
I’m currently writing the core system (started 1 day ago )
it’s really simple, current hardware I’ll be testing on is:
Pi Zero Bare Metal!
5" LCD Resistive touch (waiting for this to arrive in the post)
HDMI interface
SPI for touch
Core HMI system would be a .zip file containing:
Script File
resources png/jpg/gif/sf2/ttf e.t.c.
Current status:
I have images loading
ttf fonts loading
and a simple setup to test all these things
have textures fonts and rects clipping
have BorderTexture system working (for rounded rects e.t.c.)
here’s a screenshot of it running
Whats needed:
Script language choice - not decided - needs to be fast and lightweight and easy host binding. Was looking at wren - looked promising but it’s whitespace sensitive!
here’s a list of script languages:
I’ve used lua/pawn/angelscript/squirrel and a few others in the past on projects.
Problems:
Pi Zero bare metal emm sd card speed was low last time I did some bare metal - around 1mb/sec Will check it again this week see if the bare metal lib is any better! And this is one of the reasons I’m using .zip as a container and .ttf - it’s quicker to decompress than load the uncompressed file.
I’ve never setup a REPO ever - so I’ll look into that in the next few days and get back to you -
It’ll probably take a few iterations to get a repo setup good.
Current setup is a simple x64.exe using opengl testing the classes e.t.c.
I’m thinking that with the pi zero - we could even built the editor in the device.
Pi Zero is a monster soc compared to the STM32, 512bm ram, opengl, hdmi e.t.c.
System would work the same way as nextion HMI - i.e. simple comms commands via uart to MCU.
Any ideas/request/info e.t.c. post here!
Here’s the current list of sources I’m using for this
STB_IMAGE
STB_TRUETYPE
TinySF
TinyMidi
Shabby!
1 Like
Wow, paint me awestruck.This is all new to me, but I’m trying to read up a little bit using the links provided. Those look very promising indeed. Having the result above after 1 day is just mind-blowing to me.
I normally pick up technology stuff quickly, but please bear with me… Things will start clicking once I see how these pieces fit together.
I would be looking for anything that resembles the LittlevGL examples, which Circle seems to support. If the Pi could also communicate over the Circle Mqtt library to an automation system then the MCU would not even be required for basic comms… But I’ll first see if I can grasp what’s needed and let you take the lead.
Atm I don’t have a pi zero handy, but that can easily be arranged. Got a Pi4 and Pi3 tied up in other projects. Any suggestion for the touchscreen?
Setting up a repo is quite easy, it’s the updating pull/push/commit sequences that took me a while to get used to. What’s the best place for a newbie to start learning/experimenting with bare-metal Pi? I checked out some Circle examples, but not sure where to go from there…
Hi fvanroie
Yeah I started looking into a REPO on github - just gotta rearrange my projects folders and whatnot it’ll be a few days then I’ll check something in. Most development for the moment
will be Win x64 - to get a bare system working. Make everything tons easier and quicker.
Ummm Bare metal pi - That circle lib is great - the hardest thing I had was getting a good arm toolchain - took me a few hours to find one - that was 1yr ago dunno what the situation is with that now tho. I’ve just checked I’m using arm GCC 2018-q2-update - and that worked fine. Took a while to figure out CMAKE and get the examples building and running on the PIZero. One problem I never figure out was getting STL to work with the Circle/Arm setup.
My Project is a GuitarFX using a ESP32-A1S(MCU) and PiZero+LCD as display!
Which LCD? I bought a super cheap 5" HDMI display with resistive touch - no idea what make it is - second hand - hope it works:) should arrive on thursday - then I’ll test out the Circle HDMI stuff. I’d get the Circle HDMI example running on any old monitor first - make sure it works (I havn’t tested that yet).
I’ve choosen HDMI over I2C or SPI - because 1) Ease of connection 2) Data Speed.
Because Circle supports OpenGL over HDMI - it just cuts out loads of hassle connecting up some I2C/SPI LCD Driver - plus u have all the hardware acceleration from the PiZeros VideoCore 4 gpu - which makes writing the majority of the HMI tons easier. Plus circle supports Audio over the HDMI connection (Hence the reason I’m plugging that tinysf lib into the HMI system).
And that’s one issue to solve how to connect with HDMI without having bulky cables everywhere!
The LCD I ordered comes with a tiny HDMI bridge thing - and then it needs a HDMI to mini HDMI connector (also ordered- arrives this week). I’ve looked into unsoldering the HDMI socket and connecting ribbon connector - HDMI only needs 8 pins minimum or 12 with audio I think. It’s doable - but I’m leaving that for the moment till I find out the connection Pitch sizes e.t.c. I also looked into using a thin ribbon connector sheet and just plugging that directly in the sockets instead of a GINORMOUS hdmi plug and cable. It might work!
Power consumption - I think it’s gonna be a lot maybe 1w or more for PiZero+Screen - just a guess.
Still havn’t decided on a script language yet - spent hours going thru them all. Might just plug in a simple expression system for the moment.
PiZero W - has wifi+bluetooth - but you can’t use it - real shame that - no one has bare metal coded a stack for either and it’s a shed ton of work porting over the linux drivers - sucky!
LittlevGL looks ace! But I’m still writing my own in the spirit of only one or two core files
Shabby
OpenSource HMI system current status:
Currently called HUMII (anagram of HMI UI)
Currently 80% core systems in place and working
Rects
Textures
Fonts
Shaders
Audio
Tested the Circle Lib HMDI and HDMI Audio samples - they work just great.
Just gotta get Circles stdlib extension working and compiling. Circle is linux based and it’s a
bit tricky to get that setup under windows - without installing winsxs linux crap.
Looking into using the Circle GL compiler as the script language (a variation of ‘C99’ - but missing strings and pointers, will see how much work it is to wrangle all that into place).
System will work similar to Unity’s Canvas System:
Rects are the core UI objects and can have simple scripts attached to them.
Rects have parents,sibilings and childern (classic Hierarchy system).
Rects will have pre defined events that fire off script code (down,up,move,render,start,exit e.t.c)
Timeline - I think it’ll be another week or so before I get anything running on the PiZero - and then checked in.
Super chuffed with the Cricle lib and it’s full blown GL stack - being able to run shaders is a massive help.
I’m happy how this is all heading - I’m hoping I can write the editor with the UI system itself.
Here’s a screen shot of the win build running - testing shaders and clipping (shaders are from GLSLsandbox and shadertoy).
its been a long time since i looked at this problem and i can tell you the checksum isnt that complex. however there are a few “issues” from version 0.53+ the format changed (havent looked into the new format at all other than i noticed it when analyzing the software) the serial flash stores the whole tft flash file in raw format in the memory and can therefore be extracted from any device (this chips doesnt have any read protection)
For those with basic C knowledge you can use a simple IL code viewer to examine the software executable as its a .NET IL file and dig deeper in how the format works by looking at the read / write routines.
Ive dumped the STM32 processors firmware both on TJC and NEXTION (3.5") and both are more or less identical (They dont seem to contain anything relating to region based obfuscation as a raw flash dump can be transplanted to TJC/NX and they work but region will change) we are talking very very few bytes probably some bug fix. (diff below)
|000020b0: d121 0008 044b 9c43 6300 fcd3 0000 baaf .!..K.Cc. ||000020b0: d121 0008 42de 14b0 6400 fcd3 0000 853d .!..B…d.|
|—|---|
|000020c0: 6304 0030 f000 0000 ffee dd78 5634 12f0 c…0… ||000020c0: 94ba 0830 f000 0000 ffee dd78 5634 12f0 …0…|
|00005670: e9fe 1146 0320 02f0 a5fe 1e2c 09d2 ff20 …F. … ||00005670: e9fe 1146 0320 02f0 a5fe 062c 09d2 ff20 …F. …|
|0000fff0: 43ff 4e00 0b52 5443 3133 3a21 ffff ffff C.N…RTC13 ||0000fff0: ffff ffff ffff ffff ffff ffff ffff ffff …|
from my old notes i can tell the following assumptions have been made (and they might be wrong, long time since i looked at them before i started to studie the design software executable)
Map of Serial Flash (64K block alignment)
0x5000 … Device Name related.
0x6000-61E9 … Possibly STM32 instruction code
0x6800-6DE0 … Possibly STM32 instruction code aligns with 4 (Dword?)
0x800B-8C78 … Some data padded align 4
0x9000- … Garbage + Checksum ?
0xA000-A60F … Strings?
0xC000-C44A … ???
0x10000-??? TFT image.
By pokeing the STM32 with a debugger during runtime i did pinpoint a few interesting addresses.
536872052 = Screen ID string.
40023000 = Serial number ?
0x5020 = Serial number
0x9018 = Serial number 2 ??
2 Likes
Hi Guys
let’s say that I found the algorithm for creating the tft file, the checksum is calculated progressively for each object present on each page, but it is easily calculated, using the same code.
If anyone is interested, just write
2 Likes
hello im very interested
+1 Also really interested and in this!
+1 same here
(adding meaningless characters to the required minimum of twenty)