Sign in

username:

password:



Not a member?

Search motoroladsp



Search tips

Subscribe to motoroladsp



motoroladsp by Keywords

56303 | 563xx | 5680 | 56805 | 5680x | 56F80 | 56F800DEMO | 56F805 | 56f807 | 56F830 | ADC | Bootloader | Codec | CodeWarrior | CW5 | CW6 | Debugger | DSP56303 | DSP56303EVM | DSP563xx | DSP5680 | DSP56800 | DSP56807 | DSP56858 | DSP56858EVM | DSP56F803 | DSP56F805 | DSP56F807 | DSP56F80x | DSP56F826 | DSP56F827 | DSP56F8xx | EVM | FFT | Flash_over_jtag | GPIO | Interrupt | Interrupts | JTAG | LCD | Linker | MCF5307 | Metrowerks | Modulus | MSCAN | PCMaster | PWM | Quad | Rif | RTOS | SDK | SPI

Discussion Groups

Discussion Groups | Freescale DSPs | Looking at registers

Technical discussions about Freescale (Motorola) DSPs (including the DSP56000, DSP56300, DSP56600, 56800 DSPs).

  

Post a new Thread

Stepping through assembly language... - dibosco - Nov 22 20:22:00 2003



Hi Folks,

I'm trying to work out why one of the routines in our code is taking
so damn long to execute. The code is written in C. What I want to do
is look at the disassembled code, mixed with the C. So, I want to set
a break point at the start of a function (in the C code or
disassembled code - but if it's disassembled code, I want to see the C
code at the same time). Once the program stops at the line of C code,
I want to be able to follow the program through every step of the
assembly language code the C compiler has generated.

The closest we've managed to achieve so far is to just disassemble the
source code, but we can't set a break point or step through it.

Surely this is possible? Every other debugger I've worked with has
been able to do this.

BTW, when we look at our disassebled code it looks bizarre. Here's an
example:

; 651: outval = outval + 6;
; 652:
;
0x00000024 0x87C540C0 movei #16576,B
0x00000026 0xDE0B lea (SP)+
0x00000027 0xD19F move B0,X:(SP)
0x00000028 0xDE0B lea (SP)+
0x00000029 0xD71F move B1,X:(SP)
0x0000002A 0xB4FD move X:(SP-0x0003),A
0x0000002B 0xF0CBFFFC move X:(SP-0x0004),A0
0x0000002D 0xE9C80000 jsr 0x000000
0x0000002F 0xDE1B pop
0x00000030 0xDE1B pop
0x00000031 0x96FF move A1,X:(SP-0x0001)
0x00000032 0xD0CBFFFE move A0,X:(SP-0x0002)

So, to add 6 to the outval (float) value it's taking twelve
instructions, one of which is this strange jsr 0x000000 and then there
are the two "pop"s!

Can anyone shed any light on either of the above issues?

Many thanks,

Rob.




(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

Re: Stepping through assembly language... - Kenneth Ciszewski - Nov 23 19:20:00 2003

There is a document (attached) that describes how the ELF disassembler files are structured, but I admit that it's not very intuitive, and I really don't see how it works.  It looks like Codewarrior C is calling a subroutine with the JSR, and is setting up that call with register initializations.  However....!  It is not obvious how the JSR 0x0000000 points to what wherever the subroutine actually is, although in some disassemblies, the subroutine name is given in the  comment field.

dibosco <r...@apostrophe.co.uk> wrote:
Hi Folks,

I'm trying to work out why one of the routines in our code is taking
so damn long to execute. The code is written in C. What I want to do
is look at the disassembled code, mixed with the C. So, I want to set
a break point at the start of a function (in the C code or
disassembled code - but if it's disassembled code, I want to see the C
code at the same time). Once the program stops at the line of C code,
I want to be able to follow the program through every step of the
assembly language code the C compiler has generated.

The closest we've managed to achieve so far is to just disassemble the
source code, but we can't set a break point or step through it.

Surely this is possible? Every other debugger I've worked with has
been able to do this.

BTW, when we look at our disassebled code it looks bizarre. Here's an
example:

;  651:       outval = outval + 6;
;  652: 
;
0x00000024  0x87C540C0             movei    #16576,B
0x00000026  0xDE0B                ;  lea      (SP)+
0x00000027  0xD19F                ;  move     B0,X:(SP)
0x00000028  0xDE0B                ;  lea      (SP)+
0x00000029  0xD71F                ;  move     B1,X:(SP)
0x0000002A  0xB4FD                ;  move     X:(SP-0x0003),A
0x0000002B  0xF0CBFFFC             move     X:(SP-0x0004),A0
0x0000002D  0xE9C80000             jsr      0x000000
0x0000002F  0xDE1B                ;  pop     
0x00000030  0xDE1B                ;  pop     
0x00000031  0x96FF                ;  move     A1,X:(SP-0x0001)
0x00000032  0xD0CBFFFE             move     A0,X:(SP-0x0002)

So, to add 6 to the outval (float) value it's taking twelve
instructions, one of which is this strange jsr 0x000000 and then there
are the two "pop"s!

Can anyone shed any light on either of the above issues?

Many thanks,

Rob.



_____________________________________
/groups.php3


Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


Attachment (not stored)
ELF description.pdf
Type: application/pdf




(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

Re: Stepping through assembly language... - Jan Zizka - Nov 25 7:16:00 2003

Hi,

the jsr 0x00000000 is most probably because you are viewing object file
of compiled but not linked module. The adresses to "library" routines
are filled in by linker. Check the final elf file I'm sure you'll see
some reasonable address there.

As was saied by someone other, mixed floating point and integer arithmetics
is very expencive. Try using constants like "5.0" (not "5"). In any case
I would suggest to use fractional types instead of floats sice DSPs usually
don't have floating point unit so they have to emulate it.

Regards
Jan On Sat, Nov 22, 2003 at 08:22:25PM -0000, dibosco wrote:
> Hi Folks,
>
> I'm trying to work out why one of the routines in our code is taking
> so damn long to execute. The code is written in C. What I want to do
> is look at the disassembled code, mixed with the C. So, I want to set
> a break point at the start of a function (in the C code or
> disassembled code - but if it's disassembled code, I want to see the C
> code at the same time). Once the program stops at the line of C code,
> I want to be able to follow the program through every step of the
> assembly language code the C compiler has generated.
>
> The closest we've managed to achieve so far is to just disassemble the
> source code, but we can't set a break point or step through it.
>
> Surely this is possible? Every other debugger I've worked with has
> been able to do this.
>
> BTW, when we look at our disassebled code it looks bizarre. Here's an
> example:
>
> ; 651: outval = outval + 6;
> ; 652:
> ;
> 0x00000024 0x87C540C0 movei #16576,B
> 0x00000026 0xDE0B lea (SP)+
> 0x00000027 0xD19F move B0,X:(SP)
> 0x00000028 0xDE0B lea (SP)+
> 0x00000029 0xD71F move B1,X:(SP)
> 0x0000002A 0xB4FD move X:(SP-0x0003),A
> 0x0000002B 0xF0CBFFFC move X:(SP-0x0004),A0
> 0x0000002D 0xE9C80000 jsr 0x000000
> 0x0000002F 0xDE1B pop
> 0x00000030 0xDE1B pop
> 0x00000031 0x96FF move A1,X:(SP-0x0001)
> 0x00000032 0xD0CBFFFE move A0,X:(SP-0x0002)
>
> So, to add 6 to the outval (float) value it's taking twelve
> instructions, one of which is this strange jsr 0x000000 and then there
> are the two "pop"s!
>
> Can anyone shed any light on either of the above issues?
>
> Many thanks,
>
> Rob.


(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

Sending a CAN message - Robert Wood - Jan 24 20:17:00 2004

Hi folks,

I'm trying to set up a 56F807 to send out and receive CAN messages. I'm new to
CAN (apart from having read numerous articles about it!) so I'm probably
missing something fundamental here.

I've set the transmit identifier, some transmit data and the data length
register. However, nothing comes out! I'm guessing there's a flag somewhere
you have to set to actually make the processor send the message out?

I've done something along the lines of:

CAN_TB0_IDRx = Identifier number

CAN_TB0_DSR0-x = various data

CAN_TB0_DLR = Number of databytes in the DSR register.

So, what do I do to force that data out?! I've set the CANE bit, btw.

Many thanks,

Rob


(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

RE: Sending a CAN message - Corey, Rick - Jan 24 21:18:00 2004

Hi Robert

There's about a bushel of register setups required. I _would_ urge you
to read the MSCAN chapter in the User Manual, but reading it repeatedly
didn't suffice for me either. Art Johnson was much more helpful - I haven't
seen him post to this list in months, but he is a leading guru with these
tools.

Don't forget the mask register. If you use any interrupts, you will have to
enable them in the SDK or (by hand) in GPR3 and GPR4.

I don't see anything in my code that sets the GPIO Data Direction Register
or PER (Peripheral Enable Register) to tell the chip that the pins MSCAN_TX
and MSCAN_RX are to be used by the peripheral and not GPIO. I know I had to
do that for the four SPIbus pins. Maybe simply poking CANE reserves those
two pins for the MSCAN peripheral - I forget.

On the 56803, the packet length (DLC) register doesn't always limit itself
to 0..8. The higher bits in that register sometimes take on values copied
from some other MSCAN register - if you put the MSCAN registers in a Memory
Window and "break" when (DLC > 8), you should be able to see where the
garbage gets copied from. MASK DLC TO ZERO THE NAUGHTY BITS! You could win
the bang-my-head-against-a-brick-wall NoPrize if you can find the line in
the manual that, with sufficient imagination, hints that you can't just read
the data length from the data length register. I would have called that a
silicon erratum.

I strongly recommend starting with an app that performs self-loopback. See
the User Manual for the register bits to enable self-loopback (?? LOOPB in
*CANControlRegister1??). Once you can send and receive packets to yourself,
wire up one board to another and try again. It couldn't hurt to start at
1/4 speed to minimize concerns such as termination resistors.

Remember that if only one board is on a CANbus network, when it tries to
send a packet, it will never receive an "ACK" bit from another board, so it
will keep re-trying to send the packet until you *do* connect a board
willing to ACK the packet. Then (I've seen it happen after 30 seconds of
re-trying), the ACK will permit the packet to "go", and the sender should
finally signal TX Empty.

I wound up using the SDK for my interrupt dispatcher, but not the lame SDK
MSCAN driver sold by Motorola (or is it Metrowerks?), for several thousand
USD. If you aren't already confident that you have a firm grasp of how to
do interrupts with the SDK, you might want to debug your MSCAN code with
something that just polls the TXE bit (I forget its name). Once MSCAN is
working reliably, add interrupts.

I've attached some code suggestions as a flat text doc. See especially
"ReInitializeMSCAN()". I may have unnecessary things in there, but the code
didn't work until I added a few seemingly redundant lines borrowed from an
example from Art Johnson. (Things like writing zero to registers that
already held zero.)

I used bit-timing "magic numbers" suggested by someone on this group
(probably Art) or possibly Daniel Malik (the best Motorola tech support
person I've dealt with).

Good luck! The User Manual is a necessary starting point, but it might not
get you all the way to actually passing packets.

I would suggest scanning the archives of this group for "MSCAN", "CAN" and
"CANbus", then selecting anything that offers code examples. MSCAN requires
relatively complex setup.

I saved the best advice for last: don't forget to check the errata sheet on
the 56F807 Product Home Page! There are certain bit patterns in msg
identifiers that won't work.

Rick Corey -----Original Message-----
From: Robert Wood [mailto:]
Sent: Saturday, January 24, 2004 3:17 PM
To:
Subject: [motoroladsp] Sending a CAN message Hi folks,

I'm trying to set up a 56F807 to send out and receive CAN messages. I'm new
to
CAN (apart from having read numerous articles about it!) so I'm probably
missing something fundamental here.

I've set the transmit identifier, some transmit data and the data length
register. However, nothing comes out! I'm guessing there's a flag somewhere
you have to set to actually make the processor send the message out?

I've done something along the lines of:

CAN_TB0_IDRx = Identifier number

CAN_TB0_DSR0-x = various data

CAN_TB0_DLR = Number of databytes in the DSR register.

So, what do I do to force that data out?! I've set the CANE bit, btw.

Many thanks,

Rob

_____________________________________
/groups.php3




/***************************************************************
* FUNCTION : ReInitializeMSCAN()
* PURPOSE : Initializes MSCAN, and can be called after recovery from BUSOFF.
* Also called from Periodic.c after detecting CANBOFFIF (BussOff)
* RETURNS : Always zero, but may trap forever if fail to leave SoftReset - never
has happened yet.
* ALGORITHM :
* Must get into SoftReset mode, if not already there (but CHIP RESET does put
you there)
* First, enter SLEEP mode to assure all is clear for the next step.
* Then, enter SoftReset so you can modify certain critical MSCAN registers.
*
* Since MSCAN is initialized to SoftReset at CHIP RESET,
* I can just modify CANCTRL1, CANBTR0 & BTR1 & CANIDAC, CANIDAR0-7 & CANIDMR0-7.
* Then, leave SoftReset. MSCAN will start trying to synch with CANbus.
* Finally, config CANRIER & CANTCR.
* You could modify CANCTL0 & CANRFLG now if needed.
* Check CANCTL0.SYNCH (bit#4==1 means synched)
* WARNING : Certain registers (CANRFLG & CANTFLG) plus one bit (CANCTL0.RXFRM )
* work by writing a ONE to a bit CLEARING that bit.
***************************************************************/
UWord16 ReInitializeMSCAN ( UWord16 WhichIMU )
{
UWord16 tmp=0;
UWord16 MaxSleepTries=200; // time delay to enter SleepMode (before
re-entering SoftReset) // ********** if we do NOT use the SDK in the future, **********
// ********** Configure IRQs **********
// ********** (I1 & I0 IRQ masks for Maskable/nonMaskable IRQs)
// * several code examples suggest these lines when configuring IRQs
// * Cfg SR.I0.I1=01 use ASM to poke core System Status Register (sr)
// * SET $100 "to enable NMI" or for future compatibility & family
compatibility
// * CLEAR $200 to enable maskable IRQ
// * asm {
// * bfset #0x0100,sr ;
// * bfclr #0x0200,sr ;
// * }
// * periphBitSet( 0x1C00 , pIPR ); // (enable IRQ Channels 3, 4 & 5)
IPR @ $FFFB
// * periphBitSet( 0x5400 , GPR3 ); // (Priority Levels 5 & 4, CAN Rx &
Tx IRQs) ITCN_BASE+3
// * periphBitSet( 0x0046 , GPR4 ); // (Priority Levels 3 & 5,CANWAKE &
CAN Errors) ITCN_BASE+4
// * These IRQs are set up by the SDK now with priority level 1, see
APPCONFIG.H
// ********************************************************************

// *** confirm that you are already in SoftReset mode or ENTER SoftReset
***

if ( ((*CANControlRegister0) & CANSFTRES) == 0 ) // 0 means NOT in
SoftReset
{
//
***************************************************************************
// ********** OK, I am NOT YET in SoftReset. I can fix that.
*********
// ********** enter SLEEP MODE for safety, before going to SoftReset
*********
// ********** re-assure you're NOT in SoftReset, then enter SleepMode
********
//
***************************************************************************
periphBitClear ( CANSFTRES, CANControlRegister0 ); // CANCTL0.0=0 means
normal, NOT SoftReset
*CANTxControlReg = 0x00 ; // disable all TX IRQs (must be done while
NOT in SoftReset)
*CANRIER_Register = 0x00 ; // disable all RX IRQs " "
periphBitSet ( CANSLPRQ , CANControlRegister0 ); // CANCTL0.1=1 means
SleepREQUEST

// *** Never fails to enter SleepMode - and could not
fix it if it did not, and it may not matter anyway.
// *** Also, can't report failure to enter SleepMode
because can't configure CANbus.
// *** test if we REALLY entered sleep mode
// for ( tmp = 0; (tmp<MaxSleepTries); tmp++ )
// { if ( ((*CANControlRegister0) & CANSLPAK) == 1
) // 1 means in SleepMode
// break; }
// if ( ((*CANControlRegister0) & CANSLPAK) != 1 )

// *** Now enter SoftReset Mode (SoftReset AND SLEEPRQ=$03?)
// *** if you failed to enter SleepMode first, that's OK, go to
SoftReset anyway (may put a blip of noise on CANbus)
// *** setting this SoftReset bit is supposed to be guaranteed to
succeed

*CANControlRegister0 = CANSFTRES ;

} // end if CANSFTRES==0 (was not in SoftReset yet)
// *** this should always succeed in entering SoftReset

if ( ((*CANControlRegister0) & CANSFTRES) != 0x01 )
{
while ( 1 )
{
g_ForeverTrap++; // hang here if couldn't enter SoftReset, which
should never happen
Blink3DigitsBlocking ( 3,1,5 );
}
}

// *** configure these CAN Control & bit-timing registers for an IMU:
*************
// *** CANCTRL1, CANBTR0, CANBTR1, CANIDAC, CANIDAR0-7 & CANIDMR0-7
*************
// *** CANTCTRL1

// $83 = CANCANE | CANWUPM | CANCLKSRC but not CANLOOPB
// $87 = CANCANE | CANWUPM | CANCLKSRC | CANLOOPB
// CANCANE "is only write-capable once in normal modes" (page 8-19 8.7.2)
// CLKSRC @01 => set is IPBus Clock, not external (alleged less jitter)
// WUPM @02 => wake only after filtering bus noise
// LOOPB @04 => DO loopback (was for LOOPBACK_250 early test mode)
// CANE @80 => ENABLE MSCAN *CANControlRegister1= 0x83 ; // IPBus ClockSource, CAN_Enable,
FilterCanNoise for WakeUp, NOT LOOPB

#ifdef CAN_BAUD_1_MBPS
*CANBTR0_Register = 0xC1 ; // 1 MBPS 40 MHz
*CANBTR1_Register = 0x6B ;
#else
*CANBTR0_Register = 0xC9 ; // 250 KBPS 40 MHz IPBus /10 -> 4 MHz
*CANBTR1_Register = 0x49 ; // 1/4 speed, if no termination resistor
#endif

//
****************************************************************************
// *** Touching these flags here helps, even though Motorola manual doesn't
require it.
// *** I already see "0000" in memory but still, re-clearing them here
helps.
*CANRcvFlagRegister = 0x00FF; // clear all CANRFLG flag bits by writing
1. Not mentioned in Motorola manuals.

// **************** CLEAR ALL TXEIEs BEFORE LEAVING SOFT RESET
**************
*CANTxControlReg = 0x0000 ; // not in Motorola manuals

//***************** Initialize CANIDAC, CanIDAR_MR
**********************
*CANIDAC_Register = 0x0000 ; // two, 32-bit filters. For one IMU
address, plus a BROADCAST
InitializeCanIDAR_MR ( WhichIMU );

//
*****************************************************************************
// *** leave SoftReset, which will start MSCAN trying to SYNCH with CANbus
***
*CANControlRegister0 = 0x0000 ;
*CANTxFlagRegister = 0x0000 ; // not required by Motorola manuals

// ********** (CANCTL0 & CANRFLG are already OK at $00, as reset
***********************

// ********** confirm that we are synched with CANbus, or timeout.
**********
// while ( ((*CANControlRegister0) & CANSYNCH) != CANSYNCH )
// if not synched, return( MSCAN_NOT_SYNCHED );
// has never failed to synch promptly //******************* ENABLE RXFIE & Error IRQS **********************
//******************* Leave TX disabled until needed ******************
periphBitSet ( (CANRXFIE | CANOVRIE | CANBOFFIE) , CANRIER_Register );

return ( 0 );
} // end ReInitializeMSCAN()
/***************************************************************
* FUNCTION : InitializeCanIDAR_MR()
* PURPOSE : Initializes the CAN ID Acceptance Registers & Mask registers
* RETURNS :
* ALGORITHM : test whether IMU or DSP0
***************************************************************/
static UWord16 InitializeCanIDAR_MR ( UWord16 WhichIMU )
{
// ****************** Acceptance Registers and Mask Registers **********
// ****************** These differ for IMUs and DSP0. **********
// ****** 0,1,2,3 are for the first filter: msgs for THIS IMU only ***
// ****** AR: bit pattern to match for a "hit" **********
// ****** MR: CLEARED means "AR must match". **********
// ****** MR: $FF = SET means "DON'T care about AR". **********

// ****************** 1,2,3,4 are for individual-IMU msgs ***************
*CANIDAR0 = 0x00; // Priority & CSN high
*CANIDAR1 = 0x18; // $38 means TO_CF. $18 means NOT to CF. (SRR & IDE
bits === 1)
*CANIDAR2 = WhichIMU; // CANIDAR are Acceptance Filters: what I expect to
RECEIVE
*CANIDAR3 = 0x00; // CSN low
if ( WhichIMU == DSP0 )
*CANIDAR1 = 0x38; // $38 means TO_CF. $18 means to some IMU.

*CANIDMR0 = MR_DONT_CARE; // don't care: any priority & CSN-hi
*CANIDMR1 = 0xC7; // $C7 means DO care about TO_CF & SRR & IDE
*CANIDMR2 = MR_CARES_ALL; // IMU DOES care about ToDSP_Address (17, 18 ...)
*CANIDMR3 = MR_DONT_CARE; // DON'T care about CSN-low (DO care RTR==0 NO
remote frames)
if ( WhichIMU == DSP0 )
*CANIDMR2 = MR_DONT_CARE; // DSP0 must receive from ANY IMU

// ****************** 4,5,6,7 are for BROADCAST msgs ($FB) **************
*CANIDAR4 = 0x00; // Priority & CSN high, don't care
*CANIDAR5 = 0x18; // $38 means TO_CF. $18 means NOT to CF.
*CANIDAR6 = 0xFB; // address = $FB means broadcast
*CANIDAR7 = 0x00; // CSN low, don't care
if ( WhichIMU == DSP0 )
*CANIDAR5 = 0x38; // $38 means TO_CF. $18 means NOT to CF.

*CANIDMR4 = MR_DONT_CARE;
*CANIDMR5 = 0xC7; // $C7 means DO care about TO_CF, SRR & IDE
*CANIDMR6 = MR_CARES_ALL; // DO care about ToDSP_Address, for BROADCAST,
address must == $FB
*CANIDMR7 = MR_DONT_CARE; // only care that RTR==0, if that

