Gen2.1.20 : ClassyWalk: Motor does not spin, can't detect SELF_HOLD, BUTTON, and hall order

[hoverboardhavoc]

This board from Classy Walk hoverboard and has a GD32F130, FORTIOR FD6287T GA1015 and a NCE01P13K 1PKL2. It's marked with OLSZ 0L20190703-V4.1

Master

Slave

Config

The hall order was not detected by autoconfig (see below). Every combination of HALL_A, HALL_B and HALL_C have been tested with every combination of the detected hall pins, PA1, PC13 and PC14. None of them make the motor turn forwards and backwards using REMOTE_DUMMY.

#ifndef DEFINES_2_x_H
#define DEFINES_2_x_H


//#define SINGLE
//#define MASTER_OR_SINGLE
	
#ifdef MASTER_OR_SINGLE		// layout 2.2 and 2.7 have buzzer on the slave board.
	#define HAS_BUZZER
#endif

// add autodetect #defines below and rename to defines_2-xy.h
// then add another
//	#elif LAYOUT == xy
//		#include "defines_2-xy.h"		// https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/issues/40
// to defines.h and set #define LAYOUT xy in config.h in your chosen GD32E230/MM32SPIN05/GD32F103/GD32F130 target section

// autodetect 2.13 as example only !!!!!!!!!!!!!!!!!!!!!!! begin

// PC13, PC14, PA1
// PC13, PA1, PC14 // Spins smooth one way
// PC14, PC13, PA1
// PC14, PA1, PC13
// PA1, PC13, PC14
// PA1, PC14, PC13

#define HALL_A          PC13
#define HALL_B          PA1
#define HALL_C          PC14

//#define PHASE_A		PB0 // This was detected
//#define PHASE_B		PB1 // This was not detected
//#define PHASE_C		P_UNKOWN

#define LED_RED         PB4
//#define LED_ORANGE            P??
#define LED_GREEN               PB3
#define UPPER_LED               PB2
#define LOWER_LED               PB5
//#define ONBOARD_LED           P??
#define BUZZER          PB9

#define VBATT           PA4
#define CURRENT_DC              PA0 
//#define SELF_HOLD		PB2
//#define BUTTON		PC15
// autodetect 2.13 as example only !!!!!!!!!!!!!!!!!!!!!!! end

// 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


// Timer BLDC short circuit emergency shutoff define
//#define TIMER_BLDC_EMERGENCY_SHUTDOWN	P_UNKOWN

// choose the serial ports available (and set them to Remote or MasterSlave below)

//#define HAS_USART0	// tx=PB6,rx=PB7	uncomment to connect via 19200 baud serial
// GD32F130 USART0 TX/RX:	(PA9/PA10)AF1	, (PB6/PB7)AF0 , 	(PA2/PA3)AF1 , (PA14/PA15)AF1 GD32F130x4 only!
#ifdef HAS_USART0
	#define USART0_TX	PB6
	#define USART0_RX	PB7
	
	//#define USART0_MASTERSLAVE		// uncomment if this usart is used for master-slave communication
	#define USART0_REMOTE						// uncomment if this usart is used for optional remote control
#endif


#define HAS_USART1	// tx=PA2,rx=PA3	uncomment to connect via 19200 baud serial
// GD32F130 USART1 GD32F130 TX/RX: (PA14/PA15)AF1 , (PA2,PA3)AF1	, (PA8/PB0)AlternateFunction4
#ifdef HAS_USART1
	#define USART1_TX		PA2
	#define USART1_RX		PA3
	
	#define USART1_MASTERSLAVE		// uncomment if this usart is used for master-slave communication
	//#define USART1_REMOTE				// uncomment if this usart is used for optional remote control
#endif


#endif

Hold detection

output.mp4

Hold detection freezes after the release OnOff button stage. When the power button is released, the board just turns off.

