Gen2.1.13 (ex2.15) (Several more board layouts)

[andyshmandy]

Hello @RoboDurden! I have 3 hoverboards that I would like to reverse engineer as I have several project ideas in mind and I am too cheap to buy BLDC driver boards for them when they already come with what is needed. The layouts appear to be different than the ones that you have already added.

I would like to know how you would like me to proceed with adding layouts for these boards. Should I create a separate issue for each layout? Or should I add the new layouts to my fork and create folders for the new layouts and submit pull requests for them. Maybe it would be best to work on one at a time. Here are photos of the boards. In your opinion, which one would be best to start with?

Hover-1

Razor

Generic - YK201C

Thank you for all of your work on this project!

Andy

[RoboDurden]

Gd32f130c8 MCU have the best usage.
Look at the 2.14 front+back images.
I create the with gimp.
The perspective tool can stretch the images to rectangles.
Needed to trace pins .
If you can do that you are welcome to fork and build the first defines File.

But you can upload four hi res photos to a new issue each and I do the gimp compilation and assign a new layout number. I then will change the issue title to contain the layout number.

Forking might be better suited if you want to add new code functionality like a RemotePwm or torque control..

[RoboDurden]

If you know how to add a MM MCU target to Keil this would help others. Look at the other MM MCU issue .

[RoboDurden]

Do you know the purpose of that additional white Hall cable of first layout?
We are having such a white cable also on 2.14.

[RoboDurden]

Hover1 is probably the best board as it has the two dual opamp 8pin chips that are needed for two additional phase currents. These are not needed for this simple firmware here but for the new simpleFOC firmware .

[andyshmandy]

Do you know the purpose of that additional white Hall cable of first layout? We are having such a white cable also on 2.14.

My guess is that it controls blue LEDs on the wheel hub that turn on when you connect to Bluetooth. I will take the wheel apart and check though to let you know.

[RoboDurden]

Please do not copy/quote my words. These issues tend to get very long.

Yes of course, another led output :-)
No need to take the motor apart.
@dexterbot80

[andyshmandy]

In order to get familiar with the electronics and code, I think my first project will be to build a force feedback flight stick that I can use with Microsoft Flight Simulator to simulate what might be felt in a real airplane. I am not certain but I think I would want FOC for that? Just so you know, I have very little experience with electronics so I am learning as I go (but I have been coding for years). Using Gimp and a multimeter, I started tracing some of the pins but I stopped to get better pictures of the board. I can send you the .xcf file of what I have traced so far if you are interested. I am going to trace the remaining using the better photos.

[RoboDurden]

FOC is for more efficiency or less noise.
If you want to use a hoverboard motor as a servo, you can build on my iOdom values and add a closed loop to rotate to a certain position/angle.

You are doing a good job with tracing the pins. You might already want to copy the defines_2-x.h to defines_2-15.h and fill in the pins you have already traced.

The six MOSFET output pins are mostly the same

// Brushless Control DC (BLDC) defines
#define BLDC_GH PA10		// green	, Tommyboi2001 all bldc pins same as 2.0
#define BLDC_GL PB15		
#define BLDC_BH PA9			// blue
#define BLDC_BL PB14		
#define BLDC_YH PA8			// yellow
#define BLDC_YL PB13		
#define TIMER_BLDC_PULLUP	GPIO_PUPD_NONE	// robo: not sure if some boards indeed nned GPIO_PUPD_PULLUP like 2.2 or 2.3

When you have the three hall sensors and the three main led, you could already compile a first single_RemoteDummy.bin

But you for sure should have a 1A constant current power supply!!!
Do not attach a battery to a new board/binary !!!!!

[andyshmandy]

I am going to order a CC power supply. It will be a few more days before I will be able to do any more testing. I will let you know how it goes. Thank you for your help!

[RoboDurden]

I can not download your pin tracing image :-/

[RoboDurden]

So i added the 2.15 to this repo. When you have completed the hall sensor defines, you could already compile and test:

// Hall sensor defines
#define HALL_A	PA0		// todo !! robo can not see the hall pins on andyshmandy pin tracing image
#define HALL_B	PC15			// todo !! robo can not see the hall pins on andyshmandy pin tracing image
#define HALL_C	PC14		// todo !! robo can not see the hall pins on andyshmandy pin tracing image

