<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Problems with MCBSTM32C CAN Ports</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/26906/problems-with-mcbstm32c-can-ports</link><description> 
Hi there, 
I have problems setting up the two CAN ports on the MCBSTM32C demo
board. I got them to work in loopback mode but in normal mode the
INAK bit doesn&amp;#39;t set itself to 0. 

 
In the manual it says that the hardware has to monitor 11
consecutive</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Problems with MCBSTM32C CAN Ports</title><link>https://community.arm.com/thread/130765?ContentTypeID=1</link><pubDate>Sun, 20 Mar 2011 15:26:53 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f681c369-0fe1-4b1a-8ebf-be07926e54bf</guid><dc:creator>Karsten Jarke</dc:creator><description>&lt;p&gt;&lt;p&gt;
Problem solved. The set up of the Rx pin was causing the problem.
It is working if the Rx pin is configured as a floating input. I had
it configured as an input with pull down.&lt;/p&gt;

&lt;p&gt;
Nothing special is required for the synchronisation. It just looks
for an idle bus before switching from initialisation mode to normal
mode.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Problems with MCBSTM32C CAN Ports</title><link>https://community.arm.com/thread/126711?ContentTypeID=1</link><pubDate>Tue, 15 Mar 2011 16:24:28 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f8a06d4c-e0ae-4796-83c3-e9edce09fc70</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;I can think of two reasons why clearing of the bit is not
happening:&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;1. These 11 bits are not received for some reason&lt;br /&gt;
2. Something is wrong with the hardware set up&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
So, enough with the thinking: get measuring! Get out your
oscilloscope and &lt;b&gt;check&lt;/b&gt; what&amp;#39;s on your RX pin. Is your CAN
transceiver even enabled? What&amp;#39;s the actual state of the RX line
(from transceiver to CPU)?&lt;/p&gt;

&lt;p&gt;
Is there any other CAN device on that CAN bus in this case? Is the
bus properly terminated, i.e. does it have recessive state while no
device is transmitting?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Problems with MCBSTM32C CAN Ports</title><link>https://community.arm.com/thread/116289?ContentTypeID=1</link><pubDate>Mon, 14 Mar 2011 18:45:17 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e5a464a8-6026-4bac-bd11-19cf1d9c5689</guid><dc:creator>Karsten Jarke</dc:creator><description>&lt;p&gt;&lt;p&gt;
For some reason the Initialization acknowledge bit (INAK) does not
clear when I request to leave the initialization mode. The following
is a quote from the manual in the INAK bit description:&lt;/p&gt;

&lt;p&gt;
&amp;quot;This bit is cleared by hardware when the CAN hardware has left
the initialization mode (to be synchronized on the CAN bus). To be
synchronised the hardware has to monitor a sequence of 11 consecutive
recessive bits on the CAN Rx signal.&amp;quot;&lt;/p&gt;

&lt;p&gt;
I can think of two reasons why clearing of the bit is not
happening:&lt;/p&gt;

&lt;p&gt;
1. These 11 bits are not received for some reason&lt;br /&gt;
2. Something is wrong with the hardware set up&lt;/p&gt;

&lt;p&gt;
I don&amp;#39;t know why the 11 bits would be required. Only reason I can
think of is that it has something to do with the bit timing or baud
rate. The processor is expecting nothing on the bus for a defined
time period. Therefore I assumed that these 11 bits have to be
flanked by dominant bits because otherwise the processor does not
know when the time starts and ends. I&amp;#39;m just guessing because
otherwise it doesn&amp;#39;t make much sense.&lt;/p&gt;

&lt;p&gt;
The other possibility is that there is something wrong with the
hardware set up. To make CAN work I have to re-map the CAN pins
because of the way the transceiver chips are connected. I think I
have done this right but it would be great if somebody has a set-up
that works so I can compare. As I mentioned the CAN ports work in
loopback mode.&lt;/p&gt;

