Closed EmerickH closed 6 years ago
I've tested TX pin of the hoverboard with an osciloscope, the voltage is about 0v with some very little fluctuations when the button is not pressed and constant -10V when pressed!
EDIT: Tested with a multimeter, Red wire = GND! I'm going to retry changing this (with an isolator for security)
EDIT2: The RX an TX seems to be inverted too but now have have no output...
~EDIT3: I can see now a beautifull signal with osciloscope but at only 50mV!~
EDIT4: I flashed your hoverboard.bin and now I have a 3.3v constant signal! I also have the red LED turning on on the board but when I press the power button, I turns on for ~1s then it stops or if I don't release the button I have a little click every second with serial going to 0v... (maybe heartbeat missing?)
EDIT5: I tested my serial port with an Arduino and it is working fine, ~I can't get it working with my own firmware, but I see that the start header is not the same:~ I recompiled the firmware on Windows and it's now working. ~My firmware vs yours:~
EDIT6: I installed hoverbot interface and your hoverboard.bin, ~but it's not working, I can only hear a litlle double click in the buzzer when sending a command~ the motors are turning on when I hold arrows !!!!! But they are randomly stopping and restarting and I need to hold the start button pressed to keep the board on. The calibration mode is working well (I don't need to keep the button pressed and a receive motors calib values). ~I also have a lot of~
{ "parsing": { "statusBit": 0, "code": 0, "success": "Good parsing", "failure": "Bad parsing" }, "speed": { "statusBit": 1, "code": 0, "success": "Speed in bounds", "failure": "Speed out of bounds" }, "heartbeat": { "statusBit": 2, "code": 0, "success": "Heartbeat ok", "failure": "Heartbeat missing" }, "power": { "statusBit": 3, "code": 0, "success": "Power ok", "failure": "Max power reached" }, "battery": { "statusBit": 4, "code": 0, "voltage": 27, "success": "Battery ok", "failure": "Low battery" }, "charging": { "statusBit": 5, "code": 0, "success": "Not charging", "failure": "Is charging" } }
To sum up my problem:
// stm32f1xx_it.c
int8_t firstitbutton = 1; [...] /**
if (firstitbutton == 1)
{
firstitbutton = 0;
}else{
button_toggle();
__HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_1);
}
button_toggle();
__HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_1);
buzzer_short_beep();
}
// Main.c
int main(void) { [...] button_init();
button_toggle();
#endif
[...]
}
- Stay on and not rebooting when in Calibration Mode
@isabellesimova can you help me please?
Thank you
Glad to hear you got the button working. Occasionally when I was working, it would also have power problems where it wouldn't stay on unless I held on to it, but just recompiling the code and reflashing it would fix it. I'll see if I can chase this down exactly why this is and push a fix!
As for the rebooting - it is probably caused by the watchdog, initialized here: https://github.com/isabellesimova/HoverboardFirmware/blob/1c9ca92496af10f17d3333445a68e572443b211d/src/main.c#L47 This means that it throws an error before hitting the refresh line: https://github.com/isabellesimova/HoverboardFirmware/blob/1c9ca92496af10f17d3333445a68e572443b211d/src/main.c#L91
If you can isolate where in the code it's crashing by adding debugging methods, I might be able to give you better pointers. Alternatively, if you set up a debugging tool, it'll usually tell you which method / line your code crashes. I've written up a setup guide for system workbench, which is what I use.
Hello, I added a beep after the Refresh and I can hear it...
while (1) {
[...]
HAL_IWDG_Refresh(&hiwdg); //819mS
#ifdef BUZZER_START_DEBUG
buzzer_one_beep();
#endif
}
I'm going to try to setup debuging.
I tried to compile on System Workbench with your instructions, but:
make
manually~
~(maybe wrong gcc version?)~Thank you
Oh yes, let me include the GNU C part into the setup guide.
For System Workbench, you can add breakpoints (up to 6 I believe) and run your code with breakpoints. This can help you see where things go wrong, or for you to see what different values are at that point in the code.
One thing you can do is to comment out the watchdog (both the init and refresh statements), let it run for a bit and pause it. Then it'll show you the stack trace of where it's at and you'll be able to figure out where the program crashes.
Hello,
Hmm, what do you mean when you say the compiled firmware is not working? Are you able to start debugging? To do so, you click on Run > Debug. Then, viewing it in debug mode (the bug in the top right corner should be selected), you should be able to pause it and see what the program is running / where it's crashing.
Hello,
To make symbols resolving working, this is the only solution I found on Stackoverflow:
I'm able to run debug without any problem
The LED is not turning on on the board and I can't hear any sound from the buzzer
When I pause debug,
Thank you
Hmm, that's weird. So it seems like the symbols aren't being put into the elf file. Could you check Properties > C/C++ Build > Settings > Tool Settings > MCU GCC Compiler? Under Optimization, it should be "None (-O0)" and under Debugging I have "Maximum (-g3)". Without these flags, you won't be able to see any of the symbols when you look at the stack frame when you pause it. Otherwise, I'm not too sure what's happening.
As for the reset pin, I recommend connecting the RST signal to your debugger - I was also having a lot of issues prior to soldering a wire to the RST pin.
Hello,
reset_config none
)
Open On-Chip Debugger 0.10.0-dev-00010-g96aab7b (2018-07-13-06:51)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter_nsrst_delay: 100
adapter speed: 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v29 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : vid/pid are not identical: 0x0483/0x374B 0x0483/0x3748
Info : using stlink api v2
Info : Target voltage: 3.512770
Info : Stlink adapter speed set to 950 kHz
Info : STM32F103RCTx.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : Stlink adapter speed set to 950 kHz
adapter speed: 950 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xb9337822 msp: 0x4c05b510
Info : Stlink adapter speed set to 4000 kHz
adapter speed: 4000 kHz
Info : device id = 0x13090414
Info : flash size = 256kbytes
Info : Stlink adapter speed set to 950 kHz
adapter speed: 950 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xb9337822 msp: 0x4c05b510
Info : Stlink adapter speed set to 4000 kHz
adapter speed: 4000 kHz
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x4c05b510
Info : Stlink adapter speed set to 950 kHz
adapter speed: 950 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xb9337822 msp: 0x4c05b510
Hello, first of all: very nice project thanks for putting all the information together so nicely @isabellesimova
I can confirm the issue reported here on a GD32F103 RE T6 Controller. Status currently is: -Compilation and flashing works ( i have been able to unlock the GD as described here https://github.com/NiklasFauth/hoverboard-firmware-hack )
@EmerickH as for the "No Source available" problem, i had similar issues at the beginning and resolved them. To check if you have the same problem as i had before, please
For me compilation appeared okay on a first glance, but linking was not okay because i had misplaced the startup file in the root directory and therefore it did not get build and of course linking did not work.
Make sure the startup_stm32f103xe.s is in the /startup/ folder not in the root, then clean, rebuild, and check the output.map file again. It now should contain valid addresses and debugging should work.
I will try to make some progress with the serial interface today and keep you updated.
Thank you very much @ChristianStrobel !!
I just noticed that I included stm32f103rctx_flash.ld
instead of startup_stm32f103xe.s
....
http://www.hellspark.com/cgi-bin/facepalm.pl
I had a compilation error: I had to add this:
And now I can pause and see the source!!! It seems to be blocked at line 632: https://github.com/isabellesimova/HoverboardFirmware/blob/1c9ca92496af10f17d3333445a68e572443b211d/src/motor.c#L627-L633
Maybe a timer with a different name on GD32?
OK i got it fully running now, controllable via HTerm when sending the Motor Request via HTerm in Autosend Mode (0,1s update interval).
Seems that there are some code adaptions required for the GD32 family regarding periphery and possibly clock... This code was intended for the STM32 so maybe we can collect all differences somewhere else instead of abusing this issue.
Regarding the original issue (Garbage Serial Data): With #CALIBRATION enabled, i can reliably receive valid data on Windows via HTerm (http://www.der-hammer.info/terminal/) only if i change the baudrate to 9800 (instead of 9600). Maybe the GD32 Board uses a different crystal or expects different configurations for the baudrate generation, not sure yet why exactly this happens, but it seems that the baudrate is just slightly off. So far so good.
Now when disabling #CALIBRATION the code in main first starts up fine and runs until the time tick is > TX_WAIT_PERIOD. The call to transmit_data() takes too long and the watchdog hits. Some debugging shows that transmit_data() reads out GET_BATTERY_VOLT, which calls ADC_BATTERY() which recursively calls itself until valid data is read. Seems that the GD32 Board/CPU is not happy with the ADC method (via DMA), so i just modified the GET_BATTERY_VOLT function to always return 36V
float GET_BATTERY_VOLT(void) {
//fixed point, everything * 16
/*
battery_voltage -= battery_voltage / ROLLING_SAMPLES;
battery_voltage += ADC_BATTERY();
return (float) (battery_voltage / ROLLING_SAMPLES) * ADC_BATTERY_VOLT;
*/
return 36.0; //Fake Voltage
}
A similar ADC related issue seems to applly for the GET_MOTOR_AMP function. To disable ADC measuring for a quick test just rename #DEBUG to #DEBUG_CURRENT:
commenting out #DEBUG in config.h is of no use in this case because #DEBUG is automatically added by system workbench for the "Debug" build configuration
I confirm that @ChristianStrobel fix is working, we just have to know why theses ADC are not working...
It also solved power problem!
Thank you
~EDIT: I have a missing heartbeat when the motors are stopped, is it normal?~
Thanks a ton for the PR @EmerickH - it's been merged! Also thanks to @ChristianStrobel for pinning down the problem :)
Hello, Thank you for merging, if I found why read the ADC is crashing the board, I would propose another pull request.
Emerick
That'd be perfect! Thanks!
Hi I uploaded the software to the board https://github.com/isabellesimova/HoverboardFirmware I can't turn on I press the start button and the board turns on for 1 s How to fix it >? After compilation, I have a problem with the function HAL_IWDG_Start(&hiwdg); What function to replace it with?
EDIT: I made a lot of modifications on this issue, please see https://github.com/isabellesimova/HoverboardFirmware/issues/2#issuecomment-408867614
A temporary fix is available on #3 thanks to https://github.com/isabellesimova/HoverboardFirmware/issues/2#issuecomment-410233611
Hello, I'm trying to install this firmware on my hoverboard to create a robot. The firmware is downloading well (with CALIBRATION enabled) on the STM32 ~but when I try to access serial, I can only see strange characters with minicom at 9600 bauds, like if there was a wrong baudrate:~
I can hear little clicks in the buzzer about 2~3 times/second and when I keep the power button pressed I can hear capacitors charging then nothing...
Any idea of what's wrong?
Thank you