Autonomous Swarming Robots

Did a lot of troubleshooting with pretty much everyone today. As far as I remember, here is our status:

- Professor Conforth was able to get his sam7 project and board running, therefore ruling out the JTAG usb connector.
- The issue appears to be with flashing to the board. Using Memory map observing software (forgot the name), we tried writing main.bin and other arbitrary values to the flash, but it would not completely store. A simple mdw showed that the values were similar, but not every bit on the board would be accurate. This could be due to noise. Note: the memory is written in Little Endian. If the software shows "12 34 56 78," a mdw will read "78 56 34 12."
-Running a "flash info 0" in OpenOCD showed that the memory locations were all listed as protected, which we felt were causing the inability to write to the locations.
Attempted to run "flash protect 0 0 7 off," but I did not have any results. The syntax for the command is flash protect /bank/ /low/ /high/ /on/off/

As per Kerry's latest email:
Ok, I fixed the flash issue. I changed the script to erase the entire
flash instead of just half. I'm not really convinced it was broken in
the first place.

Anyway, I disassembled the first four opcodes of the bin file, which
are supposed to be vectors for various handlers (load PC with some
address), and it's totally wrong. This means that the startup code (
and maybe the rest of the code) is not being built properly.

Me and Evan updated the program in a new version of the program.

Project Name: Woo_test

In this project, changes were done in the main.c file. A new function was created in order to implement the PLL (Phase Locked Loop) which does the following:
The PLL accepts an input clock frequency in the range of 10 MHz to 25 MHz
The new function is that was created is called:
static void prvSetupHardware( void );
Ran the program but no change in the memory location after a telnet look at the memory. But we can change it manually in the program by the following code:
mww

Another thing that I modified was the clock in the config file to the following:
Previous: flash bank lpc2000 0x0 0x40000 0 0 lpc2000_v1 0 14765 calc_checksum
New: flash bank lpc2000 0x0 0x40000 0 0 lpc2000_v1 2292 14765

We were not sure why "calc_checksum" was in the code but we took that out because the convention was the following:
flash bank lpc2000 0 0

One suggestion by Kerry is that we should look to at the startup program and put a value to a memory location to see if the startup program is running. Tony said that we should look at the 2292 datasheet to look for the specific commands on how to implement this because various microprocessors use different assembly code therefore it is not the same CpE 390.

I think the problem with the OPENOCD has to do with the fact that our source code doesn’t work- maybe it has to do with the timers or clock cycle sync. Today, we tried to manually set the register that controls the pin p0.30 and test if there’s a voltage output. However, it didn’t do anything, as Kerry pointed out that, the values of the registers should automitally set to zero after each clock cycle ( or however we defined it). From poking around in the debug menu, we noticed that the values doesn’t automatically reset. Here are the steps to replicate it:

/* General Purpose Input/Output (GPIO) */
#define IOPIN (*((volatile unsigned long *) 0xE0028000))
#define IOSET (*((volatile unsigned long *) 0xE0028004))
#define IODIR (*((volatile unsigned long *) 0xE0028008))
#define IOCLR (*((volatile unsigned long *) 0xE002800C))
// set io pins for led P0.30
IODIR |= 0x40000000; // pin P0.30 is an output, everything else is input after reset
IOSET = 0x40000000; // led off
IOCLR = 0x40000000; // led on

1) Run OPENOCD debug menu
2) Telnet to localhost via port 4444 telnet localhost 4444
3) Set the direction of the pin by changing the high byte register to 4. Initially, register 0xE0028004 is 0x0000000 – which means that initally, an voltage should exist at p0.30???
mww 0xE0028008 0x40000000
4) Turn on the pin by clearing it ( from the comments in main.c). it should set 0xE0028004 to 0
Mww 0xE002800C 1
5) U can verify the changes using mdw address

As you can see, the IOSET doesn’t change back , so we can infer that the clock is messed up. Another thing we did today was to have the program write to a random flash memory location some value. After debug, the memory didnt change. O yea, one hting we know for sure is that the code does get uploaded to the microprocessor.

I guess for next week, we can focus on checking out why our clock cycle is not working – prodding through the source code and see wats up.

Matt worked on remapping the symbols and the makefile but to no avail. we are still stuck at the 10% on the debug menu. What Matt suggest we do is take out the lpc 2106 and tingle around with it, just to see how the debug menu looks, how it works, and maybe we can learn from that.

