New motherboard YST-DXT-J20 V4 with "ATERY" AT32F403RCT6

[cloidnerux]

Hello,

I bought a hoverboard mainboard off ebay in order to use this firmware, hover on arrival I realized that this mainboard seems to be newer and different to the ones currently used. It features a "AT32F403RCT6" which seems to be a Chinese STM32F103RCT6 clone with faster clock speed, a M4F core, more peripherals, and more RAM. As far as I could see it, it should be possible to compile the current firmware for the new controller.

Also, it seems to have dedicated gate driver ICs instead of the discrete ones, some of the connectors are different and the layout changed. They also changed the pinout of the SWD connection. I try to reverse engineer the layout as I could not find anything on the internet at the moment.

Does anybody already have any experience with these boards?

[p-h-a-i-l]

Shoutout to @TomTinkering Is that yet another new variant? Or is this similar to your GD F403 board?

[TomTinkering]

That is exactly my board. The AT32F403 chip is (I think) more or less the same as the GD32F403RCT6, which provides a bit more support/documentation. I have made a schematic of the board.

Here are some resources for the GD version of the chip:

• firmware library
• reference manual
• datasheet

And for the AT32F403 chip:

• datasheet
• reference manual
• peripheral library

I have just started working on it, but not much time right now. Pretty sure it will not run the firmware directly, but it should not be too hard to port. I will let you know if I make any progress

[cloidnerux]

The GD32 and the AT32 are not exactly the same devices, they have some differences, however the footprint is quite the same and the schematic matches my board.

I try to compile something for the AT32, hopefully it works.

[TomTinkering]

Hmm, for the artery chip I could only find a chinese datasheet/reference manual. Do you have more information? My chinese is not great :P

[cloidnerux]

Some of the stuff is in English and I use the google translator, otherwise, I am also left to guess. If there is some critical stuff I can ask some Chinese friends of mine if they can translate it for me. From the excerpts, I could understand they have a core which achieves 200MHz operation, the GD32 only achieves 168MHz. I am guessing they are indeed different parts. GigaDevices propably has a serial flash, which is glued on the top of the DIE https://zeptobars.com/en/read/GD32F103CBT6-mcm-serial-flash-Giga-Devices The AT32 might have the flash on the same DIE,

Somewhere on the bottom of this site are the standard lib, the files for their dev board and some other stuff: http://www.arterytek.com/html/product/product_AT32F403.jsp

I expect them to be mostly compatible to the STM32 stuff to allow for easier migration, GigaDevices did the same.

Also I asked on reddit if somebody knows these chips, which brought only little insight: https://old.reddit.com/r/AskElectronics/comments/bs0k3n/someone_heard_of_artery_mcus/ https://old.reddit.com/r/embedded/comments/bs7p1z/xpostsomeone_heard_of_artery_mcus/

[TomTinkering]

Ah that library is great, that will probably answer most of my questions. Thanks, and good luck

[cloidnerux]

The hoverboard hack firmware uses the ST HAL, which isn't provided by Atery. So it is necessary to look through the files and see where there are differences that need to be patched... However it seems that only the "low level" functions should be patched to include the differences between the parts?(Not true)

[TomTinkering]

I would start from the 3ADCs_DMA example, get it running, integrate PWM, UART and GPIO and then take all the non hardware related bits from the hoverboard-hack. I don't think you can reuse much hardware related stuff, or at least, it will be easier to start from scratch, using the STM32F103 source as a reference.

Then based on an #ifdef or maybe something fancy like a chip-ID at runtime, it should not be too hard to merge the two projects back together.

[cloidnerux]

Then based on an #ifdef or maybe something fancy like a chip-ID at runtime, it should not be too hard to merge the two projects back together.

Ok.

I searched a bit for information about the gate driver and it seems to be a copy of the IR2108S

I managed to compile the example code with Keil uVision and upload it with a Segger J-Link, so now I just have to port this to the gcc toolchain

[cloidnerux]

It was a bit frustrating to be able to flash the AT32 with jlink, as there is little to no information about everything. At this point I found out, that I need a flash loader as the flash is not directly wirtable through SWD. So this is some code that is loaded into ram, then the PC is set to the start of the code, it gets executed and it can copy/verify blocks of code that is also within the RAM, crazy stuff.

Luckily everything necessary is within the uVision support package from Atery, so theoretically I have everything to try it.

Software side I could get the Buzzer to work with uVision, so using the timers is no problem. There are tons of examples in the StdLib, which should make it somewhat easy to port the firmware. However a lot of bits and registers are named differently, so there will be some work to make it compatible.

[cloidnerux]

I patched the HAl driver to work with the AT32 and could successfully compile it and upload it. I will test it later today. The code is in my repository https://github.com/cloidnerux/hoverboard-firmware-hack

[TomTinkering]

Thanks for posting all the updates here!

[EFeru]

@cloidnerux Nice work! Few questions: At what frequency do you run the AT32? And is the pinout connections the same as for the STM32 boards? I also ordered the AT32 board. By the way, i made a much beter control for the motors. Maybe you can try and see if you like it. I will make a new commit soon with improvements. You can check it in my repository. https://github.com/EmanuelFeru/hoverboard-firmware-hack

[cloidnerux]

Currently, I set 72 MHz to use the same frequency the STM32F103 code does, in case there is some hardcoded frequency dependent stuff.

The pinout is mostly the same. I use the schematic TomTinkering provided, and it seems that the R_MTR_PHB and R_MTR_PHA are swapped and there are no motor current shunts. Also, the LED is missing or is on one of the auxiliary boards.

I had an error in my hardware definition files so my code did not work yesterday, I fixed it but I have to try it today, so hopefully, everything now works as intended and I can test your changes.

