Failed to read ROM table via AP 3 - Failed to start GDB server

[rtalan]

@RomainR. @SofLit 

UPDATE 04/30/24:

I no longer believe this is a debugger only problem. CM7 is always successful in flashing and debugging or running.

The ST Link GDB Server cannot flash the CM4 in either debug or Release mode. Please see attached file CM7_CM4_Release_Mode_Output.txt.

=====================================================================================

UPDATE 04/29/24:

After spending 3 hours writing up all of these details below, I came back at the problem the next day with a fresh approach. I decided to see if I could get just CM7 running in both projects. Here is what I found.

CM7 is indeed being flashed properly from both projects. It is hanging in the debugger for both projects because the CM4 will not start (see CM4 DEBUGGER FAILS TO RUN below). It gets stuck in an infinite loop which makes perfect sense because CM4 is not running.

/* USER CODE BEGIN Boot_Mode_Sequence_1 */
  while(__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) != RESET) { asm("NOP"); }
/* USER CODE END Boot_Mode_Sequence_1 */

If I comment out the while loop it falls through to the next while loop which also waits for the CM4 but times out and jumps to the Error_Handler() which then enters its own while loop. This gave me the impression of a failed flash.

Only when I stop the debugger and reset the PH7 is it clear that the CM7 has been flashed properly because my led's start flashing a special sequence I programmed to let me know it is running.

To make this ridiculously long story short, my problem has been reduced to the CM4 not starting because of the:

'Failed to read rom table via AP 3' error

or the 

'Failed to start GDB server, Error in initializing ST Link device' error.

Feel free to read everything below (I'm not deleting it because it took me 3 hours to put it together!) but the only relevant portion of it now is the CM4 DEBUGGER FAILS TO RUN which is what I need help with now.

======================================================================================

I've seen this issue in a few places. Some with solutions, none of which have worked for me. I am programming a Portenta H7 via a Portenta Breakout board with an ST Link v2 (please don't direct me to the Arduino forum. I have this conversation going over there as well).

CM4 DEBUGGER FAILS TO RUN

OR ST LINK IS FAILING TO CONNECT

In both projects, I start the CM7 debugger with no problems. When I start the CM4 debugger in either project, I get this error:

COM frequency = 4000 kHz
Target connection mode: Attach
Failed to read ROM table via AP 3

Error in initializing ST-LINK device.
Reason: Unknown. Please check power and cabling to target.

With this dialog popup:

Error in final launch sequence:

Failed to start GDB server
Failed to start GDB server
Error in initializing ST-LINK device.
Reason: (255) Unknown. Please check power and cabling to target.

Here is the CM7 and CM4 stack at this point:

STM32H747XI_CM7 Debug [STM32 C/C++ Application]	
	STM32H747XI_CM7.elf [cores: 0]	
		Thread #1 [main] 1 [core: 0] (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)	
			0x800041c	
			<signal handler called>() at 0xfffffff9	
			0x804000	
			<signal handler called>() at 0xffffffff	
	arm-none-eabi-gdb (13.2.90.20230627)	
	ST-LINK (ST-LINK GDB server)	

<terminated>STM32H747XI_CM4 Debug [STM32 C/C++ Application]	
	<terminated, exit value: 0>arm-none-eabi-gdb (13.2.90.20230627)	
	<terminated, exit value: 255>ST-LINK (ST-LINK GDB server)	

ST Link connections are fine as I can download the Bootloader, CM7 and CM4 .elf files from STMCubeProgrammer.

• The Bootloader (portentah7_bootloader_mbed_hs_v2.bin)
• CM7 address 0x08040000
• CM4 address 0x08100000
• My linker file for both CM7 and CM4 FLASH entry are set accordingly
• Debugger configurations for both CM7 and CM4 Startup->Set program counter (hex): are set accordingly

The power mode for CM4, as suggested in this post, is generated correctly with my version of STM32CubeIDE (1.15.1)

  HAL_PWREx_ClearPendingEvent();
  HAL_PWREx_EnterSTOPMode(PWR_MAINREGULATOR_ON, PWR_STOPENTRY_WFE, PWR_D2_DOMAIN);

Also, these OB settings are checked:

NRST_STOP_D2
NRST_STBY_D2

