-
Notifications
You must be signed in to change notification settings - Fork 1k
SPI does not work without a call to delay(0) #797
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
Comments
Hi @ghent360 Arduino_Core_STM32/cores/arduino/wiring_time.c Lines 37 to 45 in 2cc7dc7
I would expect the optimization simply ignore it. |
You use the core 1.7.0 or the git repo (if yes on which commits?) ? |
The latest git code.
…On Wed, Nov 27, 2019 at 2:51 AM Frederic Pillon ***@***.***> wrote:
You use the core 1.7.0 or the git repo (if yes on which commits?) ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#797?email_source=notifications&email_token=AB6FRVQPU24STF3MN5COKKLQVZGMNA5CNFSM4JSE2AY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFJDPUY#issuecomment-559036371>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB6FRVTIRKPIXFW5BGUXGMDQVZGMNANCNFSM4JSE2AYQ>
.
|
Tested at commit 2cc7dc7 There is probably some default "week" SysTick_Handler in the HAL, which gets used otherwise and it messes things up. |
Found it, it is defined in the startup_stm32xxxx.s file: So by default it is a noop and the value from HAL_GetTick dies not change. Not sure why that would affect the SPI HAL code though. |
This was introduced by #677. |
@ghent360 the first found is used when |
The issue is that both symbols are in core.a and the linker picks the first one it sees. The order of objects in the library archive comes into play. I tested that if you make the core.a archive with the startup_stm32yyxx.S.o at the end, then it picks the handles from clock.o Proposals, not sure how feasible these are with the arduino IDE: |
@ghent360 |
All smt32 drivers moved to built-in library to avoid object files to be archived in core.a. Fixes stm32duino#797 Signed-off-by: Frederic Pillon <[email protected]>
All stm32 drivers moved to built-in library to avoid object files to be archived in core.a. Fixes stm32duino#797 Signed-off-by: Frederic Pillon <[email protected]>
Yes looks fixed. |
I found a very weird issue with the SPI code (may affect others as well).
The code bellow works fine, but produces no SPI signal if you comment out the call to
delay(0)
in thesetup()
.I'm testing this on STM32F407VE MCU.
-----Bug repro code start -----
-----Bug repro code end -----
The only significant difference I can spot is when I call delay(0), some extra code is linked to the binary. I suspect the SPI code depends on the SysTick handler and does not quite work without it.
I would guess some week linking is causing this weirdness.
Extra code in the working binary:
The text was updated successfully, but these errors were encountered: