hoverboard-firmware-hack
hoverboard-firmware-hack copied to clipboard
cloidnerux
Artery AT32F413RCT7 on "YST-DXT-J20 V5.1"
I bought a controller from Aliexpress in the 'classic' form factor (https://www.aliexpress.com/item/33003742445.html), with an Artery AT32F413RCT7 on the mainboard, and two sensor boards, one of which only seems to carry the optical switches but no angle sensor. Board prints: "YST-DXT-J20 V5.1", "YST-TLY-J20 V3", "YST-TLY-BT-J20 V1". It looks quite similar to the "V4" one featured in this repository.
This may be the most hackable control board I have, the others are split-mainboard ones with GD32F130C8T6 (TaoTao TT-SD2.2) and MM32SPIN05PF (YST, no version).
MCU comparison:
It seems the AT32F413 seems to be an economy version with less peripherals. Unfortunately, I was only able to find datasheets in Chinese which I can't read.
AT32F403RCT6, ARM® Cortex®-M4, LQFP64, 256 kB Flash http://www.arterytek.com/html/product/product_AT32F403.jsp http://www.arterytek.com/download/DS_AT32F403_V1.05.pdf
AT32F413RCT7, ARM® Cortex®-M4, LQFP64, 256 kB Flash http://www.arterytek.com/html/product/product_AT32F413.jsp http://www.arterytek.com/download/DS_AT32F413_V1.04.pdf
Here's another fork for AT32F403: https://github.com/sjamthe/hoverboard-firmware-hack
They keep making it cheaper it seems. I could not get too much info out of the datasheet either, but they are quite comparable to the STM32 datasheets, so one can infer some information.
For the F413 there is also the STD lib available, so it is possible to adapt the firmware to it as I did for the F403.
Also bought some on aliexpress, which turned out to be the F413. Unfortunately I am failing to flash this version. Would appreciate a working firmware for them.
Unfortunatly I don't have such a board available, so it is upon someone else to port it. Honestly it should not be that hard, as one can follow my guide on how to port it.
I also have a board with the AT32F413RCT7, might try to adapt the firmware to this chip in the next days, but I never used an stm32 based device before, so it probably will be a total mess.
@cloidnerux can you give me a hint at which files I should look at first to get started?
These are the differences between the two MCUs I found so far:
Specs
| MCU | Freq (MHz) | Flash(KB) | SRAM(KB) | I/O | Advanced TM(16bit) | GPTM(32bit) | GPTM(16bit) | Basic TM(16bit) | Systick(24bit) | IWDG | WWDG | RTC | I2C | SPI | I2S | USART/UART | SDIO | USB Device | CAN | ADC engine | 12bit ADC channel | DAC engine | 12bit DAC channel | XMC | SPIM | Package |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| AT32F413RCT7 | 200 | 256 | 32/16/64 | 55 | 2 | 2 | 5 | 0 | 1 | 1 | 1 | 1 | 2 | 2 | 2 | 3+2 | 1 | 1 | 2 | 2 | 16 | 0 | 0 | 0 | 1 | LQFP64 |
| AT32F403RCT6 | 200 | 256 | 96/224 | 51 | 2 | 2 | 8 | 2 | 1 | 1 | 1 | 1 | 3 | 3 | 3 | 3+2 | 2 | 1 | 1 | 3 | 16 | 2 | 2 | 0 | 1 | LQFP64 |
Pinout
| Pin number | AT32F413RCT7 | AT32F403RTC6 | Difference | Functions |
|---|---|---|---|---|
| 64 | VDD | VDD_3 | Name changed | |
| 63 | VSS | VSS_3 | Name changed | |
| 48 | PF7 | VDD_2 | I/O Pin instead of Voltage | I2C1_SCL/I2C2_SCL |
| 47 | PF6 | VSS_2 | I/O Pin instead of Voltage | I2C1_SDA/I2C2_SDA |
| 32 | VDD | VDD_1 | Name changed | |
| 31 | VSS | VSS_1 | Name changed | |
| 19 | PF5 | VDD_4 | I/O Pin instead of Voltage | UART4_RX/TMR5_CH2 |
| 18 | PF4 | VSS_4 | I/O Pin instead of Voltage | UART4_TX/TMR5_CH1 |
Main differences in the new mainboard version
- Less SRAM (64KB instead of 224KB)
- 4 new I/O pins (probably not accesable on the mainboard)
- Less 16bit Timers
- Less I2C, SPI, I2S (2 instead of 3)
- only one SDIO
- one more CAN (probably not accesable on the mainboard)
- lost one ADC engine (2 left)
- completely lost DAC functionality
@HayWo Get the SDK from Atery and check if the register definitions are the same(Drivers\CMSIS\CM4\DeviceSupport\at32f4xx.h), it's a bit tedious but important. The flash section might be different from the AT32F403 and it is definitely different from the STM32. Next is to check if the peripherals are at the same pins, which I expect is the case. Then you should check the startup script and the system_at32f4xx.c code and see if they match up. If everything is ok you might be just able to compile it and it should work.
Hey, you may want to check out this repository; https://github.com/someone42/hoverboard-firmware-hack it seems to handle AT32F413RCT7.
@thanek thank you. It's at least working in ADC Mode, but starting from that point it's definitely easier to implement the other modes.
Yeah, I tried the motor test option (which is fixed in this repo) and it worked fine, and so is the ADC (tested on only one potentiometer). In commits history I've noticed that @someone24 did some work with PWM, but I failed to use it (I don't event know how to wire the things up). I would like to connect this board to rPI/Arduino, so I keep studying the code to figure out how to do it (I'm a noob in MCU's world). BTW; don't be surprised as the buzzer is turned OFF by default in this config ;)
I tried to get the UART control working, but failed. It seems like @someone24 has not adapted it for the at32f413 yet. The PWM control uses the pins PC13 and PC14, but I couldn't figure out how the PWM signal should look like to get usefull controll of the motors. Also calibrating the ADCs is hard, as they use the same pins as UART2 and UART3 is not working. I created a more improved ADC control option which let's you use a joystick and move in any direction, it can be found here: https://github.com/HayWo/hoverboard-firmware-hack
Hej @HayWo, I've just uploaded your firmware and wired up with Arduino UNO as you said (PC13 for channel1, PC14 for channel2 and GND) and it worked. It needs some calibration (arduino uses value 0-254 for PWM), because it seems like "center" value (making motors stop) is about 190, then values 195-235 makes motor to turn forward (the higher value the higher speed) and changing it to 140-180 makes them to turn backward (higher value - lower speed). So I guess those values should be somehow mapped to -1000 - +1000 used by the firmware.
I've added some simple serial communication for UART and it seems to work quite OK. It's available in my repo: https://github.com/thanek/hoverboard-firmware-hack
Hi to all, i'm not able to remove rdp protection of at32f413rct7 on e new board.
I try with openocd 0.11 and 0.12 and i modify the file src/flash/nor/stm32f1x.c before make and install openocd, adding the case 0x240, like @sameone42 write but nothing...
i try with different command: openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c init -c "reset halt" -c "stm32f1x unlock 0" , changing f0x f1x, f2x, f3x in the target and in the unlock 0 after changing _CPUTAPID in /usr/local/share/openocd/scripts/target/stm32f0/1/2/3x.cfg like in
to avoid UNEXPECTED idcode but afther i have cannot identify targhet
Can sameone help me?...what i can try? what i'm doing wrong...
Thanks in andvance
what i see that is strange for me is Cortex-M0...i think depend on cputapid but will not have to see Cortex-M4? Any suggestion @someone42 ?
potentiometer
I've added some simple serial communication for UART and it seems to work quite OK. It's available in my repo: https://github.com/thanek/hoverboard-firmware-hack
Hey @thanek, I'm trying to utilize your repo, and it appears to be working when I use CONTROL_MOTOR_TEST, but nothing happens when I use the hoverboard serial example from @someone24. Do you have any ideas on how I might solve this problem?
Hi, if someone is still interested, ArteryTek have a fork of openocd that supports their chips - https://github.com/ArteryTek/openocd. I have compiled the openocd and then using it successfully removed the protection and flashed the AT32F413RCT7 via ST-Link v2 dongle.