0 now A5 : 1106
0 now A6 : 1106
0 now A7 : 1106
0 now B0 : 1106
0 now B1 : 1106
0 now B2 : 1106
0 now B10 : 1106
0 now A1 : 1106
0 now B12 : 1106
0 now A11 : 1107
0 now F6 : 1106
0 now F7 : 1107
0 now A12 : 1106
0 now A15 : 1107
0 now B3 : 1106
0 now B4 : 1107
0 now B5 : 1106
0 now B6 : 1106
0 now B7 : 1105
0 now B8 : 1107
0 now B9 : 1106
release OnOff button
ENTER to begin, 's' for next stage, 'q' for menu

Hall / Hall order detection

output1.mp4

The hall detection works but the hall order detection does not detect the order.

hit ENTER:
:-)

:-)
:-)
:-)
:-)
:-)
:-)
:-)autodetect menu:
0: do all
1: VBatt
2: Hold
4: Led
5: Hall
8: Results

hall and phase currents: 'r'=restart	's'=save
try 0 = C13	HALL
try 1 = C14	HALL
try 2 = C15	
try 3 = F0	
try 4 = F1	
try 5 = A0	
try 6 = B11	
try 7 = A4	
try 8 = A5	
try 9 = A6	

Slave board

The slave board flashes but does not appear to turn on. There is obviously no switch to bridge.

Questions

Flashing

The master board can't be flashed when being powered via the bench power supply but can be flashed when powered via the 3.3V line on the ST-LINK flasher. I read elsewhere that this is bad and the ST-LINK does sometimes behave strangely. (Maybe too much current is being drawn?) Any idea why it does not flash while being powered by the bench power supply and are there any workarounds? Maybe it would be better to have an external 3.3V power supply rather than using the 25.9V bench power supply?

Version number

Any idea how this board would fit into the existing version number scheme? It says 0L20190703-V4.1 on it.

[RoboDurden]

Please post the full autodetect log.
And from your video i see that you do not use an arduino with my autodetect.ino as the serial log data proxy.
Only my autodetect.ino can save the tested HOLD pin so on repowering the board, the autodetect firmware can retrieve the last tested button from autodetect.ino and reconize this as the HOLD button..

You should also to run the normal autodetect procedure with "0". Then i think the first pin to detect is the voltage adc VBATT.

And anyway, if the HOLD detection does not work, then simply keep the onOff button bridged and skip this detection stage.
So we see if the different led and the buzzer can be detected.

The hall dectection normaly needs the VBATT, because the pwm ratio must be adjusted for 26V or 36V...

[RoboDurden]

I can not read the log ouput on your hall video.
Does the autodetect indeed finds all three hall pins ?
I only see two pins detected in the beginning, then you mention a phase being detected. But the scan continous until all possible pins have been tested but no third hall found ?

[I-hate-2FA]

hall detect work normally 3 pin found but no order is valid
self hold and button is not required for the firmware to function so you dont need to test those

[hoverboardhavoc]

Thanks for the help with this!

I'm running autodetect.ino on a Blue Pill. I can send pull request with the changes I made to make it work.

Yes, all three hall pins are detected. I failed to paste the logs properly because the buffer is weird in the Aurdino IDE. Creating an entire log has proved problematic, If I run the whole detect routine using, 0 the board just dies when I unbridge the power button. If I detect VBATT (PA4) prior to detecting the hall sensors, hall order detection still fails. The three HALL pins are detected, PC13, PC14, PA1.

Every combination of HALL_A, HALL_B and HALL_C have been tested with every combination of the detected hall pins, PA1, PC13 and PC14. None of them make the motor turn forwards and backwards using REMOTE_DUMMY.

[RoboDurden]

Yes, he could already proceed with a RemoteDummy firmware and simply test the 6 hall permutation with six different firmwares.
But i would autodetect the rgb leds first so that they will blink according to the hall sensors:

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

[hoverboardhavoc]

I only have two color leds to play with unfortunately. There is only green and red (no orange). But they do light up when I manual rotate the wheel when using REMOTE_DUMMY. Maybe I could try with the up or down led as the third led

[I-hate-2FA]

you should use putty as the default serial terminal if you are using windows

[RoboDurden]

If i remember correctly, my HOLD detection has two stages. First it tries to detect the power fail quickly enough to keep code running. If this fails it will use the autodetect.ino to save the last pin tested and recover that information after repowering.

