Atmel Start ... sigh.

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have used Atmel processors on numerous boards for over 10 years.  I really like Atmel Studio.  I selected a SAME54 part and was forced to use START / ASF4 because its not supported in ASF3.  Before I get to the really negative parts I will state a few things:

 

  • It's a good idea, and the overall implementation is pretty good.  
  • I particularly like the pin editor and selecting pins in modules which helps prevent bad pin assignments from pin mux confusion.
  • ASF4 is a complete rewrite of the libraries and parts of these libraries are better implemented, specifically asynchronous I2C is better and CAN implementation was better.

 

Now the part you probably want to hear.

 

  • Yesterday, the server gave me "Failed Loading Project".  It persists today.  Old archived versions of the project also don't load.  My guess is there was a server update that broke my project.  It's only a guess because I am given zero information to diagnose the problem.
  • Let me be crystal clear to the START developers.  I am in the middle of tight deadline and look to be forced to re-enter a complex project from scratch. 
  • NEVER EVER do this to me, this is a very serious issue.  I will never use ASF4 / START again for this reason alone, and probably will need to abandon Atmel processors.  This is the exact fear of using an online project configuration tool, it can disappear and break at any time.  This is not a toy for me, it is not a hobby.  You can't just break project loading and provide zero information on how to correct the problem.
  • ASF4 is a complete re-write of the libraries.  All my old shared code for multiple boards on this project is non-functional.  You cannot mix / match ASF3 and ASF4 code.
  • ASF4 documentation is non-existent.  What I could find is basically just a list of function calls. ASF3 documentation was stellar in comparison.
  • There are almost no example projects for my processor.  The code generator has some examples in it but they are inadequate.  
  • In order to do anything complex you have to go into the library code to figure out what it is doing.  This code has sparse documentation and parts of it are written in absurd abstract ways by a code generator that only serious C developers can reverse engineer.  Thankfully I can do this, but 20 years ago it would have been a hopeless endeavor.
  • The cycle time for loading, changing a minor parameter, exporting is too long.  I ended up going into the generated configuration headers and changing it there.
  • Some modules aren't well developed yet.  The I2S module doesn't allow advanced implementation and the code generator has bugs that I had to track down and fix manually.  Every time I export code I have to go back in and re-fix the code.

 

Summary.  Good idea.  95% implemented well.  The last 5% are an absolute deal breaker.  Things I would like to see:

 

  1. Diagnostics on failed project loads and access to previous server implementations.
  2. Better ASF4 documentation and better examples up to the previous ASF3 standard.
  3. A less abstracted version of library code.
  4. Access to library code for modules not in the START project.
  5. A way to run START when I don't have online access.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wholeheartedly agree!

 

To work around a lot of those problems I find myself loading the project back into START, making changes or adding components, exporting the source code to a new project, then MANUALLY merging the new code into my project (WinMerge is my diff program of choice right now).

 

One thing to try for the failed server import - manually edit the atmel_start_config.start file and delete modules under the drivers section, one by one until it imports.  In my case the server failing to load was fixed by removing the CRYPTOGRAPHY_0 section.  The rest of the project loaded fine.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Disclaimer: I've been assimilated by the Borg and have fully embraced Atmel START surprise.  Yes, it has its holes and quirks, but it has allowed me to configure (and reconfigure) large and complex systems for the SAME54 rapidly.

 

When the server gave you the "Failed Loading Project" error, was that using the web browser or from within the Atmel Studio "Re-Configure Atmel Start Project" menu item? 

 

I ask because the I've seen that message ("Failed Loading Project") from within Atmel Studio, when actually there was a dialog window (hidden under the main window) asking if it was safe to reload the project.  That has thrown me for a loop a couple of times, and more a failing of Atmel Studio 7 than Atmel START.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried both Atmel Studio and loading the files manually in my browser.  It's not a corrupted file because all the archived projects are broken too (!!!).

 

