Reply by Edward Karpicz May 7, 20052005-05-07
Jonathan,

> CAN0TFLG |= 0x01;

This is wrong. If TX1 buffer is also empty (sent) then above statement will
schedule both buffers (TX0 and TX1) for transmission. 3 ored with 1 gives 3
and you clear TFLG bits 0 and 1 by writing one.

CAN0TFLG=1; // this is fine
CAN0TFLG&=1; // this is also fine and may compile into BCLR
CAN0TFLG,#0xFE > if ((CAN0TBSEL & 0x01) != 0)
> {
> CAN0TXTBPR = 1;
> CAN0TFLG |= 0x01;
> }
> else
> if ((CAN0TBSEL & 0x02) != 0)
> {
> CAN0TXTBPR = 2;
> CAN0TFLG |= 0x02;
> }
> else
> {
> CAN0TXTBPR = 3;
> CAN0TFLG |= 0x04;
> }

This is an overkill. TBSEL can't have more than 1 'one'. Anytime you write
couple of ones into TBSEL only single one is accepted. TBSEL can be set to
1, 2, 4 but not to 3,7 or 6.
It's safe to schedule TX buffer for transmission simply doing:

CAN0TXFLG0TBSEL;

Edward ----- Original Message -----
From: "Jonathan Masters" <jon@jon@...>
To: <68HC12@68HC...>
Sent: Saturday, May 07, 2005 1:23 AM
Subject: RE: [68HC12] CAN Extended ID > Thanks for all the comments.
>
> To clarify, the DSP was receiving the 7 byte message (all 7 bytes were
> correct and could be changed from the source end), but the DSP was not
> providing the correct ID or data length in its registers.
>
> The gotcha seems to be that if the transmit buffer priority register
> (TBPR) is zero for all the buffers, some sort of corrupt message is
> sent. My correct transmit interrupt code is posted below if it has any
> significance.
>
> The final snag in this process was a fault in the mc9s12dp256.h header
> file supplied with my recently purchased CodeWarrior IDE. The location
> of the TBPR was defined as REGBASE + 0x017F. In fact, from the Freescale
> documentation I have, the TBPR is at 0x17D. Locations 0x017E and 0x017F
> are the time stamp registers. Can anyone confirm?
>
> Jonathan.
>
> #define CANTXSEG(i) CANTX0DSR##i = K->data[##i];
>
> /* CAN_TXinterrupt -- vectored when transmitter is empty */
> interrupt void CAN_TXinterrupt(void)
> {
> int i;
> struct canmsg *K;
>
> VGIntEnter();
> if (Can_TXQ.inp != Can_TXQ.outp)
> {
> CAN0TBSEL = CAN0TFLG;
> // point to the current message
> K = &Can_TXQ.Q[Can_TXQ.outp++];
> Can_TXQ.outp &= CANQMOD;
> // put the next message into the transmit data register
> CANTXSEG(0);
> CANTXSEG(1);
> CANTXSEG(2);
> CANTXSEG(3);
> CANTXSEG(4);
> CANTXSEG(5);
> CANTXSEG(6);
> CANTXSEG(7);
> CAN0TXDLR = K->nbytes;
> CAN0TXIDR0 = K->port | 0x80; // CAN requirement that not all
> recessive
> CAN0TXIDR1 = 0x18; // keep SRR, IDE high for extended ID
> CAN0TXIDR2 = K->origin;
> CAN0TXIDR3 = (K->dest << 1);
> CAN_TXQtest();
> // transmit it
> if ((CAN0TBSEL & 0x01) != 0)
> {
> CAN0TXTBPR = 1;
> CAN0TFLG |= 0x01;
> }
> else
> if ((CAN0TBSEL & 0x02) != 0)
> {
> CAN0TXTBPR = 2;
> CAN0TFLG |= 0x02;
> }
> else
> {
> CAN0TXTBPR = 3;
> CAN0TFLG |= 0x04;
> }
> PTT ^= 0x01; // debug
> }
> else
> // disable the transmitter interrupt
> CAN0TIER &= ~0x07;
> VGIntExt();
> }
>
> -----Original Message-----
> From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
> Of John Dammeyer
> Sent: Saturday, 7 May 2005 12:39 AM
> To: 68HC12@68HC...
> Subject: RE: [68HC12] CAN Extended ID
>
> Hi Jonathan,
>
> I'm not sure how you can say that the DSP is receiving 7 byte messages
> correctly when the length and ID are wrong.
> Perhaps you mean that a message is put on the CAN bus and the DSP
> supplies an ACK to the message and an interrupt to
> your application stating that a message has been received.
>
> It's really difficult to debug both sides of a network and to determine
> where the error(s) lie(s).
>
> When I developed a MilCAN port on the 9S12 I was fortunate enough to
> have access to a number of working CAN modules. In
> fact before I even received my HCS12 T-Board I roughed out the master
> software on my PICCAN. Since I had multiple
> PICCAN boards I was easily able to use one of those for a network
> monitor to see if what I thought I was sending was
> really what was being sent. Needless to say, when the target MilCAN
> hardware arrived, getting CAN working was a no
> brainer.
>
> Later, as the project progressed, I started using the PCAN Dongle from
> PEAK systems because the PCANView software
> provided a nice tabular format for MilCAN messages. I happened to
> have a PCAN dongle because I used it to program
> ATMEL 8051 processors that had a CAN bus bootloader.
>
> Further into the project, because the customer owned CAN4USB dongles
> from Zanthic I wrote a Delphi application to serve
> as a user interface. The DLL that comes with that device is full
> featured but once again, I had both the PCAN and my
> PICCAN boards to listen to (or send messages from) for testing the
> software. First step in that code was to query the
> driver for version information before I even attempted CAN
> communications. Now it's a tool that provides access to
> MilCAN node parameters.
>
> Now I often just connect a CAN232 onto a serial port, use Hyperterm to
> set the bit rate and examine or send messages
> using that.
>
> I'm sure you can see by now that debugging using a working after market
> module is a really easy way to go here.
> Whenever I develop a new CAN driver, I always connect the working
> module to the target hardware. I then use it to send
> a message to first get the target to correctly receive and report a
> message. That confirms bit rate etc. Then I work
> on the transmit side not worrying about interrupts or queues etc. Once
> I have that working I create the interrupt
> driven, time/space sensitive code.
>
> And when I developed my library for the MCP2510 on my CANRF I went even
> further and wrote a monitor that dumped all the
> device registers in a tabular format that matched the data sheet
> register summary. I also wrote other commands that
> dump individual registers with text describing the status, interrupt and
> error flags. And additional commands to take
> the device from Loop Back to Config mode to run mode and to sleep mode.
>
> BTW, that approach isn't any different from working with other
> complicated hardware like specialty A/D or GPS devices
> on the SPI bus or IIC bus.
>
> John Dammeyer >
>
> Wireless CAN with the CANRF module now available.
> http://www.autoartisans.com/products
> Automation Artisans Inc.
> Ph. 1 250 544 4950 >> -----Original Message-----
>> From: 68HC12@68HC... [mailto:68HC12@68HC...]
>> On Behalf Of Jonathan Masters
>> Sent: Friday, May 06, 2005 3:35 AM
>> To: 68HC12@68HC...
>> Subject: RE: [68HC12] CAN Extended ID
>>
>>
>> I have set up a CAN connection between an HCS12DP256 and a TMS320F243
>> DSP System.
>>
>> Having sorted out bit timing and various issues in the DSP I am
>> receiving 7 byte messages correctly. However the DSP is
>> saying that the
>> CAN is only receiving 2 bytes, the ID receives has no relationship to
>> the ID sent, and the DSP claims that the message is an 11bit ID, when
>> the HC12 is configured to send a 29bit ID. Several things are
>> relevant:
>>
>> i) The CAN ID2 register is always set to 0x18 - SRR=1,
>> IDE=1 - as a constant
>> ii) Whatever values are placed in the other ID
>> registers,
>> no change is seen at the DSP end. The DSP is setup to receive any IDs
>>
>> Are there any restrictions on writing to the ID registers? The data
>> registers are changing so I assume that the ID registers in the same
>> buffer block are changing. The code for the data registers immediately
>> follows the ID register setup after the TX buffer is selected.
>>
>> Are there any gotchas with the msCAN12 in terms of ID setup
>> or extended
>> identifiers?
>>
>> Thanks to anyone who can make any suggestions.
>>
>> Jonathan Masters
>>
>>
>>
>>
>>
>>
>>
>> > Service. >
>
> Yahoo! Groups Links