As your board seem to turn off immediately, setting all possible pins to INPUT_PULLUP does not seem to activate the HOLD button.
maybe OUTPUT and digitalWrite(1) is needed. or even digitalWrite(0).

I think you should try to detect as many other pins as possible, so when everything else runs, you have less to try-and-error with the HOLD/BUTTON pins.

Yes, if you have detected UP or DOWN, you can manualy define the orange pins as such a one.

If the led blinking does confirm that you have found the correct three hall pins, than i think that one of the six possible permutations must do.

Because my hall pin detection stage does make the motor spin. So the the activations of the six mosfet seem to work as they are supposed to.

My autodetect log output does support the Arduino serial terminal.

[I-hate-2FA]

I only have two color leds to play with unfortunately. There is only green and red (no orange). But they do light up when I manual rotate the wheel when using REMOTE_DUMMY. Maybe I could try with the up or down led as the third led

yes this is what i do when i develop on the spin06 board where there is only 2 led driver on master
your board seems to contain 7 led driver transistor though which is quite allot

[hoverboardhavoc]

I tried using red, green and up and I think this indicates that I have correctly detected the hall pins. I have tried all the possible different orders and nothing worked but I can try again.

output1.mp4

[I-hate-2FA]

in fact i probably know why it doesnt work

[hoverboardhavoc]

Am I OK to flash the board using the power from the ST-LINK? I can't seem to flash the board when it's powered from the PSU.

[hoverboardhavoc]

@I-hate-2FA The serial is running on a mac currently. I can try putty on Windows. Thanks

[I-hate-2FA]

this is gen2, you should always use the stlink to power the board when flashing, gen1 dev dont know what they are doing

[I-hate-2FA]

1. make sure the battery low protection is disabled
2. make sure invert lowside is set correctly

[RoboDurden]

I do not think that he needs to change "invert lowside"

	// Set up the output channel parameter struct
	timerBldc_oc_parameter_struct.ocpolarity 		= TIMER_OC_POLARITY_HIGH; //HIGH: CHx_O is the same as OxCPRE , LOW: CHx_O is contrary to OxCPRE
	timerBldc_oc_parameter_struct.ocnpolarity 	= TIMER_OCN_POLARITY_LOW; //HIGH: CHx_ON is contrary to OxCPRE, LOW: CHx_O is the same as OxCPRE

As my hall detection stage is already able to make the motors spin.

[RoboDurden]

No need for putty. He obviously can send comands to autodetect.bin and receive the log output :-)

[hoverboardhavoc]

Success!! It seems really smooth :)

@ I-hate-2FA hinted at how voltage problems and BAT_CELLS was set incorrectly. It's defined both on line 14 and 36 in config.h

output2.mp4

Thanks so much for the help.

So the remaining issues I have are:

• Making the slave board power up
• Hold / power button detection

[hoverboardhavoc]

If I send a PR for this board, what should I call it? Ahh I see you gave it a name Gen2.1.20

[RoboDurden]

The slave usualy gets 5V or 12V via the Master-Slave cable which makes it wake up.
So simply measure what positive voltage you have on the master slave cable, and feed this to the correct pin of the slave board.

[RoboDurden]

Your defines you be named defines_2-1-20.h

[hoverboardhavoc]

Is there any lower bound to the voltage I can use. Can I try 12V? I guess it will be slow if it works?

[RoboDurden]

Concerning the HOLD button.. I guess i would add to main.c

typedef struct {
   uint32_t i;
   char*  s;
   uint8_t  wState;   // 1=adc
   int16_t  iAdc;  
} PinAD;


		#define COUNT_PinDigital 31
		PinAD aoPin[COUNT_PinDigital] = {
				{PC13,"C13",0}	,{PC14,"C14",0}	,{PC15,"C15",0}	,{PF0,"F0",0}	,{PF1,"F1",0}		,
				{PA0,"A0",1}		,{PB11,"B11",0}		,{PA4,"A4",1}		,{PA5,"A5",1}	,{PA6,"A6",1} 	,
				{PA7,"A7",1}		,{PB0,"B0",1}		,{PB1,"B1",1}		,{PB2,"B2",0}	,{PB10,"B10",0}	,
				{PA1,"A1",1}	,{PB12,"B12",0}	,{PA11,"A11",0}	,{PF6,"F6",0}	,{PF7,"F7",0} 	,
				{PA12,"A12",0}	,{PA15,"A15",0}	,{PB3,"B3",0}		,{PB4,"B4",0}	,{PB5,"B5",0}	,
				{PB6,"B6",0}		,{PB7,"B7",0}		,{PB8,"B8",0}		,{PB9,"B9",0}	,{PA2,"A2",1}	,
				{PA3,"A3",1}
				};