Also try to complete/confirm the other defines in defines_2-15.h

Cheapest cc power supply is a 3A 60V step down converter: https://www.aliexpress.com/item/4001360810712.html

[andyshmandy]

Thank you for adding the 2.15 layout! I didn't get a chance to do much more circuit tracing over the weekend. I received the constant current power supply. I am trying to trace the hall sensor wires but to set them properly in the defines file but I am not clear how Hall_A, Hall_B, and Hall_C relate to the colors Green, Blue, and Yellow. Should the variables be renamed to the colors?

[RoboDurden]

You have to try all six permutations.
Five will make the motor vibrate and one spin nicely :-/

I would like to program an auto tracer for so long now :-(

In bldc.c the hall position is read at 16 kHz.
Would be quite easy to overwrite it with a constant 60 rpm... Without load, the motor should spin anyway.
And then set all possible pins to input and find the correct three pins and there permutation by software...

But I never have the happiness to do it :,(

[andyshmandy]

I think I might be working with a board that has already let out its magic smoke (fried). :-( I tried to program this board several years ago and ran into issues after flashing it at one point. Currently, when connected to the CC power supply set to 42v and 1 A, when pressing (and holding) the power button in, the power indicator light flashes on and off rapidly. I tried setting it to 2A and I am getting the same response. I am currently unable to flash it because it won't stay on long enough. The power supply keeps switching between CC and CV. It seems like the load is too heavy. I don't even have the motor wires connected. Do they have to be connected when flashing? Anyway, the slave board was untouched when I was messing with this hoverboard a few years ago. I was thinking of trying to flash it but I am not sure how it would work since it doesn't have some of the components that the master has.

[RoboDurden]

Slave should be fine when powered directly with power supply but it might need the red voltage line on the slave cable to power the MCU . This can hold 5V or 14V depending on layout.

Check the six MOSFETs of the master for short cuts.

[RoboDurden]

Better run the power supply at 26 volt.

[andyshmandy]

Oops... Two of my MOSFETs on my master are shorted. My slave board doesn't have any shorts on the MOSFETs. It looks like the slave cable supplies both 5v and 15v to the slave (if I trust the markings on the board). I'll need to see if I can figure out how to do that.

[RoboDurden]

Unsolder the two MOSFET.
If you are lucky, the master will power up an can supply slave via masterSlave cable.
Then order new MOSFETs on AliExpress..

[andyshmandy]

When I attempted to remove the bad MOSFETs, I messed destroyed several of the soldering pads on the board and lost a surface mount resistor in the carpet somewhere. :-(. I don't want to give up on my project so I am looking into using a different hoverboard that closely matches layout 2.7. I was thinking about swapping the processor on that layout with one that I can program using the ST-Link v2. Is that a bad idea?

[RoboDurden]

If it is a smd resistor from the mosfet gate drives, you can measure the reistance at the identical circuit of one of the other two phases.
Yes i also badly damaged some boards while replacing mosfets. But apart from the gate driver, the mosfet are only connected to the phase or either VBatt or GND. So you can solder new wires directly to one of these three targets..

I think it is not worth the trouble to replace the MCU. And i myself do have a board with a MM processor. So i dream that one day some guy will show up who knows how to add the MM mcu as a target to the Keil project.

Your Razor board has a nice GD32F130C8, so this might be 2.16 :-)

[RoboDurden]

As i have already added a defines_2-15.h to the repo, it would be good for the community if you continue with the slave board to succeed with making the motor spin and RemoteUart working..

[andyshmandy]

1. I was able to get the bad MOSFETs removed on the master board and get it connected so that it will now supply 3.3v and 14v (measured via multimeter) to the slave board.
2. Built the hoverboard firmware for layout 15 using Keil.
3. I soldered header pins into the slave board and connected the ST-Link.
4. Used the st-link.exe to program the slave board using the suggested command in a batch file. The output shows success!!

I am going to try your Arduino sketch to run the motor back and forth later this afternoon. Thank you for your help!

[RoboDurden]

Be very careful, i have forgotten how far we have proceeded with pin tracing.
Try RemoteDummy first, so no arduino remote control neccessary.

[andyshmandy]

I will try RemoteDummy first. I was able to get a bit farther on tracing the layout but I am having some difficulty making sense of the hall sensor traces. I tried to upload my gimp file but it is too big (40MB).

[RoboDurden]

i feel you trace too many lines so it becomes difficult to understand.
Why not simply test with a diode tester (multimeter) from after the initial resistor to mcu pin ?

[RoboDurden]

I still can not download the images you post here: private-user-images.githubusercontent.com/37341137/28....

Good night from Germany.

[andyshmandy]

Ahh.. I see... that makes more sense. I actually have them traced properly (I just tested it) but I need to remove some of the extra BS that is causing confusion. After changing the hall ABC pinout in the compiler, I see that MOSFET_OUT is also on PA1 (same as blue). I tried commenting out that line and it didn't compile. I'll do a bit more investigation. Thank you for your help!! Goodnight!

[RoboDurden]

Set MOSFET_OUT to TODO_PIN

[RoboDurden]

Check if the three led pins are correct:

// LED defines
#define LED_GREEN PA15	// robo, from andyshmandy pin tracing image
#define LED_ORANGE PB3	// colors might be wrong !
#define LED_RED PB4

Then activate/uncomment
#define TEST_HALL2LED // led the 3-led panel blink according to the hall sensors in config.h . This will help to confirm the hall pins when rotating the motor by hand.

The 6 mosfet output pins are very limited , so you only need to check some of the pins:

#define BLDC_GH PA10		// green	, Tommyboi2001 all bldc pins same as 2.0
#define BLDC_GL PB15		
#define BLDC_BH PA9			// blue
#define BLDC_BL PB14		
#define BLDC_YH PA8			// yellow
#define BLDC_YL PB13		

[andyshmandy]

Thank you for encouraging me to push forward with this. I was able to map the hall sensors. Now I have a motor that is spinning smoothly back and forth!! That is awesome!! I also created a PR for the changes that are working for me. #41

[RoboDurden]

It makes me happy to have users who can really contribute to the project :-)

With RemoteDummy working, the 2.15 layout is ready for others to build on :-))

