[ABANDONED] Data and code graphs are not in sync

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

  • [ABANDONED] Data and code graphs are not in sync

    Hello,

    I'm trying to debug an app with ozone 3.10e and jtrace pro cortex-m on stm32F412.

    In a nutshell, I have an iissue with hardware watchdog fired during flash erasing / writing.


    To toubleshoot, I disabled the watchdog. Here a screenshot of timeline.
    On the data panel, there's a green line that goes to 1 then to 0, flash operations happens
    during this period.
    The issue is that all trace information is loose from the begining of the capture to the last
    write operation of the capture.



    Here is a second screenshot in which I stop the process during the write operation. You can see
    that I have only 120 ms of measure (while around 1.5 second during "normal" operation).



    The third screenshot is a zoom on the second one where you can see the last flash write operation
    captured.



    I'm blind in the most interesting part. What can I do ?

    Thanks
    Julien

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

  • Hello Julien,

    Thank you for your inquiry.
    The timeline is created from the backtrace information that is buffered on J-Trace PRO. This always contains the latest x instructions that have been executed on target.
    Per default Ozone sets the maximum instruction count to 10M instructions.
    This translates to the 1.5s in your setup.

    You can increase this value in Tools->Trace Settings->Maximum Instruction count.

    The buffer is 64 MB in size so usually ~ 80M instructions fit in there maximum, depending on your setup.
    Should that still not cover the flash process you would need to work with breakpoints and halt at the end of the flash process.

    Best regards,
    Nino
    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.

  • Hello Nino,

    Thanks for your answer.
    Maximum instruction count is already set to 100M.

    SEGGER - Nino wrote:



    This translates to the 1.5s in your setup.

    julienD wrote:

    Here is a second screenshot in which I stop the process during the write operation. You can see

    that I have only 120 ms of measure (while around 1.5 second during "normal" operation).



    Ok for 1.5s but If I stop during flash, the trace is only 120ms.
    In fact trace seems to be lost 2 ms before write to flash. Have look to screenshot 2.

  • Hello Julien,

    That is odd indeed.
    To make sure I understand your setup here correctly, you do a Flash program from within your application, is that correct?
    Do you get any error messages in Ozone?
    Is that program part build with optimization enabled?
    Is it a RAM code? If yes did you consider the following?
    wiki.segger.com/Getting_unknow…sses_in_instruction_trace

    Could you provide a reproducer that we could test on an eval board?
    If you set a breakpoint during your flash algorithm, do you see trace data then?

    Best regards,
    Nino
    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.

  • Hello Nino,


    SEGGER - Nino wrote:

    To make sure I understand your setup here correctly, you do a Flash program from within your application, is that correct?
    Correct

    SEGGER - Nino wrote:

    Do you get any error messages in Ozone?
    I think no:

    Source Code

    1. Connected to target device.
    2. Reset: Halt core after reset via DEMCR.VC_CORERESET.
    3. Reset: Reset device via AIRCR.SYSRESETREQ.
    4. Elf.GetBaseAddr(); // returns 0x8000000
    5. Target.ReadU32 (0x08000000); // returns 0x20020000
    6. Target.SetReg ("SP", 0x20020000);
    7. Elf.GetEntryPointPC(); // returns 0x8005D14
    8. Target.SetReg ("PC", 0x8005D14);
    9. J-Link: Flash download: Bank 0 @ 0x08000000: Skipped. Contents already match
    10. Elf.GetBaseAddr(); // returns 0x8000000
    11. Target.ReadU32 (0x08000000); // returns 0x20020000
    12. Target.SetReg ("SP", 0x20020000);
    13. Elf.GetEntryPointPC(); // returns 0x8005D14
    14. Target.SetReg ("PC", 0x8005D14);
    15. Debug.Continue();
    16. Debug.Continue();
    17. Debug.Halt();
    Display All

    SEGGER - Nino wrote:

    Is that program part build with optimization enabled?
    -Og optimise for debug

    SEGGER - Nino wrote:

    Is it a RAM code? If yes did you consider the following?
    Except if there is some in the ST hal lib (very unlikely imho... ;) ) so no.


    SEGGER - Nino wrote:

    Could you provide a reproducer that we could test on an eval board?
    I was some work. But yes. The full project is joined. Open with atollic. Designed for STM32F446E-EVAL. (hopefully I had one ! :D ).
    Few instructions :
    The soft does nothing until you press the blue user button. Then it erases some flash and write some data in flash.
    The yellow led is on from the beginning of the process to the end
    The red led is on only when writing (not during erase).

    I added a "count" global variable that is displayed on the timeline below. It is initialized to 0 just before the first write operation occurs.
    It is incremented during the write process so one can easily see on the timeline what happens.

    Some more investigations on my side:
    If I strictly do a pause: I got very few data.


    If I do a stop after a pause, I have (much) more data:


    but sometimes, the result is.... odd :D



    And If I set a breakpoint during flash, the trace is very very small.

    Julien

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

  • Hello,

    Thank you for providing the setup. With it the reported behaviour was reproducible.
    What is odd is that there is no trace data generated while the MCU is waiting for the button press. This indicates that the target is in some kind of sleep/low power mode.
    Please note that Arm instruction trace can't be used reliably with sleep modes or low power modes active.
    In the sources I saw a couple of WFI instructions and sleep modes. We recommend removing these from your application if your are looking to gather gapless trace data.

    Best regards,
    Nino
    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.

  • Hello,

    Please understand that debugging user code is out of regular support scope, especially as the probe you are using is no longer in valid support period.
    Attached you will find a Trace Example project for a STM32F412 that should run out of the box on any STM32F412 target.
    Could you give it a try and report back if the sample is working?

    If this sample works and your application does not then the issue lies inside the code executed by your application.
    In some way your application is impacting either the debug connection or the trace related initialization of e.g. trace pins and trace clock etc.

    We recommend to find the spot where the trace data starts disappearing and see what registers are being altered in that line.

    Best regards,
    Nino
    Files
    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.

  • Hello,

    SEGGER - Nino wrote:

    Please understand that debugging user code is out of regular support scope, especially as the probe you are using is no longer in valid support period.
    Of course I do understand that you do not have to debug my code. I've provided a smaller code to reproduce.
    Then, I realized that it can be smaller, that's why I sent you several verions. (btw, weTransfer did not notify me that you had downloaded them).

    Investigating further, it seems that it might not be a hole in the trace but maybe a synchronization problem between data and code graph (I changed the title of the topic):

    Here's a really minimum code to reproduce the issue :
    - ST library used only for initialization ( issue is after initialization)
    - no interrupt
    - no OS
    - no low power mode
    - only register manipulation to write in flash (which seems to be what triggers the problem).

    The full project is available here : we.tl/t-6SM8WRI83h

    It writes 30 * 1204 32 bits data to flash sector 7


    C Source Code

    1. int main(void) {
    3. SystemClock_Config();
    5. __disable_irq();
    7. /* Authorize the FLASH Registers access */
    8. WRITE_REG(FLASH->KEYR, FLASH_KEY1);
    9. WRITE_REG(FLASH->KEYR, FLASH_KEY2);
    11. while ((FLASH->SR & FLASH_FLAG_BSY) != 0) {
    12. }
    14. //--- erase sector 7
    15. CLEAR_BIT(FLASH->CR, FLASH_CR_PSIZE);
    16. FLASH->CR |= FLASH_PSIZE_WORD;
    17. CLEAR_BIT(FLASH->CR, FLASH_CR_SNB);
    18. FLASH->CR |= FLASH_CR_SER | (7 << FLASH_CR_SNB_Pos);
    19. FLASH->CR |= FLASH_CR_STRT;
    21. while ((FLASH->SR & FLASH_FLAG_BSY) != 0) {
    22. }
    24. //--- write 30 * 1024 32bits values to sector 7
    25. for (uint32_t i = 0; i < 30 * 1024; i++) {
    26. count++;
    27. uint32_t address = 0x08060000 + i * 4; // sector 7
    29. CLEAR_BIT(FLASH->CR, FLASH_CR_PSIZE);
    30. FLASH->CR |= FLASH_PSIZE_WORD;
    31. FLASH->CR |= FLASH_CR_PG;
    33. *(__IO uint32_t*) address = i;
    35. while ((FLASH->SR & FLASH_FLAG_BSY) != 0) {
    36. }
    38. FLASH->CR &= (~FLASH_CR_PG);
    39. }
    41. // lock flash
    42. FLASH->CR |= FLASH_CR_LOCK;
    43. while (1) {
    44. }
    46. }
    Display All
    It leads to this graph which is obviously wrong : count variable is incremented after SystemClock_Config is over.




    Best regards
    Julien

    The post was edited 2 times, last by julienD ().