ARM processor update

For the last few weeks I have been banging my head against the wall trying to get an Atmel SAM7S256 processor up and running. It has taken lots of time, but I think I see the end of the tunnel. Last night was a watershed moment when I got the real time operating system running a single thread.

So far I have run into many problems. The tool chain is not intuitive at all. The Eclipse/Yagarto/OpenOCD system can’t seem to use hardware breakpoints in the GUI. I can use the command line tools, but that is extraordinarily cumbersome. So I have been doing the nasty assembler level debugging with my work IAR compiler.

Over the last few days I have hit two bugs in the Micrium RTOS port for the Atmel SAM7S256. Admittedly the port was for IAR and not the GNU tool chain so some of the problems I hit may be related. Most notably was an issue with spurious interrupts and one where registers were not properly pushed and popped when calling a C routine from ISR level. Perhaps the IAR compiler leaves registers untouched, but the GNU tools clobber registers.

Tonight I hope to get the RTOS scheduler (timer tick) routine working and have two tasks running at the ‘same’ time. If I can get over that hurdle then I can start writing code to control my robot!

I may also write a simple Python program to interface to OpenOCD and allow me to automate the hardware breakpoint issue. I should be able to do most of my debugging using test points and RS-232 messages, but for those tough nuts, I will need something other than the work IAR compiler I have very limited access to. If you are aware of a way to get hardware breakpoints to work in Eclipse, I would LOVE to hear from you!

As an update to this update, I was able to get multiple threads running this evening as well as an OsTimeDelay. Does not seem like much, but it was a major accomplishment. Now I can clean up some loose ends and start writing uBlox6 code and cross track error algorithms for my robot!