return ( 0 );
} // end InitializeCanIDAR_MR() /***************************************************************
* FUNCTION : InitCanHdrRubberStamp()
* PURPOSE : sets up a blank pkt-"template" with IDR2=$18 or #38 and IDR2 with
FROM_DSP_ADDR
* RETURNS : void
* ALGORITHM : set default values according to WhichIMU = g_IMU_Number
* NOTE!! ID bits 16 & 17 can not BOTH be "1"s. There is a Motorola silicon
error in the 803
* that can't handle having CAN stuff a bit between 16 & 15. Therefor we must
often avoid
* the bit pattern "1111" in the ID field (SRR-IDE-17-16).
* Since SRR & IDE must be 1s, 17 & 16 can't both be "1".
* Thus IDR1 can be $18 or $38, but avoid these 2 bits in IDR1: $06. As 16&17
in ID itself: $03_0000
***************************************************************/
void InitCanHdrRubberStamp ( UWord16 WhichIMU )
{

//
**************************************************************************
// construct the Can Header to use on every packet
// make the rubber-stamp global, setup at CFG-time
// Note this is the CAN *ID*. Elsewhere is similar-looking code for
setting up CANIDAR & CANIDMR
sCanPktRubberStamp.IDR0 = 0;
sCanPktRubberStamp.IDR1 = 0x18; // changed below: 0x18 or 0x38 for
extended IDs
sCanPktRubberStamp.IDR2 = WhichIMU; // changed below if DSP0
sCanPktRubberStamp.IDR3 = 0;

if ( WhichIMU == DSP0 )
{
sCanPktRubberStamp.IDR1 = 0x18; // $18 means NOT to CF. (also SRR &
IDE) $18/38
sCanPktRubberStamp.IDR2 = 17 ; // TO_IMU address is set inside
SendCanMsg()
}
else
{
sCanPktRubberStamp.IDR1 = 0x38; // $38 means TO CF - TO DSP0.
(also SRR & IDE)
sCanPktRubberStamp.IDR2 = WhichIMU; // FromDSP_Address
}

sCanPktRubberStamp.PktDataByte[0] = sCanPktRubberStamp.PktDataByte[1] = 0;
sCanPktRubberStamp.PktDataByte[2] = sCanPktRubberStamp.PktDataByte[3] = 0;
sCanPktRubberStamp.PktDataByte[4] = sCanPktRubberStamp.PktDataByte[5] = 0;
sCanPktRubberStamp.PktDataByte[6] = sCanPktRubberStamp.PktDataByte[7] = 0;
sCanPktRubberStamp.BuffStatus = BUFF_TO_TX; // unused bufers == FREE_BUFF
complete msg == ?
sCanPktRubberStamp.PacketLen = 8; // THIS MAY CHANGE FOR PACKET #1 AND
LAST PACKET
sCanPktRubberStamp.TxPriority = 4; // we do not use this MSCAN
LocalTxPriority. 0 is highest priority. This is MSCAN12 internal TX Priority,
NOT CAN ID first-3-bits priority
sCanPktRubberStamp.pnext = NULL; // becomes Head->pnext, insert me as
new first packet (inverting order of packets)

} // end of InitCanHdrRubberStamp()

/*******************************************************
* FILE : PeriphRegisters.h
*
* from sample code from Metrowerks, a Motorola Company
********************************************************/

#ifndef __PeriphRegs_H
#define __PeriphRegs_H

// ----------------------------------------------------------
// Peripheral register definitions for M56803

#define CANBASE 0x0D80
#define SPIBASE 0x0F20
//#define ITCN_BASE 0x0E60 // in DPC_56803.H
#define IPR_Register 0xFFFB
// Interrupt priority register's address
#define pIPR (unsigned short volatile *)0xFFFB // Interrupt priority
register // **************** MSCAN12 registers for 56F803 **************************
#define CANControlRegister0 (unsigned short volatile *)(CANBASE) // CANCTL0
#define CANControlRegister1 (unsigned short volatile *)(CANBASE+1) // CANCTL1
#define CANBTR0_Register (unsigned short volatile *)(CANBASE+2) //
CANBusTimingRegister0
#define CANBTR1_Register (unsigned short volatile *)(CANBASE+3) //
CANBusTimingRegister1
#define CANRcvFlagRegister (unsigned short volatile *)(CANBASE+4) // CANRFLG
WARNING: write one to CLEAR a bit
#define CANRIER_Register (unsigned short volatile *)(CANBASE+5) // CAN Rcv IRQ
Enable Register
#define CANTxFlagRegister (unsigned short volatile *)(CANBASE+6) // CANTFLG
WARNING: write one to CLEAR a bit
#define CANTxControlReg (unsigned short volatile *)(CANBASE+7) // CANTCR
#define CANIDAC_Register (unsigned short volatile *)(CANBASE+8) //
CANIdAcceptanceControlRegister
#define CANRcvErrorCounter (unsigned short volatile *)(CANBASE+0x0E)//
CANRXERR = REC 96, 127, 255
#define CANTxErrorCounter (unsigned short volatile *)(CANBASE+0x0F)// CANTXERR
= TEC
#define CANIDAR0 (unsigned short volatile *)(CANBASE+0x010)
#define CANIDAR1 (unsigned short volatile *)(CANBASE+0x011)
#define CANIDAR2 (unsigned short volatile *)(CANBASE+0x012)
#define CANIDAR3 (unsigned short volatile *)(CANBASE+0x013)
#define CANIDAR4 (unsigned short volatile *)(CANBASE+0x018)
#define CANIDAR5 (unsigned short volatile *)(CANBASE+0x019)
#define CANIDAR6 (unsigned short volatile *)(CANBASE+0x01A)
#define CANIDAR7 (unsigned short volatile *)(CANBASE+0x01B) // CAN ID
Acceptance Register: what pattern to look for in the Msg ID
#define CANIDMR0 (unsigned short volatile *)(CANBASE+0x014) // CAN Mask
Register: what bits to IGNORE in Msg ID. 1 means DON'T CARE.
#define CANIDMR1 (unsigned short volatile *)(CANBASE+0x015)
#define CANIDMR2 (unsigned short volatile *)(CANBASE+0x016)
#define CANIDMR3 (unsigned short volatile *)(CANBASE+0x017)
#define CANIDMR4 (unsigned short volatile *)(CANBASE+0x01C)
#define CANIDMR5 (unsigned short volatile *)(CANBASE+0x01D)
#define CANIDMR6 (unsigned short volatile *)(CANBASE+0x01E)
#define CANIDMR7 (unsigned short volatile *)(CANBASE+0x01F)
#define CANRcvBuff (struct CanPktBuffer volatile *)(CANBASE+0x040)
#define CANTxBuff0 (struct CanPktBuffer volatile *)(CANBASE+0x050)
#define CANTxBuff1 (struct CanPktBuffer volatile *)(CANBASE+0x060)
#define CANTxBuff2 (struct CanPktBuffer volatile *)(CANBASE+0x070)
#define TXE0 0x01 // value of bit position of TXE0 EMPTY FLAG (1=> Empty <=>
Ready for more data
#define TXE1 0x02 // value of TXE1 TX EMPTY FLAG in CANTxFlagRegister
#define TXE2 0x04 // value of TXE2 TX EMPTY flag: for masking, write ONE to
CLEAR the bit (XOR)

