STM32H743XI silicon Y - DBGMCU dead ?

[Dan4]

Curious if anyone else encountered this: I work on a design using STM32H743XI silicon Y and DBGMCU seems to be completely dead. Reading any register returns 0 (so no REV_ID/DEV_ID). Writing to get 'timer freeze on debug' does not work either and reading back the written registers returns 0's.

The Errata does not mention anything like that.

I am aware that the Debugger is supposed to see DBGMCU at 0xE00E1000 and the CPU at 0x5C001000, but neither works.

Am I missing something ? - there is no RCC clock enabling for this class of MCUs... ; the ref manual lists DBGMCU->CR bits D1DBGCKEN and D3DBGCKEN, which are not dealt with in the standard HAL, but again trying to set them and re-read, I get back 0's...

Thanks.

[Tesla DeLorean]

All the Nucleo's seem to be Rev Y, pretty sure I've programmed into the debug space and have the SWV working via code running on the parts. Some of the ARM sub-units need to be unlocked, but not sure you're talking about that.

*(__IO uint32_t*)(0x5C001004) |= 0x00700000; // DBGMCU_CR D3DBGCKEN D1DBGCKEN TRACECLKEN

https://community.st.com/s/question/0D50X00009ce0vWSAQ/nucleoh743zi-board-and-printf-swo-not-working

[Tesla DeLorean]

Rev Z on the EVAL

H743XI Z

CPUID 411FC271 DEVID 450 REVID 1001

Cortex M7 r1p1

STM32H7xx

C0000018 20000F48 00000000

10110221 12000011 00000040

FPU-D Single-precision and Double-precision

[Tesla DeLorean]

Not much going on here either

Core=500000000, 500.00 MHz
CPUID 411FC271 DEVID 450 REVID 2001
Cortex M7 r1p1
C0000038 24013978 00000000
10110221 12000011 00000040
FPU-D Single-precision and Double-precision
STM32H7xx
HCLK=250000000
APB1=125000000
APB2=125000000
5C001000 : 20016450 00700000 00000000 00000000 
5C001010 : 00000000 00000000 00000000 00000000 
5C001020 : 00000000 00000000 00000000 00000000 
5C001030 : 00000000 00000000 00000000 00000000 
5C001040 : 00000000 00000000 00000000 00000000 
5C001050 : 00000000 00000000 00000000 00000000 
5C001060 : 00000000 00000000 00000000 00000000 
5C001070 : 00000000 00000000 00000000 00000000 
5C001080 : 00000000 00000000 00000000 00000000 
5C001090 : 00000000 00000000 00000000 00000000 
5C0010A0 : 00000000 00000000 00000000 00000000 
5C0010B0 : 00000000 00000000 00000000 00000000 
5C0010C0 : 00000000 00000000 00000000 00000000 
5C0010D0 : 00000000 00000000 00000000 00000000 
5C0010E0 : 00000000 00000000 00000000 00000000 
5C0010F0 : 00000000 00000000 00000000 00000000 

[Dan4]

Thanks Clive!

Looks OK with the REVID 1001 and 2001 - you are getting DEVID and REVID and it keeps it down when setting the CR. Mine ( Y ) is supposed to be ( reading the Errata ) REVID 1003 and reading/writing/reading of 0x5C0010xx returns 0s.

Already tried CR |= 0x00700000 - nothing. I had the equivalent of your SWD_Init in the Initialization script of the debugger, tried also the SWD_Init script in code - same thing.

I will be getting a Nucleo and Eval boards in a couple of days and will post results.

I am either forgetting to set something or have a bunch of bad chips.

BTW - impressive with the 500 MHz core, have to try this...

[Tesla DeLorean]

I have this code working on Rev Y, didn't have one immediately to hand.

​

The operational ceiling is a ways above 500 MHz​. This chip can haul.

[CHead]