This post on GitHub follows the same debugger setup as AN5361 Section 3 with one exception: in the CM7 configuration, it shows 'Halt all cores' as checked which contradicts AN5361 . Which one is correct or does it matter?

I also implemented this suggestion from that post:

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

Of course, all help/suggestions are greatly appreciated!

Here are my debugger settings for both cores:

CM7

CM4

[RomainR. · Accepted solution]

Hello @rtalan 

When CM7 is stuck and is waiting for RCC_FLAG_D2CKRDY, it means the D2 domain has not booted properly. 

As CM4 is in D2 domain, did you checked the option byte BOOT_CM4 is correctly enabled on the device?

Can you also confirm that NRST_STOP_D2 and NRST_STBY_D2 option byte are enabled?

Here a link for a similar issue if these option byte are not properly enabled.

Dual Core boot up example · Issue #34 · STMicroelectronics/STM32CubeH7 · GitHub

With regards,

Romain

[Tesla DeLorean]

For odd behavior check voltages and capacitors on VCAP pins.

[rtalan]

@RomainR. 

Well the BCM4 flag OB was the culprit. I am finally running both cores!

I have read through the STM32CubeIDE and STM32CubeProgramming manuals and I've never seen anything that explains the Option Bytes. The STM32CubeProgrammer Section 2.4 simply reads "For more details refer to the option bytes section in the programming and reference manuals, available from www.st.com."

Which manuals is it referring to?

Does STM have a central location for all of the documentation? I have also perused all of the docs shown on the CubeIDE Information Center and I never saw anything about Option Bytes. Where is the document that explains Option Bytes?

Again, thank you for your help!

[RomainR.]

Hi @rtalan 

Yes, all the documents are on st.com, usually including the reference manual, data sheet, errata sheet and application note:
https://www.st.com/en/microcontrollers-microprocessors/stm32h745-755/documentation.html

If I understand correctly, you are still using the Arduino Portenta H7 board, which has a dual-core STM32H747?
Well, there's the documentation for tools such as STM32CubeIDE or CubeProgrammer, and there's also the numerous device documentations.
The Reference manual in question is RM0399, which you can find here.
https://www.st.com/resource/en/reference_manual/rm0399-stm32h745755-and-stm32h747757-advanced-armbased-32bit-mcus-stmicroelectronics.pdf

Their description is in section 4.4 FLASH option bytes.
As the STM32H747 is dual-core, both the Cortex-M7 and M4 cores are enabled for all devices leaving our factories. This is the default configuration (see RM0399 in Table 20. Option byte organisation) and you would find this on one of our NUCLEO-H745ZI-Q or STM32H747I-Discovery boards:
https://www.st.com/en/evaluation-tools/nucleo-h745zi-q.html
https://www.st.com/en/evaluation-tools/stm32h747i-disco.html

I think that disabling the BOOT_CM4 byte option is done by Arduino? Do their SDK and example use both cores? I don't know?

All the best and good luck.
Romain

[rtalan]

@RomainR. 

Thanks again for the additional information.

Yes, all the documents are on st.com, usually including the reference manual, data sheet,
errata sheet and application note:
https://www.st.com/en/microcontrollers-microprocessors/stm32h745-755/documentation.html

Nice! RM0399 looks like some heavy reading but I can tell it will come in handy.

I think that disabling the BOOT_CM4 byte option is done by Arduino? Do their SDK and
example use both cores? I don't know?

Yes, that makes perfect sense now. In all of their dual core demos they have this little block of code somewhere in setup():

#ifdef CORE_CM7
  bootM4();
#endif

So that confirms your suspicions.

I have no intention of using the Arduino IDE for the Portenta H7 (STM32H647XI). For the project I have in mind I need to be closer to the metal and the Arduino libraries abstract too much of that away. I prefer the CubeIDE interface for development. It does so much more.

These past several weeks I have been trying to get the H7 up and running with the CubeIDE suite of tools just to make sure it was possible. I see the H7 as a breakout board for the STM32H647XI. And the H7 also promises integration with TensorFlow Lite which will be a huge part of my project.

With that said, I am not an electrical or mechanical engineer. I am a retired Software Engineer with 40+ years of experience. The MCU world is new to me and very exciting! It is a steep learning curve but with people like you I am making progress. Over time I will bug you less and less :beaming_face_with_smiling_eyes:!!

Thanks again for your help! I'd be stuck without it.

rtalan