// *** the following lines were borrowed from MSCAN.H *********************

/*** MSCAN Masks for registers ***/

/* CMCR0 - Module Control Register 0 */
#define CANSFTRES 0x01 /* Software Reset */
#define CANSLPRQ 0x02 /* Sleep Mode Request */
#define CANSLPAK 0x04 /* Sleep Mode Acknowledge (READ ONLY) */
#define CANTLNKE 0x08 /* Timer Enable */
#define CANSYNCH 0x10 /* Synchronized status (READ ONLY) */
#define CANCSWAI 0x20 /* CAN Stops in Wait Mode */

/* CMCR1 - Module Control Register 1 */
#define CANCLKSRC 0x01 /* Clock Source (PLL or crystal oscillator) */
#define CANWUPM 0x02 /* Wake-Up mode */
#define CANLOOPB 0x04 /* Loop Back Self Test mode */
#define CANCANE 0x80 /* CAN Enable */ /* CBTR0 - Bus Timing Register 0 */
#define CANSJW 0xC0 /* Re-Synchronization Jump Width */
#define CANBRP 0x3F /* Baud Rate Prescaler */

/* CBTR1 - Bus Timing Register 1 */
#define CANSAMP 0x80 /* Sample Mode */
#define CANTSEG2 0x70 /* Time Segment 2 duration */
#define CANTSEG1 0x0F /* Time Segment 1 duration */

/* CRFLG - Receiver Flag Register */
#define CANWUPIF 0x80 /* Wake-up Interrupt Flag */
#define CANRWRNIF 0x40 /* Receiver Warning Interrupt Flag */
#define CANTWRNIF 0x20 /* Transmitter Warning Interrupt Flag */
#define CANRERRIF 0x10 /* Receiver Error Passive Interrupt Flag */
#define CANTERRIF 0x08 /* Transmitter Error Passive Interrupt Flag */
#define CANBOFFIF 0x04 /* Bus-Off Interrupt Flag */
#define CANOVRIF 0x02 /* Overrun Interrupt Flag */
#define CANRXF 0x01 /* Receive Buffer Full */

/* CRIER - CANRIER - Receiver Interrupt Enable Register */
#define CANWUPIE 0x80 /* Wake-up Interrupt Enable */
#define CANRWRNIE 0x40 /* Receiver Warning Interrupt Enable */
#define CANTWRNIE 0x20 /* Transmitter Warning Interrupt Enable */
#define CANRERRIE 0x10 /* Receiver Error Passive Interrupt Enable */
#define CANTERRIE 0x08 /* Transmitter Error Passive Interrupt Enable */
#define CANBOFFIE 0x04 /* Bus-Off Interrupt Enable */
#define CANOVRIE 0x02 /* Overrun Interrupt Enable */
#define CANRXFIE 0x01 /* Receiver Full Interrupt Enable */

/* CTFLG - CANTFLG - Transmitter Flag Register */
#define CANABTAK2 0x40 /* Abort Acknowledge for Tx buffer 2 */
#define CANABTAK1 0x20 /* Abort Acknowledge for Tx buffer 1 */
#define CANABTAK0 0x10 /* Abort Acknowledge for Tx buffer 0 */
#define CANTXE2 0x04 /* Transmit buffer 2 empty */
#define CANTXE1 0x02 /* Transmit buffer 1 empty */
#define CANTXE0 0x01 /* Transmit buffer 0 empty */

/* CTCR - Transmitter Control Register */
#define CANABTRQ2 0x40 /* Abort Request for Tx buffer 2 */
#define CANABTRQ1 0x20 /* Abort Request for Tx buffer 1 */
#define CANABTRQ0 0x10 /* Abort Request for Tx buffer 0 */
#define CANTXEIE2 0x04 /* Transmit buffer 2 empty interrupt enable */
#define CANTXEIE1 0x02 /* Transmit buffer 1 empty interrupt enable */
#define CANTXEIE0 0x01 /* Transmit buffer 0 empty interrupt enable */

/* CIDAC - Identifier Acceptance Control register */
#define CANIDAM0 0x10 /* Identifier Acceptance mode settings (0) */
#define CANIDAM1 0x20 /* Identifier Acceptance mode settings (1) */
#define CANIDHIT1 0x02 /* Identifier Acceptance Hit Indicator */
#define CANIDHIT0 0x01 /* (READ ONLY bits) */ /*** Driver Flags ***/
#define CANWATCHFLAG ( CANTERRIF | CANTWRNIE | CANBOFFIE ) /* process flags */
#define CANERRORFLAG ( CANOVRIE | CANBOFFIE | CANTERRIE | CANRERRIE |
CANTWRNIE | CANRWRNIE ) // *** end lines addded by R.Corey *** #endif // __PeriphRegs_H
C:\Corey\Portrait Arial .doc Page 1


(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

CAN on the 56F8300DEMO board. - Robert Wood - Mar 2 23:54:00 2004

Hi folks,

Just a quick question:

Has *anyone* actually got the CAN to work on the 56F8300DEMO board? If so, did
you interface with another 3.3V node or did you manage to interface with a 5V
node?

I'm kinda tired of banging my head against this particular brick wall! ;-)

Cheers,

Rob.




(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

Re: CAN on the 56F8300DEMO board. - rootesracer - Mar 3 18:56:00 2004

Does the demo board have a physical layer chip on it?

If so, the 3v/5v issue should not be a concern, since the ISO CAN
physical layer is differential.

You will however need to add a terminating resistor to one or both
ends of the network, since the ISO CAN physical layer requires a load
to pull the network pair to the recessive state.

Also if no physical layer chip is provided, you have three issues to
consider if you want to to a direct hardware connection to the bus:

1) You will have to connect can_tx and can_rx together, so that the
CAN MAC sees what looks like a non-faulted network.

2) can_tx output requires a pullup resistor, typically 1Kohm, but
depends on your signalling speed.