Reply by Jonathan Masters May 6, 20052005-05-06
Thanks for all the comments.

To clarify, the DSP was receiving the 7 byte message (all 7 bytes were
correct and could be changed from the source end), but the DSP was not
providing the correct ID or data length in its registers.

The gotcha seems to be that if the transmit buffer priority register
(TBPR) is zero for all the buffers, some sort of corrupt message is
sent. My correct transmit interrupt code is posted below if it has any
significance.

The final snag in this process was a fault in the mc9s12dp256.h header
file supplied with my recently purchased CodeWarrior IDE. The location
of the TBPR was defined as REGBASE + 0x017F. In fact, from the Freescale
documentation I have, the TBPR is at 0x17D. Locations 0x017E and 0x017F
are the time stamp registers. Can anyone confirm?

Jonathan.

#define CANTXSEG(i) CANTX0DSR##i = K->data[##i];

/* CAN_TXinterrupt -- vectored when transmitter is empty */
interrupt void CAN_TXinterrupt(void)
{
int i;
struct canmsg *K;

VGIntEnter();
if (Can_TXQ.inp != Can_TXQ.outp)
{
CAN0TBSEL = CAN0TFLG;
// point to the current message
K = &Can_TXQ.Q[Can_TXQ.outp++];
Can_TXQ.outp &= CANQMOD;
// put the next message into the transmit data register
CANTXSEG(0);
CANTXSEG(1);
CANTXSEG(2);
CANTXSEG(3);
CANTXSEG(4);
CANTXSEG(5);
CANTXSEG(6);
CANTXSEG(7);
CAN0TXDLR = K->nbytes;
CAN0TXIDR0 = K->port | 0x80; // CAN requirement that not all
recessive
CAN0TXIDR1 = 0x18; // keep SRR, IDE high for extended ID
CAN0TXIDR2 = K->origin;
CAN0TXIDR3 = (K->dest << 1);
CAN_TXQtest();
// transmit it
if ((CAN0TBSEL & 0x01) != 0)
{
CAN0TXTBPR = 1;
CAN0TFLG |= 0x01;
}
else
if ((CAN0TBSEL & 0x02) != 0)
{
CAN0TXTBPR = 2;
CAN0TFLG |= 0x02;
}
else
{
CAN0TXTBPR = 3;
CAN0TFLG |= 0x04;
}
PTT ^= 0x01; // debug
}
else
// disable the transmitter interrupt
CAN0TIER &= ~0x07;
VGIntExt();
}