Would be nice if you list here what other pins you also traced/confirmed :

Onoff button input ?
HOLD output ?
Led gred red orange ?
Led upper lower ?
Onboard led ?
Vbatt ?
currentDC ?
Uart0 ?
Uart1 ?
(2-3x Lowside phase currents?)

[andyshmandy]

I am doing some more tracing to try to figure out what the rest of these map to. This is where my lack of electronics knowledge is making things difficult. I think I might need some help mapping the unknowns you listed above because I don't know what I am looking at. I exported a high-res image of what my tracing looks like.

[RoboDurden]

Thanks, this time i can download the image. Very nice.
You did also trace some GND and VBatt lines i guess. This might make the picture a bit too complicated.

Have updated the defines_2-15.h
Search for // robo from pin tracing photo to see my changes.

I am very unsure about this:

#define VBATT PA4 // robo just guessing, maybe PA0 PA4 PA5
You could try all 3 possible analog pins until the arduino log data shows a voltage matching your power supply..
If PA5 is working, then you have to swap the BUTTON define.

#define SELF_HOLD PB2 // robo from pin tracing photo
this pin should go to the base of a little smd transistor.

Would need some more try compiling and error. But i do not know if the onOff and HOLD of your master board is still working.

So that might happily be left for some future user who happens to have such a layout.

`

[andyshmandy]

Thank you for tracing the rest of those for layout 2.16. You have been a tremendous help! I will try to figure out VBATT and do some more testing. I haven't hooked it up to the Arduino yet.

One problem that I have now is that I have to hold the power button on the master in order to do any testing on the slave. Do I need to flash the master so that the power will stay on? I guess I could just wire in a toggle switch.

I also have a potential candidate a 2.16 layout that I have started to trace but I haven't tested any code with it yet.

Here is a spreadsheet of what I have traced so far for the Razor board (Version: V03; Model No: HT24150-1; Manufactured by: TAOTAO INTELLIGENT TECHNOLOGY)

[RoboDurden]

Please create a seperate issue for that razor board :-)

Yes i did change the hold pin to

#define SELF_HOLD PB2 // robo from pin tracing photo

So there is a chance that when you flash the new binary to the master, it will keep power.

If it does not turn off when pushing onOff again, then this definition is still wrong:

#define BUTTON PA5 // robo from pin tracing photo

[AILIFE4798]

@andyshmandy are you willing to help with supporting the mm32 board as you also had the hardware