serial RX failing on GD32 ?

[RoboDurden]

In my case data was sent every 10ms, that could lead to the issue. Unfortunately I had to travel abroad this morning so I can't test next few days.

@Candas1 i can even send from ESP to GD every 5 ms and everything gets returned. But the GD_rx buffer size seems to be 64 bytes because when i check for incoming data only every 100ms then only 63 bytes get returned:

The ESP-tx packets every 5ms are a counter 1375_ then the millis() of the ESP32 109316 The GD-tx sent every 100ms is the millis() of the GD32 GD32: 689300

1375_109316 1376_109321 1377_109326 1378_109331 1379_109336 1380_109341 1381_109346 1382_109351 1383_109356 1384_109361 1385_109366 1386_109371 1387_109376 1388_109381 1389_109386 1390_109391 1391_109396 1392_109401 1393_109406 1394_109411 
GD32: 689300    
1395_109416 1396_109421 1397_109426 1398_109431 1399_109436 1400_109441 1401_109446 1402_109451 1403_109456 1404_109461 1405_109466 1406_109471 1407_109476 1408_109481 1409_109486 1410_109491 1411_109496 1412_109501 1413_109506 1414_109511 
GD32: 689400    
1415_109516 1416_109521 1417_109526 1418_109531 1419_109536 1420_109541 1421_109546 1422_109551 1423_109556 1424_109561 1425_109566 1426_109571 1427_109576 1428_109581 1429_109586 1430_109591 1431_109596 1432_109601 1433_109606 1434_109611 
GD32: 689500    

So all 20 packets every 100ms (= 200 Hz) get received and sent back :-) If i however only read the rx buffer every 100ms, then only 63 chars get sent back:

18543_93530 18544_93535 18545_93540 18546_93545 18547_93550 185
GD32: 12700 
18563_93630 18564_93635 18565_93640 18566_93645 18567_93650 185
GD32: 12800 
18583_93730 18584_93735 18585_93740 18586_93745 18587_93750 185
GD32: 12900 

i let an ESP 32 S2 mini sent serial Data to a GD32F130C6 split hoverboard to test if RX of the GD32-Arduino-Core is not working properly. I used my https://github.com/RoboDurden/Split_Hoverboard_SimpleFOC/blob/main/src/main.cpp#L154 which is based on your Sideboard-Arduino and which sends bldc data to ESP every 100ms and returns all incoming RX back to ESP.

I can not confirm that RX fails with the GD32-Arduino-Core :-/ And if your loop() is not blocked for too long, your Hoverserial::receive() empties the rx buffer :-)

In your Sideboard use case, the rx data would be realtime hoverboard data. Sending these at 10ms would mean 100 Hz data refresh rate - only needed for some closed loop control of speed or torque. I personally think that any realtime closed loop should be in the hoverboard firmware and NOT in the Sideboard controller. 100ms refresh rate = 10 Hz should be sufficient for any use case ?

Greetings from Germany, Roland and :-)

[Candas1]

It's not about where this loop should be. This code works on arduino-stm32 and worked on gd32 with the spl code, but fails on arduino-gd32.

So it helps check if there is any issue in arduino-gd32.

It was happening with my setup so I will check if the recent arduino-gd32 fixed this issue when I am back home next week.

[Candas1]

But thanks for your help with this. It could also be a specific to my setup.

[RoboDurden]

Yes sorry, i fear that for you reading my words means more trouble and i better stay silent. I now only send data from ESP32 to Gen2_D32F130C6, and not sending data from Gen1 to sideboard_GD32F130C6 Next step would be to send your SerialFeedback struct from ESP32 and then test your receive function with your original Sidebaord-Arduino on a Gen2_GD32F130C6 In the end i might built myself another sideboard_GD32F130C6 test-setup and test ESP32<->sideboard_GD32F130C6 Tell me when this might help you.

[Candas1]

Please don't get me wrong. All tests we can do will result in fixes in the firmware/libraries/framework that less experienced users won't face later.

So your help is really appreciated. For me the next step after that is to test i2c also, it will be very useful with the i2ccommander

[RoboDurden]

Yes i like the i2ccommander too. I have some experience with using arduino i2c just like uart serial. So will be happy to add some i2c-slave test code to the GD-Arduino

[Candas1]

Yes i like the i2ccommander too. I have some experience with using arduino i2c just like uart serial. So will be happy to add some i2c-slave test code to the GD-Arduino

That would be great. I have zero experience with i2c outside using IMUs

[robcazzaro]

Adding a link to https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/issues/11#issuecomment-1584842216 for me to jog my memory once I get the GD32 boards and can start testing on real hardware. This way we track all Serial port issues (initialization, reliability) in one issue

[Candas1]

Hi guys,

I finally came back yesterday. With the recent fixes, I could receive data with uart for 30 minutes without an issue, so it's fixed for me.

[RoboDurden]

Nice to hear from you :-) I am a little disappointed that the driver port from you and @robcazzaro https://github.com/Candas1/Arduino-FOC/blob/master/src/drivers/hardware_specific/gd32/gd32_mcu.cpp hast not publicly making progress any more. Please inform me when it would be better for me to continue..

[robcazzaro]

@Candas1 probably this was a clock issue. Having a chip overclocked by 50% can cause problems to anything with a strict timing like the serial port.

As an update, my boards have gone past US customs and are in the hands of the local delivery network in California, on their way to Seattle

[Candas1]

@Candas1 probably this was a clock issue. Having a chip overclocked by 50% can cause problems to anything with a strict timing like the serial port.

As an update, my boards have gone past US customs and are in the hands of the local delivery network in California, on their way to Seattle

In any case, it looks more robust now. I am closing this issue.