The project loader knows where it failed, or it should.  If it gave me an error such as "failed to load object I2S" then it would give me somewhere to look.  If they update their server code there ought to be a way to know that, and what was changed.  This would also allow me to debug it.  I'm just editing the config files now.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I just ran across a CAN bus driver bug.  CAN bus memory buffers must be in memory locations <64K.  It was reported over 7 months ago and a support ticket was opened.  
https://www.avrfreaks.net/forum/...

 

Never fixed, along with another bug reported in the same thread.  It's a bit abysmal when somebody takes the time to document a bug in your library and you take no action.  

 

So I did a search on all the drivers in my project, every single one of them is:
#define DRIVER_VERSION 0x00000001u

 

This device/API has basically been abandoned.  Perhaps it's the takeover by Microchip and the typically disaster that happens after a takeover.

 

Ugh.  

 

EDIT: For any poor soul that runs into this.  The issue is the RXBC register is only 16 bits long.   The driver treats it like a 32 bit register.  The end result is CAN happily chugs along and gives you message buffers from la-la land on receive.

I just edited the project file and moved hpl_can.c so it was the first file compiled to force the fifo's to be allocated early and in lower memory.

Last Edited: Sat. Jan 19, 2019 - 11:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update: So I went through the process ... compared a working file against the corrupt one.  The header does show a new "content" version for whatever that means.  This is the offending section on the right in the I2S section, I have no idea what that is doing:

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yea, trying to start a new SAME54 project, and I just always keep getting errors.  My first foray into playing with these devices, and the tool that they advertise everywhere as being awesome hasn't been able to give me a project for 3 days now.  

 

Hand coding it all up with a half dozen reference pdf's open I guess.  I'm typically a just type by hand guy, but this would be a nice reference honestly to just see how *they* would layout and implement certain functionality.

 

Edit: Now working, as long as I blew my old project away and then selected no pins at all.  It's just weird thoug hwhen I select something like the ATSAME54 Xplained Pro devel kit, that when I choose SPI ports it comes up with bad pin mappings as the defaults...

Last Edited: Thu. Jan 24, 2019 - 05:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The I2S pin mapping was also a total mess.  I could not unmap I2S input pins that I wasn't using for I2S receive, and it would "secretly" change the function of some pins from GPIO to I2S.  So I was strobing the power enable of my amp at 48 KHz.  I'd fix it, regenerate the project, and regenerate the bug.  I thought I was through with this but then apparently they updated the server and it started doing the same thing to another pin.

I would report these problems but it is apparent from other threads that Atmel is not acting on any bug reports, and they certainly don't apparently care what anyone says in a forum.

I would have literally saved time by avoiding ASF4 and writing code to the bare metal.  This thing has potential but the flaws are serious, correctable, and need addressed.

Don't even get me started on trying to get ASF4 to do linked DMA transactions.  Totally non-functional, and literally impossible to do without rewriting parts of the driver.  

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bumping this thread to see if your opinion of ASF4/Start has changed at all.

 

I made the decision to move to ASF4 because I was about to take a pile of prototype spaghetti code and start building it into something resembling production firmware.  I figured that it made more sense to start with the latest environment rather than continue with ASF3.  The more involved I get with ASF4, the more I regret that decision.  Basic functionality is severely lacking, documentation is largely absent, and help from Atmel/Microchip is slow at best.  

 

For example, take the SPI driver, The API page for it has this under limitations: " The slave select (SS) is not automatically inserted during read/write/transfer, user must use I/O to control the devices' SS. "

WHY? WHY WOULD YOU DO THIS? The entire chip select behavior can be configured in hardware so that you never have to explicitly toggle an IO line to drive the Chip Select lines.

 

The abstraction also hits absurd levels at times, with 4 or more levels of function calls to do something as simple as set a baud rate register.

I already had to re-write a chunk of the I2C driver to implement internal address functionality (again, built right into the hardware), and now I'm re-writing a ton of the SPI driver just to make it acceptable.  I need to add in my own DMA functions as well since those are missing despite being listed as an option in the API documentation.  AS3 had drawbacks and horrible bugs that perpetuated throughout versions despite numerous people reporting them, but AS4 is just...bad.