Got the syntax errors sorted out. Portmacro.h had to be included in a lot of the header files.
Changed lp2368.ld to reflect the flash and ram sizes (256k and 16k).
Deleted usb and ethernet descriptions from lp2368.ld file

We are now getting "undefined reference" errors, which from a quick google seems to be a linker problem. I posted something in the yahoo group, hopefully we'll get an answer.

===

Everyone should at least be coming into the lab 2-3 times a week to work on software. If I don't see this happening then I'm going to have to start getting on people's cases and assigning time slots; I know no one wants that. That's all I have to say for now.

I'm not sure if anyone's working in the lab today/this weekend (I'll be at home), but I was thinking that some of the errors are coming from variable types such as portBASE_long, etc are not being defined properly because the header file is being called after the file it is actually used in.

We can look at the order the files are being called, or just define those variable types in main.c

Attempted to look as to why there are 399 errors. Checked to make sure that the 4 necessary files are included and they are associated properly in the makefile:
tasks.c
queue.c
list.c
port.c
**Makefile code**:
RTOS_SOURCE_DIR=./FreeRTOS/Source
...
$(RTOS_SOURCE_DIR)/list.c \
$(RTOS_SOURCE_DIR)/queue.c \
$(RTOS_SOURCE_DIR)/tasks.c \
$(RTOS_SOURCE_DIR)/portable/GCC/ARM7_LPC2000/port.c \
*******************
The above files were specified on the FreeRTOS website at this link.
Maybe we need to include these files in another location, I am not sure.
The projects that were looked at or most up-to-date is RTOSDemo.

I tried to make some headway in compiling freeRTOS; no dice.

Evan I'm sorry I deleted the files in your LPC2292-2 project, I was trying something out.

I made a new project from scratch, and tried to see if that would work. I named it RTOSDemo, as it is in the original makefile settings straight from the site download. We should probably try working with this one as the main code for now.

I also copied all the FreeRTOS files into that directory structure, which can be seen when you look into the project tree. I changed the linked resources parameter (Windows-Preferences) to reflect that change. I also included (Project Properties -> Include paths) every directory that the includes were in.

None of that really did anything.

Just to try it out I downloaded FreeRTOS v4.5 (project freeRTOS_4_5_test). Different set of errors, but still similar. If anyone wants to download older ones and test them out, feel free.

So I don't know if the header files themselves have another include file they're missing?

===

I asked Brian to check out how to manipulate the ports. He found that it's just hex numbers and calculated P0.30 (LED on schematic) to be 0x40000000. We changed that in the demo_blink_flash and reflashed the board. We didn't know the pin layout so we weren't positive which was P0.30, but we didn't find any oscillating voltages. One did hit 200mV, but no oscillation.

===

Sidenote: Please write whatever you did for the day before you leave the lab or very soon after. If there's someone following you, then I guess you can transfer info verbally. But if nobody's there to see what you've done so far, by the time they read your post (if any) by the end of the day, it would already been too late.

I also expect specific directory/filenames/etc so that no one gets confused on what to work with when they come in.

There's no point of having this up if no one writes.

Brian didn't link to the actual forum posts:

Yahoo Group

Embeddedrelated.com

Worked with Evan, spent some time trying to figure out why those errors are propagated even though the following changes were made [Thanks to Joe with his post and response from a forum]:
1st Change:
File Name: makefile
Original Line:"-I $(RTOS_SOURCE_DIR)/portable/GCC/ARM7_LPC23xx"
Updated Line: "-I $(RTOS_SOURCE_DIR)/portable/GCC/ARM7_LPC2000" [just the last three characters are different].

2nd Change:
Remove all web server, Ethernet and TCP/IP stack code.

3rd Change:
Edit the file, File Name: ParTest.c [ARM7_LPC2368_Eclipse\RTOSDemo\ParTest\]
Purpose: so it toggles the LED that are connected to your hardware. Check the LED flashing code works using a simple hello world style program before trying them within a FreeRTOS.org application.

We made the necessary updates but still given errors. Seems like header files were still not associated correctly because variables seems to be undefined; thus, the errors message. We tried to fiddle around with that but to no avail.

Right now, trying to get the initial code running and then creating "a simple hello world style program" before using FreeRTOS.org application as specified by the "expert" on the forum.
**UPDATE**
Link, sorry.
LINK: http://tech.groups.yahoo.com/group/lpc2000/message/28975