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.

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

Compiling with newer versions of GCC results in broken firmware #1343

Open
robbederks opened this issue Apr 11, 2023 · 8 comments
Open

Compiling with newer versions of GCC results in broken firmware #1343

robbederks opened this issue Apr 11, 2023 · 8 comments
Labels

Comments

@robbederks
Copy link
Contributor

The application firmware image compiled with arm-none-eabi-gcc version 10.3 instead of 9.3.1 (default in ubuntu 20.04) does not boot on white pandas (have not tested others). Bootstub seems fine.

@robbederks robbederks added the bug label Apr 11, 2023
@pd0wm
Copy link
Contributor

pd0wm commented Apr 13, 2023

Same issue as #1204 ?

@olesalscheider
Copy link

I am seeing the same, but the buffer size is already set to the smaller one.

@danielzmod
Copy link

The application firmware image compiled with arm-none-eabi-gcc version 10.3 instead of 9.3.1 (default in ubuntu 20.04) does not boot on white pandas (have not tested others). Bootstub seems fine.

Tried with grey panda and had similar or same problem. Just seems to be completly dead.

@pd0wm
Copy link
Contributor

pd0wm commented Aug 22, 2023

Looks like after c66b98b it works again. Seems like touching these UART FIFOs has the tendency to break/fix the code on newer compilers. See #1204

Tested with arm-none-eabi-gcc (Arch Repository) 13.2.0

@robbederks
Copy link
Contributor Author

Still want to look into the root cause at some point to prevent this issue from happening again, so will keep this open for now.

@adeebshihadeh
Copy link
Contributor

Once we investigate and fix properly, we’ll also add a latest GCC build to CI.

@briskspirit
Copy link
Contributor

@pd0wm reported that #1559 fixed the issue. Should we close it or still want to investigate the cause?

@adeebshihadeh
Copy link
Contributor

No, we definitely still need to look into this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants