custom 5206e board gdb initialization

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

custom 5206e board gdb initialization

11,011 Views
Dietrich
Contributor II
 
This message contains an entire topic ported from the WildRice - Coldfire forum.  Freescale has received the approval from the WildRice administrator on seeding the Freescale forum with messages.  The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value as you search for answers to your questions.  Freescale assumes no responsibility whatsoever with respect to Posted Material.  For additional information, please see the Terms of Use - Message Boards and Community Forums.  Thank You and Enjoy the Forum!
 

Mar 21, 2005, 9:59 AM
Post #1 of 25 (516 views)
 
 [ColdFire] custom 5206e board gdb initialization
--------------------------------------------------------------------------------
 
Hi ,
Well I have now compiled all the tools, I can access the BDM adaptor
on a linux PC, and now I want to load a binary image into my board's
internal SRAM and then burn it to flash.
This will test setting up the chip selects of my custom board.
I have created gdb scripts as follows:
define addresses
set $rambar = 0x20000001
set $mbar = 0x10000000
set $rom-base = 0xffe00000
set $ram-base = 0x30000000
set $rambar0 = 0xc04
set $rambar1 = 0xc05
set $mbar-reg = 0xc0f
set $cacr = 0x2
set $acr0 = 0x4
set $acr1 = 0x5
set $acr2 = 0x6
set $acr3 = 0x7
set $vbr = 0x801
set $simr = $mbar + 0x003
set $icr1 = $mbar + 0x014
set $icr2 = $mbar + 0x015
set $icr3 = $mbar + 0x016
set $icr4 = $mbar + 0x017
set $icr5 = $mbar + 0x018
set $icr6 = $mbar + 0x019
set $icr7 = $mbar + 0x01A
set $icr8 = $mbar + 0x01B
set $icr9 = $mbar + 0x01C
set $icr10 = $mbar + 0x01D
set $icr11 = $mbar + 0x01E
set $icr12 = $mbar + 0x01F
set $icr13 = $mbar + 0x020
set $icr14 = $mbar + 0x021
set $icr15 = $mbar + 0x022
set $imr = $mbar + 0x036
set $ipr = $mbar + 0x03A
set $rsr = $mbar + 0x040
set $sypcr = $mbar + 0x041
set $swivr = $mbar + 0x042
set $swsr = $mbar + 0x043
set $par = $mbar + 0x0ca
set $csar7 = $mbar + 0x0B8
set $csmr7 = $mbar + 0x0BC
set $cscr7 = $mbar + 0x0C2
set $dmcr = $mbar + 0x0C6
set $par = $mbar + 0x0CA
set $tmr1 = $mbar + 0x100
set $trr1 = $mbar + 0x104
set $tcr1 = $mbar + 0x108
set $tcn1 = $mbar + 0x10C
set $ter1 = $mbar + 0x111
set $tmr2 = $mbar + 0x120
set $trr2 = $mbar + 0x124
set $tcr2 = $mbar + 0x128
set $tcn2 = $mbar + 0x12C
set $ter2 = $mbar + 0x131
end
define setup-cs
set *((short*) $csar0) = 0xffe0
set *((short*) $csmr0) = 0x001f0000
set *((short*) $cscr0) = 0x05a3
set *((short*) $csar1) = 0x4001
set *((short*) $csmr1) = 0x00000000
set *((short*) $cscr1) = 0x0d23
set *((short*) $csar2) = 0x3000
set *((short*) $csmr2) = 0x001f0000
set *((short*) $cscr2) = 0x0503
set *((short*) $csar3) = 0x4000
set *((short*) $csmr3) = 0x000f0000
set *((short*) $cscr3) = 0x0d03
end
These gdb commands are in a file called mtpFlashPgm.gdb
So now I want to start up gdb
I execute
>m68k-bdm-elf-gdb -n -x $COLDFIRE/gdbScripts/mtpFlashPgm.gdb
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=m68k-bdm-elf".
(gdb) target bdm /dev/bdmcf0
trying kernel driver: /dev/bdmcf0
trying bdm server: localhost:/dev/bdmcf0
Detected V2 core
GDB target bdm connected to /dev/bdmcf0
Coldfire debug module version is 0 (5206(e)/5272/5282)
(gdb) bdm-reset
(gdb) help user-define
User-defined commands.
The commands in this class are those defined by the user.
Use the "define" command to define a command.
List of commands:
addresses -- User-defined
flash-erase -- User-defined
flash-program -- User-defined
flash-programstartaddr -- User-defined
flash-programword -- User-defined
initboard -- User-defined
setup-cs -- User-defined
setup-entry -- User-defined
setup-sram -- User-defined
Type "help" followed by command name for full documentation.
Command name abbreviations are allowed if unambiguous.
(gdb) addresses
No symbol table is loaded. Use the "file" command.

Why doesn't this work?

How can I directly access the 5206e registers directly, I want to
invalidate cache, while I am using the debugger.
(gdb) bdm-read-creg /x $cacr
Value can't be converted to integer.

Thanks for all your help
Jayne
--------------------------------------------------------------------
Mar 21, 2005, 3:19 PM
Post #2 of 25 (512 views)
 
 [ColdFire] GNU (no)load [In reply to]
