JN Controller Hacking Basics for newbie

[Bikeronin]

Good morning chaps,

Hope this is the right place to post this. This is more of a learning journey for me than anything else. I’m trying to properly understand the fundamentals of these controllers, MOSFETs, firmware, how they’re put together, and how people go about reverse engineering them. I’m definitely a beginner. I’ve got curiosity and solder smoke, but that’s about it.

I’ve been playing with a few JN controllers. I know they’re not open source and there isn’t much documentation floating around, which weirdly makes it more interesting for me. Having a dyslexic/ADHD brain, the novelty and mystery of something undocumented is actually what keeps me engaged. It feels like a puzzle I want to solve.

In another post I mentioned I had a controller from Amazon that I tried repairing. I did manage to get it running again, but eventually it threw an E07 error. From what I understand that’s some kind of motor communication issue. All the controllers I’ve got are JN based. Two are locked from an Engwe EP Pro, one is brand new and working so I’m not touching that, and one is partially working. That last one is my guinea pig.

The fault on that board happened when I connected an LED light that was drawing too much power. Now the controller itself works, but the light output doesn’t switch off properly. So I figured that’s the one to experiment on and learn from.

So far I’ve mapped out some pin differences between two controller types, converted some SM connectors to waterproof ones, and identified what I believe are 5V, ground, TX and RX pads. I’ve ordered a USB to TTL adapter and an ST-Link. Soldering skills are improving slowly. I’m leaning heavily on ChatGPT to understand things, but I’d rather also hear from people who’ve actually done this in the real world.

What I’d really like to do is dump the firmware from the controllers. I want to compare the working one with the locked ones and just see what’s different. From what I’ve read, I probably can’t do that over UART and would need to find the SWD or programming pads. I’m not fully sure how to identify those properly or whether I’d need to go directly onto the MCU pins.

Sniffing was also mentioned in other threads. That sounds like a good learning route. Maybe comparing the display communication between controllers and seeing what’s actually being sent. I just don’t really know where to start with that properly.

A few beginner questions if anyone’s willing to point me in the right direction. Is sniffing display traffic the smartest place to begin? Do I need a logic analyser straight away or can I get started with USB-TTL? Can these boards be powered safely on the bench below 48V or do they need full battery voltage to initialise properly? And is an oscilloscope something I genuinely need now, or can that wait?

I know something like VESC or Flipsky would be the easy path if the goal was parameter control. But that’s not really the point for me. I want to understand what’s going on under the hood. Even if I hit a wall, I’ll have learned something.

If anyone can suggest a sensible learning order or just say “don’t bother with that yet, focus on this first”, I’d really appreciate it.

Thanks in advance.

 

[stancecoke]

I probably can’t do that over UART and would need to find the SWD or programming pads. I’m not fully sure how to identify those properly or whether I’d need to go directly onto the MCU pins.

Have you identified the processor? From your photos, I can only see that it is a 48-pinner.

Do I need a logic analyser straight away or can I get started with USB-TTL?

Yes, but you have to find the right BAUD rate by trial and error then.

If anyone can suggest a sensible learning order or just say “don’t bother with that yet, focus on this first”, I’d really appreciate it.

Depends on what you want to learn. Is it more the hardware side? Or the firmware side? Reading out the firmware (if it is not read out protected from the manufacturer) is quite senseless, as it contains no human readable information. You woud have to decompile it and even the output of common decompilers is not helpful for newbies...

 

[Bikeronin]

Hey buddy, thanks for replying, really appreciate it.

I’m in the process of pulling one controller apart, so I can have it on the bench and actually play with it without it being half mounted in the bike. Once I’ve got clearer access, I’ll post better photos of the MCU so we can hopefully identify it properly. All I know so far is that it’s a 48-pin package.

The baud rate being trial and error makes sense. I didn’t realise that at first, but I’m actually looking forward to the USB-TTL arriving so I can just start listening and see what comes out of it.

As for what I want to learn, I think I’m still figuring that out. Hardware feels more natural and fun right now, tracing lines, finding rails, understanding what’s doing what. But I also know firmware is where the real behaviour lives, so I don’t want to ignore that side either. I’m trying both for now just to see what resonates more.

You’re probably right that dumping and decompiling firmware won’t be very useful at my level. But if I’m honest, I tend to enjoy doing things the hard way. If it’s too straightforward, I lose interest. The challenge is part of the fun for me.

I come from a VFX technical background, so I’m used to digging into undocumented systems and figuring them out from scratch. This feels similar, just with more solder involved.

Do you think trying to explore hardware and firmware at the same time is too much? Or is that just part of the learning curve?