3) If you followed points 1 and 2, you may still have problems due to
logic level compatibilities if one system is 3v and the other is 5v.
This particularly if the 5V is CMOS instead of TTL specifications on
the input... HTH --- In , Robert Wood <robert.wood@a...>
wrote:
> Hi folks,
>
> Just a quick question:
>
> Has *anyone* actually got the CAN to work on the 56F8300DEMO board?
If so, did
> you interface with another 3.3V node or did you manage to interface
with a 5V
> node?
>
> I'm kinda tired of banging my head against this particular brick
wall! ;-)
>
> Cheers,
>
> Rob.




(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

Re: CAN on the 56F8300DEMO board. - Bende Georg - Mar 4 8:17:00 2004

The Demo board has a CAN transceiver on it; it's a Ti SN65HVD230; it's 5V
compatible, but with some pull-ups you can interface it with the DSP as well.
(I didn't try it yet but the transceiver works fine with other 56F8xx family
processors)

Georg Bende
Softwareentwickler
Abteilung Elektronik
Dr. Fritz Faulhaber GmbH & Co KG
Daimlerstr. 23
71101 Schönaich
Tel: +49 7031 638294 > -----Ursprüngliche Nachricht-----
> Von: rootesracer [mailto:]
> Gesendet: Mittwoch, 3. März 2004 19:56
> An:
> Betreff: [motoroladsp] Re: CAN on the 56F8300DEMO board. > Does the demo board have a physical layer chip on it?
>
> If so, the 3v/5v issue should not be a concern, since the ISO CAN
> physical layer is differential.
>
> You will however need to add a terminating resistor to one or both
> ends of the network, since the ISO CAN physical layer requires a load
> to pull the network pair to the recessive state.
>
> Also if no physical layer chip is provided, you have three issues to
> consider if you want to to a direct hardware connection to the bus:
>
> 1) You will have to connect can_tx and can_rx together, so that the
> CAN MAC sees what looks like a non-faulted network.
>
> 2) can_tx output requires a pullup resistor, typically 1Kohm, but
> depends on your signalling speed.
>
> 3) If you followed points 1 and 2, you may still have problems due to
> logic level compatibilities if one system is 3v and the other is 5v.
> This particularly if the 5V is CMOS instead of TTL specifications on
> the input... > HTH > --- In , Robert Wood <robert.wood@a...>
> wrote:
> > Hi folks,
> >
> > Just a quick question:
> >
> > Has *anyone* actually got the CAN to work on the 56F8300DEMO board?
> If so, did
> > you interface with another 3.3V node or did you manage to interface
> with a 5V
> > node?
> >
> > I'm kinda tired of banging my head against this particular brick
> wall! ;-)
> >
> > Cheers,
> >
> > Rob. >
>
> _____________________________________
> /groups.php3
>
> Yahoo! Groups Links




(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

Re: Re: CAN on the 56F8300DEMO board. - Robert Wood - Mar 6 17:24:00 2004

Having replaced the HVD230 with a 82C250 and done some hacking of the board to
allow for the 82C250's requirement for 5V, the signals now look right from a
physical layer perspective, but the bits that the transmitter of the 56F8323
send out are just bizarre.

When I try to send a message out, I get cluster of activity on the bus. What
happens is there is a long period of the bus being in a recessive state, then
there's a dominant state 18us long, then a recessive state of around 25us,
then 1us of dominant state. After this, there's a number of periods of 25us of
recessive state and 1us pulses of dominant state. It doesn't matter what
values I try to send out, the same bit patterns always appear on the bus.

The fact that I'm getting pulses of 1us would suggest to me I have the bit
rate set correctly at 1M. Does that seem a reasonable assumption?!

If anyone's ever come across this and knows how to solve it, I really would be
very grateful. I've spend around four long days on this now and it's just not
fun any more!

Cheers,

Rob The Demo board has a CAN transceiver on it; it's a Ti SN65HVD230; it's 5V
compatible, but with some pull-ups you can interface it with the DSP as well.
(I didn't try it yet but the transceiver works fine with other 56F8xx family
processors)

Georg Bende
Softwareentwickler
Abteilung Elektronik
Dr. Fritz Faulhaber GmbH & Co KG
Daimlerstr. 23
71101 Schönaich
Tel: +49 7031 638294 > -----Ursprüngliche Nachricht-----
> Von: rootesracer [mailto:]
> Gesendet: Mittwoch, 3. März 2004 19:56
> An:
> Betreff: [motoroladsp] Re: CAN on the 56F8300DEMO board. > Does the demo board have a physical layer chip on it?
>
> If so, the 3v/5v issue should not be a concern, since the ISO CAN
> physical layer is differential.
>
> You will however need to add a terminating resistor to one or both
> ends of the network, since the ISO CAN physical layer requires a load
> to pull the network pair to the recessive state.
>
> Also if no physical layer chip is provided, you have three issues to
> consider if you want to to a direct hardware connection to the bus:
>
> 1) You will have to connect can_tx and can_rx together, so that the
> CAN MAC sees what looks like a non-faulted network.
>
> 2) can_tx output requires a pullup resistor, typically 1Kohm, but
> depends on your signalling speed.
>
> 3) If you followed points 1 and 2, you may still have problems due to
> logic level compatibilities if one system is 3v and the other is 5v.
> This particularly if the 5V is CMOS instead of TTL specifications on
> the input... > HTH > --- In , Robert Wood <robert.wood@a...>
> wrote:
> > Hi folks,
> >
> > Just a quick question:
> >
> > Has *anyone* actually got the CAN to work on the 56F8300DEMO board?
> If so, did
> > you interface with another 3.3V node or did you manage to interface
> with a 5V
> > node?
> >
> > I'm kinda tired of banging my head against this particular brick
> wall! ;-)
> >
> > Cheers,
> >
> > Rob. >
>
> _____________________________________
> /groups.php3
>
> Yahoo! Groups Links
_____________________________________
/groups.php3

Yahoo! Groups Links