--------------------------------------------------------------------------------
 
 
Hi all ---
This should really go on a GNU mailing list, but ironically, while I've
found lists for "users and installers of GNU JEL" and "mcron" I haven't
found one for the simple old GNU compile-and-link chain. Any pointers
welcome!
My (today's) problem is this. I have a bunch of code that goes into
EEPROM, then a small bit that goes into RAM for faster execution. My
fast-execution assembly file says
==================================================================
.section timecritical
PrimedGo:
link a6,#64
movem.l #0xFFFF,(a7) | Save all registers to stack
... blah blah assembly code...
rte
.end
==================================================================
My linker command file says
==================================================================
MEMORY
{
.TEXT (RX) : ORIGIN = 0x00100000, LENGTH = 80k
.TEXT.RAM (RWX): ORIGIN = 0x60000400, LENGTH = 4k
.DATA (RW) : ORIGIN = 0x60004000, LENGTH = 12k
}
SECTIONS
{
.application_text : /* code and constants */
{
*(startup) *(.text) *(.strings) *(.rodata) *(.lit)
} > .TEXT
.ram_program : /* code running in ram instead of rom */
{
*(timecritical)
} > .TEXT.RAM
.initialized_data :
{
*(.data)
} > .DATA
.uninitialized_data :
{
. = ALIGN(0x4);
__bss_start = .;
*(.bss)
*(COMMON)
_end = ALIGN(0x8);
__end = _end;
} > .DATA
}
==================================================================
But when I link, I get the following in my .elf:
0 .application_text 000041ce 00100000 00100000 00002000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .ram_program 000003f8 60000400 60000400 00008020 2**0
CONTENTS, READONLY
2 .initialized_data 00000020 60004000 60004000 00008000 2**2
CONTENTS, ALLOC, LOAD, DATA
3 .uninitialized_data 000009e0 60004020 60004020 00008020 2**2
ALLOC
... and nothing in the world I can do will get the LOAD attribute to
show up for the .ram_program section. There are lots of ways to set
NOLOAD, in the linker, in the assembler, but no way to tell it to go
ahead and LOAD this section. As a result, nothing shows up in any of my
object files. I've tried objcopy to change the attribute, no luck. It
will change every attribute other than LOAD.
Any suggestions?
Thanks as always ---
--Scott

--------------------------------------------------------------------
 
Mar 21, 2005, 3:22 PM
Post #3 of 25 (505 views)
 
 Re: [ColdFire] custom 5206e board gdb initialization [In reply to]
--------------------------------------------------------------------------------
 
Jayne Dickinson wrote:
>
> set $rom-base = 0xffe00000
I think this is saying '$rom' minus 'base' and GDB is assuming 'base' is
a symbol.
>
> How can I directly access the 5206e registers directly, I want to
> invalidate cache, while I am using the debugger.
>
> (gdb) bdm-read-creg /x $cacr
> Value can't be converted to integer.
>
What happens if you do not supply the '/x' option ?
The 5206e registers should be defined, ie try 'info reg' and if you get
a no selected frame issue 'select 0' first.
--
Chris Johns
--------------------------------------------------------------------
 
Mar 22, 2005, 6:46 AM
Post #4 of 25 (505 views)
 
 Re: [ColdFire] custom 5206e board gdb initialization [In reply to]
--------------------------------------------------------------------------------
 
Thanks Chris,

I started m68k-bdm-elf-gdb and can now see the registers...but
bdm-read-creg $cacr isn't returning the value of the cacr register

Here's my trace of what I performed this morning.....
 
>m68k-bdm-elf-gdb -n -x $COLDFIRE/gdbScripts/mtpStart.gdb bblock.elf
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=m68k-bdm-elf"...
(gdb) target bdm /dev/bdmcf0
trying kernel driver: /dev/bdmcf0
trying bdm server: localhost:/dev/bdmcf0
Detected V2 core
GDB target bdm connected to /dev/bdmcf0
Coldfire debug module version is 0 (5206(e)/5272/5282)
(gdb) info registers
No selected frame.
(gdb) select 0
Current language: auto; currently c++
(gdb) bdm-read-creg $cacr
Value can't be converted to integer.
(gdb) bdm-read-creg $mbase
Value can't be converted to integer.
(gdb) info registers
d0 0x1 1
d1 0x10000c0 16777408
d2 0xd2 210
d3 0xd3 211
d4 0xd4 212
d5 0xd5 213
d6 0x10000000 268435456
d7 0xd7 215
a0 0x10000000 0x10000000
a1 0x3000ed48 0x3000ed48
a2 0xffe12a80 0xffe12a80
a3 0xa3 0xa3
a4 0xa4 0xa4
a5 0xa5 0xa5
fp 0x20000000 0x20000000
sp 0x20000000 0x20000000
ps 0x2700 9984
pc 0xffe00000 0xffe00000 <_VECTOR_TABLE>
vbr 0x74 116
cacr 0x0 0
acr0 0x0 0
acr1 0x0 0
rambar 0x20000000 536870912
mbar 0x10000000 268435456
macsr 0x8 8
mask 0xffff5555 -43691
acc 0xff4d0166 -11730586
csr 0x1000000 16777216
aatr 0x5 5
tdr 0x40000000 1073741824
pbr 0x0 0
pbmr 0x0 0
abhr 0x0 0
ablr 0x0 0
dbr 0x0 0
dbmr 0x0 0
(gdb)
(gdb) hb main
Hardware assisted breakpoint 1 at 0xffe02f34: file main.c, line 140.
(gdb) run
Starting program:
/home/jayned/mtpDev/mtpRev3Baseline/BootBlock/bblock.elf
BDM driver error: No response to BDM request
(gdb)
On Mon, 2005-03-21 at 16:22, Chris Johns wrote:
> Jayne Dickinson wrote:
> >
> > set $rom-base = 0xffe00000
>
> I think this is saying '$rom' minus 'base' and GDB is assuming 'base' is
> a symbol.
>
> >
> > How can I directly access the 5206e registers directly, I want to
> > invalidate cache, while I am using the debugger.
> >
> > (gdb) bdm-read-creg /x $cacr
> > Value can't be converted to integer.
> >
>
> What happens if you do not supply the '/x' option ?
>
> The 5206e registers should be defined, ie try 'info reg' and if you get
> a no selected frame issue 'select 0' first.
--------------------------------------------------------------------
 
Mar 22, 2005, 7:08 AM
Post #5 of 25 (504 views)
 
 Re: [ColdFire] custom 5206e board gdb initialization [In reply to]
--------------------------------------------------------------------------------
 
 
Don't do run - try 'cont' or 'c'
Mark
 
Message from Jayne Dickinson
received on 03/22/2005
09:46 AM

03/22/2005 Jayne Dickinson 09:46 AM
 

To: Mark C.
cc:
Subject: Re: [ColdFire] custom 5206e board gdb initialization
 

Thanks Chris,

I started m68k-bdm-elf-gdb and can now see the registers...but
bdm-read-creg $cacr isn't returning the value of the cacr register

Here's my trace of what I performed this morning.....
 
>m68k-bdm-elf-gdb -n -x $COLDFIRE/gdbScripts/mtpStart.gdb bblock.elf
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=m68k-bdm-elf"...
(gdb) target bdm /dev/bdmcf0
trying kernel driver: /dev/bdmcf0
trying bdm server: localhost:/dev/bdmcf0
Detected V2 core
GDB target bdm connected to /dev/bdmcf0
Coldfire debug module version is 0 (5206(e)/5272/5282)
(gdb) info registers
No selected frame.
(gdb) select 0
Current language: auto; currently c++
(gdb) bdm-read-creg $cacr
Value can't be converted to integer.
(gdb) bdm-read-creg $mbase
Value can't be converted to integer.
(gdb) info registers
d0 0x1 1
d1 0x10000c0 16777408
d2 0xd2 210
d3 0xd3 211
d4 0xd4 212
d5 0xd5 213
d6 0x10000000 268435456
d7 0xd7 215
a0 0x10000000 0x10000000
a1 0x3000ed48 0x3000ed48
a2 0xffe12a80 0xffe12a80
a3 0xa3 0xa3
a4 0xa4 0xa4
a5 0xa5 0xa5
fp 0x20000000 0x20000000
sp 0x20000000 0x20000000
ps 0x2700 9984
pc 0xffe00000 0xffe00000 <_VECTOR_TABLE>
vbr 0x74 116
cacr 0x0 0
acr0 0x0 0
acr1 0x0 0
rambar 0x20000000 536870912
mbar 0x10000000 268435456
macsr 0x8 8
mask 0xffff5555 -43691
acc 0xff4d0166 -11730586
csr 0x1000000 16777216
aatr 0x5 5
tdr 0x40000000 1073741824
pbr 0x0 0
pbmr 0x0 0
abhr 0x0 0
ablr 0x0 0
dbr 0x0 0
dbmr 0x0 0
(gdb)
(gdb) hb main
Hardware assisted breakpoint 1 at 0xffe02f34: file main.c, line 140.
(gdb) run
Starting program:
/home/jayned/mtpDev/mtpRev3Baseline/BootBlock/bblock.elf
BDM driver error: No response to BDM request
(gdb)
On Mon, 2005-03-21 at 16:22, Chris Johns wrote:
> Jayne Dickinson wrote:
> >
> > set $rom-base = 0xffe00000
>
> I think this is saying '$rom' minus 'base' and GDB is assuming 'base' is
> a symbol.
>
> >
> > How can I directly access the 5206e registers directly, I want to
> > invalidate cache, while I am using the debugger.
> >
> > (gdb) bdm-read-creg /x $cacr
> > Value can't be converted to integer.
> >
>
> What happens if you do not supply the '/x' option ?
>
> The 5206e registers should be defined, ie try 'info reg' and if you get
> a no selected frame issue 'select 0' first.
--------------------------------------------------------------------

Message Edited by Dietrich on 04-03-2006 10:46 AM

Message Edited by Dietrich on 04-04-2006 09:05 PM

Labels (1)
0 Kudos
6 Replies

1,147 Views
Dietrich
Contributor II
This message contains an entire topic ported from the WildRice - Coldfire forum.  Freescale has received the approval from the WildRice administrator on seeding the Freescale forum with messages.  The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value as you search for answers to your questions.  Freescale assumes no responsibility whatsoever with respect to Posted Material.  For additional information, please see the Terms of Use - Message Boards and Community Forums.  Thank You and Enjoy the Forum!
 

Mar 22, 2005, 1:59 PM
Post #8 of 25 (503 views)
 
 Re: [ColdFire] custom 5206e board gdb initialization [In reply to]
--------------------------------------------------------------------------------
 
Chris,
I am trying to figure out why I can't single step.
I have successfully used the m68k-elf-bdmflash to program the board's
flash memory with the boot code.
I can connect with the bdm driver on my linux-2.6 box
I downloaded my user-defined ( addresses, setup-cs, setup-sram macros )
when I look at the registers using info registers I must select frame 0
so I can set $pc=start, set $sp=0x301fff00 , set $sr=0x2700
 
Here so more info

(gdb) bt
#0 0xffe00556 in start ()
#1 0xffffffff in ?? ()
#2 0xffffffff in ?? ()
#3 0xffffffff in ?? ()
#4 0xffffffff in ?? ()
#5 0xffffffff in ?? ()
#6 0xffffffff in ?? ()
#7 0xffffffff in ?? ()
#8 0xffffffff in ?? ()
#9 0xffffffff in ?? ()
#10 0xffffffff in ?? ()
#11 0xffffffff in ?? ()
#12 0xffffffff in ?? ()
#13 0xffffffff in ?? ()
#14 0xffffffff in ?? ()
#15 0xffffffff in ?? ()
#16 0xffffffff in ?? ()
#17 0xffffffff in ?? ()
#18 0xffffffff in ?? ()
#19 0xffffffff in ?? ()
#20 0xffffffff in ?? ()
#21 0xffffffff in ?? ()
#22 0xffffffff in ?? ()
---Type <return> to continue, or q <return> to quit---
#23 0xffffffff in ?? ()
#24 0xffffffff in ?? ()
#25 0xffffffff in ?? ()
#26 0xffffffff in ?? ()
#27 0xffffffff in ?? ()
#28 0xffffffff in ?? ()
#29 0xffffffff in ?? ()
#30 0xffffffff in ?? ()
#31 0xffffffff in ?? ()
#32 0xffffffff in ?? ()
#33 0xffffffff in ?? ()
#34 0xffffffff in ?? ()
#35 0xffffffff in ?? ()
#36 0xffffffff in ?? ()
#37 0xffffffff in ?? ()
#38 0xffffffff in ?? ()
#39 0xffffffff in ?? ()
#40 0xffffffff in ?? ()
#41 0xffffffff in ?? ()
#42 0xffffffff in ?? ()
#43 0xffffffff in ?? ()
#44 0xffffffff in ?? ()
#45 0xffffffff in ?? ()
---Type <return> to continue, or q <return> to quit---
#46 0xffffffff in ?? ()
#47 0xffffffff in ?? ()
#48 0xffffffff in ?? ()
#49 0xffffffff in ?? ()
#50 0xffffffff in ?? ()
#51 0xffffffff in ?? ()
#52 0xffffffff in ?? ()
#53 0xffffffff in ?? ()
#54 0xffffffff in ?? ()
#55 0xffffffff in ?? ()
#56 0xffffffff in ?? ()
#57 0xffffffff in ?? ()
#58 0xffffffff in ?? ()
#59 0xffffffff in ?? ()
#60 0xffffffff in ?? ()
#61 0xffffffff in ?? ()
#62 0xffffffff in ?? ()
#63 0xffffffff in ?? ()
#64 0xffffffff in ?? ()
#65 0xffffffff in ?? ()
#66 0xffffffff in ?? ()
#67 0xffffffff in ?? ()
#68 0xffffffff in ?? ()
---Type <return> to continue, or q <return> to quit---
#69 0xffffffff in ?? ()
#70 0xffffffff in ?? ()
#71 0xffffffff in ?? ()
#72 0xffffffff in ?? ()
#73 0xffffffff in ?? ()
#74 0xffffffff in ?? ()
#75 0xffffffff in ?? ()
#76 0xffffffff in ?? ()
#77 0xffffffff in ?? ()
#78 0xffffffff in ?? ()
#79 0xffffffff in ?? ()
#80 0xffffffff in ?? ()
#81 0xffffffff in ?? ()
#82 0xffffffff in ?? ()
#83 0xffffffff in ?? ()
#84 0xffffffff in ?? ()
#85 0xffffffff in ?? ()
#86 0xffffffff in ?? ()
#87 0xffffffff in ?? ()
#88 0xffffffff in ?? ()
#89 0xffffffff in ?? ()
#90 0x301fff00 in ?? ()
#91 0xffe00556 in sbrk ()
---Type <return> to continue, or q <return> to quit---
#92 0xffe004d8 in ___fini ()
#93 0xffe004da in exception02 ()
#94 0xffe004dc in exception03 ()
#95 0xffe004de in exception04 ()
#96 0xffe004e0 in exception05 ()
#97 0xffe004e2 in exception06 ()
#98 0xffe004e4 in exception07 ()
#99 0xffe004e6 in exception08 ()
#100 0xffe004e8 in exception09 ()
#101 0xffe004ea in exception0A ()
#102 0xffe004ec in exception0B ()
#103 0xffe004ee in exception0C ()
#104 0xffe004f0 in exception0D ()
#105 0xffe004f2 in exception0E ()
#106 0xffe004f4 in exception0F ()
#107 0xffe004f6 in exception10 ()
#108 0xffe004f8 in exception11 ()
#109 0xffe004fa in exception12 ()
#110 0xffe004fc in exception13 ()
#111 0xffe004fe in exception14 ()
#112 0xffe00500 in exception15 ()
#113 0xffe00502 in exception16 ()
#114 0xffe00504 in exception17 ()
---Type <return> to continue, or q <return> to quit---
#115 0xffe091d4 in _OSDma2ISR ()
#116 0xffe00548 in exception_handler ()
#117 0xffe09146 in OSTimer1ISR ()
#118 0xffe091ea in OSFpga1ISR ()
#119 0xffe09118 in _OSIntCtxSw ()
#120 0xffe00548 in exception_handler ()
#121 0xffe00548 in exception_handler ()
#122 0xffe00506 in exception18 ()
#123 0xffe00508 in exception20 ()
#124 0xffe0050a in exception21 ()
#125 0xffe0050c in exception22 ()
#126 0xffe0050e in exception23 ()
#127 0xffe00510 in exception24 ()
#128 0xffe00512 in exception25 ()
#129 0xffe00514 in exception26 ()
#130 0xffe00516 in exception27 ()
#131 0xffe00518 in exception28 ()
#132 0xffe0051a in exception29 ()
#133 0xffe0051c in exception2A ()
#134 0xffe0051e in exception2B ()
#135 0xffe00520 in exception2C ()
#136 0xffe00522 in exception2D ()
#137 0xffe00524 in exception2E ()
---Type <return> to continue, or q <return> to quit---
#138 0xffe00526 in exception2F ()
#139 0xffe00528 in exception30 ()
#140 0xffe0052a in exception31 ()
#141 0xffe0052c in exception32 ()
#142 0xffe0052e in exception33 ()
#143 0xffe00530 in exception34 ()
#144 0xffe00532 in exception35 ()
#145 0xffe00534 in exception36 ()
#146 0xffe00536 in exception37 ()
#147 0xffe00538 in exception38 ()
#148 0xffe0053a in exception39 ()
#149 0xffe0053c in exception3A ()
#150 0xffe0053e in exception3B ()
#151 0xffe00540 in exception3C ()
#152 0xffe00542 in exception3D ()
#153 0xffe00544 in exception3E ()
#154 0xffe00548 in exception_handler ()
#155 0xffe00548 in exception_handler ()
#156 0xffe00548 in exception_handler ()
#157 0xffe00548 in exception_handler ()
#158 0xffe00548 in exception_handler ()
#159 0xffe00548 in exception_handler ()
#160 0xffe00548 in exception_handler ()
---Type <return> to continue, or q <return> to quit---
#161 0xffe00548 in exception_handler ()
#162 0xffe00548 in exception_handler ()
#163 0xffe00548 in exception_handler ()
#164 0xffe00548 in exception_handler ()
#165 0xffe00548 in exception_handler ()
#166 0xffe00548 in exception_handler ()
#167 0xffe00548 in exception_handler ()
#168 0xffe00548 in exception_handler ()
#169 0xffe00548 in exception_handler ()
#170 0xffe00548 in exception_handler ()
#171 0xffe00548 in exception_handler ()
#172 0xffe00548 in exception_handler ()
#173 0xffe00548 in exception_handler ()
#174 0xffe00548 in exception_handler ()
#175 0xffe00548 in exception_handler ()
#176 0xffe00548 in exception_handler ()
#177 0xffe00548 in exception_handler ()
#178 0xffe00548 in exception_handler ()
#179 0xffe00548 in exception_handler ()
#180 0xffe00548 in exception_handler ()
#181 0xffe00548 in exception_handler ()
#182 0xffe00548 in exception_handler ()
#183 0xffe00548 in exception_handler ()
---Type <return> to continue, or q <return> to quit---
#184 0xffe00548 in exception_handler ()
#185 0xffe00548 in exception_handler ()
#186 0xffe00548 in exception_handler ()
#187 0xffe00548 in exception_handler ()
#188 0xffe00548 in exception_handler ()
#189 0xffe00548 in exception_handler ()
#190 0xffe00548 in exception_handler ()
#191 0xffe00548 in exception_handler ()
#192 0xffe00548 in exception_handler ()
#193 0xffe00548 in exception_handler ()
#194 0xffe00548 in exception_handler ()
#195 0xffe00548 in exception_handler ()
#196 0xffe00548 in exception_handler ()
#197 0xffe00548 in exception_handler ()
#198 0xffe00548 in exception_handler ()
#199 0xffe00548 in exception_handler ()
#200 0xffe00548 in exception_handler ()
#201 0xffe00548 in exception_handler ()
#202 0xffe00548 in exception_handler ()
#203 0xffe00548 in exception_handler ()
#204 0xffe00548 in exception_handler ()
#205 0xffe00548 in exception_handler ()
#206 0xffe00548 in exception_handler ()
---Type <return> to continue, or q <return> to quit---
#207 0xffe00548 in exception_handler ()
#208 0xffe00548 in exception_handler ()
#209 0xffe00548 in exception_handler ()
#210 0xffe00548 in exception_handler ()
#211 0xffe00548 in exception_handler ()
#212 0xffe00548 in exception_handler ()
#213 0xffe00548 in exception_handler ()
#214 0xffe00548 in exception_handler ()
#215 0xffe00548 in exception_handler ()
#216 0xffe00548 in exception_handler ()
#217 0xffe00548 in exception_handler ()
#218 0xffe00548 in exception_handler ()
#219 0xffe00548 in exception_handler ()
#220 0xffe00548 in exception_handler ()
#221 0xffe00548 in exception_handler ()
#222 0xffe00548 in exception_handler ()
#223 0xffe00548 in exception_handler ()
#224 0xffe00548 in exception_handler ()
#225 0xffe00548 in exception_handler ()
#226 0xffe00548 in exception_handler ()
#227 0xffe00548 in exception_handler ()
#228 0xffe00548 in exception_handler ()
#229 0xffe00548 in exception_handler ()
---Type <return> to continue, or q <return> to quit---
#230 0xffe00548 in exception_handler ()
#231 0xffe00548 in exception_handler ()
#232 0xffe00548 in exception_handler ()
#233 0xffe00548 in exception_handler ()
#234 0xffe00548 in exception_handler ()
#235 0xffe00548 in exception_handler ()
#236 0xffe00548 in exception_handler ()
#237 0xffe00548 in exception_handler ()
#238 0xffe00548 in exception_handler ()
#239 0xffe00548 in exception_handler ()
#240 0xffe00548 in exception_handler ()
#241 0xffe00548 in exception_handler ()
#242 0xffe00548 in exception_handler ()
#243 0xffe00548 in exception_handler ()
#244 0xffe00548 in exception_handler ()
#245 0xffe00548 in exception_handler ()
#246 0xffe00548 in exception_handler ()
#247 0xffe00548 in exception_handler ()
#248 0xffe00548 in exception_handler ()
#249 0xffe00548 in exception_handler ()
#250 0xffe00548 in exception_handler ()
#251 0xffe00548 in exception_handler ()
#252 0xffe00548 in exception_handler ()
---Type <return> to continue, or q <return> to quit---
#253 0xffe00548 in exception_handler ()
#254 0xffe00548 in exception_handler ()
#255 0xffe00548 in exception_handler ()
#256 0xffe00548 in exception_handler ()
#257 0xffe00548 in exception_handler ()
#258 0xffe00548 in exception_handler ()
#259 0xffe00548 in exception_handler ()
#260 0xffe00548 in exception_handler ()
#261 0xffe00548 in exception_handler ()
#262 0xffe00548 in exception_handler ()
#263 0xffe00548 in exception_handler ()
#264 0xffe00548 in exception_handler ()
#265 0xffe00548 in exception_handler ()
#266 0xffe00548 in exception_handler ()
#267 0xffe00548 in exception_handler ()
#268 0xffe00548 in exception_handler ()
#269 0xffe00548 in exception_handler ()
#270 0xffe00548 in exception_handler ()
#271 0xffe00548 in exception_handler ()
#272 0xffe00548 in exception_handler ()
#273 0xffe00548 in exception_handler ()
#274 0xffe00548 in exception_handler ()
#275 0xffe00548 in exception_handler ()
---Type <return> to continue, or q <return> to quit---
#276 0xffe00548 in exception_handler ()
#277 0xffe00548 in exception_handler ()
#278 0xffe00548 in exception_handler ()
#279 0xffe00548 in exception_handler ()
#280 0xffe00548 in exception_handler ()
#281 0xffe00548 in exception_handler ()
#282 0xffe00548 in exception_handler ()
#283 0xffe00548 in exception_handler ()
#284 0xffe00548 in exception_handler ()
#285 0xffe00548 in exception_handler ()
#286 0xffe00548 in exception_handler ()
#287 0xffe00548 in exception_handler ()
#288 0xffe00548 in exception_handler ()
#289 0xffe00548 in exception_handler ()
#290 0xffe00548 in exception_handler ()
#291 0xffe00548 in exception_handler ()
#292 0xffe00548 in exception_handler ()
#293 0xffe00548 in exception_handler ()
#294 0xffe00548 in exception_handler ()
#295 0xffe00548 in exception_handler ()
#296 0xffe00548 in exception_handler ()
#297 0xffe00548 in exception_handler ()
#298 0xffe00548 in exception_handler ()
---Type <return> to continue, or q <return> to quit---
#299 0xffe00548 in exception_handler ()
#300 0xffe00548 in exception_handler ()
#301 0xffe00548 in exception_handler ()
#302 0xffe00548 in exception_handler ()
#303 0xffe00548 in exception_handler ()
#304 0xffe00548 in exception_handler ()
#305 0xffe00548 in exception_handler ()
#306 0xffe00548 in exception_handler ()
#307 0xffe00548 in exception_handler ()
#308 0xffe00548 in exception_handler ()
#309 0xffe00548 in exception_handler ()
#310 0xffe00548 in exception_handler ()
#311 0xffe00548 in exception_handler ()
#312 0xffe00548 in exception_handler ()
#313 0xffe00548 in exception_handler ()
#314 0xffe00548 in exception_handler ()
#315 0xffe00548 in exception_handler ()
#316 0xffe00548 in exception_handler ()
#317 0xffe00548 in exception_handler ()
#318 0xffe00548 in exception_handler ()
#319 0xffe00548 in exception_handler ()
#320 0xffe00548 in exception_handler ()
#321 0xffe00548 in exception_handler ()
---Type <return> to continue, or q <return> to quit---
#322 0xffe00548 in exception_handler ()
#323 0xffe00548 in exception_handler ()
#324 0xffe00548 in exception_handler ()
#325 0xffe00548 in exception_handler ()
#326 0xffe00548 in exception_handler ()
#327 0xffe00548 in exception_handler ()
#328 0xffe00548 in exception_handler ()
#329 0xffe00548 in exception_handler ()
#330 0xffe00548 in exception_handler ()
#331 0xffe00548 in exception_handler ()
#332 0xffe00548 in exception_handler ()
#333 0xffe00548 in exception_handler ()
#334 0xffe00548 in exception_handler ()
#335 0xffe00548 in exception_handler ()
#336 0xffe00548 in exception_handler ()
#337 0xffe00548 in exception_handler ()
#338 0xffe00548 in exception_handler ()
#339 0xffe00548 in exception_handler ()
#340 0xffe00548 in exception_handler ()
#341 0xffe00548 in exception_handler ()
#342 0xffe00548 in exception_handler ()
#343 0xffe00548 in exception_handler ()
#344 0xffe00548 in exception_handler ()
---Type <return> to continue, or q <return> to quit---
#345 0xffe00548 in exception_handler ()
#346 0xffe00556 in sbrk ()
#347 0xffe08898 in EraseAppBlockRAM () at DOWNLOAD.C:75

On Tue, 2005-03-22 at 13:30, Chris Johns wrote:
> Jayne Dickinson wrote:
> >
> > (gdb) bdm-read-creg $cacr
> > Value can't be converted to integer.
>
> This could be a bug.
>
> >
> > (gdb) hb main
> > Hardware assisted breakpoint 1 at 0xffe02f34: file main.c, line 140.
> > (gdb) run
> > Starting program:
> > /home/jayned/mtpDev/mtpRev3Baseline/BootBlock/bblock.elf
> > BDM driver error: No response to BDM request
> > (gdb)
> >
>
> Do you have the BDM processor status signals configured as I/O ?
>
> If you do then it may pay to add after the target connect command:
>
> bdm-cf-pst 0
>
> This stops the BDM driver from using the PST signals and uses software
> to detect the target has halted. This command only works on the 5206e.
-------------------------------------------------------------------- 
 

Message Edited by Dietrich on 04-03-2006 10:44 AM

Message Edited by Dietrich on 04-04-2006 09:03 PM

0 Kudos

1,147 Views
Dietrich
Contributor II
This message contains an entire topic ported from the WildRice - Coldfire forum.  Freescale has received the approval from the WildRice administrator on seeding the Freescale forum with messages.  The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value as you search for answers to your questions.  Freescale assumes no responsibility whatsoever with respect to Posted Material.  For additional information, please see the Terms of Use - Message Boards and Community Forums.  Thank You and Enjoy the Forum!
 

Mar 22, 2005, 3:22 PM
Post #9 of 25 (503 views)
 
 Re: [ColdFire] custom 5206e board gdb initialization [In reply to]
--------------------------------------------------------------------------------
 
Jayne Dickinson wrote:
>
> I am trying to figure out why I can't single step.
>
Do you need to use the bdm-cf-pst command ?
Are you stepping in flash ?
> I have successfully used the m68k-elf-bdmflash to program the board's
> flash memory with the boot code.
>
> I can connect with the bdm driver on my linux-2.6 box
>
> I downloaded my user-defined ( addresses, setup-cs, setup-sram macros )
>
> when I look at the registers using info registers I must select frame 0
> so I can set $pc=start, set $sp=0x301fff00 , set $sr=0x2700
>
If you have code in flash you should not need to setup anything up. Just:
target bdm /dev/bdmcf0
display /i $pc
si
>
>
> Here so more info
>
>
> (gdb) bt
> #0 0xffe00556 in start ()
> #1 0xffffffff in ?? ()
This can happen depending on the state of the stack.
--
Chris Johns
--------------------------------------------------------------------
 
Mar 22, 2005, 4:15 PM
Post #10 of 25 (503 views)
 
 [ColdFire] Interrupt latency [In reply to]
--------------------------------------------------------------------------------
 
 
What do y'all think I should expect in terms of interrupt latency, from
an IRQ to the start of the routine? I'm seeing anywhere from 23 to 46
clock cycles. This doesn't seem right.
I'm running entirely out of internal SRAM *and* I have cache enabled
(redundant, but caching seemed to help a little). Single-chip mode, but
after copying things into internal SRAM I turn off the Flash module,
just in case it was slowing things down. This is on a 5282LITE board,
if that makes a difference...
My apologies for the recent series of questions, folks, I'm trying to
pull a colleague's project out of the fire, and it's due next week.
Please believe me that I'll turn around and answer as many questions as
I can once this local emergency is over! Thanks again for everyone's help.
--Scott
--------------------------------------------------------------------
Mar 22, 2005, 7:40 PM
Post #11 of 25 (503 views)
 
 Re: [ColdFire] Interrupt latency [In reply to]
--------------------------------------------------------------------------------
 
As you are running out of SRAM I assume you have no OS?
Are you disabling interrupts, I assume no?
Are you doing divisions?
Are you writing out of internal SRAM?
Remember when you service an interrupt the current instruction is finished and
all pending writes are performed.
Enabling cache improving the situation would suggest you are writing to
external memory.
Regards
Charles
On Tue, 22 Mar 2005 07:15 pm, you wrote:
> What do y'all think I should expect in terms of interrupt latency, from
> an IRQ to the start of the routine? I'm seeing anywhere from 23 to 46
> clock cycles. This doesn't seem right.
>
> I'm running entirely out of internal SRAM *and* I have cache enabled
> (redundant, but caching seemed to help a little). Single-chip mode, but
> after copying things into internal SRAM I turn off the Flash module,
> just in case it was slowing things down. This is on a 5282LITE board,
> if that makes a difference...
>
> My apologies for the recent series of questions, folks, I'm trying to
> pull a colleague's project out of the fire, and it's due next week.
> Please believe me that I'll turn around and answer as many questions as
> I can once this local emergency is over! Thanks again for everyone's help.
>
> --Scott
>
> --------------------------------------------------------------------
>
>
>
--
Charles Esson R&D group Colour Vision Systems
The views expressed herein are mine. No one else wants them.
Please sent attachments in PDF, HTML or TXT. Sorry but my spam filter now
rejects any message that contains <HTML> in the text. It was that or change
email address again.
 
-------------------------------------------------------------------- 
 
Mar 23, 2005, 6:45 AM
Post #12 of 25 (502 views)
 
 RE: [ColdFire] Interrupt latency [In reply to]
--------------------------------------------------------------------------------
 
 
Things that take time when you get an IRQ:
Finish the current instruction
Finish all pending bus writes
Build and write the exception frame
Fetch the vector
Now you're in the IRQ routine.
If the instruction was an invalidate cache, it can take a _long_ time.
Math can take a while too. You can look up the times/bus cycles for the
other stuff.
The times you are seeing are reasonable.
Comment: When doing a system, one of the many core decisions/assumptions
you make is what is your interrupt latency. In addition to the above delays
you may have code that:
Turns off interrupts for a while
You're already in a service routine, so you have wait for
that routine to finish up
You make be flushing the cache (data cache with DMA means you're
doing this a lot)
You have to juggle the IRQ priorities.
Some examples from the project I'm hacking:
A serial port IRQ service time takes about 2 uS
One of my PITs takes 14 us, the other 3 uS
I have IRQ for one device that takes 60 uS.
I have various pieces of code that turn off IRQs for 3-15 uS.
On my system, I've "designed" for a maximum IRQ latency of about 100 uS.
The typical delay is 400 to 1000 nS, about what your seeing. BTW, all IRQ
service routines but two are in assembly.
A final comment: Any system designed for tight IRQ latencies or that is
highly dependant on IRQ levels and nesting interrupts probably won't work.
You can have one or two high priority interrupts, but after that the
permutations become too much to grasp, and testing is very difficult.
The time difference between running out of SDRAM vs. on board flash is
about a 25% speedup when using on board FLASH. So one thing I do is run
everything out of on board SDRAM and be sure it works. Then, when it moves
to FLASH I've got some margin. If you can't take a 25% variance in
performance, you've probably got things "wound up too tight". All I cache
are SDRAM code. So while the cache on the 5282 is small, I've got 512K of
code that is "always in the cache" (has no time penalty), and 64K of RAM
with the same situation. My Ethernet buffers and descriptors are in SRAM,
as are core variables and some of the stacks for tasks. I never have to
flush the cache to do DMA, and there is no penalty for Ethernet traffic
because of the dual porting of the on board SRAM.
Another long winded rely, but hope it helps.
- pete
> -----Original Message-----
> From: On
> Behalf Of Scott A. McDermott
> Sent: Tuesday, March 22, 2005 7:15 PM
> Subject: [ColdFire] Interrupt latency
>
>
> What do y'all think I should expect in terms of interrupt latency, from
> an IRQ to the start of the routine? I'm seeing anywhere from 23 to 46
> clock cycles. This doesn't seem right.
>
> I'm running entirely out of internal SRAM *and* I have cache enabled
> (redundant, but caching seemed to help a little). Single-chip mode, but
> after copying things into internal SRAM I turn off the Flash module,
> just in case it was slowing things down. This is on a 5282LITE board,
> if that makes a difference...
>
> My apologies for the recent series of questions, folks, I'm trying to
> pull a colleague's project out of the fire, and it's due next week.
> Please believe me that I'll turn around and answer as many questions as
> I can once this local emergency is over! Thanks again for everyone's
> help.
>
> --Scott
 
-------------------------------------------------------------------- 
 

Message Edited by Dietrich on 04-03-2006 10:42 AM

Message Edited by Dietrich on 04-04-2006 09:02 PM

0 Kudos

1,147 Views
Dietrich
Contributor II
This message contains an entire topic ported from the WildRice - Coldfire forum.  Freescale has received the approval from the WildRice administrator on seeding the Freescale forum with messages.  The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value as you search for answers to your questions.  Freescale assumes no responsibility whatsoever with respect to Posted Material.  For additional information, please see the Terms of Use - Message Boards and Community Forums.  Thank You and Enjoy the Forum!
 

Mar 23, 2005, 7:20 AM
Post #13 of 25 (502 views)
 
 Re: [ColdFire] custom 5206e board gdb initialization [In reply to]
--------------------------------------------------------------------------------
 
Hi Chris,
I am trying to single step my flash boot code, I can do this using
P&E debugger without problems.
Here's another log of what goes on... I powerup my board, connect to the
bdm pod on my linux pc, display the PC register... interesting the PC is
NOT set to entry address loaded in flash (amd29L160B) device, like the
bdm reset doesn't know where flash base address is? Single stepping in
flash still doesn't do a thing...HOWEVER, after I set my PC to the
correct location of my startup entry in flash, and execute 'c' I can run
my application code ( which was loaded into another region in flash )
that my boot code understands....then I wait for my application code to
run and interrupt GDB... guess what...single stepping now works....
Does this mean that gdb doesn't support single stepping flash ?

flash base address = 0xffe00000
ffe00000 = 301fff00
ffe00004 = ffe00556

>m68k-bdm-elf-gdb
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=m68k-bdm-elf".
(gdb) target bdm /dev/bdmcf0
trying kernel driver: /dev/bdmcf0
trying bdm server: localhost:/dev/bdmcf0
Detected V2 core
GDB target bdm connected to /dev/bdmcf0
Coldfire debug module version is 0 (5206(e)/5272/5282)
(gdb) display /i $pc
1: x/i $pc 0xffe03228: bges 0xffe0322c
(gdb) set $pc=0xffe00556
(gdb) display /i $pc
2: x/i $pc 0xffe00556: braw 0xffe00568
(gdb) c
Continuing.

( I wait for a few seconds for my application code to start, which got
copied into external ram by my boot code ....)

( I interrupted GDB by typing <ctrl><c> twice )
[New process 42000]
Program received signal SIGTSTP, Stopped (user).
0x300427ea in ?? ()
2: x/i $pc 0x300427ea: tstl %d0
1: x/i $pc 0x300427ea: tstl %d0
(gdb) si
0x300427ec in ?? ()
2: x/i $pc 0x300427ec: beqs 0x300427ea
1: x/i $pc 0x300427ec: beqs 0x300427ea
(gdb) c
Continuing.
--------------------------------------------------------------------

Mar 23, 2005, 1:54 PM
Post #14 of 25 (501 views)
 
 RE: [ColdFire] Interrupt latency [In reply to]
--------------------------------------------------------------------------------
 
Any thoughts on interrupt latencies with uClinux?
> Things that take time when you get an IRQ:
> Finish the current instruction
> Finish all pending bus writes
> Build and write the exception frame
> Fetch the vector
> Now you're in the IRQ routine.
>
> If the instruction was an invalidate cache, it can take a _long_ time.
> Math can take a while too. You can look up the times/bus cycles for the
> other stuff.
>
> The times you are seeing are reasonable.
>
> Comment: When doing a system, one of the many core
> decisions/assumptions
> you make is what is your interrupt latency. In addition to the
> above delays
> you may have code that:
> Turns off interrupts for a while
> You're already in a service routine, so you have wait for
> that routine to finish up
> You make be flushing the cache (data cache with DMA means you're
> doing this a lot)
> You have to juggle the IRQ priorities.
>
> Some examples from the project I'm hacking:
> A serial port IRQ service time takes about 2 uS
> One of my PITs takes 14 us, the other 3 uS
> I have IRQ for one device that takes 60 uS.
> I have various pieces of code that turn off IRQs for 3-15 uS.
>
> On my system, I've "designed" for a maximum IRQ latency of about 100 uS.
> The typical delay is 400 to 1000 nS, about what your seeing. BTW, all IRQ
> service routines but two are in assembly.
>
> A final comment: Any system designed for tight IRQ latencies or that is
> highly dependant on IRQ levels and nesting interrupts probably won't work.
> You can have one or two high priority interrupts, but after that the
> permutations become too much to grasp, and testing is very difficult.
> The time difference between running out of SDRAM vs. on board flash is
> about a 25% speedup when using on board FLASH. So one thing I do is run
> everything out of on board SDRAM and be sure it works. Then,
> when it moves
> to FLASH I've got some margin. If you can't take a 25% variance in
> performance, you've probably got things "wound up too tight". All I cache
> are SDRAM code. So while the cache on the 5282 is small, I've got 512K of
> code that is "always in the cache" (has no time penalty), and 64K of RAM
> with the same situation. My Ethernet buffers and descriptors are in SRAM,
> as are core variables and some of the stacks for tasks. I never have to
> flush the cache to do DMA, and there is no penalty for Ethernet traffic
> because of the dual porting of the on board SRAM.
>
> Another long winded rely, but hope it helps.
>
> - pete
>
> > -----Original Message-----
> > From: On
> Behalf Of Scott A. McDermott
> Sent: Tuesday, March 22, 2005 7:15 PM
> Subject: [ColdFire] Interrupt latency
>
>
> What do y'all think I should expect in terms of interrupt latency, from
> an IRQ to the start of the routine? I'm seeing anywhere from 23 to 46
> clock cycles. This doesn't seem right.
>
> I'm running entirely out of internal SRAM *and* I have cache enabled
> (redundant, but caching seemed to help a little). Single-chip mode, but
> after copying things into internal SRAM I turn off the Flash module,
> just in case it was slowing things down. This is on a 5282LITE board,
> if that makes a difference...
>
> My apologies for the recent series of questions, folks, I'm trying to
> pull a colleague's project out of the fire, and it's due next week.
> Please believe me that I'll turn around and answer as many questions as
> I can once this local emergency is over! Thanks again for everyone's
> help.
>
> --Scott
 
--------------------------------------------------------------------
 
Mar 23, 2005, 2:01 PM
Post #15 of 25 (501 views)
 
 Re: [ColdFire] custom 5206e board gdb initialization [In reply to]
--------------------------------------------------------------------------------
 
Jayne Dickinson wrote:
>
> I am trying to single step my flash boot code, I can do this using
> P&E debugger without problems.
Stepping an instruction at a time for code in read-only memory is supported.
The BDM debug hardware has a bit that masks interrupts (CSR[IPI]) while
stepping and a bit that steps and instruction (CSR[SSM]) with the BDM GO
command. These bits together mean you can step code in read-only memory.
The only other way to halt the processor is to use the hardware break
point support and GDB does not do this automatically as this is a
limited resource and may already be used by you.
Any other sort of stepping in GDB requires a software break point and a
software break point is modifying code by placing a 'halt' instruction
at the break point address. To do this code must be in RAM.
>
> Here's another log of what goes on... I powerup my board, connect to the
> bdm pod on my linux pc, display the PC register... interesting the PC is
> NOT set to entry address loaded in flash (amd29L160B) device, like the
> bdm reset doesn't know where flash base address is?
The processor has been at reset. Loading the PC occurs after reset. This
is documented in the user manual and exists so you can set the PC. If
you set the PC via BDM the Coldfire will not fetch the reset vector from
the vector table. Nice feature when you do not have a vector table, ie
blank flash.
> Single stepping in
> flash still doesn't do a thing...HOWEVER, after I set my PC to the
> correct location of my startup entry in flash, and execute 'c' I can run
> my application code ( which was loaded into another region in flash )
> that my boot code understands....then I wait for my application code to
> run and interrupt GDB... guess what...single stepping now works....
>
Is your vector table setup correctly ?
> Does this mean that gdb doesn't support single stepping flash ?
No. Here is my trace from the 5282 eval board of stepping in flash:
(gdb) display /i $pc
1: x/i $pc 0x400: movew #9984,%sr
(gdb) si
0x00000404 in ?? ()
1: x/i $pc 0x404: jmp 0xffe1f8e4
(gdb) si
0xffe1f8e4 in ?? ()
1: x/i $pc 0xffe1f8e4: movew #9984,%sr
(gdb) si
0xffe1f8e8 in ?? ()
1: x/i $pc 0xffe1f8e8: movel #1073741825,%d0
(gdb) si
0xffe1f8ee in ?? ()
1: x/i $pc 0xffe1f8ee: movel %d0,0x40000000
(gdb) si
0xffe1f8f4 in ?? ()
1: x/i $pc 0xffe1f8f4: movel #-268435423,%d0
(gdb)
>
> ( I interrupted GDB by typing <ctrl><c> twice )
>
This is a bug and I am hoping to look at this soon. It could be a source
of your problem, ie not cleanly stopping after si and automatically
continuing. The step stops but GDB does not cleanly stop.
Try after stopping and without leaving GDB:
(gdb) bdm-reset
(gdb) set $pc = *4
(gdb) set $sp = *0
(gdb) display /i $pc
(gdb) si
--
Chris Johns
--------------------------------------------------------------------

Mar 23, 2005, 5:50 PM
Post #16 of 25 (501 views)
 
 RE: [ColdFire] Interrupt latency [In reply to]
--------------------------------------------------------------------------------
 
 
Sorry. I'm on from scratch hardware with a home made OS, peripherals in a
FPGA, drivers, and everything else. I would imagine that any OS on the 5282
would be pressed to guarantee interrupt latencies less than 10 uS. This is
in part why the global RL bit in the EIR for the Ethernet is such a problem-
it's hard to guarantee you can get the packet in time to know which buffer
ring descriptor had the retry limit. And yet this is also a good example of
where you might use the higher priority hardware interrupt in a device
driver. You'd have a hybrid- Ethernet stuff would have a 5 uS latency,
everything else might be 10 uS. The limit is a function of the longest IRQ
service routine and the longest atomic operation that any software does.
I suspect the various people who have worked with uClinux could comment on
the latencies.
- pete
> -----Original Message-----
> From: On
> Behalf Of Robert Furber
>
> Any thoughts on interrupt latencies with uClinux?
 
--------------------------------------------------------------------
 
Mar 24, 2005, 6:37 AM
Post #17 of 25 (498 views)
 
 Re: [ColdFire] Interrupt latency [In reply to]
--------------------------------------------------------------------------------
 
Hi Robert,
Robert Furber wrote:
> Any thoughts on interrupt latencies with uClinux?
Significantly longer :smileysad:
There is a number of places where interrupts and disabled for
reasonably long periods of time. This will hurt your average
latency quite badly.
You can play tricks with high priority interrupts (level 7),
if you are careful with your interrupt routines.
Regards
Greg
 

>>Things that take time when you get an IRQ:
>> Finish the current instruction
>> Finish all pending bus writes
>> Build and write the exception frame
>> Fetch the vector
>> Now you're in the IRQ routine.
>>
>> If the instruction was an invalidate cache, it can take a _long_ time.
>>Math can take a while too. You can look up the times/bus cycles for the
>>other stuff.
>>
>> The times you are seeing are reasonable.
>>
>> Comment: When doing a system, one of the many core
>>decisions/assumptions
>>you make is what is your interrupt latency. In addition to the
>>above delays
>>you may have code that:
>> Turns off interrupts for a while
>> You're already in a service routine, so you have wait for
>> that routine to finish up
>> You make be flushing the cache (data cache with DMA means you're
>> doing this a lot)
>> You have to juggle the IRQ priorities.
>>
>> Some examples from the project I'm hacking:
>> A serial port IRQ service time takes about 2 uS
>> One of my PITs takes 14 us, the other 3 uS
>> I have IRQ for one device that takes 60 uS.
>> I have various pieces of code that turn off IRQs for 3-15 uS.
>>
>> On my system, I've "designed" for a maximum IRQ latency of about 100 uS.
>>The typical delay is 400 to 1000 nS, about what your seeing. BTW, all IRQ
>>service routines but two are in assembly.
>>
>> A final comment: Any system designed for tight IRQ latencies or that is
>>highly dependant on IRQ levels and nesting interrupts probably won't work.
>>You can have one or two high priority interrupts, but after that the
>>permutations become too much to grasp, and testing is very difficult.
>> The time difference between running out of SDRAM vs. on board flash is
>>about a 25% speedup when using on board FLASH. So one thing I do is run
>>everything out of on board SDRAM and be sure it works. Then,
>>when it moves
>>to FLASH I've got some margin. If you can't take a 25% variance in
>>performance, you've probably got things "wound up too tight". All I cache
>>are SDRAM code. So while the cache on the 5282 is small, I've got 512K of
>>code that is "always in the cache" (has no time penalty), and 64K of RAM
>>with the same situation. My Ethernet buffers and descriptors are in SRAM,
>>as are core variables and some of the stacks for tasks. I never have to
>>flush the cache to do DMA, and there is no penalty for Ethernet traffic
>>because of the dual porting of the on board SRAM.
>>
>> Another long winded rely, but hope it helps.
>>
>> - pete
>>
>>
>>>-----Original Message-----
>>>From: On
>>Behalf Of Scott A. McDermott
>>Sent: Tuesday, March 22, 2005 7:15 PM
>>Subject: [ColdFire] Interrupt latency
>>
>>
>>What do y'all think I should expect in terms of interrupt latency, from
>>an IRQ to the start of the routine? I'm seeing anywhere from 23 to 46
>>clock cycles. This doesn't seem right.
>>
>>I'm running entirely out of internal SRAM *and* I have cache enabled
>>(redundant, but caching seemed to help a little). Single-chip mode, but
>>after copying things into internal SRAM I turn off the Flash module,
>>just in case it was slowing things down. This is on a 5282LITE board,
>>if that makes a difference...
>>
>>My apologies for the recent series of questions, folks, I'm trying to
>>pull a colleague's project out of the fire, and it's due next week.
>>Please believe me that I'll turn around and answer as many questions as
>>I can once this local emergency is over! Thanks again for everyone's
>>help.
>>
>>--Scott
>
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL:
SnapGear -- a CyberGuard Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: --------------------------------------------------------------------
 
 

Message Edited by Dietrich on 04-03-2006 10:40 AM

Message Edited by Dietrich on 04-04-2006 09:01 PM

0 Kudos

1,147 Views
Dietrich
Contributor II
This message contains an entire topic ported from the WildRice - Coldfire forum.  Freescale has received the approval from the WildRice administrator on seeding the Freescale forum with messages.  The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value as you search for answers to your questions.  Freescale assumes no responsibility whatsoever with respect to Posted Material.  For additional information, please see the Terms of Use - Message Boards and Community Forums.  Thank You and Enjoy the Forum!
 

Mar 24, 2005, 8:52 AM
Post #18 of 25 (498 views)
 
 Re: [ColdFire] custom 5206e board gdb initialization [In reply to]
--------------------------------------------------------------------------------
 
Chris,
I still don't understand why I can breakpoint using P&E debugger with
the same boot code and I can't with gdb.
My vector table is setup just fine, does gdb use a different vector for
setting breakpoints, watchpoints?
Here's a result of running gdb...
Coldfire debug module version is 0 (5206(e)/5272/5282)
(gdb) display /i $pc
target_fetch_registers (pc) = ffe03232 0xffe03232 4292882994
(gdb) bdm-reset
(gdb) set $pc = *4
target_fetch_registers (pc) = ffe03232 0xffe03232 4292882994
target_xfer_memory (0x4, xxx, 4, read, xxx) = 4, bytes =
ff e0 05 56
target_fetch_registers (fp) = 301ffea0 0x301ffea0 807403168
target_fetch_registers (sp) = 301ffe9c 0x301ffe9c 807403164
target_prepare_to_store ()
target_store_registers (pc) = ffe00556 0xffe00556 4292871510
(gdb) set $sp = *0
target_xfer_memory (0x0, xxx, 4, read, xxx) = 4, bytes =
30 1f ff 00
target_prepare_to_store ()
target_store_registers (sp) = 301fff00 0x301fff00 807403264
(gdb) si
target_terminal_inferior ()
target_resume (-1, step, 0)
nothing happens....
however if I execute 'c' the boot code runs fine, and copies my
application code from flash to external ram and I can then stop the
execution, set a breakpoint or single-step.

Jayne
 
On Wed, 2005-03-23 at 15:01, Chris Johns wrote:
> Jayne Dickinson wrote:
>
> >
> > I am trying to single step my flash boot code, I can do this using
> > P&E debugger without problems.
>
> Stepping an instruction at a time for code in read-only memory is supported.
>
> The BDM debug hardware has a bit that masks interrupts (CSR[IPI]) while
> stepping and a bit that steps and instruction (CSR[SSM]) with the BDM GO
> command. These bits together mean you can step code in read-only memory.
> The only other way to halt the processor is to use the hardware break
> point support and GDB does not do this automatically as this is a
> limited resource and may already be used by you.
>
> Any other sort of stepping in GDB requires a software break point and a
> software break point is modifying code by placing a 'halt' instruction
> at the break point address. To do this code must be in RAM.
>
> >
> > Here's another log of what goes on... I powerup my board, connect to the
> > bdm pod on my linux pc, display the PC register... interesting the PC is
> > NOT set to entry address loaded in flash (amd29L160B) device, like the
> > bdm reset doesn't know where flash base address is?
>
> The processor has been at reset. Loading the PC occurs after reset. This
> is documented in the user manual and exists so you can set the PC. If
> you set the PC via BDM the Coldfire will not fetch the reset vector from
> the vector table. Nice feature when you do not have a vector table, ie
> blank flash.
>
> > Single stepping in
> > flash still doesn't do a thing...HOWEVER, after I set my PC to the
> > correct location of my startup entry in flash, and execute 'c' I can run
> > my application code ( which was loaded into another region in flash )
> > that my boot code understands....then I wait for my application code to
> > run and interrupt GDB... guess what...single stepping now works....
> >
>
> Is your vector table setup correctly ?
>
> > Does this mean that gdb doesn't support single stepping flash ?
> No. Here is my trace from the 5282 eval board of stepping in flash:
>
> (gdb) display /i $pc
> 1: x/i $pc 0x400: movew #9984,%sr
> (gdb) si
> 0x00000404 in ?? ()
> 1: x/i $pc 0x404: jmp 0xffe1f8e4
> (gdb) si
> 0xffe1f8e4 in ?? ()
> 1: x/i $pc 0xffe1f8e4: movew #9984,%sr
> (gdb) si
> 0xffe1f8e8 in ?? ()
> 1: x/i $pc 0xffe1f8e8: movel #1073741825,%d0
> (gdb) si
> 0xffe1f8ee in ?? ()
> 1: x/i $pc 0xffe1f8ee: movel %d0,0x40000000
> (gdb) si
> 0xffe1f8f4 in ?? ()
> 1: x/i $pc 0xffe1f8f4: movel #-268435423,%d0
> (gdb)
>
> >
> > ( I interrupted GDB by typing <ctrl><c> twice )
> >
>
> This is a bug and I am hoping to look at this soon. It could be a source
> of your problem, ie not cleanly stopping after si and automatically
> continuing. The step stops but GDB does not cleanly stop.
>
> Try after stopping and without leaving GDB:
>
> (gdb) bdm-reset
> (gdb) set $pc = *4
> (gdb) set $sp = *0
> (gdb) display /i $pc
> (gdb) si

Mar 25, 2005, 11:21 PM
Post #19 of 25 (497 views)
 
 Re: [ColdFire] custom 5206e board gdb initialization [In reply to]
--------------------------------------------------------------------------------
 
Jayne Dickinson wrote:
>
> I still don't understand why I can breakpoint using P&E debugger with
> the same boot code and I can't with gdb.
>
It is a bug in the BDM backend in GDB. The fix is to cut the bdm_ptid
assignment from the end of the function 'bdm_resume' in
remote-m68k-bdm.c in your patched GDB sources:
static void
bdm_resume (ptid_t pid, int step, enum target_signal sig)
{
if (bdm_debug_level)
printf_filtered ("bdm resume called\n");
if (step)
bdm_step_chip ();
else
bdm_go ();
}
and add it to 'bdm_attach' in the same file:
static void
bdm_attach (char *args, int from_tty)
{
if (bdm_debug_level)
printf_filtered ("bdm attach called\n");
bdm_open (args, from_tty);
bdm_ptid = pid_to_ptid (42000);
}
--
Chris Johns
--------------------------------------------------------------------
Dec 17, 2005, 4:20 PM
Post #20 of 25 (127 views)
 
 RE: [ColdFire] interrupt latency [In reply to]
--------------------------------------------------------------------------------
 
Hi Chris,
You dont mention how you are measuring latency. Typically you would set
a port pin upon entering the ISR and clear it upon exiting. Using a good
scope,
connect channel one to the interrupt source and channel two to the
toggled port pin. I am assuming you are doing all this.
Are you using an RTOS? Might interrupts sometimes be disabled and at
other times not be disabled?
I dont find your readings out of the norm.... there can be a lot of
variation in latency times. As you are finding, a processor interrupt is
not always the most predictable or a consistent of processes. Please
take a look at this article by Jack Ganssle(link below). Lots of
good advice and things to ponder. Let us know what you find.
Regards,
Randy
-----Original Message-----
From:
On Behalf Of Chris Becker
Sent: Saturday, December 17, 2005 5:49 PM
To: Randy Shaull
Subject: [ColdFire] interrupt latency

Hi everyone,
I have been measuring the response time for an external interrupt line
(7,
highest priority) going low and the actual ISR running. I am finding
the
results rather confusing and inconsistent. The clock speedis 73 MHz so
cycle time is around 14ns.
I have a fetish with knowing where every single cycle is going and I am
finding this quite frusterating.
The reason I care so much is I am using a 5213 with no particularly easy
way
of connecting a PCM bus to it. I have found a way to do this but it
depends
quite a bit on servicing the external ISR in a consistent amount of
time. There seems to be a very large window of time that the ISR might
get
executed in.
Now the movem.l instruction I think is responsible for a lot of this.
Moving 14 registers to/from the stack takes 15 cycles or 210ns. So the
ISR
window is now 210ns.
Then there are other lower priority interrupts in the system. I cannot
find
any info on how long it takes to vector to an ISR, but my measurements
seeem
to indicate 250ns or around 18 cycles. This seems like quite a bit
given
that two longs need to pushed on the stack and a jsr executed. Does
anybody
know how long it really takes to jump to an ISR?
So now the ISR window is around 250ns.
Now I let a little bit more code run in the system (nothing fancy,
nothign
doing much) and the ISR from being triggered takes anywhere from
executing
almost right away to a whopping 600ns or 43 cycles later.
That implies to me that there is some atomic instruction somewhere that
takes 43 cycles to execute??? I have yet to find it or figure out what
is
going on.
Has anybody been through this already? Or know what might be causing
such a
delay in the ISR being executed? With a 14ns cycle time I personally
would
kinda thing I could get the highest priority interrupt in the system to
run
consistenly within a 200ns window.
Sorry for the length of this rambling email, I am just finding the
execution
time of things on this coldfire rather unpredictable. Probably
something to
do with the pipeline....
Thanks,
Chris

----- Original Message -----
From: "Kevin Zhang"
Sent: Friday, December 16, 2005 7:23 AM
Subject: Re: [ColdFire] Development Tools

> It was so nice that I got a lot suggestions for my question. Thank you
> all, Sarah, Tom, Robert, Jay, NZG. This ColdFire mail list is helpful.
>
> Kevin Zhang
> ----- Original Message -----
> From: "Tom Burrell"
> Sent: Wednesday, December 14, 2005 11:01 AM
> Subject: Re: [ColdFire] Development Tools
>
>
>> My personal prefrence if GNU and P&E. GNU is free, and P&E is
>> reasonible. Tried CodeWarrior for 6 months could not get a stable
>> system, Two weeks with GNU and everything is ok. The USB tools from
>> P&E are a little more expensive but nice. P&E works with ELF.
>> Tom
>> On Wed, 2005-12-14 at 09:59 -0500, Kevin Zhang wrote:
>>> Hi everybody,
>>>
>>> I am new to ColdFire, (was working on HC05/08//11/12, and a little
>>> bit
>>> 68340). Any suggestion that where I start? And what kind of
compiler,
>>> debugger, BDM hardware I may afford? CodeWarrior is too expensive to
me.
>>>
>>> Thank you in advance.
>>>
Kevin-------------------------------------------------------------------
-
 
 

Message Edited by Dietrich on 04-03-2006 10:26 AM

Message Edited by Dietrich on 04-03-2006 10:27 AM

Message Edited by Dietrich on 04-04-2006 09:00 PM

0 Kudos

1,147 Views
Dietrich
Contributor II
This message contains an entire topic ported from the WildRice - Coldfire forum.  Freescale has received the approval from the WildRice administrator on seeding the Freescale forum with messages.  The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value as you search for answers to your questions.  Freescale assumes no responsibility whatsoever with respect to Posted Material.  For additional information, please see the Terms of Use - Message Boards and Community Forums.  Thank You and Enjoy the Forum!
 

Dec 18, 2005, 1:48 PM
Post #21 of 25 (127 views)
 
 Re: [ColdFire] interrupt latency [In reply to]
--------------------------------------------------------------------------------
 
In responce to the original question ( which I did not see)
1)There are two ways to sync the coldfire core, that is finish off all queued
writes a) Execute a NOP b) trap.
My quess is your seeing the time it takes to sync the core when it has
different writes queued. If your have a logic analizer id be looking at the
bus activity.
It would be interesting to know what you find, I always thought this wouild be
the case but never had the time to play.

