unable to Autodetect the pins of my board GD32F130C6T6 & UART control

[HRAFRH]

![2024-06-02 21 41](https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/assets/125764830/d41efa82-adf7-4225-94d8-e5968e69acfb

I tried a lot but i need help on detecting the correct pin for only board i got (i think it's a master) that i want to control it using ESP32, but board is not listed in the Wiki could you please help me !!

[HRAFRH]

i compared it with The reverse-engineered schematics of the mainboard provided in GitHub it's the same wiring for the mosfets

[RoboDurden]

PB6 and PB7 might be on the header to the left:

PA2, PA3 might be the master slave header.

You did not say anything on whether you were able to flash the autodetect binary. Nor what software you are using. autoflash.bat ? Keil ? St-Link-Utility ? What power supply ?

[HRAFRH]

I've been using ST-Link Utility, STM32CubeProgrammer, ST Visual Programmer, and KeilVision5 to upload various binaries using ST-link V2

I'm unable to detect the pins on the hall sensors, driver gates, .... and other pins. My motherboard version doesn't seem to match any of the versions you're providing.

I'm having trouble establishing a connection between ESP32 and STM32 using USART. Any guidance you could provide would be greatly appreciated. Thank you!

WHAT I KNOW SO FAR

Any guidance you could provide would be greatly appreciated. Thank you!

[RoboDurden]

As you have Keil running, select target GD32F130 and for config.h

#ifndef CONFIG_H
#define CONFIG_H

#define REMOTE_AUTODETECT       // !! highly experimental 
                // ONLY test with 1-2A constant current power supply !!!!
                // will drive the motor without hall input to detect the hall pins..

#ifdef REMOTE_AUTODETECT

    #define HAS_USART0  // tx=PB6,rx=PB7    uncomment to connect via 19200 baud serial
    //#define HAS_USART1    // tx=PA2,rx=PA3    uncomment to connect via 19200 baud serial

F7 + F8 and watch my latest autodetect youtube video :-) You very very likely do not mean PB2 and PB3 for usart1 but PA2 and PA3..

[HRAFRH]

For the power supply i have some generators

[RoboDurden]

Yes, the max 2A cc is fine. Make sure you have your tx rx pins corrected in autodetec.ino

#ifdef ESP32
  const int pinRX = 39, pinTX = 37;   // Wemos S2 Mini
  //const int pinRX = 16, pinTX = 17;    Wemos Lolin32
  #define oSerialHover Serial1    // ESP32

[HRAFRH]

for the autodetec.ino here's the ESP32 i'm using and the code :

define ESP32 // comment out if using Arduino

define _DEBUG // uncomment to get additional debug output

ifdef _DEBUG

define OUTC(code) {code}

define OUT(s) {Serial.print(s);}

define OUT2T(s,i) {Serial.print(s);Serial.print(": ");Serial.print(i);Serial.print(" ");}

define OUT2TX(s,i) {Serial.print(s);Serial.print(": ");Serial.print(i,HEX);Serial.print(" ");}

define OUT2N(s,i) {Serial.print(s);Serial.print(": ");Serial.print(i);Serial.println();}

else

define OUTC(code)

define OUT(s)

define OUT2T(s,i)

define OUT2TX(s,i)

define OUT2N(s,i)

endif

// Serial interface, baud, RX GPIO, TX GPIO // Note: The GPIO numbers will not necessarily correspond to the // pin number printed on the PCB. Refer to your ESP32 documentation for pin to GPIO mappings.

define BAUDRATE 19200 // 19200 is default on hoverboard side because Arduino Nano SoftwareSerial cannot do 115200

ifdef ESP32

const int pinRX = 3, pinTX = 1; // Wemos S2 Mini // const int pinRX = 16, pinTX = 17; Wemos Lolin32

define oSerialHover Serial1 // ESP32

else

include

// const int pinRX = 3, pinTX = 1; SoftwareSerial oSerialHover(pinRX, pinTX); // RX, TX // #define oSerialHover Serial // Arduino

endif

void setup() { pinMode(2, OUTPUT); Serial.begin(115200); Serial.println("Hello Hoverboard V2.x Autodetect :-)");

ifdef ESP32

oSerialHover.begin(BAUDRATE, SERIAL_8N1, pinRX, pinTX);

else

oSerialHover.begin(BAUDRATE);

endif

}

define PINS_DETECT 18

const char* asScan[PINS_DETECT] = {"HALL_A","HALL_B","HALL_C","PHASE_A","PHASE_B","PHASE_C","LED_RED","LED_ORANGE","LED_GREEN","UPPER_LED","LOWER_LED","ONBOARD_LED","BUZZER","VBATT","CURRENT_DC","SELF_HOLD","BUTTON","BUTTON_PU"}; uint32_t aiPinScan[PINS_DETECT] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; // the found pins

typedef struct attribute((packed, aligned(1))) { uint8_t cStart; // = '/'; uint8_t wCmd; } HeaderData;

enum { DATA_None, DATA_Request, DATA_Save }; HeaderData oDataHeader = {0x01, DATA_None}; // when autodetect.ino receives 0x01 it stores the incoming data or returns its storage

unsigned long iTimeTest = 0; int iSerialHoverType = 0;

void loop() { digitalWrite(2, (millis() % 2000) < 500); if (Serial.available()) // If anything comes in Serial (USB), {
char c = Serial.read(); oSerialHover.write(c); // read it and send it to hoverboard }

if (oSerialHover.available()) // If anything comes in from hoverboard {
if (iSerialHoverType == 1) { int iAvail = oSerialHover.available(); if (iAvail < sizeof(HeaderData) - 1 + sizeof(aiPinScan)) return;

  HeaderData oHeaderRx;
  uint32_t aiPinScanRx[PINS_DETECT];
  oSerialHover.readBytes(((uint8_t*)&oHeaderRx) + 1, sizeof(oDataHeader) - 1);   // 0x01 already read
  oSerialHover.readBytes((uint8_t*)aiPinScanRx, sizeof(aiPinScanRx));
  iSerialHoverType = 0;

  OUT2N(oHeaderRx.wCmd, oDataHeader.wCmd)
  if (oHeaderRx.wCmd == DATA_Request)
  {
    oSerialHover.write((uint8_t*) &oDataHeader, sizeof(oDataHeader)); 
    oSerialHover.write((uint8_t*) aiPinScan, sizeof(aiPinScan)); 
    OUT2N("DATA_Request", sizeof(oDataHeader) + sizeof(aiPinScan));
  }
  else
  {
    oDataHeader.wCmd = oHeaderRx.wCmd;  // store for later request
    memcpy((uint8_t*)aiPinScan, (uint8_t*)aiPinScanRx, sizeof(aiPinScanRx));
  }
  OUTC(
    OUT("\npins:\t")
    for (int i = 0; i < PINS_DETECT; i++)
    {  
      OUT2T(asScan[i], aiPinScan[i])
    }
    OUT("\n")
  )
  return;    
}

char c = oSerialHover.read();

// MM32 pinFinder: emulate serial bridge
if ((c >= 0x11) && (c <= 0x14))
{
  oSerialHover.write(c);  // send back to hoverboard because MM32 pinFinder that way detects your serial port :-)
  return;
}
else if (c == 0x01)  // GD32 autodetect temporary storage
{
  iSerialHoverType = 1;
  return;
}
Serial.write(c);   // read it and send it out Serial (USB)

} if (iTimeTest > millis()) return; iTimeTest = millis() + 1000; }

also i keil this what i did :

yes my bad it's usart1 PA2 and PA3

[RoboDurden]

GPIO1 and GPIO3 might be the Serial pins used for serial terminal. You might try others like pinRX = 16, pinTX = 17

[HRAFRH]

yeees i changed it and at least i can see the smiley face :)