(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

[DSP56858EVM] LCD ?? - Dsp Devil - Mar 7 17:00:00 2004

Does anyone know what type of LCD I can (should) use
on the DSP56858EVM?

Thanx

--- Robert Wood <> wrote:
> Having replaced the HVD230 with a 82C250 and done
> some hacking of the board to
> allow for the 82C250's requirement for 5V, the
> signals now look right from a
> physical layer perspective, but the bits that the
> transmitter of the 56F8323
> send out are just bizarre.
>
> When I try to send a message out, I get cluster of
> activity on the bus. What
> happens is there is a long period of the bus being
> in a recessive state, then
> there's a dominant state 18us long, then a recessive
> state of around 25us,
> then 1us of dominant state. After this, there's a
> number of periods of 25us of
> recessive state and 1us pulses of dominant state. It
> doesn't matter what
> values I try to send out, the same bit patterns
> always appear on the bus.
>
> The fact that I'm getting pulses of 1us would
> suggest to me I have the bit
> rate set correctly at 1M. Does that seem a
> reasonable assumption?!
>
> If anyone's ever come across this and knows how to
> solve it, I really would be
> very grateful. I've spend around four long days on
> this now and it's just not
> fun any more!
>
> Cheers,
>
> Rob > The Demo board has a CAN transceiver on it; it's a
> Ti SN65HVD230; it's 5V
> compatible, but with some pull-ups you can interface
> it with the DSP as well.
> (I didn't try it yet but the transceiver works fine
> with other 56F8xx family
> processors)
>
> Georg Bende
> Softwareentwickler
> Abteilung Elektronik
> Dr. Fritz Faulhaber GmbH & Co KG
> Daimlerstr. 23
> 71101 Schönaich
> Tel: +49 7031 638294 > > -----Ursprüngliche Nachricht-----
> > Von: rootesracer
> [mailto:]
> > Gesendet: Mittwoch, 3. März 2004 19:56
> > An:
> > Betreff: [motoroladsp] Re: CAN on the 56F8300DEMO
> board.
> >
> >
> > Does the demo board have a physical layer chip on
> it?
> >
> > If so, the 3v/5v issue should not be a concern,
> since the ISO CAN
> > physical layer is differential.
> >
> > You will however need to add a terminating
> resistor to one or both
> > ends of the network, since the ISO CAN physical
> layer requires a load
> > to pull the network pair to the recessive state.
> >
> > Also if no physical layer chip is provided, you
> have three issues to
> > consider if you want to to a direct hardware
> connection to the bus:
> >
> > 1) You will have to connect can_tx and can_rx
> together, so that the
> > CAN MAC sees what looks like a non-faulted
> network.
> >
> > 2) can_tx output requires a pullup resistor,
> typically 1Kohm, but
> > depends on your signalling speed.
> >
> > 3) If you followed points 1 and 2, you may still
> have problems due to
> > logic level compatibilities if one system is 3v
> and the other is 5v.
> > This particularly if the 5V is CMOS instead of TTL
> specifications on
> > the input...
> >
> >
> > HTH
> >
> >
> > --- In , Robert Wood
> <robert.wood@a...>
> > wrote:
> > > Hi folks,
> > >
> > > Just a quick question:
> > >
> > > Has *anyone* actually got the CAN to work on the
> 56F8300DEMO board?
> > If so, did
> > > you interface with another 3.3V node or did you
> manage to interface
> > with a 5V
> > > node?
> > >
> > > I'm kinda tired of banging my head against this
> particular brick
> > wall! ;-)
> > >
> > > Cheers,
> > >
> > > Rob.
> >
> >
> >
> >
> > _____________________________________
> > /groups.php3
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> _____________________________________
> /groups.php3
>
> Yahoo! Groups Links __________________________________





(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

CAN on the 56F8323, the saga continues. - Robert Wood - Mar 21 18:14:00 2004

Hi Folks,

Having received a new demo board with an 8323 on, the code I'd been
struggling with - with the CAN module not synchronising to the bus and just
filling the bus with rubbish - started to work. So, nice to see that the
software I'd written wasn't at fault but incredibly frustrating that two
different demo boards wouldn't work and a third one does.

However, I've now been struggling for a furthe couple of days with further
problems.

First is that whenever I send a message out it sends the message out twice.
The messages are absolutely identical (I've checked them in detail with a
storage scope). If you look on a receiving node, you can see the message come
in on the Rx pin and it set the Tx line low to acknowledge the message.

Secondly, no matter what I do, I simple cannot receive a message. The
CANalyser will send a message out just once, so the DSP (which is the only
other node on the bus) must be acknowledging the message. I've even set the
message mask for message buffer 14 to be zero so it should pick up any
message ID, but the CODE nibble in the control word for MB14 never changes
from 0x4.

I'm pretty sure I've set up the pins correctly (I've certainly set up the
output pin correctly as it sends messages out no problem.

Anyone ever come across anything like this?!

Many thanks,

Rob



(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

Looking at registers - Robert Wood - Mar 24 0:33:00 2004

Hi Folks,

It's dawned on me recently that one of the worst things about Codewarrior is
the fact that you can't see the contents of registers as you step through
code or when you hit a breakpoint.

Two questions therefore:

1. Is that really the case, or am I just missing something?
2. If it is the case, has anyone got a neat work around? It makes debugging so
much easier than having to put debug lines of software in to load a
particular register into a temporary variable. (Even looking at a temp
variable is a major pfaff in CW!)

A separate question: is it possible to reset the program without having to
reload the code each time with CW6?

Cheers,

Rob




(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

RE: Looking at registers - Corey, Rick - Mar 24 13:20:00 2004

Hi Robert

Somewhere in the Peripheral Users Manual is a line that warns that if you
have a debugger window open on FlexCAN registers, the debugger will read
them in order to display them, and by reading them, cause FlexCAN to behave
unpredictably.

For instance, reading the Control/Status word locks a MB. Reading the
free-running timer unlocks it. I see 7.6.1.2 mentions this in passing.

Copying the register to a temp variable also requires one to read the
register, breaking things.

While figuring out how to initialize the thing, I would typically set a
breakpoint where I wanted to look, look, and then re-download and start a
new run to look at the next line of code. If the register might change
before I could look, I would do what you had to - insert a line of code to
copy the register to a temp var, hit the breakpoint, look, start over from
scratch.

>> A separate question: is it possible to reset the program without having
to
reload the code each time with CW6? <<

I used to wish for that, but now I wouldn't trust variables to be set to
initial values without going through the entire rigmarole.

I just ran overnight with JTAG connected to trap a rare error, but CW bombed
so that I couldn't connect, hence I'm not very trusting this morning.
"Interface function IMWProtocol::GetPreference is unimplemented" and
"currently unable to set breakpoint in target (possibly not connected)".
This isn't the first time or the only PC where I've seen CW unable to last
through the night.

-----Original Message-----
From: Robert Wood [mailto:]
Sent: Tuesday, March 23, 2004 7:33 PM
To:
Subject: [motoroladsp] Looking at registers Hi Folks,

It's dawned on me recently that one of the worst things about Codewarrior is

the fact that you can't see the contents of registers as you step through
code or when you hit a breakpoint.

Two questions therefore:

1. Is that really the case, or am I just missing something?
2. If it is the case, has anyone got a neat work around? It makes debugging
so
much easier than having to put debug lines of software in to load a
particular register into a temporary variable. (Even looking at a temp
variable is a major pfaff in CW!)

A separate question: is it possible to reset the program without having to
reload the code each time with CW6?

Cheers,

Rob

_____________________________________
/groups.php3

Yahoo! Groups Links




(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

RE: Looking at registers - Hutchings William-p23437 - Mar 24 15:18:00 2004

If you need to view peripheral registers you can open a memory window to the proper memory locations. Core registers can be viewed as described below. You can configure CodeWarrior to not download each time. This is can be configured in the settings for the target. It is in the remote debugging window. In there is a configuration on what to do on the initial envocation on the debugger and then what to do on each subsequent envocation of the debugger. Thanks.
 
 

 

 

-----Original Message-----
From: Bende Georg [mailto:g...@faulhaber.de]
Sent: Wednesday, March 24, 2004 6:22 AM
To: R...@apostrophe.co.uk
Cc: m...@yahoogroups.com
Subject: AW: [motoroladsp] Looking at registers

To view the registers:
View/Registers
:)))
Bonus question:
ALT+F7
Debugger/M56800 Target and uncheck "use flash config file"

Georg Bende
Softwareentwickler
Abteilung Elektronik
Dr. Fritz Faulhaber GmbH & Co KG
Daimlerstr. 23
71101 Schönaich
Tel: +49 7031 638294> -----Ursprüngliche Nachricht-----
> Von: Robert Wood [mailto:r...@apostrophe.co.uk]
> Gesendet: Mittwoch, 24. März 2004 01:33
> An: m...@yahoogroups.com
> Betreff: [motoroladsp] Looking at registers> Hi Folks,
>
> It's dawned on me recently that one of the worst things about
> Codewarrior is
> the fact that you can't see the contents of registers as you
> step through
> code or when you hit a breakpoint.
>
> Two questions therefore:
>
> 1. Is that really the case, or am I  just missing something?
> 2. If it is the case, has anyone got a neat work around? It
> makes debugging so
> much easier than having to put debug lines of software in to load a
> particular register into a temporary variable. (Even looking
> at a temp
> variable is a major pfaff in CW!)
>
> A separate question: is it possible to reset the program
> without having to
> reload the code each time with CW6?
>
> Cheers,
>
> Rob>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
> Printer at MyInks.com.  Free s/h on orders $50 or more to the
> US & Canada.
> http://www.c1tracking.com/l.asp?cid=5511
> http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/PNArlB/TM
> --------------------------------------------------------------
> -------~->
>
> _____________________________________
> /groups.php3
> 
> Yahoo! Groups Links>
> 

_____________________________________
/groups.php3




(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

Re: Looking at registers - Robert Wood - Mar 24 16:01:00 2004

Hi William,

Thanks for that, but I do think that's really poor if I understand correctly.
With this method, do you not have to know which peripheral is at which memory
location? Just about every other IDE I've ever used makes it easy to look at
peripherals. Even Atmel's free of charge Studio allows you to open a window
you can anchor somewhere with sets of peripheral registers that even tell you
which but corresponds to which function.

Go and check out the likes of Keil's excellent IDE to see what I mean. Bring
up a window that examines the registers' contents of a peripheral you're
trying to debug, that even changes as you step through the code.

Maybe I'm missing something, maybe there's a way of working with CW that
makes it much easier than with traditional debuggers, but if not, I really
would have thought this would make a massive improvement to the IDE...

Cheers,

Rob If you need to view peripheral registers you can open a memory window to the
proper memory locations. Core registers can be viewed as described below. You
can configure CodeWarrior to not download each time. This is can be
configured in the settings for the target. It is in the remote debugging
window. In there is a configuration on what to do on the initial envocation
on the debugger and then what to do on each subsequent envocation of the
debugger. Thanks.
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

General Business Information Motorola Internal Use Only Motorola Confidential
Proprietary Personal Memorandum
-----Original Message-----
From: Bende Georg [mailto:]
Sent: Wednesday, March 24, 2004 6:22 AM
To:
Cc:
Subject: AW: [motoroladsp] Looking at registers To view the registers:
View/Registers
:)))
Bonus question:
ALT+F7
Debugger/M56800 Target and uncheck "use flash config file"

