Gen2.1.15 (ex2.17) - GD32F130C6T6 - Another layout

[andyshmandy]

Hello @RoboDurden! I have yet another board layout that I would like to try to get working. Please let me know if you think it is capable of FOC. It is called a GoTrax SRX Mini. It is using a GD32F130C6T6 MCU.

I created a new layout and made the necessary code changes and I was able to compile and flash just fine (after doing removing the resistor and adding the wire to NRST as shown in the readme for the ST-link v2). The problem I am having is that the power isn't staying on. When I press the power button I get a chirp from the buzzer and it seems to reset so it appears that REMOTE_DUMMY doesn't even have a chance to start.

I removed several of the components (Buzzer, optical sensor, and capacitor) temporarily in order to better trace the board.

I am having difficulty identifying the following:
SELF_HOLD
BUTTON (I am not certain that I have it mapped correctly) PB2?
VBATT
CURRENT_DC

By the way, I have another board that is very close to this one but it uses the MM32SPIN MCU (see 3rd board on issue #38).

[RoboDurden]

Only test with a 2A cc constant current power supply!!!
You should not have unsoldered anything. This only increases the risk to damage the board.
When you have traced at least one led you can activate the debug_led macro in config.h and let the led turn on or off or blink when code execution reaches a certain point. See the usage of that macro in main.c
I never succeeded with Step by step debugging in the Keil IDE.

C6 instead of C8 means only 32 kB instead of 64 kB. Our simpleFOC firmware has become far bigger then 32 kB, so there is little chance that code optimization will ever bring it below 32 kB again :-(

This gen2.x runs nicely with 32 kB.

I can not open your private-user-images.githubusercontent.com- images.

Concerning MM32SPIN see the 2.8 issue. #22

Please make a pull request with your defines_2-17.h (I guess that is the next number).

[RoboDurden]

Untill you have found the correct SELF_HOLD pin you can bridge the onoff button to keep the board powered.

currentDC and VBatt can wait until you have serial communication to esp32 or likewise.

Thanks for pictures of the gotrax housing. So others will know what is inside from the outside :-)

[RoboDurden]

Please upload photo with the cables attached so we know what the headers are meant for.

[andyshmandy]

I was able to get this layout to work using REMOTE_DUMMY. I put up a PR #45 with my changes. I tried to get serial output using the arduino but I am still getting junk... even with nothing connected to the arduino using the TestSpeed.ino. This behavior is strange. I tried different pins on the arduino and I am still getting junk characters so I am still trying to figure that out.

[andyshmandy]

When I am running REMOTE_DUMMY, should I be able to connect an arduino to the UART0 TX/RX and GND and see output output? Also, I connected a logic analyzer (I don't have an osciliscope) to UART0 TX/RX when running REMOTE_DUMMY and it is showing high when I power on but there is no digital signal otherwise. I am guessing that I am missing something stupid.

[RoboDurden]

RemoteDummy does not have uart communication!
You need to choose RemoteUart or RemoteUartBus!
Better do not start with uartBus because then the hoverboard only answers when it successfully received a message from Esp.
RemoteUart will send log data about every 100 Ms.
This is no acii log data but a c struct.
You need the example ino with it's hoberserial.h to decode the data.

[andyshmandy]

After a lot of tinkering and learning/hacking I figured out that this layout doesn't have USART0 accessible on the PCB. After defining USART1_Remote with the proper pins I was seeing bits transmitted when I connected my logic analyzer. Using the TestSpeed.ino sketch I was still not able to get anything but garbage on my serial monitor when connected to my Arduino Mega. I discovered that the SoftwareSerial library might be causing issues so I switched over to hardware serial defined as Serial1 which uses pins 19, 18 (RX/TX). After making that change, I was able to get the TestSpeed to start controlling the motor.

After that I was able to figure out a few more of the ADC defines

// ADC defines
#define VBATT	PB1				// Confirmed AndyShmandy 12/22/2023
#define CURRENT_DC 	PA7 // Confirmed AndyShmandy 12/22/2023

#define SELF_HOLD	PC13  // Confirmed AndyShmandy 12/19/2023
#define BUTTON	 PB2 		// Confirmed AndyShmandy 12/19/2023

I will do a PR for my changes to this layout.

@RoboDurden Thank you for your help with this!

[andyshmandy]

I added a PR for #46. Thanks again!

[RoboDurden]

No way to access pb6 and pb7 ?
If you only have one uart you will need RemoteUartBus to control 2+ motors with one serial port.

Some other user recently had problems with RemoteUartBus but I live outdoors and can not test any hardware for the next weeks.
As you are really good at solving problems yourself you might give the RemoteUartBus a try :-)

[andyshmandy]

Unfortunately, it appears that these pins don't have traces. :-(.

Stay safe! Stay warm. It looks like weather conditions are similar in Germany to where I am in the United States. I will probably give RemoteUartBus a try. I would like to attempt to remote control this this thing.

[RoboDurden]

You even unsoldered the MCU ?

There are uart0 alternatives, target.h:

#define AF_USART0_TX(pin)	(pin==PB6 ? GPIO_AF_0 : GPIO_AF_2)			// GD32F130: AF0 = PB6 , AF1 = PA2 or PA9 or PA14
#define AF_USART0_RX(pin)	(pin==PB7 ? GPIO_AF_0 : GPIO_AF_2)			// GD32F130: AF0 = PB7 , AF1 = PA3 or PA15 

maybe you can make use of PA14 and PA15

[RoboDurden]

But here you trace PB6 and PB7 to the IMU:

which makes sense as these two pins with AF1 (alternate function 1) can do I2C

[andyshmandy]

No, the only thing that I left unsoldered is the single optical sensor in the middle of the board that was used to detect 'foot on hoverboard'. In the image above, (using Gimp) I just had the opacity set to 50% so you could see both sides of the board and that PB6 and PB7 don't go to vias on the bottom of the board.

The image you are showing above is from the Razor layout 2-16 #42. For this layout, the IMU is traced to pins PB10 and PB11

When I get better at soldering, I may try to attach to those pins directly.

There are a few more "broken" free hoverboards that I am going to pick up so we will see what those boards look like. I am learning so much and having so much fun with this. Thank you!

[RoboDurden]

When you have finished with your nice pin tracings, please make another pull request :-)
RemoteUartBus working again. The TestSpeed arduino example had an outdated hoverserial.h library.