[EFeru]

Ok. I am curious if you run it at higher frequency, if you get better performance for the new BLDC control that I made. Just wait for my commit with latest updates. In approx. 2-3 days should be there. I am doing final calibrations and testing.

If no motor current shunts are there, I wonder how do they do the overcurrent protection?

[cloidnerux]

Currently I try to get it working at all. There are a lot of small details that mess up the port.

Maybe later after everything works I try to increase the freqeuncy, however it only helps so much because there is no reason for the MCU to idle for twice the amount of cycles because the control loops are limited by the motor speed.

I think they just measure the phase current and use this value but I really don't know.

[cloidnerux]

Yes! It works now. I ported the HAL libraries, so I hope it is quite easy to use the same code for both MCUs.

[EFeru]

Nice! Let us know the progress.

[TomTinkering]

The board has a simple circuit that trips an IO pin on overcurrent, but not also an amplifier connected to and ADC like the stm32/older boards

[EFeru]

@cloidnerux The new sinusoidal based BLDC control is committed: https://github.com/EmanuelFeru/hoverboard-firmware-hack

Feel free to give it a try...and tell me if you hear the sound of silence :)

[cloidnerux]

I tried it and it works. The motors weren't terrible noisy before, they are not noisy now. They seem to be faster, that could however also be a different setting in the config.h

The wheels seem to "twitch" however in idle. They seem to move a bit forward and backwards.

[EFeru]

At what frequency do you run the controller? You might need to re-adjust the following calibratable in BLDC_controller_data.c :

Recalculate (based on your frequency in Hz)

cf_speedCoef    = round(f_ctrl * 4 * (pi/180) * (30/pi));     % [-] Speed calculation coefficient (factors are due to conversions rpm <-> rad/s) 4 = MechanicalAngle`

Examples: cf_speedCoef = 11111 for f_ctrl ~= 16000 Hz (default) cf_speedCoef = 5333 for f_ctrl = 8000 Hz and so on.

And you might need some adjustmenst on:

dz_counterHi    = 50;       % [-] Counter gradient High. Above this value the control resets to Commudation method (to deal with the high dynamics)
dz_counterLo    = 20;       % [-] Counter gradient Low. Below this value the control authorizes the Advance method (high dynamics have passed)

Then it should be ok. Does it run well (silent) for higher speeds?

• EDIT: You can measure the DMA interrupt frequency by toggling the LED pin (or another pin) in DMA1_Channel1_IRQHandler() in bldc.c. Then with an oscilloscome measure the time between pulses = Ts_ctrl. Then f_ctrl = 1/Ts_ctrl.

[cloidnerux]

I changed the cf_speedCoef to match the control loop frequency and it worked a bit better. However, after some time of idling it starts to twitching again. Is there some I-loop running wild?

[EFeru]

No, it is all open loop and I do not have any Integral action. Is it possible to make a short movie with the behavior?

[cloidnerux]

No, it is all open loop and I do not have any Integral action. Is it possible to make a short movie with the behavior?

I will make a video as soon as I am able to, unfortunately, this will probably be Tuesday.

[EFeru]

@cloidnerux This is how the motors work for me with the code from my main branch (for reference) https://photos.app.goo.gl/E38ZATYqnf8wf9tE6

And comparison with Commutation method (1st half = commutation; 2nd half = Sinusoidal 3rd harmonic) https://drive.google.com/file/d/1vC_kEkp2LE2lAaMCJcmK4z2m3jrPUoBD/view

[cloidnerux]

Here is a video of the old bldc controller: https://youtu.be/Vn0n6_TUgWo

Here is a video of the new bldc controller: https://youtu.be/eXSLYO_MpYY

Here is a video of the wheels jittering while idle: https://youtu.be/7B-F05YvMEU

I think I saw some jittering with the old controller too, however not that strong. I also think that the wheels spin faster with the new bldc controller. The new controller seems to be a bit less noisy, however, I not that much. It might be due to the gate drivers, that there is less switching noise.

[EFeru]

@cloidnerux First of all, very nice setup! I like it... It's very nice, especially with those offroad wheels ;)

• Regarding the jittering issue. That is most probably from your input. What input mode do you use: Potentiometer, PPM... ? However, the input at 0 is not a perfect 0, so you get small movements. You will not see them when the vehicle is on the ground.

• Solution_1: If you what to minimize them you need to apply more filtering on the input. So, go in config.h and modify #define FILTER 0.1f // lower value == softer filter. do not use values <0.01, you will get float precision issues. Put something like 0.05f. Try different numbers and see which one is better (lower value = less jitter but slower response to input, higher value = more jitter but faster response to input).

• Solution_2: Add a dead band. So, if your -eps<inputRaw<eps, where eps is a small number, then input = 0, else input = inputRaw

Overall, I think it is a good behavior. For me looks improved compared to old method. It does not excite those vibrations (at medium speed) as the old controller does. Currently, I am working on improving even further the dynamic behavior, so stay tuned for an update.

[cloidnerux]

I added a dead band, but it does not help. I don't think it is really a dead band issue, as it only starts after some time stopping. However, it isn't that big of a problem, as it is hardly noticeable during normal operation.

[TomTinkering]

@cloidnerux I finally had some time to work on my own board. Thanks a lot for sharing the port and info on flashing the chip, that saved me a ton of time. Evenything seems to run (interrupt gets executed, buzzer works, I can step through the code), except for the PWM outputs. pwml/r are being set, and the BLCD step returns with values that seem to make sense, but nothing happens on the PWM outputs. I double checked this with a logic analyzer. Have you maybe run into the same problem? Otherwise I will just continue debugging :)