&lt;p&gt;
Thanks,&lt;br /&gt;
Karsten&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Problems with MCBSTM32C CAN Ports</title><link>https://community.arm.com/thread/104677?ContentTypeID=1</link><pubDate>Mon, 14 Mar 2011 16:54:08 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:864b4008-cfa6-4e4b-8f64-785c0cafcfae</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
The CAN controller expects to see &amp;quot;silence&amp;quot; on the cable. When it
then has something to send, it will try to start to send, while
checking if there is a collision. The design with dominant and
recessive bits means that collisions can always be detected. And if
two CAN transmitters starts at exactly the same time, they may both
continue to send until one of them sends a bit that differs from the
other. Then the one who did send a recessive bit will notice that it
failed and will stop further transmission, while the controller
sending a dominant bit didn&amp;#39;t notice any problems and can continue to
send the rest of the frame.&lt;/p&gt;

&lt;p&gt;
So any bit in the frame can be deciding if one CAN transmitter
should stop and retry later, or if it has still managed to transmit
exactly what it expects and are allowed to continue to transmit. This
then implies that the ID of a CAN frame also represents a priority,
in case a collision isnt detected until the transmission have reached
the ID.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Problems with MCBSTM32C CAN Ports</title><link>https://community.arm.com/thread/104686?ContentTypeID=1</link><pubDate>Mon, 14 Mar 2011 16:29:02 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7b363e87-5211-4611-9aca-d123e63bf025</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;I&amp;#39;m assuming the 11 consecutive recessive bits have to be
flanked by dominant bits.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Why?&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;Otherwise not sending anything would be sufficient to
synchronise the CAN port.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
What do you assume it would have to synchronize with?&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;Is this correct?&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
No.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Problems with MCBSTM32C CAN Ports</title><link>https://community.arm.com/thread/79120?ContentTypeID=1</link><pubDate>Mon, 14 Mar 2011 16:02:28 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:25a0a1e8-2c73-4fd0-9b65-f6aa7d57d5c1</guid><dc:creator>Karsten Jarke</dc:creator><description>&lt;p&gt;&lt;p&gt;
Hi Per,&lt;br /&gt;
Thanks for your reply.&lt;/p&gt;

&lt;p&gt;
I only connected CAN1 of the demo board to CAN2 with a 60 Ohm
resistor between the CAN+ and CAN- pins. I want to send messages
between CAN1 and CAN2 for testing purposes.&lt;/p&gt;

&lt;p&gt;
As far as I understand it a recessive bit is when there is no
voltage across the CAN+ and CAN-pins.&lt;/p&gt;

&lt;p&gt;
I&amp;#39;m assuming the 11 consecutive recessive bits have to be flanked
by dominant bits. Otherwise not sending anything would be sufficient
to synchronise the CAN port. If my assumption is correct the CAN port
would have to receive a base frame with an identifier of 0x7FF and a
dominant RTR bit. One of the nodes on the bus would have to send such
a frame. Is this correct?&lt;/p&gt;

&lt;p&gt;
In this particular case this would be possible via the loopback
mode. Later on I would like to read data from a CANopen position
encoder attached to only one of the ports. In this case the encoder
would have to send such a frame until communication has been
established. I&amp;#39;m not sure yet if CANopen sends such a sync frame at
power up by default.&lt;/p&gt;

&lt;p&gt;
Thanks,&lt;br /&gt;
Karsten&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Problems with MCBSTM32C CAN Ports</title><link>https://community.arm.com/thread/66387?ContentTypeID=1</link><pubDate>Mon, 14 Mar 2011 03:51:43 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:1f969eac-1ef9-4335-bfd7-f9ee318b0965</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
But what have you electrically connected? How do you make sure
that the bus is in recessive mode?&lt;/p&gt;

&lt;p&gt;
You are aware of the meaning of recessive and dominant bits?&lt;/p&gt;

&lt;p&gt;
See this link:&lt;br /&gt;
&lt;a href="http://en.wikipedia.org/wiki/Controller_area_network"&gt;en.wikipedia.org/.../Controller_area_network&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
So correctly connected, you don&amp;#39;t need to &amp;quot;send&amp;quot; any 11 recessive
bits.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>