-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of John Dammeyer
Sent: Saturday, 7 May 2005 12:39 AM
To: 68HC12@68HC...
Subject: RE: [68HC12] CAN Extended ID

Hi Jonathan,

I'm not sure how you can say that the DSP is receiving 7 byte messages
correctly when the length and ID are wrong.
Perhaps you mean that a message is put on the CAN bus and the DSP
supplies an ACK to the message and an interrupt to
your application stating that a message has been received.

It's really difficult to debug both sides of a network and to determine
where the error(s) lie(s).

When I developed a MilCAN port on the 9S12 I was fortunate enough to
have access to a number of working CAN modules. In
fact before I even received my HCS12 T-Board I roughed out the master
software on my PICCAN. Since I had multiple
PICCAN boards I was easily able to use one of those for a network
monitor to see if what I thought I was sending was
really what was being sent. Needless to say, when the target MilCAN
hardware arrived, getting CAN working was a no
brainer.

Later, as the project progressed, I started using the PCAN Dongle from
PEAK systems because the PCANView software
provided a nice tabular format for MilCAN messages. I happened to
have a PCAN dongle because I used it to program
ATMEL 8051 processors that had a CAN bus bootloader.

Further into the project, because the customer owned CAN4USB dongles
from Zanthic I wrote a Delphi application to serve
as a user interface. The DLL that comes with that device is full
featured but once again, I had both the PCAN and my
PICCAN boards to listen to (or send messages from) for testing the
software. First step in that code was to query the
driver for version information before I even attempted CAN
communications. Now it's a tool that provides access to
MilCAN node parameters.

