Communicating with sideboard via USART #25

redeemarr · 2022-09-15T10:30:40Z

Hi!
I'd like to use sideboard as UART-driven sensor, i.e. the goal is to read gyro/accelerometer data via UART.
Had some problems flashing the GD chip using ST-link utility, but solved them with st-flash.
Connected sideboard to external power source with 15V and connected it via USB-TTL adapter to PC's USB port (this have worked earlier with main board)
Tried different variants and noticed the following:

4-pin board LEDs (red/green) starts blinking in circle
in VARIANT_HOVERCAR and VARIANT_HOVERBOARD I can see RX blinks on the USB-TTL adapter, so seems like firmware flashed correctly (not sure though)
oscilloscope shows periodical bursts on TX pin of sideboard and they doesn't look like zeroes
when reading serial port to 16 byte buffer, 14 bytes is returned, like sizeof(SerialSideboard)

But values in the buffer are all zeroes.
Again, this setup worked normally when used with gyro's mainboard (sending commands, reading feedback).
I'm out of ideas. Maybe serial setup is different for sideboard?

HANDLE serialHandle = CreateFile("COM4", GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);

DCB serialParams = { 0 };
serialParams.DCBlength = sizeof(serialParams);
GetCommState(serialHandle, &serialParams);
serialParams.BaudRate = CBR_115200;
serialParams.ByteSize = 8;
serialParams.StopBits = ONESTOPBIT;
serialParams.Parity = NOPARITY;
SetCommState(serialHandle, &serialParams);

while (true)
{
	static char buf[16];
	memset(buf, 0xcc, sizeof(buf)); // just to make sure that zeroes comes from serial port
	DWORD bytesRead;
	ReadFile(serialHandle, buf, sizeof(buf), &bytesRead, NULL);

	std::string str;
	for (int i = 0; i < bytesRead; ++i)
	{
		str += format_string("%02x ", buf[i]);
	}

	log_msg("[%u] %s", bytesRead, str.c_str());
}

Candas1 · 2022-09-15T10:58:19Z

Hi,

Have you seen this?
https://github.com/EFeru/hoverboard-firmware-hack-FOC/wiki/Sideboards

redeemarr · 2022-09-15T11:23:07Z

Sure, but I can't see how it may help.

Candas1 · 2022-09-15T11:29:28Z

Not all imu's are supported...

redeemarr · 2022-09-15T11:42:05Z

It's MPU-6050. Nevertheless, where must be at least start codes (0xabcd), but it's all zeroes.
I'm double checking all the communication, but no luck for now

Candas1 · 2022-09-15T11:42:30Z

Have you tried debug variant ?

redeemarr · 2022-09-15T11:43:32Z

Yes, but it's even harder to debug, since the board doesn't send anything at all. And doesn't receive as well.
It seems like board is definitely working, but communication is the problem.

Candas1 · 2022-09-15T11:50:50Z

Weird.
If the leds blink, the program is running for sure.
Can it be you cooked the TX/RX with 5v ? I don't remember if those are 5v tolerant

redeemarr · 2022-09-15T12:13:56Z

Hmmm.. i doubt they are fried. I've never used 5V TTL levels just in case, since one of UARTs of main board isn't 5V tolerant.
Anyway, if they are fried, I should not have seen those 14 zeros, right?
Also, tried to read data on native UART and linux. Strangely it returns zeroes as well o_O
Flashed another board - same story. What the...

Candas1 · 2022-09-15T12:50:35Z

FYI, this should be the frame that is being sent by the sideboard

redeemarr · 2022-09-15T12:52:28Z

Flashed VARIANT_DEBUG. Sent 'h' and got a reply! Strange, it didn't work earlier.
Seems like in other variants the board is waiting for initial packet from main board

redeemarr · 2022-09-15T14:07:41Z

Alas. Now I can send commands and receive replies, but something seems to be wrong:

Command = 8
Accel ON
Gyro OFF
Command = 9
Accel ON
Gyro ON
Command = s
accel: 1598548452 -1078513427 134235703
gyro: -807494 1859635975 699839569
Gyro failed
Accel failed
Compass failed

Sometimes it getting stuck on Command = s and stucks every time on commands like 'a', 'r', 'g', 'q', 'x'.
This may be the answer why it dumps zeros on heartbeat in hoverboard variant.
Looked here, but i'm not sure it's related, since even command 'e' doesn't work.
Btw, it's GD32F130C6T6 + MPU-6050
Tried to disable DMP, nothing changes. Both boards - same results.

Candas1 · 2022-09-16T07:17:19Z

Could be a bad clone of MPU6050

EFeru · 2022-09-16T19:18:33Z

