Gen2.1.20 - YIYUN YK204U (looks almost similar to "target_1=GD32F130/v17=2.19" Gotrax"

[flow1986]

Hello,

i recently bought a used Hoverboard . The Split PCBs look almost like the GD32F130/v17=2.19 Gotrax, but not quite.

some Photos attached.

i try to use the Gotrax config and report my progress.

[RoboDurden]

As the headers have a different layout to 2.1.17 I do not think the pin definitions will be compatible.

But as you should test with a 2A cc power supply anyway, it is not that dangerous to test all 2.1.x dummy binaries until one makes the motors spin.

But running my autodetect binary will do no harm either and more likely gives you a complete set of working pin definitions. Watch my latest YouTube video on the gd32 autodetect..

[jonasniesner]

I have the same boards (16pcs) 2.18 makes the motor vibrate and my psu current limit

[I-hate-2FA]

use auto detect maybe

[jonasniesner]

Ok, autodetect worked :) , now the motor spins fine in one direction but has little to no torque in the other direction. Will continue investigating this tomorrow.

[jonasniesner]

How would this board fall into the naming/numbering convention? I would like to create a new config for it

[RoboDurden]

I think this board should become defines_2-1-20.h So config.h should be

//#define REMOTE_AUTODETECT     // !! highly experimental 
...
    // LAYOUT_2_X is used in defines.h
    #ifdef GD32F130     // TARGET = 1
        #define LAYOUT 20
        #define LAYOUT_SUB 1    // Layout 2.1.7 exisits as 2.1.7.0 and 2.1.7.1

Please post some nice photos of front and back here (with cables bent out of sight) Would be nice if you could post the complete autodetect log so i can happily see how my code worked.

No idea why no torque in other direction. Was that already with a RemoteDummy firmware or still autodetect ?

[jonasniesner]

I will post the full log tomorrow. Are you supposed to externally power the 3.3V rail during auto detect? Because my board turned off during the power switch detection. The low torque was in the RemoteDummy firmware. But I will hook up a scope tomorrow to investigate further. And the buzzer did not sound during auto detection. But I suspect it shares pins with uart0

[RoboDurden]

no, in the final try to detect power switch, i think the board is intentionally shut down. So you should NOT power the mcu with extra 3.3V

If torque is not symmetrical, then it might be that the hall sensors order is wrong. So maybe my autodetect did choose the wrong permutation out of six. And you could test all six permutations manually with RemoteDummy.

But if motor is running very smoothly, that hall order should be correct.

Do you see the three led blink according to the rotation of the motor ?

        #ifdef REMOTE_DUMMY
            #define TEST_HALL2LED   // led the 3-led panel blink according to the hall sensors
        #else
            //#define TEST_HALL2LED // led the 3-led panel blink according to the hall sensors
        #endif

[I-hate-2FA]

you can use my detecting algorithm, it never make mistake yet

[I-hate-2FA]

got a f031 board, will play with it when i have time

[I-hate-2FA]

in my reverse engineering, all the battery voltage detecting voltage divider is after the p mosfet for latch so power the mcu externally and use this may be an option

[I-hate-2FA]

but i think my current detect routine is good ill not change it

[RoboDurden]

current detection ??? i guess you are talking about your MM32 pinFinder.

[I-hate-2FA]

i mean for hall detect you can use my algorithm and for latch detect you can power the chip with 3v3 externally and use vbat adc to determen if the latch is released or not

[RoboDurden]

Let's wait to see if for @jonasniesner my hall permutation detection indeed got it wrong. Yes, if the latch transistor/mosfet will always cut off the VBATT voltage divider, i could monitor that adc voltage and tell user to also power the hoverboard with the 3.3V from the st-link dongle. That will be better then to force them to use my autodetect.ino for temporary storage of the latch pin currently tested..

[jonasniesner]

Ok, I got further. It looks like the hall order was wrong. This is what I have so far

#define HALL_A      PF1
#define HALL_B      PA0
#define HALL_C      PC15
#define PHASE_A     PB0
#define PHASE_B     PB1
//#define PHASE_C       P??

#define LED_RED     PF6
//#define LED_ORANGE        P??
#define LED_GREEN       PA12
//#define UPPER_LED     P??
//#define LOWER_LED     P??
//#define ONBOARD_LED       P??
#define BUZZER      PA11

#define VBATT       PA1
#define CURRENT_DC      PB1
#define SELF_HOLD       PA5
//#define BUTTON        P??
#define BUTTON_PU       PB2

[RoboDurden]

The third led is nice to show the three hall sensors. Maybe you have the 2 led module connected (cross) instead of the 3 led module.

[I-hate-2FA]

robo can you send me stlink driver thanks

[RoboDurden]

You mean this www.robosoft.de/forums/en.stsw-link004_v4.6.0.zip ? or that http://www.robosoft.de/forums/STM32%20ST-LINK%20Utility%20v4.6.0.exe ?

Actually i do not remember if that had been official downloads. I just found them on my computer and uploaded them for you.

[I-hate-2FA]

thanks, actually this is available elsewhere, but i forgot where to find it, i installed old version of stlink utilities and it didnt include the driver, i thought i need seperate file to install the driver