Now I often just connect a CAN232 onto a serial port, use Hyperterm to
set the bit rate and examine or send messages
using that.

I'm sure you can see by now that debugging using a working after market
module is a really easy way to go here.
Whenever I develop a new CAN driver, I always connect the working
module to the target hardware. I then use it to send
a message to first get the target to correctly receive and report a
message. That confirms bit rate etc. Then I work
on the transmit side not worrying about interrupts or queues etc. Once
I have that working I create the interrupt
driven, time/space sensitive code.

And when I developed my library for the MCP2510 on my CANRF I went even
further and wrote a monitor that dumped all the
device registers in a tabular format that matched the data sheet
register summary. I also wrote other commands that
dump individual registers with text describing the status, interrupt and
error flags. And additional commands to take
the device from Loop Back to Config mode to run mode and to sleep mode.

BTW, that approach isn't any different from working with other
complicated hardware like specialty A/D or GPS devices
on the SPI bus or IIC bus.

John Dammeyer

Wireless CAN with the CANRF module now available.
http://www.autoartisans.com/products
Automation Artisans Inc.
Ph. 1 250 544 4950 > -----Original Message-----
> From: 68HC12@68HC... [mailto:68HC12@68HC...]
> On Behalf Of Jonathan Masters
> Sent: Friday, May 06, 2005 3:35 AM
> To: 68HC12@68HC...
> Subject: RE: [68HC12] CAN Extended ID > I have set up a CAN connection between an HCS12DP256 and a TMS320F243
> DSP System.
>
> Having sorted out bit timing and various issues in the DSP I am
> receiving 7 byte messages correctly. However the DSP is
> saying that the
> CAN is only receiving 2 bytes, the ID receives has no relationship to
> the ID sent, and the DSP claims that the message is an 11bit ID, when
> the HC12 is configured to send a 29bit ID. Several things are
> relevant:
>
> i) The CAN ID2 register is always set to 0x18 - SRR=1,
> IDE=1 - as a constant
> ii) Whatever values are placed in the other ID
> registers,
> no change is seen at the DSP end. The DSP is setup to receive any IDs
>
> Are there any restrictions on writing to the ID registers? The data
> registers are changing so I assume that the ID registers in the same
> buffer block are changing. The code for the data registers immediately
> follows the ID register setup after the TX buffer is selected.
>
> Are there any gotchas with the msCAN12 in terms of ID setup
> or extended
> identifiers?
>
> Thanks to anyone who can make any suggestions.
>
> Jonathan Masters >
>
> > Service.




Reply by John Dammeyer May 6, 20052005-05-06
Hi Jonathan,

I'm not sure how you can say that the DSP is receiving 7 byte messages correctly when the length and ID are wrong.
Perhaps you mean that a message is put on the CAN bus and the DSP supplies an ACK to the message and an interrupt to
your application stating that a message has been received.

It's really difficult to debug both sides of a network and to determine where the error(s) lie(s).

When I developed a MilCAN port on the 9S12 I was fortunate enough to have access to a number of working CAN modules. In
fact before I even received my HCS12 T-Board I roughed out the master software on my PICCAN. Since I had multiple
PICCAN boards I was easily able to use one of those for a network monitor to see if what I thought I was sending was
really what was being sent. Needless to say, when the target MilCAN hardware arrived, getting CAN working was a no
brainer.

Later, as the project progressed, I started using the PCAN Dongle from PEAK systems because the PCANView software
provided a nice tabular format for MilCAN messages. I happened to have a PCAN dongle because I used it to program
ATMEL 8051 processors that had a CAN bus bootloader.

Further into the project, because the customer owned CAN4USB dongles from Zanthic I wrote a Delphi application to serve
as a user interface. The DLL that comes with that device is full featured but once again, I had both the PCAN and my
PICCAN boards to listen to (or send messages from) for testing the software. First step in that code was to query the
driver for version information before I even attempted CAN communications. Now it's a tool that provides access to
MilCAN node parameters.