with all the pins removed that you already know to have a different function.
I you had an autodetect.bin with PA2 and PA3 as rx tx pins.

Then before the while(1) loop add something like

		for (i=0;i<COUNT_PinDigital; i++)	
		{
				//pinModePull(aoPin[i].i,GPIO_MODE_INPUT,GPIO_PUPD_PULLUP);
				pinMode(aoPin[i].i,GPIO_MODE_OUTPUT);
				digitalWrite(aoPin[iTest].i,1);	// every remaining io pin might be the SELF_HOLD pin
		}

And then release the onoff button when the dummy starts spinning.
That way you might be able to find out, what make the HOLD transistor being active.

[RoboDurden]

The button input pin might no longer work if the battery voltage is too low.
And the gate drivers need at least 12V to work nicely.
You have a step down regulator that generates this gate driver voltage.
So 12V battery might only lead to 10V for the gate drivers.
But you have a nice digital power supply. you can test it :-)

[I-hate-2FA]

Is there any lower bound to the voltage I can use. Can I try 12V? I guess it will be slow if it works?

15v

[hoverboardhavoc]

Concerning the HOLD button.. I guess i would add to main.c

typedef struct {
   uint32_t i;
   char*  s;
   uint8_t  wState;   // 1=adc
   int16_t  iAdc;  
} PinAD;


		#define COUNT_PinDigital 31
		PinAD aoPin[COUNT_PinDigital] = {
				{PC13,"C13",0}	,{PC14,"C14",0}	,{PC15,"C15",0}	,{PF0,"F0",0}	,{PF1,"F1",0}		,
				{PA0,"A0",1}		,{PB11,"B11",0}		,{PA4,"A4",1}		,{PA5,"A5",1}	,{PA6,"A6",1} 	,
				{PA7,"A7",1}		,{PB0,"B0",1}		,{PB1,"B1",1}		,{PB2,"B2",0}	,{PB10,"B10",0}	,
				{PA1,"A1",1}	,{PB12,"B12",0}	,{PA11,"A11",0}	,{PF6,"F6",0}	,{PF7,"F7",0} 	,
				{PA12,"A12",0}	,{PA15,"A15",0}	,{PB3,"B3",0}		,{PB4,"B4",0}	,{PB5,"B5",0}	,
				{PB6,"B6",0}		,{PB7,"B7",0}		,{PB8,"B8",0}		,{PB9,"B9",0}	,{PA2,"A2",1}	,
				{PA3,"A3",1}
				};

with all the pins removed that you already know to have a different function. I you had an autodetect.bin with PA2 and PA3 as rx tx pins.

Then before the while(1) loop add something like

		for (i=0;i<COUNT_PinDigital; i++)	
		{
				//pinModePull(aoPin[i].i,GPIO_MODE_INPUT,GPIO_PUPD_PULLUP);
				pinMode(aoPin[i].i,GPIO_MODE_OUTPUT);
				digitalWrite(aoPin[iTest].i,1);	// every remaining io pin might be the SELF_HOLD pin
		}

And then release the onoff button when the dummy starts spinning. That way you might be able to find out, what make the HOLD transistor being active.

Thanks, using this method I discovered that hold is PB12

[RoboDurden]

So it does need output and digitalWrite(PB12,1) to activate the HOLD transistor ?

[RoboDurden]

Now in RemoteAutodetect.c on line 365 you could change

		pinModePull(aiPinScan[SCAN_SELF_HOLD],GPIO_MODE_INPUT,GPIO_PUPD_PULLUP);
		//pinMode(aiPinScan[SCAN_SELF_HOLD],GPIO_MODE_OUTPUT);
		//digitalWrite(aiPinScan[SCAN_SELF_HOLD],1);	// SELF_HOLD pin to high

