Recently, I asked myself how I would print the call stack of my program. After reading a bit about this, mainly in this document, I decided that I wanted to try it out. Here is my minimal solution (which is not recommended for use in practice).

The basic idea is that once you have a valid game pointer you can get the base address of the previous stack frame and the current return address. These are just the next words down the stack. To get the initial frame pointer, I use gcc’s built-in function for that. Theoretically, it should be possible to get the initial frame pointer via a pointer to the first stack variable of the function, but this method seems unreliable because the compile might deviate from that convention.

#include

void testStack()
{
Dl_info info;
uint64_t* esb = reinterpret_cast<uint64_t*>(__builtin_frame_address(0));
uint64_t* ra = reinterpret_cast<uint64_t*>(__builtin_return_address(0));
uint64_t* saved_esb;
std::cout << "Return address according to gcc: " << ra << std::endl;
std::cout << "--------------------------------------------------------------------" << std::endl;

while (*saved_esb != 0)

{
saved_esb = esb;
uint64_t my_ra = *(esb+1);

std::cout << "Value of current stack base pointer: " << esb << std::endl;
std::cout << "Return address according to me: " << std::hex << my_ra << std::endl;
dladdr((void*)my_ra, &info);
std::cout << info.dli_fname;
if (info.dli_sname)
{
std::cout << ", " << info.dli_sname;
}
std::cout << std::endl;
std::cout << "Value of previous stack base pointer: " << std::hex << *(saved_esb) << std::endl;
std::cout << "--------------------------------------------------------------------" << std::endl;

if (saved_esb != 0)

{
esb = reinterpret_cast<uint64_t*>(*saved_esb);

}

}

}

Here are, for reference, the documentation pages for the functions that I’ve used:

• http://man7.org/linux/man-pages/man3/dladdr.3.html
• https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html

I found an article that nicely demonstrates why thread-safe functions are sometimes not enough and why you als need atomic transactions. To this end, you also have to re-think your class’s interface.

Motivation

After I’ve started working with reward-modulated STDP in spiking neural networks, I got curious about the background of research on which it was based. This led me to the book by Richard Sutton and Andrew Barto called “Reinforcement Learning”.  The book is from 1998 and it’s freely readable on the internet! In the book’s Introduction they cover the example of an agent learning to beat a given (imperfect) agent in the game of Tic Tac Toe. Two remarks have to be made: 1. The agent has to be imperfect because a perfect agent in Tic Tac Toe (if it’s the one doing the first move) can never be beaten. 2. The agent does not learn to play Tic Tac Toe, this skill is assumed, but it learns a value map for its policy.

Since I liked the example and wanted to try it out myself, I decided to write this blog post about it. By the way, the code can be found on github (run ttt_new.py). (more…)

The Atmel 8-bit microcontrollers have fuse registers that can easily be overwritten during bootloader installation. If this happens you won’t be able to program your AVR via a serial programmer anymore. This might result in avrdude giving you the following response:

initialization failed, rc=-1 Double check connections and try again, or use -F to override this check

The most severe bits are the bits RSTDISBL, DWEN and SPIEN. The latter one cannot be overwritten in SPI mode, so that one should be save. You’re completely spoilt however if the RSTDISBL bit is set to zero (remember: fuse bits in AVR are read out as ‘enabled’ when set to 0). In this case you’ll need to use the high voltage programming mode of the AVR which I’ll explain below. The low voltage programming mode (normal ISP mode) cannot be used anymore since the reset pin is then no longer an input pin and it needs to be set to low voltage externally to enable the SPI interface.

Another problem occurs when DWEN is set to zero. This disables SPI programming and enables the debug wire single-wire interface.

To make sure, whether you’ve programmed your fuse bits to funky values try:

avrdude -c PROGRAMMER -P PORT -p DEVICE -n -v

And put the fuse byte values into the fuse calculator at http://www.engbedded.com/fusecalc/.

To resolve these issues, you need to apply high voltage programming as described here: http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon_HVSP_Description.htm

Btw.: There’s also an arduino solution for this problem: http://mightyohm.com/blog/2008/09/arduino-based-avr-high-voltage-programmer/

Helpful guides for me were:

• http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/STK505/Troubleshooting_Guide.htm

• http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/STK505/Programming_the_AVR.htm

• https://www.mikrocontroller.net/articles/AVR_Fuses (for readers capable of reading German)