Check the block diagram in RM0433 section 59.3.1. There are three access ports available, rather than the usual one AP that existed on earlier STM32F parts. I suspect you’re probably accessing everything through AP0, though that might depend on what debug software and hardware you’re using.

​

The view at 0x5C001000 is accessible through AP0 only when the part is not held in reset and, perhaps, when the D1 domain is in normal run mode (not in some sort of power saving mode).

The view at 0xE00E1000 is only accessible through AP2; if you try to access it through AP0 you see all zeroes. However, it works even with the part held in reset.

[Dan4]

Thanks @CHead​ ,

It seems the issue is there when using a STM32H7 + Ulink Pro + Keil. With STLink everything works OK, but the trace is pretty limited...

It is a very strange problem - the Ulink sees everything bright and clear when accessing at 0xE00E1000 through AP2 (as evident from the debug logs), but when accessing through code at 0x5C001000 (all domains normal run) I only get zeroes. Also when trying to view the DBGMCU registers through the Watches - all is zeroes at 0x5C001000 and at 0xE00E1000 - not sure what AP is the Watch using to access things, I would suppose AP0.

My thoughts are that somehow the MCU is getting jinxed by the debugger access sequences of the Ulink. Even stranger is that if during debug (already started), the part is power cycled, access to the DBGMCU through 0x5C001000 reappears, but then the trace is not properly initialized.

[CHead]

Is it possible the application code is using the power-saving features which might be stopping the clock to the AXI? That would prevent the debugger from seeing 0x5C001000 via AP0, I think.

[Dan4]

No power saving features - all domain are in normal run mode. I first encountered the problem with a custom code, but have thoroughly tested with Cube generated code - same problem.

Interesting is that whether using @Community member​ 's code for trace init or not - the trace works fine. Which should usually not be the case - it is supposed to only work when using it - as has always been the case with using the .INI files with F parts. I guess someone messed up the debug access sequence files.

[jeremi]

I can confirm this problem with silicon Y (Nucleo H743) and V (Nucleo H745) using both Keil and IAR, STLink and JLink. DBGMCU is all zeros under 0x5C001000 and 0xE00E1000. Nucleo H745 with Segger Ozone and JLink works fine, this seems to confirm @Community member​'s assumption it is the debugger access sequence. I asked Segger for their script https://wiki.segger.com/Tracing_on_ST_STM32H743_(SEGGER_STM32H7_Trace_Reference_Board). The problem is HAL depends on DBGMCU->IDCODE for compatibility fixes, which makes debugging difficult.

[Tesla DeLorean]

@STOne-32​  @Amel NASRI​ @Khouloud GARSI​ 

Definitely seeing occasions when the DBGMCU space is unreadable (zero). As @jeremi​ points out, this causes the chip/stepping checks to work incorrectly.

[ms1802]

As with my other post regarding this, I am seeing what Clive mentioned above. I've hacked around for a day now trying all the suggestions I can find and no joy.; the DBGMCU address space returns zeros for me always. This is under code access and debug access.

Has anyone come up with a fix or explanation?

thanks

Mark

[Tesla DeLorean]

As seen from the post flagging I did earlier I got crickets.

As @jeremi​ observes below there is a need to power cycle to fully reset the device, NRST doesn't completely clear everything, and this I believe is purposeful behaviour and relates to reading option bytes, or executing the loader first and protecting against external attack methods. It could perhaps relate to multi-target SWD, and things within the chip that have independent resets.

Needs to be some better explanation of how this can interact with debuggers, not sure if the memory is blocked, or remapped. Not been something I can throw a lot of time/resources at.

[jeremi]

The problem lies probably in the debug access sequence with STLINK. A full power reset is needed for DBGMCU to reappear, this makes testing confusing and more cumbersome. I filed a bug report with Keil/ARM. With the actual Keil MDK 5.29 and STLINK firmware V3J5M2 this bug seems finally gone on a Nucleo H745. ULINKpro appears to be immune. What debugger are you using, Mark?