stm32h755 Nucleo M7 debug problem

[JUANdeJESUS]

I am Juan de Jesus, I am a graduate student in engineering. I just bought a NUCLEO STM32H755 board.

I am writing a simple code to test this board, an algorithm that makes LED 1 blink.

The program compiles very well, and after this, I have made the configuration in the debug for the M7 core only, but when I am programming the flash memory, the st-link works well, but the microcontroller does not respond, it remains as if it were not programmed.

I have tried this algorithm with the board of one of my classmates and I have verified that my algorithm works correctly on his board.

What should I do? Should I return the board to the store?

Do you have any recomendation for me, please?

Thank you

[Tesla DeLorean]

The boards aren't particularly expensive, get a second one. The costs of shipping and returning likely exceeding the value of them.

Review the code, the board and jumpers, and any use of the board which may have resulted in physical or electrical damage. Say shorting of pins or placement on conductive surfaces.

[SofLit]

---

@JUANdeJESUS wrote:

I have tried this algorithm with the board of one of my classmates and I have verified that my algorithm works correctly on his board.

---

What do you mean by "my algorithm works correctly" in this statement? in debug or in standalone?

[SofLit]

Also please don't duplicate threads: almost the same thread on this link: https://community.st.com/t5/stm32cubeide-mcus/stm32h755-dual-core-debugging-problem/td-p/608795

EDIT sorry: it was an old thread: since Nov 2023!

[JUANdeJESUS]

Good morning:

Thank you for your message.

Regarding (my algorithm works correctly" in this statement?),  What I mean by this statement is that, I tested my algorithm on my stm32h755 nucleo board, and the board did not work. And later I tested the same algorithm on another board, owned by a friend, the same algorithm, with the same debug configuration, and on my friend's board the algorithm did work properly, which leads me to think that my board came damaged from the factory.

What do you think about this?

Thank you

[SofLit]

Hello,

---

@JUANdeJESUS wrote:

And later I tested the same algorithm on another board, owned by a friend, the same algorithm, with the same debug configuration, and on my friend's board the algorithm did work properly,

---

As it worked on your classmate laptop/PC in debug mode:

-> your board is OK.

Are you using CubeIDE? Which version? the latest one?  Did you compare the version of the IDE your classmate to the one you have? do you have use the same USB cable with your classmate laptop/PC?

[JUANdeJESUS]

Good morning:

Thank you very much for your message.

In this way, my classmate has another board of the same reference (Nucleo stm32h757).

On my classmate's board  (Nucleo stm32h757), the program works ok, but on my board  (Nucleo stm32h757) the program does not work.

We both have the same version of CubeIDE on each laptop computer. But my board does not work.

I would appreciate any help you can give me.

Thank you

[SofLit]

Does your board work with your classmate's laptop?

If not. It's something going wrong with your board..

[JUANdeJESUS]

Good morning,

I was reviewing the code generated by CubeIDE from the IOC file, and I tried to do the following test:

I put the following line of generated code between comments:

while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) != RESET) && (timeout-- > 0));

In this way the new code looks like this:

/* USER CODE BEGIN Boot_Mode_Sequence_1 */
/* Wait until CPU2 boots and enters in stop mode or timeout*/

timeout = 0xFFFF;

// while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) != RESET) && (timeout-- > 0));

After doing this, the board was programmed and working ok.

But I don't know why.

I appreciate all the help you can give me.

Thank you

[Pavel A.]

Please compare so called "option bytes" on your board and the other board. 

The "Option bytes" define how both M7 and M4 processors behave on startup.