cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H745 dual core boot stuck at RCC_FLAG_D2CKRDY in CubeIDE version 1.11.0.

Hansel
Senior

Since I've converted from 1.10.1 to 1.11.0, my dual core application is no more working. Trying to switch back doesn't work either, so our development is sitting dead in the water.

Setup:

  • Win 10
  • CubeIDE 1.11.0
  • STM32CubeProgrammer 2.12.0
  • ST-LINK firmware V31J10M3 for the STLINK-V3MINI

We've double checked the settings according to AN5361 (remember, it worked before anyways).

The option bytes (OB) are as follows according to CubeProgrammer:

 0693W00000Y8Fq9QAF.png 

0693W00000Y8Fq4QAF.png 

Because of the timeout in main.c of CM7, The following line of code is used instead or the one that bails upon timeout to be able to observe the debugger behavior:

while(__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) != RESET) {asm("NOP");}

When trying to launch the app on the board, I proceed as follows

  1. Launching configuration on CM7 which downloads the compiled code to both cores.
  2. Run the code on CM7
  3. Launch configuration on CM4.

As soon as I do the last step, a break at address "0xa05f0000" appears and the dreaded console message pops up:

Target is not responding, retrying...

This message keeps on reappearing.

To be able to try again, the board has to be power cycled and CubeIDE has to be restarted:

This whole problem started when I initiated the Device Configuration Tool where I was offered to migrate, which I did. CubeIDE then proceeded to downloaded a large chunk of data. I still have CubeIDE 1.10.1 installed but I have not managed to revert back.

The only differences on disk between my original work space and the one created for version 1.11.0 is in the .ioc file:

0693W00000Y8FseQAF.png 

Apart from that, there's also this new file called .metadata. All other files are identical.

BTW, what is this firmware package about? Where is this used?

I am experiencing pretty much exactly the same problem as the developer in this link. Their problem never got resolved.

I've spent countless hours trying to fix what should've been working from the get-go.

Could someone in this community give me some hints where else to search? Since my source files are identical, I don't know what else to do. Reverting the .ioc file didn't work.

Addendum I:

I can do the first two steps described above (configure CM7 and download the code for both cores and kick off execution on CM7) and then step through the code on CM4 line by line, passing all peripheral initialization steps. I can even click on the Run button for CM4 after I've passed initialization. However, the CM7 never gets a chance to proceed. It's waiting for RCC_FLAG_D2CKRDY for an eternity, believing the D2 domain has never been turned on. Obviously that's not correct as the code on CM4 is executing.

Addendum II:

So I dug a bit deeper and managed to return to my previous setup that I can actually run in CubeIDE 1.11.0 but I had to make sure not to migrate to the latest firmware. Apparently there's a whole slew of changes in all sorts of files in HAL and probably elsewhere.

I wish there was better quality control (if there is any) but it looks like something's been f'd up royally. It cost me another whole day and I am surprised there's not been more complaints about this.

0 REPLIES 0