hoverboard-firmware-hack
hoverboard-firmware-hack copied to clipboard
endless beep on start
Hi,wondering what i have done wrong. manage to compile with no issues. flashed the firmware and when boot, i just get a "endless loop" of beep.
wondering what i have done wrong? or anyone else experience the same issue?
Just out of curiosity, what is your compiler version?
/usr/local/bin/arm-none-eabi-gcc --version arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q3-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
@LeoDJ wondering if its my compiling issue. can you share with me a hover.bin that you have compiled? then i can test if its my "flashing" problem or the "board" problem?
i did try other "https://github.com/isabellesimova/HoverboardFirmware/blob/master/README.md" and able to compile and run it. However for the project i am doing, i need to capability of driving it like a "Transpotter" please help?
@zkong-gsma I am pretty sure the beep is indicating that you don't have sufficient voltage supplied to the mainboard (above 36V). Check your voltage and try it again.
I thought so as well, then i went back into main.c and globally set
} else { // do not beep
buzzerFreq = 0;
buzzerPattern = 0;
to force it not beep, and yet it still beep.
Anyone willing to share with me their compiled "bin" file please? just to test and prove a point?
what about https://github.com/NiklasFauth/hoverboard-firmware-hack/blob/master/build/hover.hex?
I have the same issue and the above hex does exactly the same...
Is it constantly the same frequency of beeping, or is it a loop of ascending notes?
A constant tone never changes
I think this could be due to st-flash confusing binary and hex files? It will happily write a hex file to flash, even though it needs a bin file.
Flashed 2 boards with the same bin, but the third one started doing that. Constant beep after power off button pressed nomatter what. Also it powers on when battery is connected and not when power button pressed.
power on after connecting battery sound like a hardware issue. I'd check the TIP127 darlington pairs..
power on after connecting battery sound like a hardware issue. I'd check the TIP127 darlington pairs..
I know where they are located, but how do I check them?
You can use diode mode of the Multimeter to check the component. You can compare the readings of both TIP127 to each other or use a new part as reference. In your case I expect a short, so some values should be really low. If you are not sure, write down your readings an post them here.
Yep, out of 4 boards 3 had some kind of short. It is ussualy lower tip127. One has short on all pins, others. Between 1-2 or 2-3. I am going to order some replacement parts. Also one board had burned stm32
does any one found out what is the problem ?
Does anyone have a solution, to this problem, yet? I have the same issue with 3 different boards. We tried many different sw-versions. As soon as I use the wii-nunchuck as input device, i get the backward-beeping in an endless loop.
I am having same problem of never ending beeping. I used arm-none-eabi-gcc.exe (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 for compiling. I measured 38V from battery. I also tried the provided .hex with the same issue. Using STM32CubeProgrammer to flash from WIN10. Starts beeping when power button is pressed and only stops when unplugging battery.
Does anyone have a solution, to this problem, yet? I have the same issue with 3 different boards. We tried many different sw-versions. As soon as I use the wii-nunchuck as input device, i get the backward-beeping in an endless loop.
Exactly same issue, any solution
Hey, I think I might have this same issue. Are you still able to flash/or communicate with the board? Ours won't flash anymore :/ Did you find a solution or are the boards just bricked?
Can you select WDG_SW, nRST_STOP and nRST_STDBy in option bytes of st utility?
Try replacing TIP127 components with new ones.
Can you select WDG_SW, nRST_STOP and nRST_STDBy in option bytes of st utility?
Unfortunately no, st-flash does not connect at all.
Try replacing TIP127 components with new ones.
Is 3.3V shorted to GRD if these are broken? Because that is the behavior we experience.
Can you select WDG_SW, nRST_STOP and nRST_STDBy in option bytes of st utility?
Unfortunately no, st-flash does not connect at all.
Try replacing TIP127 components with new ones.
Is 3.3V shorted to GRD if these are broken? Because that is the behavior we experience.
Yes, as it is used as voltage regulators for the board. (I am sure about this 70%, it has been a while :D )
Can you select WDG_SW, nRST_STOP and nRST_STDBy in option bytes of st utility?
Does this option available in stm32cubeprogrammer?
I am having this endless beeping on two boards I purchased on ebay. I measured voltage on all the wires, all seem normal until I get to the hall signal wires (not the power, or the ground). The signal wires with no wheels connected all measure about 3.3v. Is this normal for a hoverboard? Or, do these symptoms point to a different issue? I'm going to research more about this TIP127 component.
Daniel