MicroPython
STM32H735 CANFD init failure #16896
-
|
Hi all! |
Beta Was this translation helpful? Give feedback.
Replies: 11 comments 6 replies
-
|
I was able to pinpoint the problem to mp_hal_pin_config_alt function, and inside that the pin_find_af function fails to find the pin. I guess my ..._af.csv is bad. |
Beta Was this translation helpful? Give feedback.
-
|
For some reason the pins_....c file generated in the build folder has the FDCAN pins commented out. |
Beta Was this translation helpful? Give feedback.
-
|
Just for future reference: The problem is that in the ..._af.csv I used "FDCAN1_Tx" etc, and it should have been "CAN1_TX". I checked a few STM32 projects, and quite a few of them have it the first way, that should be fixed I guess. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @balazssarkozy94, I think you found this a couple of months after me! A fix should have been merged here: #16543 that I think will cover this case, but it's only available in "master" branch and preview builds so far (will be released in v1.25). Does that look like it covers your case, as well? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @projectgus! Yes it looks like I was late :) Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
Also: Some of the source code is not prepared for 3 CAN peripherals (or at least it looks like that to me), so I had to modify even more files, now it seem to work fine with all 3 |
Beta Was this translation helpful? Give feedback.
-
|
If you have some patches (or a copy of the source) for this then please consider either opening a Pull Request or (if not possible) share the modified code, will try to merge the fix into MicroPython. I believe I've run MicroPython on the STM32G4 NUCLEO board which has 3x CAN-FD peripherals, but maybe I didn't test all of them fully (or the patch is for H7 only?) |
Beta Was this translation helpful? Give feedback.
-
|
I have some problems still, (I can send on all 3 CANFD channels, but cant receive on either of them) trying to debug. |
Beta Was this translation helpful? Give feedback.
-
|
@balazssarkozy94 That's fine, thanks for working through the debugging! |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the late reply! Now I think all 3 CANs work well (altough I
didn't have time to test different configurations, and my code and
modifications are still quite messy)
How could I send you all the source code? If in the future you have any
questions about my modifications, feel free to ask, I hope I can contribute
somehow to this awesome project!
In the meanwhile I think I found a possible bug, on STM32H735 on SPI6, if I
set it up to a relatively low baudrate (sub MHz), initialization is ok, but
on the first transmission it will throw ETIMEDOUT OS error without moving a
single pin, but on higher clocks it works ok. This might affect all other
SPIs, and I think that there might be an unnecessary check on SPI timeout.
Or at least this should be configurable.
Angus Gratton ***@***.***> ezt írta (időpont: 2025. márc.
18., K, 0:42):
… @balazssarkozy94 <https://github.com/balazssarkozy94> That's fine, thanks
for working through the debugging!
—
Reply to this email directly, view it on GitHub
<#16896 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH2ZST2JKVSXKI4ORCQ3LUL2U5MURAVCNFSM6AAAAABYVXOXB6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJTGE2DCMY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
Thanks for letting us know about this, and the follow-up investigation. Could you please open an issue at https://github.com/micropython/micropython/issues with these SPI6 details? I think what you've written here is enough, but putting it in an issue will make it easier to track. |
Beta Was this translation helpful? Give feedback.
-
|
And for the SPI timeout I think the culprit is in stm32h7xx_hal_spi.c
HAL_SPI_Transmit function, or in one of the above layers that calls this.
Balázs Sárközy ***@***.***> ezt írta (időpont: 2025. márc.
27., Cs, 11:36):
… Sorry for the late reply! Now I think all 3 CANs work well (altough I
didn't have time to test different configurations, and my code and
modifications are still quite messy)
How could I send you all the source code? If in the future you have any
questions about my modifications, feel free to ask, I hope I can contribute
somehow to this awesome project!
In the meanwhile I think I found a possible bug, on STM32H735 on SPI6, if
I set it up to a relatively low baudrate (sub MHz), initialization is ok,
but on the first transmission it will throw ETIMEDOUT OS error without
moving a single pin, but on higher clocks it works ok. This might affect
all other SPIs, and I think that there might be an unnecessary check on SPI
timeout. Or at least this should be configurable.
Angus Gratton ***@***.***> ezt írta (időpont: 2025. márc.
18., K, 0:42):
> @balazssarkozy94 <https://github.com/balazssarkozy94> That's fine,
> thanks for working through the debugging!
>
> —
> Reply to this email directly, view it on GitHub
> <#16896 (reply in thread)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AH2ZST2JKVSXKI4ORCQ3LUL2U5MURAVCNFSM6AAAAABYVXOXB6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJTGE2DCMY>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***
> com>
>
|
Beta Was this translation helpful? Give feedback.
-
|
Also, the problem might come from the SPI baudrate being slightly different
than the one from the init (because of prescalers and such), but I
dont know if this is corrected for somewhere else.
Balázs Sárközy ***@***.***> ezt írta (időpont: 2025. márc.
27., Cs, 11:41):
… And for the SPI timeout I think the culprit is in stm32h7xx_hal_spi.c
HAL_SPI_Transmit function, or in one of the above layers that calls this.
Balázs Sárközy ***@***.***> ezt írta (időpont: 2025. márc.
27., Cs, 11:36):
> Sorry for the late reply! Now I think all 3 CANs work well (altough I
> didn't have time to test different configurations, and my code and
> modifications are still quite messy)
> How could I send you all the source code? If in the future you have any
> questions about my modifications, feel free to ask, I hope I can contribute
> somehow to this awesome project!
> In the meanwhile I think I found a possible bug, on STM32H735 on SPI6, if
> I set it up to a relatively low baudrate (sub MHz), initialization is ok,
> but on the first transmission it will throw ETIMEDOUT OS error without
> moving a single pin, but on higher clocks it works ok. This might affect
> all other SPIs, and I think that there might be an unnecessary check on SPI
> timeout. Or at least this should be configurable.
>
>
> Angus Gratton ***@***.***> ezt írta (időpont: 2025. márc.
> 18., K, 0:42):
>
>> @balazssarkozy94 <https://github.com/balazssarkozy94> That's fine,
>> thanks for working through the debugging!
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <#16896 (reply in thread)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AH2ZST2JKVSXKI4ORCQ3LUL2U5MURAVCNFSM6AAAAABYVXOXB6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJTGE2DCMY>
>> .
>> You are receiving this because you were mentioned.Message ID:
>> ***@***.***
>> .com>
>>
>
|
Beta Was this translation helpful? Give feedback.
-
|
I narrowed it a bit, 1 byte sending works, but as I saw in stm32/spi.c 1
byte sending doesn't use DMA, but polls. So most likely something is bad on
my side with the H735 config about SPI6 DMA. If I find something, I'll let
you know.
Balázs Sárközy ***@***.***> ezt írta (időpont: 2025. márc.
27., Cs, 11:44):
… Also, the problem might come from the SPI baudrate being slightly
different than the one from the init (because of prescalers and such), but
I dont know if this is corrected for somewhere else.
Balázs Sárközy ***@***.***> ezt írta (időpont: 2025. márc.
27., Cs, 11:41):
> And for the SPI timeout I think the culprit is in stm32h7xx_hal_spi.c
> HAL_SPI_Transmit function, or in one of the above layers that calls this.
>
> Balázs Sárközy ***@***.***> ezt írta (időpont: 2025.
> márc. 27., Cs, 11:36):
>
>> Sorry for the late reply! Now I think all 3 CANs work well (altough I
>> didn't have time to test different configurations, and my code and
>> modifications are still quite messy)
>> How could I send you all the source code? If in the future you have any
>> questions about my modifications, feel free to ask, I hope I can contribute
>> somehow to this awesome project!
>> In the meanwhile I think I found a possible bug, on STM32H735 on SPI6,
>> if I set it up to a relatively low baudrate (sub MHz), initialization is
>> ok, but on the first transmission it will throw ETIMEDOUT OS error without
>> moving a single pin, but on higher clocks it works ok. This might affect
>> all other SPIs, and I think that there might be an unnecessary check on SPI
>> timeout. Or at least this should be configurable.
>>
>>
>> Angus Gratton ***@***.***> ezt írta (időpont: 2025. márc.
>> 18., K, 0:42):
>>
>>> @balazssarkozy94 <https://github.com/balazssarkozy94> That's fine,
>>> thanks for working through the debugging!
>>>
>>> —
>>> Reply to this email directly, view it on GitHub
>>> <#16896 (reply in thread)>,
>>> or unsubscribe
>>> <https://github.com/notifications/unsubscribe-auth/AH2ZST2JKVSXKI4ORCQ3LUL2U5MURAVCNFSM6AAAAABYVXOXB6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJTGE2DCMY>
>>> .
>>> You are receiving this because you were mentioned.Message ID:
>>> <micropython/micropython/repo-discussions/16896/comments/12531413@
>>> github.com>
>>>
>>
|
Beta Was this translation helpful? Give feedback.
-
|
Okay, my final finding: in ports/stm32/dma.c around line 1769 it states
that BDMA is currently not supported. Sadly SPI6 is on BDMA. Later I might
try to goof around, but I think this is way beyond my skills
Balázs Sárközy ***@***.***> ezt írta (időpont: 2025. márc.
27., Cs, 16:49):
… I narrowed it a bit, 1 byte sending works, but as I saw in stm32/spi.c 1
byte sending doesn't use DMA, but polls. So most likely something is bad on
my side with the H735 config about SPI6 DMA. If I find something, I'll let
you know.
Balázs Sárközy ***@***.***> ezt írta (időpont: 2025. márc.
27., Cs, 11:44):
> Also, the problem might come from the SPI baudrate being slightly
> different than the one from the init (because of prescalers and such), but
> I dont know if this is corrected for somewhere else.
>
> Balázs Sárközy ***@***.***> ezt írta (időpont: 2025.
> márc. 27., Cs, 11:41):
>
>> And for the SPI timeout I think the culprit is in stm32h7xx_hal_spi.c
>> HAL_SPI_Transmit function, or in one of the above layers that calls this.
>>
>> Balázs Sárközy ***@***.***> ezt írta (időpont: 2025.
>> márc. 27., Cs, 11:36):
>>
>>> Sorry for the late reply! Now I think all 3 CANs work well (altough I
>>> didn't have time to test different configurations, and my code and
>>> modifications are still quite messy)
>>> How could I send you all the source code? If in the future you have any
>>> questions about my modifications, feel free to ask, I hope I can contribute
>>> somehow to this awesome project!
>>> In the meanwhile I think I found a possible bug, on STM32H735 on SPI6,
>>> if I set it up to a relatively low baudrate (sub MHz), initialization is
>>> ok, but on the first transmission it will throw ETIMEDOUT OS error without
>>> moving a single pin, but on higher clocks it works ok. This might affect
>>> all other SPIs, and I think that there might be an unnecessary check on SPI
>>> timeout. Or at least this should be configurable.
>>>
>>>
>>> Angus Gratton ***@***.***> ezt írta (időpont: 2025.
>>> márc. 18., K, 0:42):
>>>
>>>> @balazssarkozy94 <https://github.com/balazssarkozy94> That's fine,
>>>> thanks for working through the debugging!
>>>>
>>>> —
>>>> Reply to this email directly, view it on GitHub
>>>> <#16896 (reply in thread)>,
>>>> or unsubscribe
>>>> <https://github.com/notifications/unsubscribe-auth/AH2ZST2JKVSXKI4ORCQ3LUL2U5MURAVCNFSM6AAAAABYVXOXB6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJTGE2DCMY>
>>>> .
>>>> You are receiving this because you were mentioned.Message ID:
>>>> <micropython/micropython/repo-discussions/16896/comments/12531413@
>>>> github.com>
>>>>
>>>
|
Beta Was this translation helpful? Give feedback.
-
|
Sorry if this is like spamming, but maybe this is useful for someone else:
An ease workaround is to extend the if statement in the SPI functions to
check if the instance is SPI6, then use blocking/polling instead of DMA:
if (len == 1 || query_irq() == IRQ_STATE_DISABLED || self->spi->Instance ==
SPI6) {
status = HAL_SPI_Transmit(self->spi, (uint8_t *)src, len, timeout);
Balázs Sárközy ***@***.***> ezt írta (időpont: 2025. márc.
27., Cs, 17:17):
… Okay, my final finding: in ports/stm32/dma.c around line 1769 it states
that BDMA is currently not supported. Sadly SPI6 is on BDMA. Later I might
try to goof around, but I think this is way beyond my skills
Balázs Sárközy ***@***.***> ezt írta (időpont: 2025. márc.
27., Cs, 16:49):
> I narrowed it a bit, 1 byte sending works, but as I saw in stm32/spi.c 1
> byte sending doesn't use DMA, but polls. So most likely something is bad on
> my side with the H735 config about SPI6 DMA. If I find something, I'll let
> you know.
>
> Balázs Sárközy ***@***.***> ezt írta (időpont: 2025.
> márc. 27., Cs, 11:44):
>
>> Also, the problem might come from the SPI baudrate being slightly
>> different than the one from the init (because of prescalers and such), but
>> I dont know if this is corrected for somewhere else.
>>
>> Balázs Sárközy ***@***.***> ezt írta (időpont: 2025.
>> márc. 27., Cs, 11:41):
>>
>>> And for the SPI timeout I think the culprit is in stm32h7xx_hal_spi.c
>>> HAL_SPI_Transmit function, or in one of the above layers that calls this.
>>>
>>> Balázs Sárközy ***@***.***> ezt írta (időpont: 2025.
>>> márc. 27., Cs, 11:36):
>>>
>>>> Sorry for the late reply! Now I think all 3 CANs work well (altough I
>>>> didn't have time to test different configurations, and my code and
>>>> modifications are still quite messy)
>>>> How could I send you all the source code? If in the future you have
>>>> any questions about my modifications, feel free to ask, I hope I can
>>>> contribute somehow to this awesome project!
>>>> In the meanwhile I think I found a possible bug, on STM32H735 on SPI6,
>>>> if I set it up to a relatively low baudrate (sub MHz), initialization is
>>>> ok, but on the first transmission it will throw ETIMEDOUT OS error without
>>>> moving a single pin, but on higher clocks it works ok. This might affect
>>>> all other SPIs, and I think that there might be an unnecessary check on SPI
>>>> timeout. Or at least this should be configurable.
>>>>
>>>>
>>>> Angus Gratton ***@***.***> ezt írta (időpont: 2025.
>>>> márc. 18., K, 0:42):
>>>>
>>>>> @balazssarkozy94 <https://github.com/balazssarkozy94> That's fine,
>>>>> thanks for working through the debugging!
>>>>>
>>>>> —
>>>>> Reply to this email directly, view it on GitHub
>>>>> <#16896 (reply in thread)>,
>>>>> or unsubscribe
>>>>> <https://github.com/notifications/unsubscribe-auth/AH2ZST2JKVSXKI4ORCQ3LUL2U5MURAVCNFSM6AAAAABYVXOXB6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJTGE2DCMY>
>>>>> .
>>>>> You are receiving this because you were mentioned.Message ID:
>>>>> <micropython/micropython/repo-discussions/16896/comments/12531413@
>>>>> github.com>
>>>>>
>>>>
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, I opened it. Thank you for all the work you people do with the
Micropython project!
Angus Gratton ***@***.***> ezt írta (időpont: 2025. ápr. 1.,
K, 1:44):
… In the meanwhile I think I found a possible bug, on STM32H735 on SPI6
Thanks for letting us know about this, and the follow-up investigation.
Could you please open an issue at
https://github.com/micropython/micropython/issues with these SPI6
details? I think what you've written here is enough, but putting it in an
issue will make it easier to track.
—
Reply to this email directly, view it on GitHub
<#16896 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH2ZST6FMUR3JQEKKPLELKD2XHOOVAVCNFSM6AAAAABYVXOXB6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENRYGIZDCMI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
Just for future reference: The problem is that in the ..._af.csv I used "FDCAN1_Tx" etc, and it should have been "CAN1_TX". I checked a few STM32 projects, and quite a few of them have it the first way, that should be fixed I guess.