[SOLVED] Ozone Instruction Trace Not Working Running In DRAM ATSAMA5D27

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

  • [SOLVED] Ozone Instruction Trace Not Working Running In DRAM ATSAMA5D27

    I'm using Ozone for instruction trace with a ATSAMA5D27.

    Initially a bootloader is run from SRAM and trace and breakpoints work well at that point. But as soon as execution is started in DRAM the instruction trace listing is mostly 0xFFs.

    Using J-Link Ultra+ with Trace Buffer setting. Perhaps there are settings related to memory access that need to be tweaked when executing in DRAM.

    Thanks
  • Hello,

    Thank you for your inquiry.
    Make sure that all memory areas that are being traced are added to the tracecache:
    wiki.segger.com/Getting_unknow…sses_in_instruction_trace

    Per default all areas that have been downloaded by J-Trace PRO to the target during the session are added. But i some cases with e.g. Bootloaders or DRAM J-Trace PRO does not have that core parts in trace cache yet for analysis.

    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.
  • Thanks, that was very helpful! The trace is working now.

    Since I don't fully understand what the ReadIntoTraceCache command is doing, can you provide details? Is there a limitation to the number of bytes cached? For example, I have a fairly large app loaded into DDRAM and would like to be able to trace all of it. It's well over a MB.
  • Hi,

    Actually, what the command is pretty self-explanatory:
    By default, J-Link caches the download of your application on debug session start and later uses that cached contents during trace.
    Reading always from target memory would be too slow for streaming trace and real-time analysis.
    If you need to trace without prior download or you need to trace regions that are not part of the image you have downloaded, you need to tell J-Link once to read that regions and cache them as well.
    This is what the command does.
    In your case, if your application exceeds 1 MB, you may need to modify the call that is done in the example.
    As the word says, it is just an example.
    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.
  • Correct.
    Because Ozone needs to know what is running on the target to be able to crossreference the received compressed trace stream from the target.

    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.