|
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. |
|
|
Stepping through assembly language...
Started by ●November 22, 2003
Reply by ●November 23, 20032003-11-23
|
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, | |||
| |||
|
|
Reply by ●November 25, 20032003-11-25
|
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. |
|
|
Reply by ●January 24, 20042004-01-24
|
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 |
|
|
Reply by ●January 24, 20042004-01-24
|
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 _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/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 0; // 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 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 |
|
|
Reply by ●March 3, 20042004-03-03
|
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. |
|
|
Reply by ●March 3, 20042004-03-03
|
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. |
Reply by ●March 4, 20042004-03-04
|
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 Schaich Tel: +49 7031 638294 > -----Ursprgliche Nachricht----- > Von: rootesracer [mailto:] > Gesendet: Mittwoch, 3. Mz 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. > > > _____________________________________ > Note: If you do a simple "reply" with your email client, only > the author of this message will receive your answer. You > need to do a "reply all" if you want your answer to be > distributed to the entire group. > > _____________________________________ > About this discussion group: > > To Join: > > To Post: > > To Leave: > > Archives: http://www.yahoogroups.com/group/motoroladsp > > More Groups: http://www.dsprelated.com/groups.php3 > > Yahoo! Groups Links > |
|
|
Reply by ●March 6, 20042004-03-06
|
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 Schaich Tel: +49 7031 638294 > -----Ursprgliche Nachricht----- > Von: rootesracer [mailto:] > Gesendet: Mittwoch, 3. Mz 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. > > > _____________________________________ > Note: If you do a simple "reply" with your email client, only > the author of this message will receive your answer. You > need to do a "reply all" if you want your answer to be > distributed to the entire group. > > _____________________________________ > About this discussion group: > > To Join: > > To Post: > > To Leave: > > Archives: http://www.yahoogroups.com/group/motoroladsp > > More Groups: http://www.dsprelated.com/groups.php3 > > Yahoo! Groups Links > _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 Yahoo! Groups Links |
|
|
Reply by ●March 7, 20042004-03-07
|
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 Schaich > Tel: +49 7031 638294 > > -----Ursprgliche Nachricht----- > > Von: rootesracer > [mailto:] > > Gesendet: Mittwoch, 3. Mz 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. > > > > > > > > > > _____________________________________ > > Note: If you do a simple "reply" with your email > client, only > > the author of this message will receive your > answer. You > > need to do a "reply all" if you want your answer > to be > > distributed to the entire group. > > > > _____________________________________ > > About this discussion group: > > > > To Join: > > > > To Post: > > > > To Leave: > > > > Archives: > http://www.yahoogroups.com/group/motoroladsp > > > > More Groups: http://www.dsprelated.com/groups.php3 > > > > Yahoo! Groups Links > > > > > > > > > > > > > _____________________________________ > Note: If you do a simple "reply" with your email > client, only the author of > this message will receive your answer. You need to > do a "reply all" if you > want your answer to be distributed to the entire > group. > > _____________________________________ > About this discussion group: > > To Join: > > To Post: > > To Leave: > > Archives: > http://www.yahoogroups.com/group/motoroladsp > > More Groups: http://www.dsprelated.com/groups.php3 > > Yahoo! Groups Links > __________________________________ |