Hi @redeemarr, At least you should be able to read raw accelerometer and gyro data if communication with the MPU is working. DMP is not working on all chips so is more challenging.
Maybe is worth doing also a wiring check of the MPU to the GD chip for your board to be sure the MPU is mapped as the firmware expects. I hope this helps.

redeemarr · 2022-09-17T09:30:27Z

Hi @EFeru!
Checked wiring between GD and MPU, it's ok (SCL->PB6, SDA->PB7)
Tested again on linux with native UART using minicom:

Command = h
=== HELP ===
h: Print Help
x: Print Serial AUX
8: Set Accelerometer on/off
9: Set Gyroscope on/off
r: Print Registers
a: Print Accelerometer
g: Print Gyroscope
q: Print Quaternion
e: Print Euler angles in deg*100
t: Print Temperature in degC*100
p: Print Pedometer
0: Reset Pedometer
1: Set DMP/MPU freq 10 Hz
2: Set DMP/MPU freq 50 Hz
3: Set DMP/MPU freq 100 Hz
,: Set DMP interrupt to gesture
.: Set DMP interrupt to continuous
f: Set DMP on/off
v: Set Quaternion on/off
w: Test low-power accel mode
s: Run self-test (device must be facing up or down)
============
Command = 8
Accel ON
Gyro OFF
Command = 9
Accel OFF
Gyro ON
Command = r
Command = a
Command = g
Command = 1
Command = r
Command = a
Command = g
Command = s
accel: 0 0 0
gyro: 0 0 0
Gyro failed
Accel failed
Compass failed

btw, i've zeroed gyro and accel variables in mpu_start_self_test just in case:

    long gyro[3] = {0};
    long accel[3] = {0};

Looks like GD cannot communicate with MPU. Strange, the hoverboard was fully functional before disassembling.

Candas1 · 2022-09-17T11:11:43Z

Can you try my fork ?
I had started to code a function to check IMU's WHOAMI register.
It wasn't finished but maybe it gives you a hint if this is really a MPU6050.

redeemarr · 2022-09-17T12:11:38Z

@Candas1 yes, thank you.
WHO_AM_I:0x12->ICM-20602
lol wut
This is my board

This is ICM-20602

Candas1 · 2022-09-17T12:35:30Z

Really weird...
Are you supplying the board with enough power ?

redeemarr · 2022-09-17T12:49:29Z

Checked power source, turned current knobs to maximum, nothing changes.
I really hoped, that it'll be the answer, since the power supply has current limiter and occasionally it may have been lowered.
The only assumption I can make is custom firmware in mpu-6050 body.

Candas1 · 2022-09-18T08:28:21Z

If there is really an ICM-20602 inside, it's means there is no DMP for angle calculation.
But raw accelerometer/gyroscope data should be accessible.

I will check if I have any sideboard with ICM-20602 IMU, and if it behaves the same.

redeemarr · 2022-09-18T10:35:52Z

I'd check whether i2c is functional, but i have no idea how to do this lol.
Maybe somehow modify firmware to log i2c activity? (where? how?) or maybe connect an oscillicsope to SCL/SDA (what should i see?)
It's more way easier to buy a cheap and working gyro module, but getting this board to work is interesting and challenging.
I've also found out that board doesn't react to optical sensors. Really weird

redeemarr · 2022-09-19T17:38:53Z

Next chapter of this bloody mess.
Got one different sideboard (black one on photo) with GD32F and MPU-6050A. Flashed it and...

WHO_AM_I:0x12->ICM-20602
accel: 134229919 18 0
gyro: 536870924 536871353 134247897
Gyro failed
Accel failed
Compass failed

Magic!

Also this board has very weird pinout. Here it is, just in case if anyone stumbled on the same. But as always, better doublecheck.

Candas1 · 2022-09-19T17:53:55Z

Hmmm there is something weird with my code, it shouldn't say 0x12 for this chip.
But I tried it with multiple boards yesterday, it was working fine.

On those MPU6050A DMP won't work, so you can read raw accelerometer an gyroscope data, but not the angles.

redeemarr · 2022-09-19T17:57:19Z

I bet your code is ok, something is wrong on my side - maybe flashing process, maybe power source. I'll investigate further.
Btw, all three boards are flashed with st-flash, since ST-Link utility doesn't work with them.

Candas1 · 2022-09-19T18:00:04Z

I did my tests by just powering the board with 3.3v via the stlink, and it was ok.
I keep the leds on the 4 pin connector to make sure it works correctly.

redeemarr · 2022-09-19T18:05:35Z

I did my tests by just powering the board with 3.3v via the stlink, and it was ok. I keep the leds on the 4 pin connector to make sure it works correctly.

