Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

v5.01 master branch goes into a boot loop on all tested hardwares #210

Closed
Teslafly opened this issue Sep 14, 2020 · 10 comments · May be fixed by #548
Closed

v5.01 master branch goes into a boot loop on all tested hardwares #210

Teslafly opened this issue Sep 14, 2020 · 10 comments · May be fixed by #548

Comments

@Teslafly
Copy link
Contributor

With the current master branch, all code I try to compile, for both hw 6.0 (hw v1) and hw 4.1, goes into a boot loop.
This occurs even when code is uploaded to an stm32f4discovery.

Wiping all memory on the stm32, then uploading using openocd. both with and without the bootloader produces the same result.

stepping through with gdb, the code gets to the end of main and into the end loop section:

for(;;) {
	chThdSleepMilliseconds(10);
}

Then resets before running any other thread as far as I can tell.
After the reset, In RCC_CSR the IWDGRSTF bit (Independent watchdog reset flag) was set to 1.
The whole RCC_CSR register value was 0x24000003

So it appears the watchdog is timing out and resetting the cpu.

Bit 29
IWDGRSTF: Independent watchdog reset flag
Set by hardware when an independent watchdog reset from VDD domain occurs.
Cleared by writing to the RMVF bit.
0: No watchdog reset occurred
1: Watchdog reset occurred

I have tried compiling in wsl, and with a brand new ubuntu 20.04 install, with the following installed:

sudo apt install gcc-arm-none-eabi gdb-multiarch git
## then compile/install openocd from source, apt package is broke
git clone https://github.com/vedderb/bldc.git
cd bldc
# comment conf_general for your board
make
make upload

I have also tried downloading the gcc compiler binaries from arm and using those to the same effect.

Is your compiling setup different than this? what version of gcc are you using?

I will be doing a regression to find out just what version I can still compile in a working state.
at the least, I can compile v3.58 in a working state, but later versions are also likely ok.
@Teslafly
Copy link
Contributor Author

version of gcc used:
arm-none-eabi-gcc (15:9-2019-q4-0ubuntu1) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

@Teslafly
Copy link
Contributor Author

master appears to compile fine with arm-none-eabi-gcc 4.3.9 20150529 revision 227977

a specific arm compiler version should probably be specified in the readme if newer versions break the project.

@vedderb
Copy link
Owner

vedderb commented Sep 14, 2020

This is the version of gcc that I have been using:

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]

I have seen that other people had problems with later gcc versions, but I haven't looked into it myself yet. It would be great if you have time to look into what the problem is. I will have a look eventually, but at the moment I really don't have time.

@Teslafly
Copy link
Contributor Author

I may be able to look into it.
my guess in this case is that either chibios is breaking,
or there is a difference in timings with gcc versions and at boot the watchdog is just on the edge of timing out before the periodic "timeout_feed_WDT()" is first run.

@hexakopter
Copy link

I also tried several arm-none-eabi-gcc versions from the developer.arm.com website in the past and the last working one for me that is available there for download was this one:
GNU Arm Embedded Toolchain: 7-2018-q2-update June 27, 2018

All version afterwards beginning with the "GNU Arm Embedded Toolchain: 8-2018-q4-major December 20, 2018" were not working anymore. After compiling and flashing the firmware the VESC was in a rebooting loop that was noticeable when looking at the LEDs.

@nhedlun1 nhedlun1 mentioned this issue Jan 21, 2021
Open
@Teslafly Teslafly mentioned this issue Apr 9, 2021
Closed
@supercrazysam supercrazysam mentioned this issue Apr 12, 2021
Merged
@Teslafly Teslafly mentioned this issue Jul 19, 2021
Open
@kubark42 kubark42 mentioned this issue Oct 13, 2021
Closed
@kalvdans kalvdans mentioned this issue Nov 4, 2021
Merged
@Teslafly
Copy link
Contributor Author

Teslafly commented May 2, 2022

Now that the makefile handles installing a version of gcc that is known to work, this issue is "fixed".
Though it is still present. When the version of chibios is upgraded this should be tested and see if we can move onto a new compiler.

Does it make sense to close this issue? or is it something we still want to track?

@vedderb
Copy link
Owner

vedderb commented May 2, 2022

I'm not sure that this is an issue anymore, it seems to work with some of the later compilers I tested. I think it could have been from the time before the stack check that some threads had too little stack.

However, even if many different compilers work, I think it is best to stick to the same one as that is what the code is developed and tested on and there are small differences between compiler versions.

Can someone give a later compiler a try and see if it works? If it does I think we can close this one.

@Teslafly Teslafly mentioned this issue Oct 16, 2022
Closed
@Teslafly
Copy link
Contributor Author

Teslafly commented Nov 6, 2022

I tested toolchain gcc-arm-none-eabi-10.3-2021.10 and compilation and vesc functionality works fine now.

It would be nice if the toolchain was updated because coretex-debug vscode extension now has a hard requirement on gdb version >= 9

@Teslafly Teslafly mentioned this issue Nov 6, 2022
Open
@vedderb vedderb closed this as completed Nov 6, 2022
@benzjimny
Copy link
Contributor

So does anyone know the root cause of this issue?

@Teslafly
Copy link
Contributor Author

No. At some point it was fixed though. I suspect something triggered a hard fault or didn't reset the watchdog.

One could do a binary "search" of git commits if you really wanted to find out what commit affects this.

Are you running into this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Update gcc/gdb version Teslafly/vesc_firmware
4 participants
@Teslafly @vedderb @hexakopter @benzjimny