BUT i cant see 'Hit enter" option

and when i switch the power button ON the motor start for like 1 sec

[RoboDurden]

Are you sure that PB6 AND PB7 are on that header ? Sometimes it is only one:

you can also try pa2 and pa3..

No, this is only the hello_world smiley from the esp32 setup(), no incoming data from hoverboard.

You need to connect hall sensors from the hoverboard motor. and strongly mount that motor.

when the hoverboard is powered on, the motor rotates for a fraction of a second to show you that the autodetect firmware is running..

use a DSO to see the incoming serial data from hoverboard. Or led with 330 Ohm or 1 kOhm resistor to see the tx data from hoverboard (normally connected to your esp32 tx pin.

[HRAFRH]

NO i'm not that too sure, but it says REMOTE in the PCB and according to the schematics based on gd32F130 the REMOTE pins are (R: PB7 (I2C1_SDA / USART0_RX) & PB6 (I2C1_SCL / USART0_TX)),

but i'm sure about the PA2 and PA3 are for uSART1

alright i'll try to connect the hall sensor cables and strongly mount the motor;

what DSO means ?

[RoboDurden]

this has only a RX pin to receive data from remote. You need the pa2/pa3 autodetect.

DSO = oscilloscope. Buy this one: https://www.aliexpress.com/item/1005006019697163.html best value for $30.

[HRAFRH]

i tried pa2 & pa3 usart I USED both of em DSO & LED and i'm noticing that only GPOI16 and gpio17 from the ESP32 that supplying the LEDS and there no signals in the oscilloscope

also the serial monitor still blocked in Hello Hoverboard V2.x Autodetect :-)

[RoboDurden]

