STM32H743 DBGMCU register reads as zero when using ETF-Trace

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • STM32H743 DBGMCU register reads as zero when using ETF-Trace

      Hi!

      Setup:

      I am using Ozone 3.10b and a STM32H743 @ 480MHz.

      I've set up ETF trace according to wiki.segger.com/STM32H7#Tracing_on_ST_STM32H743
      In the trace settings dialog, I set the source to Trace Buffer, and CPU Frequency to 480000000.

      I'm using the .pex file from

      wiki.segger.com/images/b/b8/ST…43_400MHz_TraceBuffer.zip


      Problem:

      After the OnTraceStart() hook of the pex-File is run, the DBGMCU->IDCODE register at 0x5C001000 reads 0x00000000 instead of the expected 0x20036450.

      This can also be seen in Ozone's memory view. OK without trace, 0 after OnTraceStart.

      The problem is only resolved by a power cycle. A reset is not sufficient.


      This is problematic, because the IDCODE register is used by ST's HAL code to enable errata workarounds:

      github.com/STMicroelectronics/…s/system_stm32h7xx.c#L229

      github.com/STMicroelectronics/…m32h7xx_hal_adc_ex.h#L579

      github.com/STMicroelectronics/…/stm32h7xx_ll_adc.h#L2572


      best regards,
      Thomas
    • Googling for 0x5C001000 turns up some interesting results..

      This might be relevant to you:

      xor-gate.org/post/stlink-arm-ap-access/

      "On the STM32H743 there is an APB-AP on APSEL 2 which I suppose may be present on other STM32's as well. Through this AP you can access the DBGMCU at its documented address 0xE00E1000. However, if you use the standard ST-Link memory access commands they will clobber AP2's CSW.DbSwEnable bit. This then prevents accesses to the DBGMCU via AP0 (and presumably the CPU) at 0x5C001000. Access can be restored by manually setting AP2's CSW.DbSwEnable with the new Write AP Reg command."
    • Hi Thomas,
      Thank you for your inquiry and sorry for the delay in response.

      We are able to reproduce this.
      Thank you for making this known to us.

      We will see if we can find a solution for this that works out of the box.
      As a work around you could write your own script where you implement the solution provided in the article.

      Best regards,
      Fabian
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/


      Or you can contact us via e-mail.
    • New

      Hi Thomas,
      Sorry for the delay in response. We have pretty busy days right now (preparations Embedded World, etc.).
      We looked at this again.
      The issue is in the HAL.c and not in the way how the memory accesses are executed.
      To access the DBGMCU registers from CPU space (your application), you are supposed to use 0xE00E1000, see STM32H7 reference manual:

      (Taken from RM0433)

      Therefore we suggest that you correct the HAL-init to use the right address space (see above).
      The work-around/hack is not recommended.
      We recommend getting in contact with ST, since this is an error in their HAL which should be fixed in the ST sorces.

      Best regards,
      Fabian
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/


      Or you can contact us via e-mail.
    • New

      Hi!

      SEGGER - Fabian wrote:

      Therefore we suggest that you correct the HAL-init to use the right address space (see above).
      I think you may have posted the wrong screenshot. Perhaps you meant chapter 59.5.8. ?

      But, unfortunately, 0xE00E1000 also reads as zero.


      You should be able to reproduce that result on your side.


      SEGGER - Fabian wrote:

      The work-around/hack is not recommended.
      I was not yet able to find a work-around..

      Of course, I could fake the HAL_GetREVID function, but we have a mix of Rev. V and Y in the field, so a real solution is needed.


      SEGGER - Fabian wrote:

      We recommend getting in contact with ST, since this is an error in their HAL which should be fixed in the ST sorces.

      ST has an open bug tracker on GitHub.. but what exactly should I report?


      Best regards,
      Thomas

      The post was edited 1 time, last by thomask77 ().