isabellesimova / HoverboardFirmware

50 stars 24 forks source link

ADC reading making board crashing #2

Closed EmerickH closed 6 years ago

EmerickH commented 6 years ago

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:~

sudo minicom -b 9600 -D /dev/ttyS0

image

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

EmerickH commented 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:~ image

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" } }
EmerickH commented 6 years ago

To sum up my problem:

int8_t firstitbutton = 1; [...] /**

// Main.c

int main(void) { [...] button_init();

ifdef NOFIRSTITBUTTON

button_toggle();
#endif
    [...]

}


   - Stay on and not rebooting when in Calibration Mode

@isabellesimova can you help me please?

Thank you
isabellesimova commented 6 years ago

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.

EmerickH commented 6 years ago

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.

EmerickH commented 6 years ago

I tried to compile on System Workbench with your instructions, but:

Thank you

isabellesimova commented 6 years ago

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.

EmerickH commented 6 years ago

Hello,

isabellesimova commented 6 years ago

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.

EmerickH commented 6 years ago

Hello,

Thank you

isabellesimova commented 6 years ago

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.

EmerickH commented 6 years ago

Hello,

ChristianStrobel commented 6 years ago

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.

EmerickH commented 6 years ago

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: image I had to add this: image

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?

ChristianStrobel commented 6 years ago

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: image

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

EmerickH commented 6 years ago

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?~ image

isabellesimova commented 6 years ago

Thanks a ton for the PR @EmerickH - it's been merged! Also thanks to @ChristianStrobel for pinning down the problem :)

EmerickH commented 6 years ago

Hello, Thank you for merging, if I found why read the ADC is crashing the board, I would propose another pull request.

Emerick

isabellesimova commented 6 years ago

That'd be perfect! Thanks!

robo1973 commented 1 year ago

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?