Maybe you need to turn the hoverboard off and on after successfully flashed with Keil.

Maybe you need more than 26 volt to start up.

You could start tracing the pins manually.

If you have a led output you could activated the Debug_led macro and let led blink when gpio init has finished in main.c

[HRAFRH]

if you mean by the ' led output ' this one

unfortunately i don't got any on them, can i use simple LEDS ?

you meant to track the hall pins manually ?

where i can find the Debug_led macro ?

[HRAFRH]

I exactly what you said, i turn the hoverboard off and on after successfully flashed with Keil. using 26 volt power supply to start up. and the motor turned abit more with this in the serial monitor

[HRAFRH]

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/assets/125764830/f70729e7-09f2-4a13-b687-e8e2e0291799

[RoboDurden]

Will watch the move later. Looks like You did receive the pin backup from the autodetect firmware :-)

There is a debug led define you have to uncomment in config.h

Usage can be seen in main.c

But you will have to use a defines_2-0.h with your manually traced pins. And not autodetect..

[RoboDurden]

I would find the pin array definition in RemoteAutodetect.c and change the first value from 0 to 42. If that 42 appears on your putty terminal then you have a TX RX communication.

[HRAFRH]

the pin array definition in RemoteAutodetect.c this one ?

[RoboDurden]

no, line 94: uint32_t aiPinScan[PINS_DETECT] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; // the found pins

[RoboDurden]

the pins get printed in line 103ff of autodetect.ino

  if (oSerialHover.available())   // If anything comes in from hoverboard
  {     
    if (iSerialHoverType==1)
    {
      int iAvail = oSerialHover.available();
      //OUT2T("iAvail",iAvail)
      if (iAvail < sizeof(HeaderData)-1 +sizeof(aiPinScan))
        return;

So you must have received a full data struct before the pins get printed. Maybe try another terminal software. But putty used to work :-/

[HRAFRH]

pins: HALL_A: 6138 HALL_B: 0 HALL_C: 14417859 PHASE_A: 0 PHASE_B: 4282187776 PHASE_C: 253 LED_RED: 0 LED_ORANGE: 134217472 LED_GREEN: 1 UPPER_LED: 0 LOWER_LED: 130816 ONBOARD_LED: 0 BUZZER: 0 VBATT: 4194297 CURRENT_DC: 0 SELF_HOLD: 0 BUTTON: 4294967295 BUTTON_PU: 32775

all i can see in the monitor so far

using other software too

[HRAFRH]

could you please check the wiring diagram !

[RoboDurden]

in the last screenshot you got random numbers, no nice zeros for all pins. So only garbage on the tx-rx line.

You have to try and error which hoverboard pin is rx and which is tx. only two possibilities. onoff button seems to work as the motor does spin when you bridge the onoff button !?

Try to get the nice zeros consistently. Then attach your osscilloscope to see the data being sent from hoverboard to esp32.

If you trace the three hall sensors manually, you could compile a pa2/pa3 RemoteUart and forget about the autodetect..

[RoboDurden]

In the above image you labeled the 4 pin header next to the hall sensor to be the uart1 header !

[HRAFRH]

yes i tested them manually and there connected to PA2 & PA3

[HRAFRH]

for the pa2/pa3 RemoteUart do i need to found the pint connected to the Low-pass filter ?

[RoboDurden]

please do not ask too many questions.

[RoboDurden]

maybe this pin-array storage is the problem.. When esp32 a request from hoverboard on startup, it sends its copy to the hoverboard. If this data is wrongly interpreted by the autodetect firmware, it might skip the ":-) :-) :-)" and skips to the main menu. Which for some reason might not be printed to esp32.. So you might try to send "q" + enter to hoverboard to print menu again.

Or you could send "1" + enter and see if the firmware enters voltage pin detection. Then motor will start to spin and stop and spin and stop and spin. Then we would know that the firmware is working correctly but that your esp rx line is not receiving the output.

[HRAFRH]

Thank you so much for all the information and for taking from you valuable time to help me with my school project.

finally The UART connections are made, and I can compile the AUTODETECT program, the smiley faces shining :-) :-) :-) using CoolTerm software

Starting with Hall pins

#define HALL_A..PC14
#define HALL_B..PB11
#define HALL_C..PA1
autodetect menu:
0: do all
1: VBatt
2: Hold
4: Led
5: Hall
6: HallOrder
8: Results

I will follow through with it until defining all the pins. Could you please guide me on what I should do next after this step? 🤝

[I-hate-2FA]

i cant believe im late but im here just working on android developement things

idk whats your logic, but these too large number may overflow and cause problem in the code(imagine there is debugging for gd32, you can watch variable then), and idk why there is random value, the esp dont need eeprom, just store in ram, so just reboot the esp and all is gone

