program AT90S8515 with AVRISP mkII

The AVR ISP mkII does not support the AT90S8515 by default for programing. There s a simple workaround for that:

Go to the path where your Atmel stuff is installed. In my case it is:

  • C:Program Files (x86)atmelAVR ToolsPartdescriptionfiles
  • Look for the file AT90S8515.xml
  • Locate the <ICE_SETTINGS> part and change the <MODULE_LIST> to [SIMULATOR:STK500:STK500_2:AVRISPmkII] and add a empty <AVRISPmkII/> node like this:


<ICE_SETTINGS>
<MODULE_LIST>[SIMULATOR:STK500:STK500_2:AVRISPmkII]</MODULE_LIST>
<AVRISPmkII/>

embedded stack collision with the variable-memory

There was a strange bug I found which took me ages to find. I was implementing some stuff on a Atmel A90S8515 microcontroller. This device is quite old and has very limited memory. Both Flash and RAM. The problem occurred when sprintf from the standard library was called. When called,  any internal variables were changed (seemingly randomly). The only reason some I figured it out was because there was a soft-PWM implementation, which changed the color of a RGB led. Reading trough forums I found out that the sprintf-function is quite memory consuming, therefore uses a lot of stack related memory. As a heap is not existent (there is no dynamic data), a good reason for the strange behaviour might be the stack colliding with some global variables. Luckily, this hypothesis was underlined by this article. Therefore, what happened is, that the execution of sprintf (consuming lot of memory on the stack), overwrote global variables in the bss and or the data part of the memory. As the compiler is not able to find these kind of bugs, there is no warning or whatever. The solution was found within seconds. Some very large send/receive  buffers (defined as such in the initial phase of  the project) were just re sized from 128 bytes each to 32 bytes each, making more room for the stack!

my atmel microcontroller is continuously reseting

A problem I had multiple times was: I reuse software from the internet, but when i use the software / simulate it, it is constantly resetting! The reason why this is happening is (or can be) undefined reset vectors. This means, the hardware raises an interrupt, which is not hadled by your software. Therefore, make sure that all interrupts which might occure are written in the software, like UART, ADC, etc. related interrupts! Sometimes you just need an empty interrupt service routine:

The avr-gcc compiler will default your missing vector to the reset-vector, as it is a sign of buggy code! Another approach is to us a “catch-all” interrupt vector

which catches all undefined interrupts.