How did you read back data on UART? I'm wondering is it safe to connect both stlink and usb-ttl adapter to pc simultaneously.
Just in case :)

Candas1 · 2022-09-19T18:31:07Z

Never had a problem with that. USB-TTL is set to 3.3v, only connecting TX/RX/GND.

redeemarr · 2022-09-19T20:17:00Z

Sigh.. powered the board with stlink (3.3v) - no changes.
I've earlier encountered problems flashing this GDs with stlink utility and used stflash at last. But stlink can read chip after that, comparison of ROM to firmware file is ok and board is blinking LEDs, so I'm almost sure flashing is ok.

st-flash usage (maybe i'm doing smth wrong):

.\st-flash.exe erase
.\st-flash.exe --reset write .\firmware.bin 0x8000000

Also tried to flash with pio:

xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2021-10-16-21:19)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

hla_swd
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08005a94 msp: 0x20001000
** Programming Started **
Error: failed to get read pointer
Error: timed out while waiting for target halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0x08001366 msp: 0x20000fe0
Error: error waiting for target flash write algorithm
Error: error writing to flash at address 0x08000000 at offset 0x00000000
embedded:startup.tcl:1070: Error: ** Programming Failed **
in procedure 'program' 
in procedure 'program_error' called at file "embedded:startup.tcl", line 1135
at file "embedded:startup.tcl", line 1070
*** [upload] Error 1```

Candas1 · 2022-09-20T06:55:34Z

Maybe try disabling the DMP in config.h

redeemarr · 2022-09-20T07:38:16Z

Disabled DMP, no changes. It was obvious, since WHOAMI still gives ICM-20602.
I'll try to find STM MCU and try to replace GD, but it'll take time.

Candas1 · 2022-09-20T10:07:25Z

I simplified my WHOAMI code, but it should work the same
That's what I get with a MPU6050a

If I disable the DMP, I can read Accelerometer and gyroscope data

redeemarr · 2022-09-20T10:29:06Z

Pulled, disabled DMP, flashed, same result. I'm pretty sure something wrong happens in flashing process. Probably those GS chips are fake ones and the firmware doesn't flash fully. I'll try to find another MCUs for replacement and other boards to test.

Candas1 · 2022-09-20T11:22:09Z

I am flashing from platformio, which is set up to use a particular toolchain package/version.
It seems to be failing from pio in your case ?
Make sure you have all available option bytes checked
https://www.youtube.com/watch?v=Ow7Ydd3a66c

redeemarr · 2022-09-20T12:22:33Z

Thank you, finally, some progress!
I was able to flash with platformio after setting option bytes like in this video.
Now the board reacts to commands like 'a' and 'g' and print raw values from gyro and accel. But they won't change when i turn or shake the board. Tried to enable/disable accel/gyro with '8'/'9' commands.
Also WHOAMI is still 0x12.
Another difference is that board is blinking LEDs only on startup, then only greed LEDs stays (guess that's how it should be earlier).
Also both black and green boards started to react on optical sensors.

Command = g
gyrX:-4 gyrY:15 gyrZ:1
gyrX:-4 gyrY:15 gyrZ:1
gyrX:-4 gyrY:15 gyrZ:1

Command = a
accX:-346 accY:488 accZ:15560
accX:-346 accY:488 accZ:15560
accX:-346 accY:488 accZ:15560
accX:-346 accY:488 accZ:15560

Candas1 · 2022-09-20T12:24:47Z

What if you disable DMP in config.h now ?

redeemarr · 2022-09-20T12:28:00Z

It was disabled already. Hmmm.. I can try to enable it for green boards.

Candas1 · 2022-09-20T12:32:24Z

In my case, when I disable the DMP with a MPU6050A, I can see values and it's moving.
With the DMP, the values are all 0 and not moving.

It's weird that see non zero values and it's not moving

redeemarr · 2022-09-20T12:39:55Z

At last!
Flashed the green one (with MP-6050) with enabled MPU and it works!

Command = g
gyrX:-55 gyrY:13 gyrZ:-1
gyrX:-33 gyrY:13 gyrZ:-3
gyrX:-14 gyrY:14 gyrZ:-1
gyrX:-53 gyrY:13 gyrZ:-2
gyrX:42 gyrY:13 gyrZ:1
gyrX:60 gyrY:13 gyrZ:1
gyrX:255 gyrY:11 gyrZ:214
gyrX:1669 gyrY:-52 gyrZ:35
gyrX:2452 gyrY:-82 gyrZ:-490
gyrX:3064 gyrY:-589 gyrZ:-476
gyrX:2407 gyrY:-251 gyrZ:-234
gyrX:2374 gyrY:-144 gyrZ:-419
gyrX:1594 gyrY:-128 gyrZ:-167
gyrX:1196 gyrY:-224 gyrZ:-159

So the problem was in flashing process (correct setup of option bytes). Should I close this issue now?
It'd be nice to add to the wiki notes about setting option bytes.
Also, I'll investigate the black board and gather some extra info if it could be useful.

Candas1 · 2022-09-20T13:07:33Z

Ah great, but is it still returning 0x12 as WHOAMI ?

It's already in the wiki lol
The readme points to this page
This is valid for mainboards and sideboards as well

I think it can be closed, you can open a new issue if you have inputs about different boards/IMUs

I'll update this page if needed

redeemarr · 2022-09-20T13:37:32Z

is it still returning 0x12 as WHOAMI ?

Yep, it does. Strange.

It's already in the wiki lol

Step 6 describes how to disable read protection, but nRST_STOP, nRST_STDBY and WDG_SW are not set. Seems like that was essential. Also i've set up user data storage option bytes to 0xFF.
I used wiki when flashed mainboard (with STM) and this worked, but not in GD case.

Edit: ah, nevermind, my bad, I missed this:
Step 2: Unlock the GD32 as described above, however at Step 6, check all the boxes for User configuration option bytes

Candas1 · 2022-09-20T13:40:04Z

OK I think this was discovered later with GD32 chips, it's mentioned in the troubleshooting only
this screenshot is old, it would be worth replacing it

redeemarr closed this as completed Sep 15, 2022

redeemarr reopened this Sep 15, 2022

redeemarr closed this as completed Sep 20, 2022

redeemarr mentioned this issue Nov 16, 2022

Different SWD Programming Pins #9

Open

Communicating with sideboard via USART #25

Communicating with sideboard via USART #25

Comments

redeemarr commented Sep 15, 2022 • edited Loading

Candas1 commented Sep 15, 2022

redeemarr commented Sep 15, 2022

Candas1 commented Sep 15, 2022

redeemarr commented Sep 15, 2022

Candas1 commented Sep 15, 2022

redeemarr commented Sep 15, 2022 • edited Loading

Candas1 commented Sep 15, 2022

redeemarr commented Sep 15, 2022 • edited Loading

Candas1 commented Sep 15, 2022

redeemarr commented Sep 15, 2022 • edited Loading

redeemarr commented Sep 15, 2022 • edited Loading

Candas1 commented Sep 16, 2022

EFeru commented Sep 16, 2022

redeemarr commented Sep 17, 2022

Candas1 commented Sep 17, 2022

redeemarr commented Sep 17, 2022 • edited Loading

Candas1 commented Sep 17, 2022

redeemarr commented Sep 17, 2022 • edited Loading

Candas1 commented Sep 18, 2022

redeemarr commented Sep 18, 2022 • edited Loading

redeemarr commented Sep 19, 2022 • edited Loading

Candas1 commented Sep 19, 2022

redeemarr commented Sep 19, 2022 • edited Loading

Candas1 commented Sep 19, 2022

redeemarr commented Sep 19, 2022

Candas1 commented Sep 19, 2022

redeemarr commented Sep 19, 2022 • edited Loading

Candas1 commented Sep 20, 2022

redeemarr commented Sep 20, 2022

Candas1 commented Sep 20, 2022

redeemarr commented Sep 20, 2022 • edited Loading

Candas1 commented Sep 20, 2022

redeemarr commented Sep 20, 2022

Candas1 commented Sep 20, 2022

redeemarr commented Sep 20, 2022

Candas1 commented Sep 20, 2022

redeemarr commented Sep 20, 2022 • edited Loading

Candas1 commented Sep 20, 2022

redeemarr commented Sep 20, 2022 • edited Loading

Candas1 commented Sep 20, 2022

redeemarr commented Sep 15, 2022 •

edited

Loading

redeemarr commented Sep 15, 2022 •

edited

Loading

redeemarr commented Sep 15, 2022 •

edited

Loading

redeemarr commented Sep 15, 2022 •

edited

Loading

redeemarr commented Sep 15, 2022 •

edited

Loading

redeemarr commented Sep 17, 2022 •

edited

Loading

redeemarr commented Sep 17, 2022 •

edited

Loading

redeemarr commented Sep 18, 2022 •

edited

Loading

redeemarr commented Sep 19, 2022 •

edited

Loading

redeemarr commented Sep 19, 2022 •

edited

Loading

redeemarr commented Sep 19, 2022 •

edited

Loading

redeemarr commented Sep 20, 2022 •

edited

Loading

redeemarr commented Sep 20, 2022 •

edited

Loading

redeemarr commented Sep 20, 2022 •

edited

Loading