Support for eVic VT/Cuboid

[noisycat3]

Is there any chance that the sdk would ever support other Joyetech mods? I understand that it depends on the hardware and pinouts, but after atomizer support is added maybe other mods could be taken into consideration?

[ReservedField]

Long post ahead, beware. Many people asked this so I'll try to be clear. I would be extremely happy to get more devices supported. Let's break it down in steps.

First, can we get code execution on the eVic-VT and Cuboid? They have upgradable firmware, so yes, we can upload code. On-chip encryption would be a showbreaker, but AFAIK it's not used by Joyetech (IIRC eVic-VT firmware has been decrypted, so I expect Cuboid to be the same). As far as I know, I am the only one to have ever achieved code execution on a Joyetech product, but I'm pretty confident I can get it on any mod (as long as it has upgradable firmware that we can encrypt/decrypt).

Second, what would the implications for the SDK be? Well, if you have looked at the code you can see that the interface to the programmer is actually very abstracted from the hardware (best example is the display driver, that has three abstraction layers). So it'd be possible to have an API that is mostly the same across all products. Of course there'll be differences, for example in display size/capabilities and buttons, but the rest can be abstracted from the programmer. Abstraction is the whole point of writing an SDK in the first place. This is looking good :)

So what is stopping me? Well... I don't have the devices in hand. I absolutely cannot develop software on a device which is not in my possession, especially if it's embedded and I have to reverse engineer it. You can't debug the code in any other way. To get the first hello world working, I probably flashed 20-30 times before I got it right. If I get stuck with non-working code (initially, you're basically coding blind since there's no interface other than display and USB) and I have the device, I can crack it open, find some unused pins, hook up a logic analyzer and use them for debugging. Or I can hook up the manufacturer debugging tool, if I have it. This freedom is essential.

