Switching a project from a STM32F413 to a STM32F405 doesn't allow for debugging.

[DKend.1]

Hi,

We are in the process of switching an existing product from using a STM32F413 to a STM32F405 processor, due to part availability. There are only a few pin changes that I can see. We have modified a board with the STM32F405 processor and changes for VCAP_1 and VCAP_2, recompiled the firmware for the STM32F405 and are able to download to the processor. Looking good so far.

When we try to debug the software through IAR (JLink or STLink) it fails to connect (this process worked successfully on boards with the STM32F413).

Using Segger Ozone, I am able to debug our bootloader, but it is hard faulting after the first call to a peripheral (RCC).

I am hoping I am overlooking an expected change needed to switch between micro-controllers (and not a counterfeit part). Any help would be appreciated.

Thanks.

[Imen.D]

Hello @dlkengendall​ and welcome to the Community 🙂

What exactly did the error message say?

Which IAR version are you using ?

Make sure to set up correctly the pins of the bootloader communication peripherals, as in the AN4488: Table 7 STM32F4xxxx bootloader communication peripherals

I'll be waiting for your update regarding this issue.

Imen

[DKend.1]

Hi,

I have been reviewing our projects and noticed that we had a custom .board file that is used for IAR, that was set for the STM32F413. I updated this file for the STM32F405 and I am now able to debug through IAR. Both my bootloader and application projects are able to debug, but they both run into hard fault, Imprecise errors at this time.

I reviewed the pdf you mentioned. We are using CAN for our communications for the bootloader and it appears that this connection is the same across both processors. I noticed that we had our Boot 1 pin floating, so I added a pull-down to ensure that the floating pin wasn't causing an issue. No difference in outcomes, as Boot 0 was already pulled down.

So, now I'm looking into the hard fault issue, wondering if there is something significant between the two processors that would make the hard fault occur on only one of the processors.

Thanks.

[DKend.1 · Accepted solution]

Reviewing our bootloader, we found a hardcoded RAM address that was in a valid range on the STM32F413, but out of range on the STM32F405. This addressed the hard fault issue in the bootloader.

I found a bug in our application software that was doing something similar (buffer range overrun), that was producing the same fault.