[andyshmandy]

I tried to get REMOTE_UARTBUS working on this layout but I am not having any success. Since it doesn't have a second uart available, I have the config.h set:

#define SINGLE
#define REMOTE_UARTBUS
#define SLAVE_ID 0   // Just trying to get the first one going

In defines_2-17.h

//#define HAS_USART0
#define HAS_USART1
#define USART1_REMOTE

After flashing with this change, when I connect my logic analyzer to USART1 and turn it on, both chanels (RX and TX) go HIGH and stay until I turn it off. That behavior seems strange. When I have it configured for REMOTE_UART, I see it sending data. It seems like REMOTE_UARTBUS doesn't like USART1... just a theory.

On the other end, I wanted to make sure that the ESP32 can send data to the hoverboard. I hooked up my logic analyzer and it showed data on the TX channel and nothing on the RX as expected.

Even though the hoverboard side doesn't seem to be working, I decided to hook the ESP32 to USART1 on the hoverboard. It didn't work. :-(.

I will try to dig a bit further in the code of the remoteUartBus to see if I can figure out why it isn't using USART1. By the way, I probed USART0 pins (PB6, PB7) using the logic analyzer and it didn't appear to be sending/receiving any data and the pins stayed LOW.

My next step in troubleshooting will be to define USART0 and configure it for USART0_REMOTE and probe those pins to see if I see any bits. Unfortunately, those pins don't even have traces on this board.

Any thoughts?

[RoboDurden]

Be aware that i updated the repo today because the TestSpeed Arduino example had an outdated hoverserial.h library that did not work with UartBus ! That was the issue that made UartBus not work for that other user. Now it is working fine for him.
RemoteUartBus will not send every 100ms but (of course) first only listen to the BUS until a message with it's id is received.
If RemoteUart works, then for sure RemoteUartBus should also work hardware wise. At least for one board. With multiple boards and different type of boards you might need diodes ....

[andyshmandy]

I was using the updated hoverserial.h. After a lot of troubleshooting I was able to get it to work using REMOTE_UARTBUS. I discovered that the RX/TX pins that are set in TestSpeed.ino for ESP32 are actually GPIO pin numbers that may map to different pins on the ESP32 PCB. On my "ESP32 Dev Module" the GPIO 16, 17 are labeled 27, 28. I may put up a PR that adds a comment to that line so that all of the time I wasted won't be wasted by someone that is dumb like me ;-).

I am going to see if I can get a second one working on REMOTE_UARTBUS as you show schematic in the readme. Do you know of any code examples for steering that takes input from a potentiometer?

[RoboDurden]

AnalogRead on the esp32 side and then map the 0 - 4096 to fSteer = 0.0 - 1.0

Then speedL = (1-fSteer)* iSpeed
and speedR = fSteer * I speed

[andyshmandy]

Awesome!! Thanks! I'll give that a try.

I added a PR to clarify the GPIO port vs PCB pin number that I was confused by (#47) . I won't feel bad if you close it without merging.

[andyshmandy]

Good news... I was able to get this working and control the speed and steering using potentiometers. After that success, I tried something a bit more challenging and I figured out how to remote control this thing with my RC airplane transmitter (Flysky FS-i6x) and receiver(fs-ia10b) connected to my ESP32.

At this point, my biggest problem is that the battery junk so I only get a few minutes on a charge.