Atmel Start ASF4 Bug List

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

I have now been using the Atmel Start (AS4) tool for 8 months and I have compiled a list of the bugs I have found so far. Please feel free to add to this list. I hope this will help the developers to fix these bugs.

 

I have been using a SAMV70 chip and IAR with Atmel Start. You may see different bugs depending on the CPU you are using. While some of these bugs may seem easy to fix, they all cost time to find. Also, each one of these has to be fixed over and over again every time I run Atmel Start to make a change to the code.  This is a time consuming and error prone manual process.  I have to copy the generated files to a new folder and use a Merge tool to manually check every change that Atmel Start has made to my code  and put back all the customizations and fixes back into the code. This defeats the purpose of having a tool to make it easier for developers to generate quality code more quickly.

 

ATMEL START BUG LIST

1) Atmel Start  generates code for the timer counter tclite.c driver that does not compile.

It generates the following code in tc_clite.c that does not compile without errors.

tc0_channel_cb[channel] = cb;

It should be:

tc0_channel_cb[channel] = (tc_channel_ptr) cb;

This has to be fixed for every tc channel enabled.

 

2) I am using custom values for stack size and heap size. Since Atmel Start has no place to add these parameters, it generates a linker file that overwrites these changes in config/linker/Microchip/atsamv71q21b/sram.icf

 

3) Atmel Start generates the code for USB CDC virtual comm Port driver.   Since it just an example and not really a driver,  the code has a while – forever loop that assume you are only running this code.  You have to edit this file every time you generate code from Atmel start so that the rest of your code can be called.  The tool should be able to generate this a standalone driver rather than example code that needs to be edited each time.

 

4) The USB driver itself (usb_start.c) has some wait loops that will cause the driver to hang, instead of timeout. For example:

 

while (!cdcdf_acm_is_enabled()) {

                   // wait cdc acm to be installed

               };

If the ARM processor starts up before the USB host (which usually happens) then the code will hang here and eventually trip the watchdog timer.  If the ARM code needs to run in the absence of a USB host, this loop will not let that work. This has to be patched each time the tool is run

 

5) Any other user customizations are overwritten each time the tool is run.  This means that the programmer has to manually merge changes each time Atmel Start is used. Other CPU vendors provide hooks in the code for the user to add customizations that will not be overwritten. 

 

6) The SAMV70  has an Errata where the ADC inputs are not properly initialized if the PIO pull-ups on the ADC pins are not set to PULUP_NONE before the ADC is initialized. Otherwise the internal pull-ups can be enabled causing the voltage readings to be wrong.

The Atmel Start tool does not do this pullup disable. That means I have to modify driver_init.c to call a routine that disables the pull-ups on all used ADC channels before the ADC is initialized.

 

7) I have several TimeCounter modules enabled. Some use the tc_lite driver and some use the hal_timer driver.  In Driver_init.h the tool generates the following code:

#include <tc_lite.h>#include <hal_timer.h>
#include <tc_lite.h>#include <tc_lite.h>

This causes a compilation error. It should generate the following code:

#include <tc_lite.h>
#include <hal_timer.h>

 

8) I later converted all of the timer counters to use the tc_lite driver.  However, Atmel Start did not remove the #include <hal_timer> includes from driver_init.h.  These files no longer exist in my design, so the compiler gives me an error because the file is not found.

 

9) The asynch USART driver does a poor job of handling USART errors. It clears them without calling the USART error callback (see my other post for details, https://community.atmel.com/foru...)

 

10) This method of using a web based tool instead a downloadable configuration app makes it impossible for a developer to archive a snapshot of all the tools used to develop a particular code release.  Microchip can change the code generation in Atmel Start at any time.  This means that when a developer pulls release code ifrom a stored archive after several years and a minor configuration change is made using the latest web version Atmel Start, there is no guarantee that it will generate the same code as it did originally.

 

If the tool was a standalone app, then the tool could be archived with the users’ source code. That would guarantee that it generates the same code.  For many safety critical products it is important to have an archive that generates the exact same code. And what happens if Microchip decides to discontinue the web based version of Atmel Start in the future? There would be no easy way to make modifications to the code.

 

I have had days where Atmel Starts gives me a message like this: "Atmel Start could not generate the code. Please try again later."  This means the programmer has to stop working on the code until the website is running again. A standalone tool would not have this problem.

 

If you have found other bugs, please list them in this thread so that these bugs can be fixed.  There are many other things that can be changed in Atmel Start to make it better and easier to use. I will put those in a different post for Atmel Start Improvements.

Last Edited: Mon. Nov 30, 2020 - 04:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CpuDude wrote:
I hope this will help the developers

I think you'll have to raise a case with Microchip to get their attention:

 

https://www.avrfreaks.net/commen...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@awneil, The fact is that Microchip has released a new set of drivers, ASF4 that contains a lot of bugs. They really should have done more testing before releasing it.  They want users to do the Alpha testing on their product, instead of investing the time to do it themselves because it is cheaper for them.

 

I do not have the time to file multiple case reports on each issue. I have deadlines and work to do.  I am sure others are not filing cases for the same reason.  I am grateful for the support I have gotten on this forum.  It has saved me a lot of time. However, Microchip could have done better supporting their ARM products. If they want to use these forums as way to have users provide  the technical support that the vendor  used to provide themselves, then I think it is fair to use these forums to give the feedback on their product.  Maybe it will push Microchip to act. At least we will be providing a reference for others so they will not have to waste their time on the same bugs.

 

I am sure I am not the only one that has found bugs in ASF4. I am hoping that others will add to this list. I see that over 45 people have read this in just a few days. Add your bugs to the list.  If there were just 1 or 2 bugs, maybe it would be worthwhile to file a case report. However, I am not going to spend my time filing case reports because Microchip did not spend the money to test or support their product properly.

 

I am also using an ST Micro ARM chip on a project. I have used their code generation tool and never had to report a bug.  Their tools are better and easier to use.  Their tools provide output reports and pin lists which ASF does not. Their documentation is better. They have Youtube videos that show how to use their drivers in different use cases. Microchip should provide a similar level of support without expecting their users to do all the work of finding their bugs and filing reports.

 

Last Edited: Thu. Dec 3, 2020 - 11:11 PM