SAMA5D2 Support

Comments

16 comments

  • Avatar
    Peter Lawrence

    Thank goodness that I'm not the only one.  I have been using it, but it definitely has shortcomings and I haven't been able to use any of the Rowley-provided code except Startup.

    I put in a ticket two months ago reporting that the libchip libraries were missing for the SAMA5D2 package, but present in the SAMA5D3 and SAMA5D4.

    Another quirk that I've noticed is that the Target script is incompatible with the ARM Simulator target.  It tries to poke memory not handled by the Simulator, resulting in a cryptic fatal error with Crossworks.

    0
    Comment actions Permalink
  • Avatar
    Jfernandez

    Excellent. Glad to hear, I don't feel lonely anymore. :)

     

    I'm using Atme's softpack r2.5. Atmel has redesigned their device driver library and is much better than prior. I've not used any of the Crosswork chip libs before, even for D3 and 4.

     

    I do think that whatever the problem is with these basic functions( like LED/PIOB) is related to some new chip setting that is different than D3/D4. It is a simple IO configuration. I'm guessing that it is related to either the securiyy module, but this can't be because that is under NDA, and there is no info that so why would it be on. The other may have to do with IO sets, but that can't be either because I'm using the D2 Xplain ultra device header given by atmel with predefined settings.

     

    However, I do know that it works when JP9 jumper disabled, which runs the atmel preloaded bootstrap. But it doesn't when it is on(boot disabled). This means something is initializing something that no one seems to know about, and not found on any of the demo projects. The at91bootstrap(linux) has some magic stuff in it's startup, which may or may not be it, there is a load of other stuff that could also be, hard to tell.

     

    I hope Crossworks figures this out. It is a great chip and I hate to spend money on IAR, which may have gotten around this, I'm also looking to see.

     

    Anyhow, if you find anything, it be appreciated if you post back.

     

    0
    Comment actions Permalink
  • Avatar
    Peter Lawrence

    I suspect the issue is far more rudimentary: the Crossworks SAMA5D2 package just didn't go through Rowley's customary quality control.  My personal suggestion would be to NOT blindly trust any of the source code in the package until the package has been fixed.

    If you take a look at the "Memory Mapping" section of the SAMA5 datasheets (Section 7 for the SAMA5D2, Section 5 for the SAMA5D3), you'll see that the peripheral addresses for everything are completely different between the chips.

    As you say, Atmel has dramatically changed its softlib package recently, and this adds to Rowley's workload to adjust to the new one.

    Another major problem when using the evaluation board is entirely of Atmel's creation.  I've NEVER encountered an evaluation board that requires huge libraries to be compiled into the program just to write a simple program to flash an LED.

    The problem with the SAMA5D2 evaluation board is that the LED power supply is provided by the Power Management IC (ACT8945).  So, just to write a simple program to flash the LEDs is a major effort to configure the PMIC.  This is true whether the IDE is Rowley or IAR; it is a shortcoming of the SAMA5D2 evaluation board design.

    0
    Comment actions Permalink
  • Avatar
    Peter Lawrence

    Well, I should say *one problem* with the evaluation board. Another is that, despite Atmel publishing an app note (AN-13702) claiming that the evaluation board demonstrates all the low power modes, the evaluation board hardware doesn't support the all-important "Backup with DDR refresh mode".  D'oh.

     

    0
    Comment actions Permalink
  • Avatar
    Peter Lawrence

    Regarding your problem with "EDBG" (Atmel's proprietary CMSIS-DAP variant) not working when JP9 is installed:

    I suspect that you have Rev A silicon.  (I say this because I saw the same thing with Rev A, but I don't think I've seen it with Rev B.)

    Section 14.6.4 of the SAMA5 datasheet says "If the secure ROM code finds a bootable program, it automatically disables ROM access and enables the JTAG connection just before launching the program."

    In other words, when JP9 is installed, it doesn't find a bootable problem and therefore never enables JTAG.  Again, this is another quirk of Atmel's design.  As I said, I think they fixed this in Rev B (but don't hold me to that).

    0
    Comment actions Permalink
  • Avatar
    Jfernandez

    Thanks Peter. 

     

    I think I'm on revB. I have no debugger issues, and I'm using Segger's J-Link and not the onboard EDBG. 

     

    You mentioned the ACT8945A, and I think that is part of the problem because I get an error on init of ACT8945A twi is timing out. I did not notice that the LEDs are being powered directly by ACT8945A. I suspect the IO for the TWI is wrong. I've attempted different configurations to no avail. Not sure why it fails. They also mention the following, not sure if related.

     

    "Occasional board startup problems occurred when powered from a USB source having a weak VBUS level below 4.8V. To
    avoid the voltage drop and consequential startup problems, production boards were assembled with a 0 Ω resistor in place
    of the Schottky diode D9 shown here."

     

     

    0
    Comment actions Permalink
  • Avatar
    Peter Lawrence

    I phrased my earlier post badly.  Any JTAG debugger (internal EDBG or external such as Segger) will be locked out of the SAMA5D2 if it doesn't detect a boot image.  It is written as canon in the datasheet, but I suspect it is Rev A specific.

    Here is a quick and dirty Crossworks project that I drummed up that blinks the LED on the SAMA5D2 eval board:

    https://github.com/majbthrd/SAMA5D2ledblink/

    It is not a good long-term solution, but it might tide you over until Rowley updates their package.

    0
    Comment actions Permalink
  • Avatar
    Jfernandez

    Thank you, Peter. 

     

    I tried your project, but when I try running it the debugger comes up with zeros in the disassembly window. It may be related to what you found with the JTAG, but the project I made from the generic SAMA5D2 template doesn't suffer from this. It is able to load and debug properly even if the boot image is disabled. 

    I will continue attempting to run your project. Maybe if I make a new project for it it will run. 

    0
    Comment actions Permalink
  • Avatar
    Peter Lawrence

    No.  When the SAMA5D2's JTAG is locked out, the JTAG debugger is unable to even talk to the CPU.

    I've used a variant of that code in a variety of ways, including debugging it in SRAM and programming it into flash and booting from it.

    Something else is fundamentally going wrong for you.

    Have you tried the evaluation board's built-in debugger?  When using the built-in debugger, remove the EDBG_DIS jumper, make absolutely certain the Segger is disconnected, and connect the eval board to the computer running Crossworks to the USB-EDBG port.  Select CMSIS-DAP as the Target in Crossworks.

    When using your Segger, make *CERTAIN* that you have installed the EDBG_DIS jumper before connecting and using the Segger.  Select the Segger as the Target in Crossworks.

    0
    Comment actions Permalink
  • Avatar
    Jfernandez

    Yes. The built-in jtag is completely locked out when boot is disabled and it only works when enabled, but I also notice that the code that appears in the disassembly isn't the one from your app it seems to be the bootloader which is now running.

     

    I also noticed that the CMSIS-DAP is unreliable, it doesn't always connect and sometimes it works and other times it does not. This is why I decided to use J-Link instead and it is much more reliable, regardless of the bootloader.

     

    I agree, something is fundamentally wrong.  In particular because when the bootloader runs, there are no problems. I can even deploy on DDR.

    0
    Comment actions Permalink
  • Avatar
    Jfernandez

    I just got your code running under DDR with boot enabled. No problems. But the moment that I disable boot, the debugger shows zeros in the disassembly windows. 

     

    I can only think that the AT91bootstrap in the serialflash is taking care of all the init. 

    0
    Comment actions Permalink
  • Avatar
    Jfernandez

    Crazy... Figured it out with your help, thanks.

     

    You pointed out that the on board EDBG had to be disabled when using jlink. Before disabling it, it was enabled, because at one point it was the only way that J-Link would work. It seems the built-in EDBG plays a role on TWI or ACT8945A. I don't know how else to explain it.

     

    So for anyone else. I have the board setup in the following way and it works with the current SAMA5D2 and the latest(2.5) softpack. 

    1. Boot disabled JP9 jumped

    2. Built-in EDBG disabled

    3. Using J-Link only

    Now, I need to target DDR.

    0
    Comment actions Permalink
  • Avatar
    Peter Lawrence

    Great!

    Here are a few other things that might be of help to someone developing for the SAMA5D2 (particularly with Rowley Crossworks):

    If U10 (QSPI flash) is unpopulated on the SAMA5D2 evaluation board, you probably have Rev A silicon.  (Rev A silicon cannot boot from QSPI flash.)  Seeing "ES A" on the SAMA5D2 is also an indication of Rev A.

    What may be contributing to Jfernandez's issues is the image that is programmed into U9 (SPI flash).  It comes with the factory with U-Boot plus a Linux kernel.  Depending on the JTAG debugger and Crossworks configuration, there may be hardware resets being generated, particularly when debugging starts and/or a Crossworks "Connect".  These hardware reset causes the code in the SPI flash to execute (if JP9 is not installed) again.  This code execution can cause havoc with settings before the JTAG debugger has a chance to assume control again.

    What is very handy for re-writing the flash is Atmel's SAM-BA v3:

    http://www.atmel.com/tools/atmelsam-bain-systemprogrammer.aspx
    https://github.com/atmelcorp/sam-ba

    Here are some cheat sheet commands that may be of help (but check the syntax to see if this is what you want before blindly executing them):

    # make a backup copy of what is on the SPI flash
    ./sam-ba -p serial -b sama5d2-xplained -a serialflash -c read:backup.bin

    # erase the serial flash
    ./sam-ba -p serial -b sama5d2-xplained -a serialflash -c erase

    A goal might be to replace the image programmed on the SPI flash with one that is more friendly to JTAG debugging.  The replacement program image could be as simple as an endless loop.

    The SAM-BA v3 tools can also be used to program a .bin file generated by Crossworks.  However, Atmel's documentation is a bit lacking, so I hesitate to provide specifics that may be wrong.  The boot image is loaded from flash into ISRAM and then executed.  The boot image *MUST* be less than 64kBytes.  One must use the "boot" option in SAM-BA for it to generate the special mangling of the .bin file to provide hints to allow the SAMA5D2 to boot from it.

    0
    Comment actions Permalink
  • Avatar
    Jfernandez

    In that case, I have Rev A and not B. My boards don't have U10 populated. Now comes the pain to get Mouser to change them.. Don't know why they selling old boards. I just got them.

     

    Awesome tips, Thanks again Peter. 

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Not sure what to make of this...

    http://atmel.force.com/support/articles/en_US/FAQ/Using-EDBG-to-debug-SAMA5D2-Xplained-board-and-SAMA5D4-Xplained-board?q=edbg+firmware+upgrade&l=en_US&fs=Search&pn=1

    My experiments suggest that driving NSRST with the EDBG doesn't work on the SAMA5D2-Xplained board but it does work on the SAMA5D4-Xplained.

    0
    Comment actions Permalink
  • Avatar
    Peter Lawrence

    The eval board schematic betrays some of Atmel's design decisions.

    The RESET pin on the external JTAG connector feeds the reset pin of their EDBG AVR32, not the SAMA5D2.  Moreover, their EDBG_DIS jumper just forces said EDBG AVR32 into permanent reset using said signal.

    I presume Atmel realized that triggering RESET with a debugger had unintended consequences.  Anyone using the eval board quickly finds out that hitting the RESET pushbutton has the unpleasant side effect of disrupting the EDBG (and its USB CDC UART).  (It does this because the same reset signal also causes the ACT8945 PMIC to momentarily disrupt the power rails.)

    Hitting the RESET pushbutton also confuses the heck out of Crossworks.  It still erroneously believes it can communicate with CMSIS-DAP debugger and will persist throwing various errors until the user manually right-clicks on Targets to "Reconnect".

    0
    Comment actions Permalink

Please sign in to leave a comment.