to

		aiPinScan[SCAN_SELF_HOLD] = PB12;
		HidePinDigital(PB12);
		//pinModePull(aiPinScan[SCAN_SELF_HOLD],GPIO_MODE_INPUT,GPIO_PUPD_PULLUP);
		pinMode(aiPinScan[SCAN_SELF_HOLD],GPIO_MODE_OUTPUT);
		digitalWrite(aiPinScan[SCAN_SELF_HOLD],1);	// SELF_HOLD pin to high

Then you might be able to release the onOff button after you have choosen the BUTTON detect stage and that way discover the button input

[RoboDurden]

Maybe better add this code also(!) to line 631, then you can already release the onOff button when the menu appears.

[I-hate-2FA]

it is better to connect the button pin directly to your external micro controller and disable self hold, so you can control power to the board on demand(assume the mcu is powered externally)

[RoboDurden]

You could also set the RemoteDummy speed to 0 and try three possible pins as the hall inputs.
Then one of the three led will blink according to button pushes..
Will need a free bianries to test all possible pins.

@I-hate-2FA , what transistor/optocoupler do you suggest to emulate the onOff button ?

@hoverboardhavoc , it would be nice if you are able to find all pins and then made a pull request with your defines....h

[I-hate-2FA]

@I-hate-2FA , what transistor/optocoupler do you suggest to emulate the onOff button ?

you do not need one, just connect the button connector directly to esp gpio, the transistor is built in the hoverboard, if they have common gnd itll work

[RoboDurden]

?? the 2pin button (onOff) socket has 36V on one pin ?

[I-hate-2FA]

connect gpio to the one that dont have 36v, 36v one is not needed

[RoboDurden]

yes that might work. But if the other pin is connected to ESP32, it will kill the ESP.
But yes, if people will use a ESP32 for uart control, they might be better of turn the hoverboard on off from there.
On the other hand, the hoverboard could be used to power the esp32.

[I-hate-2FA]

i already tried it irl it worked on my board

[hoverboardhavoc]

Now in RemoteAutodetect.c on line 365 you could change

		pinModePull(aiPinScan[SCAN_SELF_HOLD],GPIO_MODE_INPUT,GPIO_PUPD_PULLUP);
		//pinMode(aiPinScan[SCAN_SELF_HOLD],GPIO_MODE_OUTPUT);
		//digitalWrite(aiPinScan[SCAN_SELF_HOLD],1);	// SELF_HOLD pin to high

to

		aiPinScan[SCAN_SELF_HOLD] = PB12;
		HidePinDigital(PB12);
		//pinModePull(aiPinScan[SCAN_SELF_HOLD],GPIO_MODE_INPUT,GPIO_PUPD_PULLUP);
		pinMode(aiPinScan[SCAN_SELF_HOLD],GPIO_MODE_OUTPUT);
		digitalWrite(aiPinScan[SCAN_SELF_HOLD],1);	// SELF_HOLD pin to high

Then you might be able to release the onOff button after you have choosen the BUTTON detect stage and that way discover the button input

Having made this change, the autoconfig just seems to go into a loop when doing 2: Hold. 3 is not available in the menu, but I can type it anyway but it also goes into an infinite loop:

release OnOff button
ENTER to begin, 's' for next stage, 'q' for menu
 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15autodetect menu:
0: do all
1: VBatt
2: Hold
4: Led
5: Hall
6: HallOrder
7: CurrentDc
8: Results

[I-hate-2FA]

and itll only make sense if you power the esp externally yes

[hoverboardhavoc]

Also, just out of curiosity, why was the autodetect not able to do the digitalWrite(aiPinScan[SCAN_SELF_HOLD],1); Was I just using it wrong somehow?

[I-hate-2FA]

because pinmode output in autodetect is not allowed

[RoboDurden]

As you can see this OUTPUT + digitalWrite was the way i did it - before @I-hate-2FA convinced me that this might create a short cut on some boards. So i switched to the INPUT_PULLUP method.

Yes, you can add wMenuStage |= AUTODETECT_Stage_Button; to make this stage visible in the menu.

