[SOLVED] Ozone, how to generate automatic coverage report

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

  • [SOLVED] Ozone, how to generate automatic coverage report

    We are using Ozone for code coverage at runtime.

    We would like to integrate the code coverage report in our continuous integration platform so it can run every time we build a new release.

    Is there a way to signal Ozone to execute commands after the Debuging session has started?
    We would like to run it for a certain time and then stop the debug session and save the code coverage report.

    For what I can see the only way to execute something in an automated way is to set a breakpoint with the script and than attach a function to the breakpoint.
    This solution does not work because it is break point dependent.

    Ideally it would be enough that we can set a callback after a timeout and not on breakpoint hit.
    Or even better a way to inject commands from a console.

    I believe automated code coverage could be an excellent use of Ozone and J-Trace and with a little effort could be achieved since the main function is already part of Ozone.

  • Hello,

    Thank you for your inquiry.
    As you already mentioned you can solve this with the hook function on a BP hit as explained here:
    wiki.segger.com/Automated_Tests_with_Ozone

    Could you elaborate why this solution would not work for your setup?

    A timeout dependent approach should also work by calling Util.Sleep.
    So you could execute your complete test in OnProjectLoad() and to the exports after the timeouts. Keep in mind though that if you are exporting the instruction trace window the target must be halted for that.

    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.

  • Hi Nino,

    thanks a lot for your reply.

    Until.Sleep in the OnProjectLoad() is what was needed.

    The function callback on a breakpoint would be a bit more cumbersome.
    We would need to modify our test sequence so the firmware would hit the breakpoint only at the end of the test sequence.


    Now we have one last small issue.
    When we call File.Exit() we get a warning that prevents ozone to close meaning the command from the command line never return.

    Is there a way to suppress the warning? "Clicking the button "Ignore & Do Not Show Again" does not work.

    The warning says: "The core support plugin for the selected target could not be loaded. In order to specify the plugin's file location manually, add command "Project.SetCorePlugin(filepath) to the project file.

    Thanks again for the help!
    Stefano

  • Hello Stefano,

    Great to hear that it is working for you now.

    ugolini wrote:

    The function callback on a breakpoint would be a bit more cumbersome.
    We would need to modify our test sequence so the firmware would hit the breakpoint only at the end of the test sequence.
    I see, but it would be the "clean" way. As the delay is a software delay on host PC the test results can be different between different test runs and this is usually something one wants to avoid when running tests.
    Breakpoints make sure that each test is executed exactly the same way no matter where the setup us so the exported trace data is comparable.
    You can also set BP via Ozone script without changing your FW. This is shown in the sample I linked you earlier. So if your FW has test functions already implemented you just need to set the BP via Ozone script on the exit point.


    ugolini wrote:

    Now we have one last small issue.
    When we call File.Exit() we get a warning that prevents ozone to close meaning the command from the command line never return.
    This is a known issue and will be fixed in V3.10b which should be released by the end of the week.
    Sorry for any inconveniences caused.

    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.

  • Hi Nino,

    we still have issue trying to run ozone with our elf file.

    After spending some time, it seems the issue is related to the elf file itself. and the

    this map our map file for the linker.

    Source Code

    1. /* Specify the memory areas */
    2. MEMORY
    3. {
    4. BOOTLOADER (rx) : ORIGIN = 0x08000000, LENGTH = 48K /* 16K sectors 0 to 3 */
    5. BOOTLOADER_DATA (rw) : ORIGIN = 0x0800B400, LENGTH = 16K /* 64K sector 4 */
    6. FLASH_FIRMWARE (rw) : ORIGIN = 0x08020000, LENGTH = 896K /* 128K sectors 5 to 11 */
    7. BOOT_DATA (rw) : ORIGIN = 0x08100000, LENGTH = 16K /* 16K sector 12 */
    8. FLASH_FIRMWARE_IMAGE (rw) : ORIGIN = 0x08120000, LENGTH = 896K /* 128K sectors 17 to 23 */
    9. RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 192K
    10. MEMORY_B1 (rx) : ORIGIN = 0x60000000, LENGTH = 0K
    11. CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K
    12. }
    14. /* Define output sections */
    15. SECTIONS
    16. {
    17. /* The startup code goes first into FLASH */
    18. .isr_vector :
    19. {
    20. . = ALIGN(4);
    21. __FLASH_FIRMWARE_BASE_ADDRESS = .;
    22. KEEP(*(.isr_vector)) /* Startup code */
    23. . = ALIGN(4);
    24. } >FLASH_FIRMWARE
    Display All
    When we run ozone with File.Open(foo.elf)

    The firmware is flashed at address 0x8000000 while it should be at 0x0x08020000.
    probably is because Elf.GetBaseAddr(); // returns 0x8000000

    If we flash the firmware manually using File.Load(foo.elf, 0x0x08020000) and we run the profiler, the code coverage seems not aligned.

    Is it possible that the issue is caused by how ozone decode the elf file?

    Thanks.

    Best regards.

    Stefano

  • Hello Stefano,

    According to your map file the base address of the elf file is 0x8000000.
    So not sure what the error should be.

    If you just want to flash and debug the firmware at 0x8020000 then make sure the bootloader image is not part of the elf file.
    Alternatively if you want to keep the bootloader and FW in one image you can set the PC and SP in AfterTargetDownload and AfterTargetReset as explained here:

    wiki.segger.com/Debug_on_a_Target_with_Bootloader


    With the difference that you want to launch from the FW instead of the bootloader.


    ugolini wrote:

    If we flash the firmware manually using File.Load(foo.elf, 0x0x08020000) and we run the profiler, the code coverage seems not aligned.
    This is expected as you introduce a 0x20000 offset on your application which according to your map file starts at 0x0 offset.

    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.