you can watch the video toturial about auto detect, all be is not very good video but you can still understand how to use it if you are not a idiot

the gd32 support is unfortunately not hapenning any time soon, because someone say he want to help with spin0280 and after i made pinfinder for it he disappeared, so i cant make any action to the code now or i wont be able to support 0280 forever, because itll get out of sync and cannot merge, i should never trust anyone, i should only work on it if he is willing to send me the board

[I-hate-2FA]

and maybe watch the wiki also if you havent

[I-hate-2FA]

finally The UART connections are made, and I can compile the AUTODETECT program, the smiley faces shining :-) :-) :-) using CoolTerm software

@RoboDurden now you understand why detect unsupported terminal is necessary

[RoboDurden]

@HRAFRH , Could you please tell me what went wrong so long and how did you resolve that problem !

The order should be from top to botton - of course. And watch my latest autodetect video.

@I-hate-2FA , yes i did not want to call you for help because i am happy if you have time for the real problems.

[I-hate-2FA]

you can call me in, i am not like the gen1 dev that are not helpful, even if it is your firmware i dont have to but ill still try to help

[RoboDurden]

someone say he want to help with spin0280 and after i made pinfinder for it he disappeared, so i cant make any action to the code now or i wont be able to support 0280 forever, because itll get out of sync and cannot merge, i should never trust anyone ...

Mankind is evil.. This guy here will also disappear. There is no happiness in the world to build something together. Mankind is totally egositic.

[HRAFRH]

@HRAFRH , Could you please tell me what went wrong so long and how did you resolve that problem !

The order should be from top to botton - of course.

And watch my latest autodetect video.

@I-hate-2FA , yes i did not want to call you for help because i am happy if you have time for the real problems.

It was all diagram-cables, Power supply issues the code was working fine (tested the RX Tx in stm32 the signal was there),

[I-hate-2FA]

Mankind is evil.. This guy here will also disappear.

he will, if you trying to ask him to do additional things after he got his project working

but like come on for the 0280 he didnt even want to try the code i written for him that he demand, and i already told him the consiquence of not sending me the board is you have to do allot of testing for me, because no programmer can do it in the first try

[HRAFRH]

Hi?@I-hate-2FA, I don’t fully understand the last conversation, but if it’s about me, I’m definitely down to help with anything you need, as long as I know how to do it. Just let me know!

[I-hate-2FA]

It is not, you have out done most bdc users, I'm just complaining about other things about my firmware with robo

[I-hate-2FA]

I'm here to help not blame you, although this is not my firmware I can only give limited help, as I don't fully understand how everything is done

[HRAFRH]

During my testing, I ran three different tests, and each test gave me different pin configurations. I want to ask if this is normal and why the code provides different pins in each test.

Additionally, could you please explain the concept behind the code and why it might give different pin results? Should I use the pin configuration from the last test, or is there a specific way to determine the correct pins?

Thank you for your help!

[I-hate-2FA]

The detection method used in gd32 is not 100% reliable, but in your case it works quite well actually The most important one is hall sensor, the board cannot work without, and all 3 test show same pinout Even the self hold pin is reliable in your case(pb2) If the led detection is not reliable, it is entirely your fault, because it is just semi auto detect you have the final decision Idk why vbat detection not work for you, it is also semi auto, if you have variable power supply it is easy to tell, unless you also faced the issue I had that multiple pin read same voltage Current DC detection is bad, don't use it, I suggested this feature but I admit it is bad, I regret it allot,I didn't even include it in my firmware

the board only need hall sensor to run, so you can already try to use main with the hall sensor and serial line pins

[HRAFRH]

Hi @RoboDurden @I-hate-2FA ,

I want to try the UART controls on my hoverboard using a potentiometer or RC Controller, joystick or a similar input device. However, I've tried the TestSpeed.ino with ESP32 , and in Keil confih.h i commented //#define REMOTE_AUTODETECT // !! highly experimental

#ifdef GD32F130     // TARGET = 1
        #define LAYOUT 4
        #define LAYOUT_SUB 1    // Layout 2.1.7 exisits as 2.1.7.0 and 2.1.7.1

#define REMOTE_UART

and nothing seems to move. The wheels don't respond, and I don't see any signal using the oscilloscope.

Could you please advise on which parts of the code I need to change and which layout I should use? I have various defines, and I'm unsure which one is the correct one to use.

Thank you for your assistance !

[RoboDurden]

please use your brain. defines_2-1-4.h :

#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

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

[HRAFRH]

I'm having trouble understanding the principle of layouts and how to use the defines in the project. :/

[I-hate-2FA]

did you enable remote uart or remote uartbus

[HRAFRH]

I have enabled Both of them, and and nothing seems to move

[I-hate-2FA]

how is it possible to enable both of them?