In response to the responce below
1) Trap 7 cannot be masked, and you cannot use OS services. For this sort of
work the OS matters not.
2) For this sort of work you should be using assembler and writing routines
that push as few registers as possible, I work by the rule of thumb MOVEM
loses against MOVE unless you push more than 3 registers. I haven't done any
recent research to work out if that rule still holds.

Regards
 
On Sunday 18 December 2005 11:20, Randy Shaull wrote:
> Hi Chris,
> You dont mention how you are measuring latency. Typically you would set
> a port pin upon entering the ISR and clear it upon exiting. Using a good
> scope,
> connect channel one to the interrupt source and channel two to the
> toggled port pin. I am assuming you are doing all this.
> Are you using an RTOS? Might interrupts sometimes be disabled and at
> other times not be disabled?
> I dont find your readings out of the norm.... there can be a lot of
> variation in latency times. As you are finding, a processor interrupt is
> not always the most predictable or a consistent of processes. Please
> take a look at this article by Jack Ganssle(link below). Lots of
> good advice and things to ponder. Let us know what you find.
> Regards,
> Randy
>
> http://www.embedded.com/showArticle.jhtml?articleID=9900320
>
> -----Original Message-----
> From: > On Behalf Of Chris Becker
> Sent: Saturday, December 17, 2005 5:49 PM
> To: Randy Shaull
> Subject: [ColdFire] interrupt latency
>
>
> Hi everyone,
>
> I have been measuring the response time for an external interrupt line
> (7,
> highest priority) going low and the actual ISR running. I am finding
> the
> results rather confusing and inconsistent. The clock speedis 73 MHz so
> cycle time is around 14ns.
>
> I have a fetish with knowing where every single cycle is going and I am
> finding this quite frusterating.
>
> The reason I care so much is I am using a 5213 with no particularly easy
> way
> of connecting a PCM bus to it. I have found a way to do this but it
> depends
> quite a bit on servicing the external ISR in a consistent amount of
> time. There seems to be a very large window of time that the ISR might
> get
> executed in.
>
> Now the movem.l instruction I think is responsible for a lot of this.
> Moving 14 registers to/from the stack takes 15 cycles or 210ns. So the
> ISR
> window is now 210ns.
>
> Then there are other lower priority interrupts in the system. I cannot
> find
> any info on how long it takes to vector to an ISR, but my measurements
> seeem
> to indicate 250ns or around 18 cycles. This seems like quite a bit
> given
> that two longs need to pushed on the stack and a jsr executed. Does
> anybody
> know how long it really takes to jump to an ISR?
>
> So now the ISR window is around 250ns.
>
> Now I let a little bit more code run in the system (nothing fancy,
> nothign
> doing much) and the ISR from being triggered takes anywhere from
> executing
> almost right away to a whopping 600ns or 43 cycles later.
>
> That implies to me that there is some atomic instruction somewhere that
> takes 43 cycles to execute??? I have yet to find it or figure out what
> is
> going on.
>
> Has anybody been through this already? Or know what might be causing
> such a
> delay in the ISR being executed? With a 14ns cycle time I personally
> would
> kinda thing I could get the highest priority interrupt in the system to
> run
> consistenly within a 200ns window.
>
> Sorry for the length of this rambling email, I am just finding the
> execution
> time of things on this coldfire rather unpredictable. Probably
> something to
> do with the pipeline....
>
> Thanks,
> Chris
>
>
> ----- Original Message -----
> From: "Kevin Zhang"
> Sent: Friday, December 16, 2005 7:23 AM
> Subject: Re: [ColdFire] Development Tools
>
> > It was so nice that I got a lot suggestions for my question. Thank you
> > all, Sarah, Tom, Robert, Jay, NZG. This ColdFire mail list is helpful.
> >
> > Kevin Zhang
> > ----- Original Message -----
> > From: "Tom Burrell"
> > Sent: Wednesday, December 14, 2005 11:01 AM
> > Subject: Re: [ColdFire] Development Tools
> >
> >> My personal prefrence if GNU and P&E. GNU is free, and P&E is
> >> reasonible. Tried CodeWarrior for 6 months could not get a stable
> >> system, Two weeks with GNU and everything is ok. The USB tools from
> >>
> >> P&E are a little more expensive but nice. P&E works with ELF.
> >> Tom
> >>
> >> On Wed, 2005-12-14 at 09:59 -0500, Kevin Zhang wrote:
> >>> Hi everybody,
> >>>
> >>> I am new to ColdFire, (was working on HC05/08//11/12, and a little
> >>> bit
> >>> 68340). Any suggestion that where I start? And what kind of
>
> compiler,
>
> >>> debugger, BDM hardware I may afford? CodeWarrior is too expensive to
>
> me.
>
> >>> Thank you in advance.
>
> Kevin-------------------------------------------------------------------
> -
Dec 18, 2005, 3:57 PM
Post #22 of 25 (127 views)
 
 Re: [ColdFire] interrupt latency [In reply to]
