[SOLVED] Segger J-Trace on ATSAME70-XPLD

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

  • [SOLVED] Segger J-Trace on ATSAME70-XPLD

    Hello,

    I try to use trace with the Microchip demoboard, but I am unable to get the trace working.
    I found the AppNote for setting up the trace for Keil MDK-ARM IDE: Advanced Debugging with ETM for SAM V7/E7/S7 MCUs
    ww1.microchip.com/downloads/en…with-ARM-ETM_App-Note.pdf

    In chapter 7.1 is written that:
    IAR has not yet implemented its own ETM configuration. The configuration must be added in the user software.
    So I understand that you need to config the device first, pins and so on. But how is this possible with Ozone.
    Can you maybe provide a trace example for this device atsame70q21 too?

    Regards, Dave
  • Hello Dave,

    Trace example projects for Ozone can be found on our Website for multiple devices including the SAME70:
    segger.com/products/debug-prob…echnology/tested-devices/

    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,

    thank you very much for your help.
    I try this example but I can't see any trace date after open the instruction trace windwos.
    Do I need to add some trace timings on the demoboard?
    And why do I need a JLinkScriptfile requested at support@segger.com?
    Is this file responsible for device setup (pins and so on) and why not for free download?

    Regards, Dave
    Ozone V2.56g
    J-Link V6.30j
    Images
    • Same70_NoTrace.PNG

      57.9 kB, 1,159×746, viewed 470 times
  • Hello Dave,

    The project is designed to work out-of-the-box for the Smart SAME70 Xplained Ev. Kit.
    See screenshot attached. Everything is working as expected.
    Which eval board are you trying to debug?
    Did you use the project from the Wiki? wiki.segger.com/Tracing_on_Atmel_ATSAME70
    How did you load it in Ozone?
    Per default the Eval board has no Trace pin header equipped. Did you solder one to it?

    Do I need to add some trace timings on the demoboard?

    Not if you are using the mentioned eval board. For other hardware that might be needed.

    More information about troubleshooting in trace setups can be found here: segger.com/products/debug-prob…hnology/setting-up-trace/

    And why do I need a JLinkScriptfile requested at support@segger.com?
    Is this file responsible for device setup (pins and so on) and why not for free download?

    Yes that file sets up device specific settings e.g. clocks and pins.
    It is included in the example project as a compiled .pex file.
    It is designed as generic as possible for the mentioned eval board so it simply works for the user without needing to worry about it.
    The Source for the Scriptfile is not freely available to protect our IP.
    However we offer the J-Link script for the Cortex-M Trace Reference Board in source form as reference so the user gets an idea on how to implement such init for custom or unlisted hardware.

    Best regards,
    Nino
    Images
    • Capture.PNG

      130.33 kB, 1,761×1,021, viewed 473 times
    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,

    Trace:
    I try the example again on a new demoboard and it works.
    The only different, in my opinion, is the chip lable.
    OK: ASTAME70Q21AN 1714C A AF8BDB
    FAIL: ASTAME70Q21AN 1535C A AD7FMA

    Do you know if there is any changes in this chip affecting the trace?

    JLinkScriptfile:

    If I have a custom hardware can I still use the .pex file from the example and just add this line in the .jdebug file?

    void BeforeTargetConnect (void) {
    Project.SetJLinkScript("./ATMEL_ATSAME70_TraceExample.pex");
    }
    Because there is no possibility to use different pins and clock for trace.


    I am still unable to understand what kind of IP you try to protect.
    All you need to do with other trace systems is:
    // Trace Clock Setup
    PMC->PMC_WPMR = 0x504D4300; // Disable PMC write protection
    PMC->PMC_PCK[3] = 0x4; // Select Master clock for ETM
    PMC->PMC_SCER = PMC->PMC_SCER | (1<< 11); // Enable PCK3
    PMC->PMC_PCER0 = PMC->PMC_PCER0 | (1 << 16); // Enable PIOD clock
    // Trace Pin Setup
    PIOD->PIO_WPMR = 0x50494F00; // Disable PIOD write protection
    PIOD->PIO_PDR = 0x000001F0; // Disable Peripherals PD04..PD08
    // Set Peripheral C for PD04..PD07 and Peripheral D for PD08
    PIOD->PIO_ABCDSR[0] = PIOD->PIO_ABCDSR[0] & (~0x0F0)|0x100;
    PIOD->PIO_ABCDSR[1] = PIOD->PIO_ABCDSR[1] | 0x1F0;

    Regards, Dave
  • Hello Dave,

    Great to hear that trace is working for you on the other board.
    OK: ASTAME70Q21AN 1714C A AF8BDB
    FAIL: ASTAME70Q21AN 1535C A AD7FMA


    This sounds really strange. Especially as we only have the 1535C A AD7FMA in house which is how I created the screenshot in my last post.

    Do you know if there is any changes in this chip affecting the trace?

    I could not find any errata explaining this behaviour. We suggest contacting Microchip in that regard.

    If I have a custom hardware can I still use the .pex file from the example and just add this line in the .jdebug file?

    The same pex/JLinkScript can be used with custom hardware as well if the same GPIOs are used for tracing as on the eval board hardware the example project is created for.
    Should you have timing issues or can't commit all 5 pins for full 4-bit trace you can configure this within Ozone as explained on our website "Setting up Trace".

    Because there is no possibility to use different pins and clock for trace.

    Some target devices offers this option though so we try to stay as flexible as possible with our Scriptfiles.

    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,

    I found the problem with the second demoboard. Bad connection to the trace pins, now fine on both boards.
    When I start the example it looks not good. If in line 34 never is true (please see picture).
    I use the *.pex in my Ozone project. Works but I am still unable to understand why you can't offer a *.JLinkScript for this mcu.
    The second problem I have is that the reset is not working fine with trace enable. When I start debug the second time I alway see a hardfault.
    I also add a picture of this problem.
    It would be very nice if you can help me.

    Regards, Dave
    Images
    • TraceDemoIf.PNG

      42.99 kB, 1,169×341, viewed 435 times
    • TraceReset.PNG

      289.68 kB, 2,556×1,170, viewed 443 times
  • Hello Dave,

    This looks strange indeed. Just retested it with the project from Wiki with ozone V2.56g and J-Link DLL V6.30k and line 34 was executed normally as seen in my previous picture.
    Try updating to J-Link software V6.30k and see if the issue resolves.
    As the previous issue was linked to "bad" wiring could you try setting trace to 1-bit trace?
    To access this option simply open the trace project in Ozone and go to Tools->Trace Settings...
    Here you can switch between different trace sources and the number of trace pins used. Default for ETM trace is Trace Source = Trace Pins and Trace Port Width = 4-bit.
    Try switching this to 1-bit for the example project. Does it work now?

    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.
  • Now it works but not clear why.
    I use the demoboard also with my code. If I clear the chip with the erase pin and download your demo code it works fine.
    But if I use the board with my code befor I see this problem.
    Is there any setup in Ozone like clear chip complete befor debug?

    Regards, Dave
  • Hello Dave,

    Currently there is no option implemented in Ozone to delete a chip. Ozone will automatically erase and overwrite memory on the target if it is different from the application you are trying to debug/download.
    However you can use the J-Link Commander in parallel to Ozone and use the "erase" command there prior to debugging.

    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,

    sorry for delay, but finaly I was able to create just a small project with trace problems on SAMe70q21.
    Please try to trace this with j-Trace pro Firmware 2018 Apr 20 and Ozone V2.56i and same70-xpld board.
    The project will maybe stop at a breakpoint. This is just to show a other M7 bug.
    If you than just try to continue, stop and use single step the mcu show very strange behavior.
    I try to reproduce this with two differnet PC and two demoboards and two j-Trace so I hope you can also see this problem with your setup.
    If not, I can also do a video for you.

    Regards, Dave
    Files
    • BugDemo.zip

      (997.85 kB, downloaded 329 times, last: )
  • Hello Dave,

    The project you provided does not contain an elf file for debugging.
    Rebuilding did not work as Atmel Studio kept rewriting some files once launched.
    One thing we noticed is that your Ozone project does not include the pex file for the Trace init. This is required for Trace to be initialized and working.

    Does it working when using the latest J-Link software and Ozone version?

    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,

    yes, you're right the pex file is missing. Perhaps it works because I run a other project with the pex-file befor. Be that as it may, I add it to the jdebug file.
    I remove the *.elf file because of the 1.05MB data limit. But I send the same zip file to microchip and they can build it so maybe there is a pack missing in you atmel studio.
    Please try again with the attachments.

    Regards, David
    Files
    • BugDemo.zip

      (574.17 kB, downloaded 281 times, last: )

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

  • Hello Dave,

    We are not quite sure what we should see with the example project?
    Tracing is working as expected and the example application runs to the "Dummy_Handler" and keeps counting the execution counter up.

    Please understand that we can't put more time into this as the trace example application from our Wiki is working normally.
    So from J-Trace perspective everything is working correctly.
    Any issues you see with target hardware specific code we suggest discussing with the target hardware manufacturer.

    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,

    sorry for the insufficient problem description, but I still don't think that trace is working as expected.
    For example the Dummy_Handler is located at 0x0040019C (see Program counter picture). But trace data stops with a BLS at 0x00401286.
    So you see the core execution the dummy_handler, but can you also see this in the trace data?
    Or the HAL_timeUsGet call from the TC1_Handler, just try to trace this execution.
    For me it looks like trace hide some core executions.

    Regards, Dave
    Images
    • traceData.PNG

      323.31 kB, 2,576×1,416, viewed 375 times
    • missingTimeUsGet.PNG

      54.67 kB, 1,886×363, viewed 404 times

    The post was edited 5 times, last by Dave ().

  • Hello Dave,

    Looking at the provided screenshot it seems that you are issuing a Reset(PB12).
    Is this reset resetting the SAME70 target device?
    If yes keep ind mind that a working trace after external reset is not guaranteed as all trace related registers will be reset as well.
    To trace over a reset either set a BP after the reset and run Ozone again, then the init steps will be handled by Ozone.
    Alternatively you can init the trace related registers through your applications if you need to keep the application running after reset.
    So the complete trace init must be set by your application after the reset has been executed.
    Please understand that we can't assist you in such an endeavor as this outreaches any general support.

    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,

    I'm totally unable to understand what you mean with Reset(PB12).
    This function just resets the uC pin PB12, as you can see in the code I provided to you.......... (Or look at the assembler code 0x400E1034 => (PIOB) Clear Output Data Register)
    I understand that you can't support if there is any hardware problem.
    But here is something wrong with the segger tool, as you will find out if you just grab the same70q21 demo-board and try the code I uploaded.

    Regards, David
  • Hello David,

    With your second BugDemo.zip we were able to reproduce the behaviour and are currently looking into it.

    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 David,

    Our findings are as follows.
    The Bugdemo had the BeforeTargetConnect() commented out. So no Scriptfile was loaded.
    That way the Ethernet Controller on the eval board was distorting the trace signals.
    If you enable it trace should work perfectly well again.

    We will consider this thread as solved now as this was a setup issue.

    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.