Now I often just connect a CAN232 onto a serial port, use Hyperterm to set the bit rate and examine or send messages
using that.

I'm sure you can see by now that debugging using a working after market module is a really easy way to go here.
Whenever I develop a new CAN driver, I always connect the working module to the target hardware. I then use it to send
a message to first get the target to correctly receive and report a message. That confirms bit rate etc. Then I work
on the transmit side not worrying about interrupts or queues etc. Once I have that working I create the interrupt
driven, time/space sensitive code.

And when I developed my library for the MCP2510 on my CANRF I went even further and wrote a monitor that dumped all the
device registers in a tabular format that matched the data sheet register summary. I also wrote other commands that
dump individual registers with text describing the status, interrupt and error flags. And additional commands to take
the device from Loop Back to Config mode to run mode and to sleep mode.

BTW, that approach isn't any different from working with other complicated hardware like specialty A/D or GPS devices
on the SPI bus or IIC bus.

John Dammeyer

Wireless CAN with the CANRF module now available.
http://www.autoartisans.com/products
Automation Artisans Inc.
Ph. 1 250 544 4950 > -----Original Message-----
> From: 68HC12@68HC... [mailto:68HC12@68HC...]
> On Behalf Of Jonathan Masters
> Sent: Friday, May 06, 2005 3:35 AM
> To: 68HC12@68HC...
> Subject: RE: [68HC12] CAN Extended ID > I have set up a CAN connection between an HCS12DP256 and a TMS320F243
> DSP System.
>
> Having sorted out bit timing and various issues in the DSP I am
> receiving 7 byte messages correctly. However the DSP is
> saying that the
> CAN is only receiving 2 bytes, the ID receives has no relationship to
> the ID sent, and the DSP claims that the message is an 11bit ID, when
> the HC12 is configured to send a 29bit ID. Several things are
> relevant:
>
> i) The CAN ID2 register is always set to 0x18 - SRR=1,
> IDE=1 - as a constant
> ii) Whatever values are placed in the other ID
> registers,
> no change is seen at the DSP end. The DSP is setup to receive any IDs
>
> Are there any restrictions on writing to the ID registers? The data
> registers are changing so I assume that the ID registers in the same
> buffer block are changing. The code for the data registers immediately
> follows the ID register setup after the TX buffer is selected.
>
> Are there any gotchas with the msCAN12 in terms of ID setup
> or extended
> identifiers?
>
> Thanks to anyone who can make any suggestions.
>
> Jonathan Masters >
>
> Yahoo! Groups Links




Reply by Jonathan Masters May 6, 20052005-05-06
I have set up a CAN connection between an HCS12DP256 and a TMS320F243
DSP System.

Having sorted out bit timing and various issues in the DSP I am
receiving 7 byte messages correctly. However the DSP is saying that the
CAN is only receiving 2 bytes, the ID receives has no relationship to
the ID sent, and the DSP claims that the message is an 11bit ID, when
the HC12 is configured to send a 29bit ID. Several things are relevant:

i) The CAN ID2 register is always set to 0x18 - SRR=1,
IDE=1 - as a constant
ii) Whatever values are placed in the other ID registers,
no change is seen at the DSP end. The DSP is setup to receive any IDs

Are there any restrictions on writing to the ID registers? The data
registers are changing so I assume that the ID registers in the same
buffer block are changing. The code for the data registers immediately
follows the ID register setup after the TX buffer is selected.

Are there any gotchas with the msCAN12 in terms of ID setup or extended
identifiers?

Thanks to anyone who can make any suggestions.

Jonathan Masters


Reply by panikjahn May 6, 20052005-05-06
Hello Everybody!

I have a MC9S12DG256 controller and I'm trying to setup the ECT module.
I studied the manual and now, I'm a little bit confused:
I've read the S12ECT16B8CV1.pdf manual. I see the block diagram of the
timer module on page 47. The free running timer block gets the TIMCLK.
The Prescaler gets the busclock and generates PCLK.

Where does this PCLK goes to? Which block gets PCLK?
Where does the TIMCLK comes from? Which block generates TIMCLK?

Is the busclock identical to the ECLK which is PLL/2?

Thanks a lot in advance,
Andreas