STM32H735 CANFD init failure

[balazssarkozy94]

Hi all!
Sorry if this is unprofessional, I'm mostly a hardware engineer, but I've "ported" (modified some c files) micropython to an STM32H735IGT6 mostly successfully, all peripherals seemed to work OK.
The only thing that I'm stuck on is FDCAN, I added ...ENABLE_CAN, and ...ENABLE_FDCAN to mpconfigboard.h, set up the PLL-s and clock selection for FDCAN, but no matter how I try I get "ValueError: CAN(x) init failure" (x = 1...3).
Is there a way to debug this? If anything else helps I can attach it if requested.
Thank you in advance!

[balazssarkozy94]

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.

[balazssarkozy94]

For some reason the pins_....c file generated in the build folder has the FDCAN pins commented out.

[balazssarkozy94]

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.

[projectgus]

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?

[balazssarkozy94]

Hi @projectgus! Yes it looks like I was late :) Thank you!

[balazssarkozy94]

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

[projectgus]

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?)

[balazssarkozy94]

I have some problems still, (I can send on all 3 CANFD channels, but cant receive on either of them) trying to debug.
I'll be glad to contribute, altough I am not a proficient user of GIT, so after tidying up the code I think I'll share the raw source code if thats ok for you.

[projectgus]

@balazssarkozy94 That's fine, thanks for working through the debugging!

[balazssarkozy94]

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>

[projectgus]

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.

[balazssarkozy94]

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> >

[balazssarkozy94]

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> >> >

[balazssarkozy94]

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> >>> >>

[balazssarkozy94]

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> >>>> >>>

[balazssarkozy94]

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> >>>>> >>>>

[balazssarkozy94]

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>

[edgaralejod]

Hi @balazssarkozy94. I'm looking to do the same thing of porting micropython to a custom board with the STM32H735 chip. Would you be willing to share some of the effort you've done so far on getting it running on that chip? Which board did you start with? Did you create a stm32h735_af.csv file and the linker script? Even if you are willing to share just that it would be a great help.