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.
