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.

[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.

[Dan4]

Yes, totally agree. I especially like the mentions of the second core...

The ST-LINK/V3 looks promising. I only have to test if the 24MHz SWO support will hold up to debugging sub-usec IRQ handlers, like in my case.

[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

[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?

[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.

[ms1802]

I'm using Crossworks and a Nucleo-H743ZI2. With a Rev V Part.

I'm sending out the rev id  HAL_GetREVID() via a webserver so I can see the version ID 'real time'

I've just played around with this again and it is related to the NRST as clive suggests.

It seems no matter how many NRST's you issue, the DBGMCU is going to read 0's once its had a debugger attached. (so starting up with a debugger its never going to read anything but 0's - ie normal development!)

It works after a hard power cycle without a debugger attached - my webserver reports the right REVID.

As soon as you attach a debugger (even when running), the DBGMCU all comes back as zeros, therefore REVID changes to 0 too.

This causes real problems when running the device in debug mode as the REVId is invalid in the HAL startup code where its used,

Also, as in my original post, trying to stop the clocks when debugging ( eg the IWDG when in a debug break!) is not going to work as the flags for all this are in the DBGMCU and not writable. Oh the irony!

Mark

[jeremi]

The problem seems to be connected to STLINK and Rev V. You could try to update the STLINK per STSW-LINK007, file a bug report with Crossworks, use a different debug adapter or consider another IDE. IAR, Keil and Segger Ozone all work for me now.

[Gpeti]

What is the status of this issue ? I'm trying to write DBGMCU_APB1LFZ1 in order to make my timer freeze during stepping, and I've found out that I can't. I thought there was an enable bit somewhere in RCC for the DBGMCU peripheral but I didn't find one.

Is it possible to use the timer freeze functionality on STM32H743 (Nucleo, rev Y, Keil) ?

EDIT: I tried to access this register through both adresses