--------------------------------------------------------------------------------
 
 
>2) For this sort of work you should be using assembler and writing routines
>that push as few registers as possible, I work by the rule of thumb MOVEM
>loses against MOVE unless you push more than 3 registers. I haven't done any
>recent research to work out if that rule still holds.
Yes, that is true in straight-line code, but on an entry to a
function, the movem instruction takes the same amount of time as the
moves(1 clock per regiser to move), but by using a movem, you give the
core a chance to fill the instruction fetch pipeline. For the V4
core, I use the following(I'm writing this off the top of my head, YMMV):
asm_isr_code:
lea -16(%sp),%sp
movem.l %d0/%d1/%a0/%a1, (%sp)
bsr c_isr_code
movem.l (%sp), %d0/%d1/%a0/%a1
lea 16(%sp),%sp
rte
which calls into a C function to handle the ISR.
--
Peter Barada

--------------------------------------------------------------------
Dec 18, 2005, 5:35 PM
Post #23 of 25 (127 views)
 
 Re: [ColdFire] interrupt latency [In reply to]
--------------------------------------------------------------------------------
 
I looked up the instruction time, the 5407 is just an amazing jigger. With
memory so slow, code bandwidth now matters, so I agree, my rule is outdated,
definitly faster for 3. Two I don't know, I reckon it might be a dead heat.
Coldfire rocks.
On Monday 19 December 2005 10:57, Peter Barada wrote:
> >2) For this sort of work you should be using assembler and writing
> > routines that push as few registers as possible, I work by the rule of
> > thumb MOVEM loses against MOVE unless you push more than 3 registers. I
> > haven't done any recent research to work out if that rule still holds.
>
> Yes, that is true in straight-line code, but on an entry to a
> function, the movem instruction takes the same amount of time as the
> moves(1 clock per regiser to move), but by using a movem, you give the
> core a chance to fill the instruction fetch pipeline. For the V4
> core, I use the following(I'm writing this off the top of my head, YMMV):
>
> asm_isr_code:
> lea -16(%sp),%sp
> movem.l %d0/%d1/%a0/%a1, (%sp)
> bsr c_isr_code
> movem.l (%sp), %d0/%d1/%a0/%a1
> lea 16(%sp),%sp
> rte
>
> which calls into a C function to handle the ISR.
--------------------------------------------------------------------
Dec 19, 2005, 12:58 PM
Post #24 of 25 (121 views)
 
 Re: Re: [ColdFire] interrupt latency [In reply to]
--------------------------------------------------------------------------------
 
He is using level 7, the non maskable interrupt. You don't wast time
writing 2700 to the status register, further the OS writing 2700 doesn't
stop the interrupt.
Look upon it as a hardware interrupt, you do hardware things not
software things.
Regards
----- Original Message -----
From: Peter Barada
Sent: 12/19/2005 9:49:56 PM
Subject: Re: [ColdFire] interrupt latency
>
> >- Use that first protected instruction inside the ISR to turn off
other
> >interrupts (good ol' movec #$2700,sp) and make sure they're not
getting
> >in the way.
>
> I think you meant:
>
> movew #0x2700,%sr
>
> Another point to ponder is that if you have critical section code that
> disables interrupts, that can be getting in the way as well.
>
> --
> Peter Barada
 

Dec 19, 2005, 1:01 PM
Post #25 of 25 (121 views)
 
 Re: Re: [ColdFire] interrupt latency [In reply to]
--------------------------------------------------------------------------------
 
Coldfire also doesn't raise the interrupt level. The slot is there so
you can write to the status register and know for sure it happened. Not
a good place for a NOP.
Regards
----- Original Message -----
From: Tom Burrell
Sent: 12/20/2005 12:54:28 AM
Subject: Re: [ColdFire] interrupt latency
> I am not currently working on coldfire, but, I remember putting a noop
> at the beginning of each interrupt because the coldfire guarentees to
> execute the first instruction of each interrupt. Don't Know if this is
> any help.
> Tom
> On Sat, 2005-12-17 at 15:49 -0700, Chris Becker wrote:
> > Hi everyone,
> >
> > I have been measuring the response time for an external interrupt
line (7,
> > highest priority) going low and the actual ISR running. I am
finding the
> > results rather confusing and inconsistent. The clock speedis 73 MHz
so
> > cycle time is around 14ns.
> >
> > I have a fetish with knowing where every single cycle is going and I
am
> > finding this quite frusterating.
> >
> > The reason I care so much is I am using a 5213 with no particularly
easy way
> > of connecting a PCM bus to it. I have found a way to do this but it
depends
> > quite a bit on servicing the external ISR in a consistent amount of
time.
> > There seems to be a very large window of time that the ISR might get
> > executed in.
> >
> > Now the movem.l instruction I think is responsible for a lot of
this.
> > Moving 14 registers to/from the stack takes 15 cycles or 210ns. So
the ISR
> > window is now 210ns.
> >
> > Then there are other lower priority interrupts in the system. I
cannot find
> > any info on how long it takes to vector to an ISR, but my
measurements seeem
> > to indicate 250ns or around 18 cycles. This seems like quite a bit
given
> > that two longs need to pushed on the stack and a jsr executed. Does
anybody
> > know how long it really takes to jump to an ISR?
> >
> > So now the ISR window is around 250ns.
> >
> > Now I let a little bit more code run in the system (nothing fancy,
nothign
> > doing much) and the ISR from being triggered takes anywhere from
executing
> > almost right away to a whopping 600ns or 43 cycles later.
> >
> > That implies to me that there is some atomic instruction somewhere
that
> > takes 43 cycles to execute??? I have yet to find it or figure out
what is
> > going on.
> >
> > Has anybody been through this already? Or know what might be
causing such a
> > delay in the ISR being executed? With a 14ns cycle time I
personally would
> > kinda thing I could get the highest priority interrupt in the system
to run
> > consistenly within a 200ns window.
> >
> > Sorry for the length of this rambling email, I am just finding the
execution
> > time of things on this coldfire rather unpredictable. Probably
something to
> > do with the pipeline....
> >
> > Thanks,
> > Chris
> >
> >
> > ----- Original Message -----
> > From: "Kevin Zhang"
> > Sent: Friday, December 16, 2005 7:23 AM
> > Subject: Re: [ColdFire] Development Tools
> >
> >
> > > It was so nice that I got a lot suggestions for my question. Thank
you
> > > all, Sarah, Tom, Robert, Jay, NZG. This ColdFire mail list is
helpful.
> > >
> > > Kevin Zhang
> > > ----- Original Message -----
> > > From: "Tom Burrell"
> > > Sent: Wednesday, December 14, 2005 11:01 AM
> > > Subject: Re: [ColdFire] Development Tools
> > >
> > >
> > >> My personal prefrence if GNU and P&E. GNU is free, and P&E is
> > >> reasonible. Tried CodeWarrior for 6 months could not get a stable
> > >> system, Two weeks with GNU and everything is ok. The USB tools
from
> > >> P&E are a little more expensive but nice.
> > >> P&E works with ELF.
> > >> Tom
> > >> On Wed, 2005-12-14 at 09:59 -0500, Kevin Zhang wrote:
> > >>> Hi everybody,
> > >>>
> > >>> I am new to ColdFire, (was working on HC05/08//11/12, and a
little bit
> > >>> 68340). Any suggestion that where I start? And what kind of
compiler,
> > >>> debugger, BDM hardware I may afford? CodeWarrior is too
expensive to me.
> > >>>
> > >>> Thank you in advance.
> > >>>
Kevin 

Message Edited by Dietrich on 04-03-2006 10:11 AM

Message Edited by Dietrich on 04-04-2006 01:54 PM

0 Kudos

1,147 Views
Dietrich
Contributor II
This message contains an entire topic ported from the WildRice - Coldfire forum.  Freescale has received the approval from the WildRice administrator on seeding the Freescale forum with messages.  The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value as you search for answers to your questions.  Freescale assumes no responsibility whatsoever with respect to Posted Material.  For additional information, please see the Terms of Use - Message Boards and Community Forums.  Thank You and Enjoy the Forum!


Mar 22, 2005, 7:22 AM
Post #6 of 25 (504 views)
 
 Re: [ColdFire] custom 5206e board gdb initialization [In reply to]
--------------------------------------------------------------------------------
 
Mark,
Thanks for the tip... so I exited gdb and restarted gdb and using your
suggestion of doing 'cont' instead of 'run' gdb command, gdb just sits
there and never reaches my hb.
BTW, I have already been able to do this in my Windows PC environment
using P&E coldfire debugger..but I want to do this in Linux! )
Here's my trace..
>m68k-bdm-elf-gdb -n -x $COLDFIRE/gdbScripts/mtpStart.gdb bblock.elf
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=m68k-bdm-elf"...
(gdb) target bdm /dev/bdmcf0
trying kernel driver: /dev/bdmcf0
trying bdm server: localhost:/dev/bdmcf0
Detected V2 core
GDB target bdm connected to /dev/bdmcf0
Coldfire debug module version is 0 (5206(e)/5272/5282)
(gdb) help user-define
User-defined commands.
The commands in this class are those defined by the user.
Use the "define" command to define a command.
List of commands:
addresses -- User-defined
flash-erase -- User-defined
flash-program -- User-defined
flash-programstartaddr -- User-defined
flash-programword -- User-defined
initboard -- User-defined
setup-bdm -- User-defined
setup-cs -- User-defined
setup-entry -- User-defined
setup-sram -- User-defined
Type "help" followed by command name for full documentation.
Command name abbreviations are allowed if unambiguous.
(gdb) setup-sram
(gdb) select 0
Current language: auto; currently c++
(gdb) addresses
(gdb) setup-cs
(gdb) setup-bdm
(gdb) hb main
Hardware assisted breakpoint 1 at 0xffe02f34: file main.c, line 140.
(gdb) x /x $pc
0xffe0322e <Delay+36>: 0x60ea60d4
(gdb) x /x $sp
0x301ffe9c: 0xffffffff
(gdb) x /x $fp
0x301ffea0: 0xffffffff
(gdb) c
Continuing.
On Tue, 2005-03-22 at 08:08,  wrote:
> Don't do run - try 'cont' or 'c'
>
> Mark
>
>
> To: Mark C.
> cc:
> Subject: Re: [ColdFire] custom 5206e board gdb initialization
>
>
>
>
> Thanks Chris,
>
>
> I started m68k-bdm-elf-gdb and can now see the registers...but
> bdm-read-creg $cacr isn't returning the value of the cacr register
>
>
> Here's my trace of what I performed this morning.....
>
>
>
> >m68k-bdm-elf-gdb -n -x $COLDFIRE/gdbScripts/mtpStart.gdb bblock.elf
> GNU gdb 6.1
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> This GDB was configured as "--host=i686-pc-linux-gnu
> --target=m68k-bdm-elf"...
> (gdb) target bdm /dev/bdmcf0
> trying kernel driver: /dev/bdmcf0
> trying bdm server: localhost:/dev/bdmcf0
> Detected V2 core
> GDB target bdm connected to /dev/bdmcf0
> Coldfire debug module version is 0 (5206(e)/5272/5282)
> (gdb) info registers
> No selected frame.
> (gdb) select 0
> Current language: auto; currently c++
> (gdb) bdm-read-creg $cacr
> Value can't be converted to integer.
> (gdb) bdm-read-creg $mbase
> Value can't be converted to integer.
> (gdb) info registers
> d0 0x1 1
> d1 0x10000c0 16777408
> d2 0xd2 210
> d3 0xd3 211
> d4 0xd4 212
> d5 0xd5 213
> d6 0x10000000 268435456
> d7 0xd7 215
> a0 0x10000000 0x10000000
> a1 0x3000ed48 0x3000ed48
> a2 0xffe12a80 0xffe12a80
> a3 0xa3 0xa3
> a4 0xa4 0xa4
> a5 0xa5 0xa5
> fp 0x20000000 0x20000000
> sp 0x20000000 0x20000000
> ps 0x2700 9984
> pc 0xffe00000 0xffe00000 <_VECTOR_TABLE>
> vbr 0x74 116
> cacr 0x0 0
> acr0 0x0 0
> acr1 0x0 0
> rambar 0x20000000 536870912
> mbar 0x10000000 268435456
> macsr 0x8 8
> mask 0xffff5555 -43691
> acc 0xff4d0166 -11730586
> csr 0x1000000 16777216
> aatr 0x5 5
> tdr 0x40000000 1073741824
> pbr 0x0 0
> pbmr 0x0 0
> abhr 0x0 0
> ablr 0x0 0
> dbr 0x0 0
> dbmr 0x0 0
> (gdb)
>
> (gdb) hb main
> Hardware assisted breakpoint 1 at 0xffe02f34: file main.c, line 140.
> (gdb) run
> Starting program:
> /home/jayned/mtpDev/mtpRev3Baseline/BootBlock/bblock.elf
> BDM driver error: No response to BDM request
> (gdb)
>
> On Mon, 2005-03-21 at 16:22, Chris Johns wrote:
> > Jayne Dickinson wrote:
> > >
> > > set $rom-base = 0xffe00000
> >
> > I think this is saying '$rom' minus 'base' and GDB is assuming 'base' is
> > a symbol.
> >
> > >
> > > How can I directly access the 5206e registers directly, I want to
> > > invalidate cache, while I am using the debugger.
> > >
> > > (gdb) bdm-read-creg /x $cacr
> > > Value can't be converted to integer.
> > >
> >
> > What happens if you do not supply the '/x' option ?
> >
> > The 5206e registers should be defined, ie try 'info reg' and if you get
> > a no selected frame issue 'select 0' first.
>
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
Mar 22, 2005, 12:30 PM
Post #7 of 25 (503 views)
 
 Re: [ColdFire] custom 5206e board gdb initialization [In reply to]
--------------------------------------------------------------------------------
 
Jayne Dickinson wrote:
>
> (gdb) bdm-read-creg $cacr
> Value can't be converted to integer.
This could be a bug.
>
> (gdb) hb main
> Hardware assisted breakpoint 1 at 0xffe02f34: file main.c, line 140.
> (gdb) run
> Starting program:
> /home/jayned/mtpDev/mtpRev3Baseline/BootBlock/bblock.elf
> BDM driver error: No response to BDM request
> (gdb)
>
Do you have the BDM processor status signals configured as I/O ?
If you do then it may pay to add after the target connect command:
bdm-cf-pst 0
This stops the BDM driver from using the PST signals and uses software
to detect the target has halted. This command only works on the 5206e.
--
Chris Johns
--------------------------------------------------------------------

Message Edited by Dietrich on 04-01-2006 01:37 PM

Message Edited by Dietrich on 04-04-2006 01:53 PM

0 Kudos