[SOLVED] 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
  • [SOLVED] STM32H743 DBGMCU register reads as zero when using ETF-Trace

    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.

    Keep in mind, this is *not* a support forum.
    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.
  • 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.

    Keep in mind, this is *not* a support forum.
    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.
  • 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 ().

  • Hi Thomas,
    Sorry for the delay in response.
    We had a lot to do for the last weeks and looking into this is very time consuming.

    We were able to narrow down the problem and found out that it is not caused by any script file functionality, but by the generic initialization for Trace that we are doing for all Arm devices.
    Our generic initialization is compliant to Arm standards, and this is the first device showing such a behavior.

    We will look at this further this week (most likely today) and see what we can do here.

    Best regards,
    Fabian
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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.
  • Hi Thomas,
    Good news, we finally found the root cause of the issue and fixed it.
    Thank you for making this issue known to us.

    The fix will be part of the next patched release (6.70h), planned for tomorrow, as a firmware update.
    It will be available here:
    segger.com/downloads/jlink#J-L…twareAndDocumentationPack

    Could you please give said version a try and come back to us if it works as expected?

    We are sorry for any inconvenience caused.

    Best regards,
    Fabian
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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.
  • Cool!

    I just installed Ozone_Linux_V310h_x86_64.deb and updated my JLink using JLink_Linux_V672a_x86_64.deb

    Everything seems to work now, DBGMCU registers can be read out correctly and trace still works.

    Thanks for the great fix!

    We can now enable ETF by default for all our debug sessions!
  • Hi Thomas,
    Good to hear that you are up and running again.

    We will consider this thread as closed now.

    Best regards,
    Fabian
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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.