ArduPilot
AP_Bootloader: Add new revisions of STM32F4xx CPUs
Use of latest STM32Fxx boards made bootloader stuck because of missing CPU revision versions list to check against. This makes new boards unusable until fixed. Also, I've found mismatch of revision values vs version names.
I see that one test failed, but that is current state of master or some other problem. My code did not affect tests :)
Those tests are just flaky, you can ignore them.
Do you have a cite from ST on these numbers?
Do you have a cite from ST on these numbers?
yep, https://www.st.com/resource/en/errata_sheet/dm00037591-stm32f405-407xx-and-stm32f415-417xx-device-limitations-stmicroelectronics.pdf
That document says
But this document (for F427/F437) says
So we must need to expand the table to also have the CPU ID. That explains the discrepancies in the ID numbers too, the table was (mostly) based on that latter document.
Does this really cause something to get stuck? Where?
So we must need to expand the table to also have the CPU ID. That explains the discrepancies in the ID numbers too, the table was (mostly) based on that latter document.
Great discovery. I was focused on stm cpu I had. I will provide a support for CPU ID.
Does this really cause something to get stuck? Where?
In support.cpp:276, get_mcu_desc() traverses through silicon_revs that does not contain valid revid. As a result returns some random ptr and hangs in bootloader.
Does this really cause something to get stuck? Where?
In
support.cpp:276,get_mcu_desc()traverses throughsilicon_revsthat does not contain validrevid. As a result returns some random ptr and hangs in bootloader.
I disagree, the loop should only run for the number of elements in the array due to the C++ iterator syntax. You notice we don't even break out of the loop, so it has to end that way. Have you looked at this with a debugger?