[RoboDurden]

If i remember correctly this button detect stage also has two parts, one with onoff bridged and one with releasing it. So the code can detect the difference and find the pin.

[hoverboardhavoc]

I figured out the last piece of the puzzel for the master board, BUTTON:

#ifndef DEFINES_2_x_H
#define DEFINES_2_x_H

#define HALL_A PC13
#define HALL_B PA1
#define HALL_C PC14
#define LED_RED PB4
#define LED_GREEN PB3
#define UPPER_LED PB2
#define LOWER_LED PB5
#define BUZZER PB9
#define VBATT PA4
#define CURRENT_DC PA0 
#define SELF_HOLD	PB12
#define BUTTON PA12

// 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

#define HAS_USART1	// tx=PA2,rx=PA3	uncomment to connect via 19200 baud serial
// GD32F130 USART1 GD32F130 TX/RX: (PA14/PA15)AF1 , (PA2,PA3)AF1	, (PA8/PB0)AlternateFunction4
#ifdef HAS_USART1
	#define USART1_TX		PA2
	#define USART1_RX		PA3
	
	#define USART1_MASTERSLAVE		// uncomment if this usart is used for master-slave communication
#endif

#endif

I'll send a PR in the coming days

[hoverboardhavoc]

I attempted to make a PR but it says I have an "entirely different commit history"

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/compare/main...hoverboardhavoc:hoverboardhavoc/classy-walk?expand=1

Ok, I've forked the wrong repo! This was a little mind bending. This issue is on one repo, but the code is elsewhere. Maybe it could all be put in the same place?

[I-hate-2FA]

no because then you will not be able to download the code in browser

[I-hate-2FA]

all big project issue tracker and wiki have seperate repo like esphome

[RoboDurden]

Yes, This home repo had become to big in size. The GD32 code repo is easy to download.

[RoboDurden]

Thanks for the pull request. I improved your missing orange led code in bldc.c :

	#ifdef TEST_HALL2LED
		#ifdef LED_ORANGE
			digitalWrite(LED_ORANGE,hall_b);
		#elif defined(UPPER_LED)
			digitalWrite(UPPER_LED,hall_b);
		#elif defined(LOWER_LED)
			digitalWrite(LOWER_LED,hall_b);
		#else
			if (hall_b)
			{
				digitalWrite(LED_GREEN,(steerCounter%2) < 1);
				digitalWrite(LED_RED,(steerCounter%2) < 1);
			}
		#endif
		digitalWrite(LED_GREEN,hall_a);
		digitalWrite(LED_RED,hall_c);
	#endif

[RoboDurden]

I think there are pads for another USART but no connector. Maybe I'll need to solder something on if I want to connect the board to a micro controller and a slave

Yes, the second uart port (usually PB6 and PB7 ) would be good to have master-slave communication.
But i added the RemoteUartBus with which you can control two or more single boards directly from ESP32 (or likewise).

What empty uart header are you reffering to ?
Please show it on a photo.
I see some bluetooth modules on your photos.
Sometimes they only offer a TX or RX line and not both..

[RoboDurden]

The slave board has a red 4 pin header mounted. That might be three additional led outputs.

[I-hate-2FA]

it is 2024 we should always use the same uartbus protocol

[hoverboardhavoc]

I think there are pads for another USART but no connector. Maybe I'll need to solder something on if I want to connect the board to a micro controller and a slave

Yes, the second uart port (usually PB6 and PB7 ) would be good to have master-slave communication. But i added the RemoteUartBus with which you can control two or more single boards directly from ESP32 (or likewise).

What empty uart header are you reffering to ? Please show it on a photo. I see some bluetooth modules on your photos. Sometimes they only offer a TX or RX line and not both..

I put a red ring around what I thought might be a UART

[RoboDurden]

but i see three little smd transistors above this 4pin header, that is why we think it is another led driver port.

Try to trace the PB6 and PB7 of the mcu. I guess at least one of those will lead to the bluetooth module.
If you are lucky, both rx and tx will end there. Then you have the second uart.

[I-hate-2FA]

there is 3 pin connector near antenna its highly likely