Georg Bende
Softwareentwickler
Abteilung Elektronik
Dr. Fritz Faulhaber GmbH & Co KG
Daimlerstr. 23
71101 Schönaich
Tel: +49 7031 638294 > -----Ursprüngliche Nachricht-----
> Von: Robert Wood [mailto:]
> Gesendet: Mittwoch, 24. März 2004 01:33
> An:
> Betreff: [motoroladsp] Looking at registers > Hi Folks,
>
> It's dawned on me recently that one of the worst things about
> Codewarrior is
> the fact that you can't see the contents of registers as you
> step through
> code or when you hit a breakpoint.
>
> Two questions therefore:
>
> 1. Is that really the case, or am I just missing something?
> 2. If it is the case, has anyone got a neat work around? It
> makes debugging so
> much easier than having to put debug lines of software in to load a
> particular register into a temporary variable. (Even looking
> at a temp
> variable is a major pfaff in CW!)
>
> A separate question: is it possible to reset the program
> without having to
> reload the code each time with CW6?
>
> Cheers,
>
> Rob >
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
> Printer at MyInks.com. Free s/h on orders $50 or more to the
> US & Canada.
> http://www.c1tracking.com/l.asp?cid=5511
<http://www.c1tracking.com/l.asp?cid=5511>
> http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/PNArlB/TM
<http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/PNArlB/TM>
> --------------------------------------------------------------
> -------~->
>
> _____________________________________
> /groups.php3
<http://www.dsprelated.com/groups.php3>
>
> > .





(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

Re: Looking at registers - MW Ron - Mar 25 23:43:00 2004

Robert Wood wrote:

> Hi William,
>
> Thanks for that, but I do think that's really poor if I understand correctly.
> With this method, do you not have to know which peripheral is at which memory
> location? Just about every other IDE I've ever used makes it easy to look at
> peripherals. Even Atmel's free of charge Studio allows you to open a window
> you can anchor somewhere with sets of peripheral registers that even tell you
> which but corresponds to which function.
>
> Go and check out the likes of Keil's excellent IDE to see what I mean. Bring
> up a window that examines the registers' contents of a peripheral you're
> trying to debug, that even changes as you step through the code.
>
> Maybe I'm missing something, maybe there's a way of working with CW that
> makes it much easier than with traditional debuggers, but if not, I really
> would have thought this would make a massive improvement to the IDE...

Currently, the best solution is to use the "Register Details" window. It
supports memory mapped registers. You will need to create xml files for the
registers you want to view. These files are located in the
Bin\Plugins\Support\Registers directory. Use the core register xml files as
a guide. The only difference for a memory mapped register is that a value
needs to be added to the REGISTER tag. You need to add ADDRESS="<addr>"
where <addr> is the address where the register is mapped.

We are looking at some additional register viewing options for an upcoming
release.

Ron

> If you need to view peripheral registers you can open a memory window to the
> proper memory locations. Core registers can be viewed as described below. You
> can configure CodeWarrior to not download each time. This is can be
> configured in the settings for the target. It is in the remote debugging
> window. In there is a configuration on what to do on the initial envocation
> on the debugger and then what to do on each subsequent envocation of the
> debugger. Thanks. > From: Bende Georg [mailto:]

> To view the registers:
> View/Registers
> :)))
> Bonus question:
> ALT+F7
> Debugger/M56800 Target and uncheck "use flash config file"

>> Von: Robert Wood [mailto:]

>> Hi Folks,
>>
>> It's dawned on me recently that one of the worst things about
>> Codewarrior is
>> the fact that you can't see the contents of registers as you
>> step through
>> code or when you hit a breakpoint.
>>
>> Two questions therefore:
>>
>> 1. Is that really the case, or am I just missing something?
>> 2. If it is the case, has anyone got a neat work around? It
>> makes debugging so
>> much easier than having to put debug lines of software in to load a
>> particular register into a temporary variable. (Even looking
>> at a temp
>> variable is a major pfaff in CW!)
>>
>> A separate question: is it possible to reset the program
>> without having to
>> reload the code each time with CW6? --
Free Download - New Version Released
CodeWarrior Development Studio for HC(S)12 Microcontrollers v3.1
Offers "emulator-like" debugging support for HCS12 derivatives
http://www.metrowerks.com/MW/Develop/Embedded/HC12/Default.htm Ron Liechty - - http://www.metrowerks.com



(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )