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.

[Tesla DeLorean]

The H7 is a science experiment, there is more going on inside than is explained. There are also descriptions in the RM that look like typos, but aren't. I'd love to see a die photo..

Given the history I suspect ARM is party to this.

The ST-LINK/V3 is capable of using the multiple AP.

I should probably dig out the ULink Pro and hook up the EVAL's trace port.