STM32F105 64 pin bootloader

[sklindt]

Hello

I have been asked how difficult it will be to create a custom bootloader for the STM32F105.

We are for some reason using the 64 pin version of the chip and from the AN2606 i can see 

"""""

Workaround
• For 64-pin packages
None. The bootloader cannot be used. 

""""""

So i guess we will have to develop our own bootloader or switch to 100 pin package.

But what would people in here suggest? 

[Peter BENSCH]

Welcome @sklindt, to the community!

It is indeed in the AN2606, section 16.3.2, but there is also additional information in the title:

Bootloader unavailability on STM32F105xx/STM32F107xx devices with date code lower than 937

Which date code can you find in the last three characters of the penultimate line starting with the 3-letter code of the country of manufacture? (the date code consists of YWW, i.e. last digit of the year + two digits for the calender week)

Regards
/Peter

[sklindt]

 Hello This is a picture of the chip

[Peter BENSCH]

Now, assuming this is not a fake (it looks like it is in the very low-resolution picture), the date code is 146. The exact year can only be recognised by the label on the packaging and the Bulk ID on it, here the 1 can currently be interpreted as 2011 or 2021.

The date code 937 refers to Bootloader V1.0, which was only included in the very first STM32F105 before 2009. Even if the 1 on your device meant the year 2011, it would contain a newer bootloader, which means that the problem described in section 16.3.2 is no longer relevant. Section 16.3.1 also describes how to determine the bootloader version. Unfortunately, it also mentions a datecode ≥227, which again raises the question of the decade - if I remember correctly, that was 2012, because the STM32F105 was not changed any further after ~2015.

Note: if you have a label with the bulk ID and would like to have it checked - please do not paste it here due to the risk of misuse, but send it to me or colleagues exclusively via PM.

[sklindt]

Hello and i really apreciate the very quick response time! 

So just to understand correctley

Since my chip is made after atleast 2011 it should actually work with the built in bootloader? 

But then i just have to hook it up and check the versioning? 

We have an external company source and mount the chips on the PCB's for us, so i am unsure if it will be possible to get any of the information about Bulk ID etc.

[Tesla DeLorean]

If you have ST-LINK (SWV/JTAG) connectivity you should be able to recover Unique ID and firmware/loader version from the IC directly, or in your own code.

You can always code you own loader functionality in FLASH, there you trade size vs functionality. Having something implement X-Modem on a serial post shouldn't take too much memory.

The F1 parts are a bit antiquated at this point, there might be better choices in 2023 / 2024

The A rev die doesn't seem to be in the primary errata for the STM32F105 (Rev 11 2022)

https://www.st.com/resource/en/errata_sheet/es022-stm32f105xx-stm32f107xx-device-errata-stmicroelectronics.pdf

[sklindt]

So what you are saying is that we should generally switch chips instaed of using the F105? 

any recomendations? 

We have not started any actual development yet and i would not think of it as a major problem of switching. The main reason it was chosen is, that it is being used in another place in another part. 

[Tesla DeLorean]

Just saying that if you consider a move to 100-pin, and PCB update / design spin, you might consider alternatives. Depends on availability and sourcing difficulties, a lot of people using F1 so potentially more competition for parts. Could of course do a dual foot-print to accommodate 64 or 100 pin packages

If using SPL their will be some annoyance in porting the code to HAL and other platforms. Newer STM32 families have easier / simpler pin routing options, so flexibility there.

Newer families had more support for SDIO/SDMMC, and split the CAN/USB FIFO allowing concurrent operation of those.

F105/107 perhaps picked for Ethernet or CAN usage.

Some applications I'm seeing pressure for "secure" MCU usage so Cortex-M33, encryption, signing, root-of-trust type things.

[sklindt]

I do agree that considering alternatives is a very good point! 

And as i said we are not 100% locked in on a specific chip, the only reason for staying with that is only due to it being used somewhere else.

The codebase is going to be made from scracth for this project.

But yes CAN is needed. 

[Pavel A.]

>I have been asked how difficult it will be to create a custom bootloader for the STM32F105.

Short answer - it depends. For someone new to STM32 and tools it can take several (2+) months. For someone who has relevant experience and ready design & code to reuse, it can take several days to a 'working' prototype.