Progress, sort of
- Posted by: ENg • 30 October, 2007
Worked with Joe in the lab today. Using the modified cfg and script files from yesterday, we were able to write main.bin from the demo_blink_flash project to the jtag board. We had to change the address location for the flash bank, you can see the changed line at the bottom of the cfg file. This location reflects the correct address for the LPC2292. We were trying to run the debugger to see if we could observe variable changes (reflecting the blinking of an led), but we were unable to get the debugger working properly. The debugger tutorial we were using is found on around page 130 of the Lynch tutorial. You can bring it up on Simm's website.
Next steps: Successfully debugging the demo code in Eclipse
Needed but harder to do - getting FreeRTOS ported and running on the board
Next steps: Successfully debugging the demo code in Eclipse
Needed but harder to do - getting FreeRTOS ported and running on the board
Jtag communication
- Posted by: DNguyen • 29 October, 2007
As per Joe's post - Evan and I were able to modify the configuration files so that we can communicate from the JTAG. we had to modify the memory mapping. the modified setting s in [this file] are [insert comment / tbd - whenever i get the full address]
We were able to establish a connection from the jtag usb thingy to the board cuz we did some raw commands and it outputted 'lpc2000' after u communicate with the jtag, the usb dongle turns orange from green , which means that there's communcation. in that stage, you can telnet to localhost using port 4444 and do raw commands. we tried to write some bin files to the processor but it gave us some error- that's for troubleshooting tomorrow.
I think the next step is to try to get the project up and running ( the makefiles is fucked up)
Important: to have some source code control system
After working on the project, just make an extra copy of the project, zip it up or whatever, and name it with a date and your name. So Dien_10-30.zip
We were able to establish a connection from the jtag usb thingy to the board cuz we did some raw commands and it outputted 'lpc2000' after u communicate with the jtag, the usb dongle turns orange from green , which means that there's communcation. in that stage, you can telnet to localhost using port 4444 and do raw commands. we tried to write some bin files to the processor but it gave us some error- that's for troubleshooting tomorrow.
I think the next step is to try to get the project up and running ( the makefiles is fucked up)
Important: to have some source code control system
After working on the project, just make an extra copy of the project, zip it up or whatever, and name it with a date and your name. So Dien_10-30.zip
Flashing progress
- Posted by: JSalomon • 25 October, 2007
I was at the lab today, trying to figure out how to flash the board. I created a new Make Managed (you don't have to make your own makefile config) project "lpc2292." I tried using the blinking led demo found on the olimex site for the 2294 board. I couldn't get it to build because it was calling GPIO0_clr_bit while the header had GPIO0_clr_offset. I'm not sure if they're the same. The original lcd.c called for . I was trying to find that file online so that I could compare our header file with it; no luck so far. I set the configuration file as sam___.cfg. It's what openocd calls when you use the external tool "OpenOCD - FreeRTOS".
I ran into Matt on the way out, and he pointed me in the right direction. A couple things he says need changing are the .cfg file and the .script file called within the .cfg file. Both are memory address changes.
The crt.s file is no longer needed. You can delete that if it's still in the project.
If we can figure that out this weekend, we'll be doing well. Please try to do some research or head into the lab when you can. Thanks.
P.S. The Drivers were already installed.
I ran into Matt on the way out, and he pointed me in the right direction. A couple things he says need changing are the .cfg file and the .script file called within the .cfg file. Both are memory address changes.
The crt.s file is no longer needed. You can delete that if it's still in the project.
If we can figure that out this weekend, we'll be doing well. Please try to do some research or head into the lab when you can. Thanks.
P.S. The Drivers were already installed.
FTDI Drivers
- Posted by: JSalomon • 25 October, 2007
[Sidenote: I deleted the WYSIWIG add item editor b/c it was buggy in adding non-media files]
As Evan mentioned, the drivers may be needed. I'm not sure yet, b/c Matt had to have been able to communicate in his previous project. Here they are from ftdi's site:
FTDI Drivers
Hopefully I'll have some time today to go into the lab and play around with it.
As Evan mentioned, the drivers may be needed. I'm not sure yet, b/c Matt had to have been able to communicate in his previous project. Here they are from ftdi's site:
FTDI Drivers
Hopefully I'll have some time today to go into the lab and play around with it.
.cfg file continued...
- Posted by: ENg • 25 October, 2007
Found a pretty good link that looks at the same ideas Joe was reading up on.
http://forum.sparkfun.com/viewtopic.php?p=35601&sid=8e764d10c1f8985f24603b4b57b0c168
Here some guy is trying to flash OpenOCD onto his LPC2294 processor. If you look at his .cfg file, it's practically the same. The interface section is different because they're using a parallel port, but we already have the FTDI commands. The user's post also contains a link to a tutorial on how to set up automated flashing on LPC2000 processors. It's simply adding another small script file, which they give an example of for us to use. There was a section in the tutorial mentioned that we would be needing extra drivers for our interfaces (which another site said caused our FTDI error). The drivers can be found here:
http://www.yagarto.de/
I think the drivers in addition to the cfg and script files should put us in good shape.
http://forum.sparkfun.com/viewtopic.php?p=35601&sid=8e764d10c1f8985f24603b4b57b0c168
Here some guy is trying to flash OpenOCD onto his LPC2294 processor. If you look at his .cfg file, it's practically the same. The interface section is different because they're using a parallel port, but we already have the FTDI commands. The user's post also contains a link to a tutorial on how to set up automated flashing on LPC2000 processors. It's simply adding another small script file, which they give an example of for us to use. There was a section in the tutorial mentioned that we would be needing extra drivers for our interfaces (which another site said caused our FTDI error). The drivers can be found here:
http://www.yagarto.de/
I think the drivers in addition to the cfg and script files should put us in good shape.
Better functionality
- Posted by: JSalomon • 25 October, 2007
Added better formatting options
Can upload any file type
30mb per file limit
Can upload any file type
30mb per file limit
OCD Flashing
- Posted by: JSalomon • 25 October, 2007
So here are my findings from the past couple hours of research..
[EDIT: added a formatting plugin. Code style still buggy and probably unuseable. Overall much better fuctionality.]
The basic process as how I've interpreted it:
Create new project in Eclipse and define the 'make' definitions such as the type of output file (hex), etc.
Write the c code and whatnot.
Build project. Based on the make definitions of the project, this should output a filetype that OCD can flash, usually a .bin file.
Run OCD external tool
1) Within Eclipse, OCD can be ran as an external tool as some of us already saw today. The important items here are the arguments being passed.
2) As can be seen, it's pointing to a .cfg file. This file basically allows communication for the USB-JTAG connection as well as tells which memory bank to flash. I found this file for an lpc2138 board:
I'm not sure if we can use those memory locations or if we have to edit them.
3) The header files may have to be modified as well, depending on the memory addresses, etc.
[EDIT: added a formatting plugin. Code style still buggy and probably unuseable. Overall much better fuctionality.]
The basic process as how I've interpreted it:
Create new project in Eclipse and define the 'make' definitions such as the type of output file (hex), etc.
Write the c code and whatnot.
Build project. Based on the make definitions of the project, this should output a filetype that OCD can flash, usually a .bin file.
Run OCD external tool
1) Within Eclipse, OCD can be ran as an external tool as some of us already saw today. The important items here are the arguments being passed.
2) As can be seen, it's pointing to a .cfg file. This file basically allows communication for the USB-JTAG connection as well as tells which memory bank to flash. I found this file for an lpc2138 board:
======= lpc2xxx_armusbocd.cfg
#daemon configuration
telnet_port 4444
gdb_port 3333
#interface
interface ft2232
ft2232_device_desc "Olimex OpenOCD JTAG A"
ft2232_layout "olimex-jtag"
ft2232_vid_pid 0x15BA 0x0003
jtag_speed 3
#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst srst_pulls_trst
#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe
#target configuration
daemon_startup reset
#target
#target arm7tdmi
target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4
run_and_halt_time 0 30
working_area 0 0x40000000 0x40000 nobackup
#flash configuration
#flash bank lpc2000 0 0
flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v1 14765 calc_checksum
flash bank cfi 0x80000000 0x400000 2 2 0
# For more information about the configuration files, take a look at:
# http://openfacts.berlios.de/index-en.phtml?title=Open+On-Chip+Debugger
==========================================
#daemon configuration
telnet_port 4444
gdb_port 3333
#interface
interface ft2232
ft2232_device_desc "Olimex OpenOCD JTAG A"
ft2232_layout "olimex-jtag"
ft2232_vid_pid 0x15BA 0x0003
jtag_speed 3
#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst srst_pulls_trst
#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe
#target configuration
daemon_startup reset
#target
#target arm7tdmi
target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4
run_and_halt_time 0 30
working_area 0 0x40000000 0x40000 nobackup
#flash configuration
#flash bank lpc2000 0 0
flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v1 14765 calc_checksum
flash bank cfi 0x80000000 0x400000 2 2 0
# For more information about the configuration files, take a look at:
# http://openfacts.berlios.de/index-en.phtml?title=Open+On-Chip+Debugger
==========================================
I'm not sure if we can use those memory locations or if we have to edit them.
3) The header files may have to be modified as well, depending on the memory addresses, etc.
The new site
- Posted by: JSalomon • 25 October, 2007
So I figured a blog would be the best way to share our information. I wanted a different theme, but the skin installation was being extremely lame so this is it for now. I'll trust you guys with finding your way around.
I made two categories: Research and Updates. One for any helpful information we find and the latter for any working updates of the project that you yourself have done. You can put any type of work in here, but I made it mainly to help us out while we're programming because we're not all going to be in the lab at the same time. I figured this was better than keeping a notepad open on the lab pc. Just make sure to specify the right category when you post an item.
Just post anything you've done and comment on others' findings as well. It's great if everyone is researching, but it's even better if someone researches from where someone else left off.
I can import this to our real Senior D site once the time comes.
I made two categories: Research and Updates. One for any helpful information we find and the latter for any working updates of the project that you yourself have done. You can put any type of work in here, but I made it mainly to help us out while we're programming because we're not all going to be in the lab at the same time. I figured this was better than keeping a notepad open on the lab pc. Just make sure to specify the right category when you post an item.
Just post anything you've done and comment on others' findings as well. It's great if everyone is researching, but it's even better if someone researches from where someone else left off.
I can import this to our real Senior D site once the time comes.