So what we need is good reverse engineers that can work on the other hardwares. But reversing is not enough, they also need to write the code and test it on their devices. I've been looking, but I can't find anyone (maybe I'm looking in the wrong places). So either someone like this pops up, or I'd have to buy the hardware. Which doesn't really make sense to me, since I'm perfectly fine with my VTC Mini and the other mods don't appeal much to me.

TL;DR: I don't own the hardware so I can't code on it.

By the way, I think evic-sdk should work as-is on the Presa 75W (but nobody tested it, so it's just a hunch) since it has nearly the same exact board as the VTC Mini and the hardware version -> display type mappings match. Reuleaux RX200 is also doable, its firmware has been decrypted a while ago. IIRC same CPU is used, just a different display (also it's I2C, not SPI as in the VTC Mini).

Finally, there has been little activity in the past week: I'm pulling through exams at uni, so I have very little time until early February. Then until March I'll be working hard on this sdk as I have no classes to attend. I have to fix a few things around the code, but most importantly I have to add atomizer control.

@Ban3 What do you think about this? Other than the VTC Mini, Presa and Reuleaux do you know more that use the same encryption scheme? Do you own other Joyetech hardware?

[Ban3]

@ReservedField put it very well. Most importantly:

TL;DR: I don't own the hardware so I can't code on it.

I have nothing against supporting those devices in the SDK, but I only own an Evic. Trying to reverse a device you don't have access to is insanity, IMHO. Somebody who owns the device needs to step up and write the device specific parts.

So what we need is good reverse engineers that can work on the other hardwares. But reversing is not enough, they also need to write the code and test it on their devices. I've been looking, but I can't find anyone (maybe I'm looking in the wrong places).

I wonder what happened to kfazz & others who were working on this pretty early on.

By the way, I think evic-sdk should work as-is on the Presa 75W (but nobody tested it, so it's just a hunch) since it has nearly the same exact board as the VTC Mini and the hardware version -> display type mappings match.

Same hardware, but the hardware versions don't completely match on Type A devices. Evic-SDK should still work, though.

What do you think about this? Other than the VTC Mini, Presa and Reuleaux do you know more that use the same encryption scheme? Do you own other Joyetech hardware?

All of the Wiscmec devices with upgradable firmware, including the vaporflask ones, are based on the same board and firmware with the same encryption. They probably have some kind of internal SDK to port it to other devices.

[ReservedField]

I wonder what happened to kfazz & others who were working on this pretty early on.

Maybe they lost interest after they reversed most of it? I know from experience that reversing and reimplementing are two very distinct processes. I love that kfazz made the reverse public, even if it's 1.30. I have my own 2.00 reverse (I use the Hex-Rays Decompiler a lot, while kfazz's reverse is pure asm) but I often refer to his to see if he had already found something I was looking for. Offsets are different, but most instructions are the same. A few days ago gxcreator posted a bitmap extraction script on Reddit, so I figured out he was still working on it and wrote to him to ask a few things about resistance reading and atomizer control, but he hasn't replied yet.

Same hardware, but the hardware versions don't completely match on Type A devices. Evic-SDK should still work, though.

I thought that the HW version change on eVic was just to prevent the Presa FW from defaulting to SSD1306 on newer SSD1327 eVics, since the Presa has less hardware versions. So the ones that are in both do not match exactly? Good to know. Anyway, it's a trivial problem to solve, no need to do it at runtime, we just add a Makefile option to select the device since we have to change the verifications strings as well anyway. (ok, given the verification method we could actually have a firmware that verifies both for eVic and Presa, but the point is that a HW -> display mapping is not an issue)

They probably have some kind of internal SDK to port it to other devices.

Sometimes I wonder if Joyetech knows about our SDK and what they think about it, eheh. At least ours is not a mess of copypasted Nuvoton example code :P (not looking down on you, Joyetech. Just sayin')

[noisycat3]

That's a lot of awesome work you are doing there guys. I understand the abstraction layers of the sdk, that's why I asked if you consider doing it in future.

Is posting reverse-engineered code prohibited by joyetech licenses? If not, I'd love to take a peek at the code, I have decent experience with x86 assembly and as far as I know arm is simmilar in many ways, maybe I could contribute a bit if my current knowedgle allows me to.

Also, I'm following the project since first post on reddit, already asked some people what would they like to see in custom rom and what annoys them in official one. I have written down some ideas and I'm only waiting for atomizer support to begin working on the project :)

[ReservedField]

Is posting reverse-engineered code prohibited by joyetech licenses?

I'm afraid it is. Kfazz posted his, I don't really feel comfortable posting mine, but my email is on my public profile so hit me up.

I have written down some ideas and I'm only waiting for atomizer support to begin working on the project :)

That's great! I kept thinking "will there be someone that actually uses evic-sdk to write a CFW?".

[noisycat3]

I've set up environment and build bot on my vps machine, ready to start coding. Just need the atomizer support and I'll be good to go.

[ReservedField]

@Ban3 I checked latest eVic 3.00 against latest Presa 3.00. Max hw version is from the bytes following device ID, SSD1327 versions are from disasm.

eVic 3.00:
Maximum HW version: 1.11
SSD1327 versions: 1.02, 1.03, 1.06, 1.08, 1.09, 1.11

Presa 3.00:
Maximum HW version: 1.03
SSD1327 versions: 1.02, 1.03

Of course evic-sdk mappings are the same as eVic 3.00. As you can see, the only mappings that we care about for Presa are 1.02, 1.03 -> SSD1327, which match the OFW/evic-sdk ones. So mapping will work as-is on the Presa (actually, eVic FW should also work on it - anybody tried?).

[Ban3]

@ReservedField Ah, sorry, I was a bit unclear. That was what I meant by not matching as there are fewer versions of Presa devices. SDK supports them all so it's not a issue.

This is slightly offtopic for this issue but could you point me in the direction where the mapping is made in the official image? I think I was looking around for it at some point but didn't see it. Might come useful for python-evic purposes.

[ReservedField]

In 3.00, it's done in the subroutine at 0x1408, which does dataflash reading. The "is SSD1327" flag is the byte at 0x20000032, hardware version is the dword at 0x20000254. The actual flag store happens at 0x153C, looking up from it you can see the comparisons.
For other versions and Presa it's similiar, you can get it in many ways: you could look for display routines, see the address that is checked for display type and xref from it, or even simpler just look for the hardware versions hex values and find the comparisons.

[mpaw]

That's great! I kept thinking "will there be someone that actually uses evic-sdk to write a CFW?"

Most definitely. I just found this project today and can't wait to start once the sdk is more mature.

[chaosman123]

I've got all examples of the SDK running on my couple of days old Cuboid.
The only thing that does not fully work, is the Atomizer example. No power output.
Already just disassembled my Cuboid to check the disassembling prozess. Will have to buy new very small (needle like) contact cables for my multimeter. Maybe then I will be able to identify the right MCU pins.
Buttons etc. working fine. Battery charge level and charging flag working fine.

I had to make a small change in the SDK source to get AROM accepted by the Cuboid and experienced a very strange behaviour with some examples.
For example the helloworld first did not show any text.
Funny thing is, that if I define a variable buf char[100] and do a siprintf into it (even if not using it anywhere else - just avoid compiler optimizing that buf away), the example just starts to do what is expected. Seems to me, like there is some minimum amount of code required to generate a working AROM. As said, strange, but did not dig into it so far.
Same true for some other examples (bigger code ones directly worked, smaller code sizes not).
Maybe that problem description already makes someone having some idea where the problem my come from... otherwise, first not important, later I will nail that problem - that's for sure ;)

[ReservedField]

@chaosman123 That's amazing!
When I first started working on the atomizer my first approach was the same as yours - hook up a logic analyzer (we're talking 150kHz PWM, a multimeter is useless in this case) and look at the signals. I quickly figured out that attaching probes to a 0.5mm pitch IC without spending a fortune wasn't gonna happen, so I just reversed the OFW.
On the eVic, the signal are apparently routed in a inner layer, so you either hook up your probes to the IC (very, very hard) or to the switches under the heatsink (easier, but requires removing the heatsink). I don't know how the Cuboid is internally, though.

You are hitting issue #16. I changed the build process to partially link CRT0 (it was getting hard to manage otherwise) and that broke something. I'm still trying to figure out what...

Care to share the change you had to make to get the APROM accepted? Are you referring to the verification string for the official updater or something else?

[mpaw]

I had the same experience. Hello world does not work, button example does.

[chaosman123]

In the startup.s line 6 I had to put:
.ascii "E060" @ Device (Cuboid) E052 eVic VTC Mini
So, changed E052 to E060. After that change my Cuboid accepted the AROMs. (not telling wrong hardware anymore)
It would be good to make the HW detection part of the AROM build process - or, at least add some parameter to it, so the build can be done for a defined HW to later run on.
Automatic detection would require the Mod to be connected and online while building, So, I'd prefer some compile option/flag for target HW definition instead.

I don't have any logic analizer (anymore). Sold mind a couple of years ago.
Let's see, how far I get without scope and logic analyzer.
If it requires one, I will just buy one - just takes more time ;)
Took me yesterday about 4 hours to get there. Time... give me more time...

[chaosman123]

Following way helloworld will work; ;)
You can try to not use buf. Tried it on a different example...

#include <stdio.h>
#include <M451Series.h>
#include <Display.h>
#include <Font.h>
#include <TimerUtils.h>

int main() {
        char buf[100];

        Display_Clear();
        // Blit text
        //Display_PutText(8, 56, "Hello,\nWorld.", FONT_DEJAVU_8PT);
        siprintf(buf, "Hello,\nWorld.");
        Display_PutText(0, 0, buf, FONT_DEJAVU_8PT);

        // Update display
        Display_Update();
}