DBGMCU ID code not available by software on STM32H7A3

[MatthiasJ]

We have been trying to access DBGMCU on an STM32H7A3 via software. The background is that the project shares code that in an other project runs on an H743 and for example needs to adjust how it interacts with the flash.

We’re now experiencing the strange behaviour that when a debugger is connected the DBGMCU ID code reads correctly as 0x10076480. When no debugger is connected it reads as zero (0x00000000). This is the case when debugging using GBD or when connecting via STM32CubeProgrammer. Connecting via STM32CubeProgrammer to an already running processor makes it readable. After disconnecting it reads zero again.

We’ve tried accessing the ID both via

AL_GetDEVID()
HAL_GetREVID()

as well as directly via

DBGMCU->IDCODE

with the same results.

Testing access to the writable parts of DBGMCU show a similar behavior where it works when connected to the debugger but not otherwise.

Now we are wondering if there are any clock or power configurations that could lead to such a behavior. We’ve seen similar topics for other MCUs where enabling Debug Module RCC peripheral clock was the solution but we can’t find mention of such a clock in the Reference manual for the H7A3.

[KDJEM.1]

Hello ​@MatthiasJ and welcome to the community;

 

Which STM32CubeProgrammer version are you using?

Could you please share a screenshot when you read 0x00000000 using STM32CubeProgrammer?

 

Thank you.

Kaouthar

[MatthiasJ]

Hello ​@KDJEM.1,

I’m currently using v2.22.0 of the STM32CubeProgrammer. But the programmer always reads the correct value. It is the firmware that reads the wrong value - but only if the programmer is not connected.

 

DBGMCU->IDCODE	Firmware Reads	Programmer Reads
Programmer Connected	0x10076480	0x10076480
Programmer not Connected	0x00000000	n/a

Best
Matthias

[KDJEM.1]

Hello ​@MatthiasJ ;

 

Could you describe the steps you followed that to read wrong value? 

Could you please share screenshots for the issue?

 

Thank you.

Kaouthar

 

[MatthiasJ]

Hello ​@KDJEM.1,

Since direct debugging isn’t an option we are using a JSON via USB serial interface to read out the information. Please see below screenshots of the code used to test, the output collected from it and a screenshot of the STM32CubeProgrammer when connected and displaying the correct values. Note that Mode = Hot plug to enable connecting and disconnecting the STM32CubeProgrammer during a single run making it clear that the same code during the same run behaves differently depending on the STM32CubeProgrammer being connected or not.

For clarity please note that the tests described run inside our full firmware, not a minimal project. The main reason for this is that the behavior is influenced by debugging so any test environment would have to at least implement one of our serial drivers to get data out. If necessary we can prepare a minimal project to further investigate this but it will at the very least need to contain some serial driver code.

It is quite possible that there is a difference in what peripheral clock domains are active compared to a bare STMcubeIDE project. Is there any documentation on clock domains that are automatically activated when debugging or are needed by DBGMCU?

Test Code:

static void JsonGet_ProcessorInfo(sJsonEngine_Typedef *psJsnEng) {
#ifdef FLASHSIZE_BASE
    uint32_t ulFlashKb = *(uint16_t *)FLASHSIZE_BASE;
#else
    uint32_t ulFlashKb = 0;
#endif

#ifdef PACKAGE_BASE
    uint32_t ulPackage = *(uint16_t *)PACKAGE_BASE;
#elif defined(SYSCFG_PKGR_PKG)
    uint32_t ulPackage = (SYSCFG->PKGR & SYSCFG_PKGR_PKG_Msk) >> SYSCFG_PKGR_PKG_Pos;
#else
    uint32_t ulPackage = 0xFFFFFFFFUL;
#endif

    psJsnEng->sResponse.lLen =
        sprintf(psJsnEng->sResponse.pcBuff,
                "{\"DEVICE_ID\":%lu,\"REVISION_ID\":%lu,"
                "\"FLASH_KB\":%lu,\"PACKAGE\":%lu,\"DEBUGGING\":%s,\"SEQ\":%ld}",
                HAL_GetDEVID(), HAL_GetREVID(), ulFlashKb, ulPackage,
                (CoreDebug->DHCSR & CoreDebug_DHCSR_C_DEBUGEN_Msk) ? "true" : "false",
                psJsnEng->sResponse.ulSequenceNumber);
    psJsnEng->sFlag.sDo.ulFlushResponseBuf = SET;
    psJsnEng->sFlag.sDo.ulComplete = SET;
}

Output generated:

{"DEVICE_ID":0,"REVISION_ID":0,"FLASH_KB":2048,"PACKAGE":0,"DEBUGGING":false,"SEQ":14} 
{"DEVICE_ID":0,"REVISION_ID":0,"FLASH_KB":2048,"PACKAGE":0,"DEBUGGING":false,"SEQ":17} 
{"DEVICE_ID":0,"REVISION_ID":0,"FLASH_KB":2048,"PACKAGE":0,"DEBUGGING":false,"SEQ":20} 
{"DEVICE_ID":1152,"REVISION_ID":4103,"FLASH_KB":2048,"PACKAGE":0,"DEBUGGING":true,"SEQ":23}  
{"DEVICE_ID":1152,"REVISION_ID":4103,"FLASH_KB":2048,"PACKAGE":0,"DEBUGGING":true,"SEQ":27}  
{"DEVICE_ID":0,"REVISION_ID":0,"FLASH_KB":2048,"PACKAGE":0,"DEBUGGING":false,"SEQ":31} 

Screenshot of STM32CubeProgrammer when connected:

Best regards
Matthias

[Mike_ST]

Hello,

 

please try to add

RCC->CKGAENR&=~(RCC_CKGAENR_JTAGCKG);

before calling the HAL_GetDEVID(), HAL_GetREVID() functions.

 

And after reading the IDs you can do:

RCC->CKGAENR|=(RCC_CKGAENR_JTAGCKG);

to reactivate clock gating.

Source (last post):

https://community.st.com/stm32-mcus-products-25/stm32h743xi-silicon-y-dbgmcu-dead-75722/index2.html

[MatthiasJ]

That does it. Thank you, ​@Mike_ST.

For reference the same thing in using HAL-style macros:

CLEAR_BIT(RCC->CKGAENR, RCC_CKGAENR_JTAGCKG);  // force the clock enabled
(...);
SET_BIT(RCC->CKGAENR, RCC_CKGAENR_JTAGCKG);  // reenable automatic mode