modifications to IE_setup.c/.h and uartio.c/.h
the goal is to create buffered and unbuffered version of the various input and output routines that involve the uart. dma will manage one half of the swinging buffer while user is interacting with the other.
in addition create a means to implement the xmodem protocol towards the end. I actually implemented xmodem completely in mc6800 assembly years ago so doing so in C should be too tasking.
IE_setup.c
create
egwu_setup_gpdma
generic gpdma configuration routines
egwu_nvic_gpdma_isr
call table for all 8 channels using pointer to void function
egwu_dma_hook_channel_isr
add user isr to call table above
egwu_dma_unhook_channel_isr
remove user isr from call table above
IE_uartio.c
create
egwu_uartio_fflush
uses dma transfer to clear out one half of the tx swinging buffer
egwu_uartio_tx_dma_isr
user isr to hook unto gpdma isr call table (for any of 8 channels)
egwu_uartio_printf/putc
printf will be buffered
putc will be unbuffered
egwu_uartio_getc/getch/gets
for now gets will be unbuffered but that might change
getc and getch will be unbuffered with the latter simply looking at the
rx fifo flag and returning a code indicating presence or absence of a
key/character
Sunday, August 9, 2015
Monday, July 27, 2015
Phase 1: Complete
blogger.com actually allows you to upload a video. cool. first time trying out this feature .. without specifying a youtube link.
video above is the completion of phase 1. was out on sick day today ... took the time to bug hunt after I got some sleep. system/pll/systick/interrupts/gpio all configured. but there were issues:
found a bug with my interrupt vector table initialization for the 256 positions (the maximum possible) though the lpc17xx only provides 40 peripheral interrupts for a total of 56 when you include the 16 core exceptions.
I was stupidly overwriting portions of the code in SRAM. this bug was easy to catch ... it was a silly mistake because I actually wanted to cover the best case scenario and reserve the first 1k for the IVT.
then I later decided what the hell thats a waste of space when only 224 bytes will be used I could save almost 700 bytes to use for program memory or a thread stack
in my Makefile now specifying
-fno-inline
and
-fno-implement-inlines
to decrease code size bloat. although I have 512kb of flash ROM, i am loading the code into the 64k of SRAM to make debugging easier. in flash rom i would be limited to 4 or 6 hardware break points verses an unlimited amount when I load into SRAM ... so I am sticking to SRAM for now, but to pull that off I have to stick to non macro functions to keep the size of the program in check.
changed NVIC pre-rempt priority grouping to 2. Allowing me to use all 32 interrupt priority levels.
Configured exceptions 4 + 5 + 6 to priority level 0
11+14 to priority level 1
15 (systick)to priority level 2
all peripheral interrupts will start from priority level 3 (highest) to 31 (lowest)
Absolutely no interrupt nesting ... keep interrupts small and simple. The NVIC does handle that feature (nesting and tail chaining) in hardware ... a big plus
bug in failing to call
Calling NVIC_EnableIRQ(15) after setting up systick registers. Dumped the interrupt SET/ENA registers and realized it wasnt set
Found a bug in how lpcopen' Chip_GPIO_GetPinState() works. Decided to read the pin directly and write it out to toggle the keep-alive-LED
//wdTemp = Chip_GPIO_GetPinState(LPC_GPIO1, LPC_LED_PORT, LPC_LED_PIN);
//Chip_GPIO_SetPinState(LPC_GPIO1, LPC_LED_PORT, LPC_LED_PIN, wdTemp);
wdTemp = (((LPC_GPIO1->PIN) >> LPC_LED_PIN) & 0x1);
wdTemp ^= 0x1;
if(wdTemp == 0)
(LPC_GPIO1->CLR) = (1 << LPC_LED_PIN);
else
(LPC_GPIO1->SET) = (1 << LPC_LED_PIN);
Phase 2 begins now. Need to write a useful serial terminal monitor program to ease communication with this board.
2:40am ... powering down ... engaging sleep mode routines
Sunday, July 19, 2015
Phase 1: Interrupt Vector Table not being initialized
the offending lines are in egwu_setup_nvic(). here is the gdb dump:
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
(gdb) load
Loading section .text, size 0x1c78 lma 0x10000000
Start address 0x10000e38, load size 7288
Transfer rate: 1 KB/sec, 3644 bytes/write.
(gdb) c
Continuing.
Breakpoint 1, egwu_setup_nvic () at core/IE_egwu_setup.c:167
167 ptrTemp = (volatile unsigned int *)EGWU_IVT;
(gdb) p /x EGWU_IVT
$1 = 0x10010000
(gdb) monitor mdw 0x10000000
0x10000000: 10010000
(gdb) monitor mdw 0x10000004
0x10000004: 10000e39
(gdb)
And of course EGWU_IVT is declared in IE_egwu_ivt.S. This is where the vector table is placed along with the labels EGWU_IVT and EGWU_IVT_END. I also created an extern int EGWU_IVT in IE_setup.h
But the value of the label EGWU_IVT resolves to the first value in the table (the address of the stack pointer on reset). but in the map file flash.map
.text 0x0000000010000000 0xe0 ivt.o
0x0000000010000000 EGWU_IVT
0x00000000100000e0 EGWU_IVT_END
Just now noticed that &EGWU_IVT resolves to 0x10000000 as expected.
(gdb) p /x &EGWU_IVT
$2 = 0x10000000
Very odd, will need to go reread the "as" assembler documentation. Its customary for the value of a label to represent the value of the location counter at that point.
Anyway this is resolved ... moving on
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
(gdb) load
Loading section .text, size 0x1c78 lma 0x10000000
Start address 0x10000e38, load size 7288
Transfer rate: 1 KB/sec, 3644 bytes/write.
(gdb) c
Continuing.
Breakpoint 1, egwu_setup_nvic () at core/IE_egwu_setup.c:167
167 ptrTemp = (volatile unsigned int *)EGWU_IVT;
(gdb) p /x EGWU_IVT
$1 = 0x10010000
(gdb) monitor mdw 0x10000000
0x10000000: 10010000
(gdb) monitor mdw 0x10000004
0x10000004: 10000e39
(gdb)
And of course EGWU_IVT is declared in IE_egwu_ivt.S. This is where the vector table is placed along with the labels EGWU_IVT and EGWU_IVT_END. I also created an extern int EGWU_IVT in IE_setup.h
But the value of the label EGWU_IVT resolves to the first value in the table (the address of the stack pointer on reset). but in the map file flash.map
.text 0x0000000010000000 0xe0 ivt.o
0x0000000010000000 EGWU_IVT
0x00000000100000e0 EGWU_IVT_END
Just now noticed that &EGWU_IVT resolves to 0x10000000 as expected.
(gdb) p /x &EGWU_IVT
$2 = 0x10000000
Very odd, will need to go reread the "as" assembler documentation. Its customary for the value of a label to represent the value of the location counter at that point.
Anyway this is resolved ... moving on
Friday, July 10, 2015
Phase 1: No external clock
ran into the following problem last night when I ran my initialization code, that I decided to manually check this out myself:
arm-none-eabi-gdb
JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Only resetting the Cortex-M core, use a reset-init event handler to reset any peripherals or configure hardware srst support.
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
(gdb) monitor mdw 0x400fc1b0
0x400fc1b0: 00000003
(gdb) monitor mdw 0x400fc1a0
0x400fc1a0: 00000009
(gdb) monitor mww 0x400fc1a0 0x39
(gdb) monitor mdw 0x400fc1a0
0x400fc1a0: 00000039
(gdb)
Basically after setting bits 4 and 5 of the system control register I checked to see if bit 6 (OSC status) would return a 1 ... meaning the external crystal/clock driver is enabled and I can switch clock sources from the internal 8Mhz RC clock to the precise 24Mhz external clock source Ill need later.
No dice
Looked at section 3.8.2 of the lpc1778 reference manual. Noticed that Cx1 and Cx2 should be either 18pf each or 39pf each depending on what the crystal (JF VNY 24Mhz) Cs and Rl parameters are.
Brought up my schematic and noticed this mistake:
Dont know what I was thinking when I put in a 12pf capacitor where an 18pf or 39pf cap was needed. Knowing my luck its probably the latter ... Ill know once I track down the crystal data sheet.
In either case I bought both on ebay (50 of each) but it wont get here until at least another two or three weeks ($1.50 for 50 ... cheaper from China but long wait times. I could have gotten it from Mouser but I dont need it that quick).
Fortunately all isnt lost. I dont need a precise time piece for well into Phase 3 when I start configuring the USB and External Memory controller blocks. And the lpc1778 provides an 8Mhz RC clock on chip for simple applications ... use able well into developing the terminal monitor program
arm-none-eabi-gdb
JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Only resetting the Cortex-M core, use a reset-init event handler to reset any peripherals or configure hardware srst support.
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
(gdb) monitor mdw 0x400fc1b0
0x400fc1b0: 00000003
(gdb) monitor mdw 0x400fc1a0
0x400fc1a0: 00000009
(gdb) monitor mww 0x400fc1a0 0x39
(gdb) monitor mdw 0x400fc1a0
0x400fc1a0: 00000039
(gdb)
Basically after setting bits 4 and 5 of the system control register I checked to see if bit 6 (OSC status) would return a 1 ... meaning the external crystal/clock driver is enabled and I can switch clock sources from the internal 8Mhz RC clock to the precise 24Mhz external clock source Ill need later.
No dice
Looked at section 3.8.2 of the lpc1778 reference manual. Noticed that Cx1 and Cx2 should be either 18pf each or 39pf each depending on what the crystal (JF VNY 24Mhz) Cs and Rl parameters are.
Brought up my schematic and noticed this mistake:
Dont know what I was thinking when I put in a 12pf capacitor where an 18pf or 39pf cap was needed. Knowing my luck its probably the latter ... Ill know once I track down the crystal data sheet.
In either case I bought both on ebay (50 of each) but it wont get here until at least another two or three weeks ($1.50 for 50 ... cheaper from China but long wait times. I could have gotten it from Mouser but I dont need it that quick).
Fortunately all isnt lost. I dont need a precise time piece for well into Phase 3 when I start configuring the USB and External Memory controller blocks. And the lpc1778 provides an 8Mhz RC clock on chip for simple applications ... use able well into developing the terminal monitor program
Monday, July 6, 2015
Phase 1: openocd woes - resolution
I printed the openocd 0.10.0 manual and decided to log unto IRC ' #freenode server and #openocd channel to get some pointers in the right direction.
As luck would have it I met up with Paul Frertser, as I happened to be reading his response to another openocd user's question on lpc17xx configuration at:
comments.gmane.org/gmane.comp.debugging.openocd.devel/25169
Actually I posted my question on the main channel (#openocd) and he responded and during that conversation I was able to point to my blog and entries related to script file setup for openocd. I sent him a copy of the section of EGWU schematic where the ft2232 ' channel 0 is interfaced to the lpc1788' JTAG lines
He responded with the following suggestions
1. replace my current ftdi_layout_init assignment with
ftdi_layout_init 0x0008 0x000b
ftdi_layout_signal nTRST -data 0x0010
use reset_config trst_only in the board script
*** this worked
openocd_ftdi
Open On-Chip Debugger 0.9.0 (2015-07-05-17:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
adapter speed: 10 kHz
adapter_nsrst_delay: 1000
jtag_ntrst_delay: 1000
cortex_m reset_config sysresetreq
cortex_m reset_config sysresetreq
Info : clock speed 10 kHz
Info : JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : lpc1788.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Error: Target not halted
undefined debug reason 7 - target needs reset
Info : JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
2. use "extended-remote" in .gdbinit script and replace arm-linux-gnueabi-gdb with gdb-arm-none-eabi as the latter is more stable and caters to what I am doing and will lively resolve the error messages about unknown architecture in file
***this worked
as a side note
apt-get install gdb-arm-none-eabi also installs
arm-none-eabi-binutils
arm-none-eabi-gcc
arm-none-eabi-ld
libnewlib-arm-none-eabi
so I am going to modify my Makefile to use the above instead of the linux-eabi
versions
also gdb-arm-none-eabi ./app.out
JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
Reading symbols from app.out...done.
(gdb) load
Loading section .data, size 0xe0 lma 0x10000000
Loading section .text, size 0x1ca8 lma 0x100000e0
Start address 0x10000f48, load size 7560
Transfer rate: 1 KB/sec, 2520 bytes/write.
(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Temporary breakpoint 1 at 0x10000f4c: file app/main.c, line 29.
3. dispense with running openocd as root ... copy contrib/99-openocd.rules into my /etc/udev/rules.d
*** to be done tomorrow
4. consider adding the following flags to CFLAGS/LDFLAGS
-ffunction-sections -fdata-sections -Wl, --gc-sections
*** to be done tomorrow
I hadnt looked at the gcc/ld manual for over 3 years. So the current CFLAGS/LDFLAGS were created from when I worked on the arm7tdmi but later modified slightly to support the cortex-m3 which has no arm (thumb2 only) mode
As I just returned from the laundromat (30 mins ago) and in need of some serious sleep (still wanted to test out these suggestions) ... its time to pack it in for the night
As luck would have it I met up with Paul Frertser, as I happened to be reading his response to another openocd user's question on lpc17xx configuration at:
comments.gmane.org/gmane.comp.debugging.openocd.devel/25169
Actually I posted my question on the main channel (#openocd) and he responded and during that conversation I was able to point to my blog and entries related to script file setup for openocd. I sent him a copy of the section of EGWU schematic where the ft2232 ' channel 0 is interfaced to the lpc1788' JTAG lines
He responded with the following suggestions
1. replace my current ftdi_layout_init assignment with
ftdi_layout_init 0x0008 0x000b
ftdi_layout_signal nTRST -data 0x0010
use reset_config trst_only in the board script
*** this worked
openocd_ftdi
Open On-Chip Debugger 0.9.0 (2015-07-05-17:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
adapter speed: 10 kHz
adapter_nsrst_delay: 1000
jtag_ntrst_delay: 1000
cortex_m reset_config sysresetreq
cortex_m reset_config sysresetreq
Info : clock speed 10 kHz
Info : JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : lpc1788.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Error: Target not halted
undefined debug reason 7 - target needs reset
Info : JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
2. use "extended-remote" in .gdbinit script and replace arm-linux-gnueabi-gdb with gdb-arm-none-eabi as the latter is more stable and caters to what I am doing and will lively resolve the error messages about unknown architecture in file
***this worked
as a side note
apt-get install gdb-arm-none-eabi also installs
arm-none-eabi-binutils
arm-none-eabi-gcc
arm-none-eabi-ld
libnewlib-arm-none-eabi
so I am going to modify my Makefile to use the above instead of the linux-eabi
versions
also gdb-arm-none-eabi ./app.out
JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
Reading symbols from app.out...done.
(gdb) load
Loading section .data, size 0xe0 lma 0x10000000
Loading section .text, size 0x1ca8 lma 0x100000e0
Start address 0x10000f48, load size 7560
Transfer rate: 1 KB/sec, 2520 bytes/write.
(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Temporary breakpoint 1 at 0x10000f4c: file app/main.c, line 29.
3. dispense with running openocd as root ... copy contrib/99-openocd.rules into my /etc/udev/rules.d
*** to be done tomorrow
4. consider adding the following flags to CFLAGS/LDFLAGS
-ffunction-sections -fdata-sections -Wl, --gc-sections
*** to be done tomorrow
I hadnt looked at the gcc/ld manual for over 3 years. So the current CFLAGS/LDFLAGS were created from when I worked on the arm7tdmi but later modified slightly to support the cortex-m3 which has no arm (thumb2 only) mode
As I just returned from the laundromat (30 mins ago) and in need of some serious sleep (still wanted to test out these suggestions) ... its time to pack it in for the night
Sunday, July 5, 2015
Phase 1: openocd woes
encountered some problems getting openocd + jtag interface up and running. the ftdi driver has superceeded the ft2232 but the latter at least produces a connection ... example:
using recently upgraded 0.9.0 (openocd)
***using "interface ft2232" script
openocd_ft2232
Open On-Chip Debugger 0.9.0 (2015-07-05-17:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 10 kHz
adapter_nsrst_delay: 1000
jtag_ntrst_delay: 1000
cortex_m reset_config sysresetreq
cortex_m reset_config sysresetreq
Warn : Using DEPRECATED interface driver 'ft2232'
Info : Consider using the 'ftdi' interface driver, with configuration files in interface/ftdi/...
Info : max TCK change to: 30000 kHz
Info : clock speed 10 kHz
Info : inter: 0.000102, inter2: 0.000102 end: 0.069985
Info : JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : inter: 0.000163, inter2: 0.000163 end: 0.001911
Info : inter: 0.000134, inter2: 0.000134 end: 0.033913
Info : inter: 0.000154, inter2: 0.000154 end: 0.017895
Info : inter: 0.000180, inter2: 0.000180 end: 0.057936
Info : inter: 0.000155, inter2: 0.000155 end: 0.031909
Info : inter: 0.000160, inter2: 0.000160 end: 0.019909
Info : inter: 0.000102, inter2: 0.000102 end: 0.023956
Info : inter: 0.000063, inter2: 0.000063 end: 0.019930
Info : inter: 0.000063, inter2: 0.000064 end: 0.019930
Info : inter: 0.000092, inter2: 0.000092 end: 0.019954
Info : inter: 0.000166, inter2: 0.000167 end: 0.020112
Info : inter: 0.000122, inter2: 0.000122 end: 0.019744
Info : inter: 0.000076, inter2: 0.000076 end: 0.019959
Info : inter: 0.000050, inter2: 0.000050 end: 0.019932
Info : inter: 0.000041, inter2: 0.000041 end: 0.019923
Info : inter: 0.000067, inter2: 0.000068 end: 0.023947
Info : inter: 0.000042, inter2: 0.000042 end: 0.019936
Info : inter: 0.000160, inter2: 0.000160 end: 0.019910
Info : inter: 0.000060, inter2: 0.000060 end: 0.019952
Info : inter: 0.000143, inter2: 0.000143 end: 0.019890
Info : lpc1788.cpu: hardware has 6 breakpoints, 4 watchpoints
arm-linux-gnueabi-gdb ./app.out produces
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
inter: 0.000265, inter2: 0.000266 end: 0.019667
inter: 0.000043, inter2: 0.000043 end: 0.019801
(gdb) load
Loading section .data, size 0xe0 lma 0x10000000
Loading section .text, size 0x1ca8 lma 0x100000e0
Start address 0x10000f49, load size 7560
Ignoring packet error, continuing...
Reply contains invalid hex digit 79
***using "interface ftdi" script
at least this turns on the BILED segment i chose in "data" argument to ftdi_layout
openocd_ftdi
Open On-Chip Debugger 0.9.0 (2015-07-05-17:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
adapter speed: 10 kHz
adapter_nsrst_delay: 1000
jtag_ntrst_delay: 1000
cortex_m reset_config sysresetreq
cortex_m reset_config sysresetreq
Info : clock speed 10 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: lpc1788.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Need to resolve this before going forward. And for now I think it best I stick to using the ftdi interface
now that I have moved and settled into a new place. attaching an updated picture of a section of the lab. parts are still in bins inside the closets
using recently upgraded 0.9.0 (openocd)
***using "interface ft2232" script
openocd_ft2232
Open On-Chip Debugger 0.9.0 (2015-07-05-17:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 10 kHz
adapter_nsrst_delay: 1000
jtag_ntrst_delay: 1000
cortex_m reset_config sysresetreq
cortex_m reset_config sysresetreq
Warn : Using DEPRECATED interface driver 'ft2232'
Info : Consider using the 'ftdi' interface driver, with configuration files in interface/ftdi/...
Info : max TCK change to: 30000 kHz
Info : clock speed 10 kHz
Info : inter: 0.000102, inter2: 0.000102 end: 0.069985
Info : JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : inter: 0.000163, inter2: 0.000163 end: 0.001911
Info : inter: 0.000134, inter2: 0.000134 end: 0.033913
Info : inter: 0.000154, inter2: 0.000154 end: 0.017895
Info : inter: 0.000180, inter2: 0.000180 end: 0.057936
Info : inter: 0.000155, inter2: 0.000155 end: 0.031909
Info : inter: 0.000160, inter2: 0.000160 end: 0.019909
Info : inter: 0.000102, inter2: 0.000102 end: 0.023956
Info : inter: 0.000063, inter2: 0.000063 end: 0.019930
Info : inter: 0.000063, inter2: 0.000064 end: 0.019930
Info : inter: 0.000092, inter2: 0.000092 end: 0.019954
Info : inter: 0.000166, inter2: 0.000167 end: 0.020112
Info : inter: 0.000122, inter2: 0.000122 end: 0.019744
Info : inter: 0.000076, inter2: 0.000076 end: 0.019959
Info : inter: 0.000050, inter2: 0.000050 end: 0.019932
Info : inter: 0.000041, inter2: 0.000041 end: 0.019923
Info : inter: 0.000067, inter2: 0.000068 end: 0.023947
Info : inter: 0.000042, inter2: 0.000042 end: 0.019936
Info : inter: 0.000160, inter2: 0.000160 end: 0.019910
Info : inter: 0.000060, inter2: 0.000060 end: 0.019952
Info : inter: 0.000143, inter2: 0.000143 end: 0.019890
Info : lpc1788.cpu: hardware has 6 breakpoints, 4 watchpoints
arm-linux-gnueabi-gdb ./app.out produces
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
inter: 0.000265, inter2: 0.000266 end: 0.019667
inter: 0.000043, inter2: 0.000043 end: 0.019801
(gdb) load
Loading section .data, size 0xe0 lma 0x10000000
Loading section .text, size 0x1ca8 lma 0x100000e0
Start address 0x10000f49, load size 7560
Ignoring packet error, continuing...
Reply contains invalid hex digit 79
***using "interface ftdi" script
at least this turns on the BILED segment i chose in "data" argument to ftdi_layout
openocd_ftdi
Open On-Chip Debugger 0.9.0 (2015-07-05-17:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
adapter speed: 10 kHz
adapter_nsrst_delay: 1000
jtag_ntrst_delay: 1000
cortex_m reset_config sysresetreq
cortex_m reset_config sysresetreq
Info : clock speed 10 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: lpc1788.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Need to resolve this before going forward. And for now I think it best I stick to using the ftdi interface
now that I have moved and settled into a new place. attaching an updated picture of a section of the lab. parts are still in bins inside the closets
Phase 1: app
/*
***********************************************************************
*name: Samuel Igwe
*date: 07/04/2015
*description: main ... what else
* phase 1: system initialization
* led + timer
* phase 2: the above with
* uart communication 115200
* simple monitor program
* phase 3: the above with
* fpga setup in order to control LED's
* enabling static and dram memory controller
* phase 4: the above with
* usb host support in place for gamepads
* /mouse/keyboards
* phase 5: the above with
* extended fpga support for usb controller
* glue logic.
***********************************************************************
*/
#include "main.h"
void
main()
{
asm ("ldr sp, =0x10010000");
egwu_setup_pll();
egwu_setup_gpio();
egwu_setup_nvic();
egwu_setup_uart();
egwu_set_lpc_biled(0x3);
while(1)
;
}
Subscribe to:
Posts (Atom)