Why does MCP2515 always return to configuration mode?

Dear all,   I use LPC1768 to communicate with MCP2515 via SPI. SPI works fine as it can set the mode of MCP2515 as well as read the registers of MCP2515.  MCP2515 can changed from configuration mode to normal mode/loop mode when it is initialed, but quickly it will switch to configuration mode automatically. This cost me lots of time , and I have no ideas now, please give me a hand!  Many thanks in advance!
 
Bellow shows some source code:
In main loop :

   
  SPI_Init (); 
  SPI_ConfigClockRate (SPI_CLOCKRATE_LOW);  // SPI rate 400KHz 
   
  SPI_CS_Low(); 
 delay_us(100); 
 uchar flag = MCP2515_Init(CAN_125KBPS);     
 delay_us(100); 
 SPI_CS_High (); 
   
 while(1){ 
                   if(needspican == 0){ 
                           needspican = 1;   // will be changed per second in timer  
                           SPI_CS_Low(); 
                           delay_us(100); 
                             res = mcp2515_read_register(CANSTAT);  // shows is configuration mode           
                          delay_us(100);   // delay 100us 
                           SPI_CS_High (); 
                           } 
                   } 
  

 


 
MCP2515  initial code:

 uchar MCP2515_Init(const uchar CanSpeed) 
{ 
  uchar res; 
  res = mcp2515_read_register(CANCTRL);  
  res = mcp2515_read_register(CANSTAT);  
  MCP2515_RESET();  
       delay_us(1000); 
  res = mcp2515_read_register(CANSTAT);  //配置模式 
  mcp2515_bit_modify(CANCTRL,MODE_MASK,CAN_SETUP_MODE); 
  delay_us(1000); 
  while((mcp2515_read_register(CANSTAT) & MODE_MASK) != CAN_SETUP_MODE){    
          delay_us(100); 
    } 
  res = MCP2515_ConfigRate(CanSpeed); 
  delay_us(100); 
  if(res == MCP2515_OK) 
  { 
     MCP2515_PinCfg(); 
    delay_us(100); 
    MCP2515_InitCanBuffers(); 
  } 
  
  mcp2515_bit_modify(CANCTRL,MODE_MASK,CAN_NORMAL_MODE); 
  delay_us(1000); 
  while((res& MODE_MASK) != CAN_NORMAL_MODE){ 
 res = mcp2515_read_register(CANSTAT);  
   delay_us(100); 
  } 
    
  res = MCP2515_OK; 
  return res; 
} 
 

 
CF1  CF2 CF3  configuration:
// 125KBPS,NBT:PS:PS1:PS2 = 16:6(PS2):7(ps1):2(Ps):1    sampling bit locate at  62.5%
#define MCP_12MHZ_125KBPS_CFG1 0X02 //(00(SJW)  00001 (BRP))
#define MCP_12MHZ_125KBPS_CFG2 0XB1 //(1 0  110(PS1 length)  001(propSeg))
#define MCP_12MHZ_125KBPS_CFG3 0X05 //(0 0  000 101(PS2 length)) 
  
  
 
Re:Why does MCP2515 always return to configuration mode? 9 hrs. ago ( permalink)

5

> quickly it will switch to configuration mode automatically.
 
Automatically? That's not a documented function.

There are only three documented ways for the chip to get into Configuration Mode:
 
1 - Hardware Reset (Reset pin forced low),
2 - Software Reset by SPI command,
3 - Setting the CANCTRL REQOP bits.
 
So if you're not accidentally resetting it in Software, maybe you've got the Reset pin floating, or connected to something that isn't a proper Reset signal.
 
Tom 
 

 

 

 

Thanks for your replay.  But I checked the three ways, it is fine for the code. 
There are only three documented ways for the chip to get into Configuration Mode: 
1 - Hardware Reset (Reset pin forced low),    
Pin 19(Reset Pin) is connected with MCU, and it keeps 3.3V high level when runing

2 - Software Reset by SPI command
There are reset command and Pin reset  at the beginning of MCP2515_Init(). At the end of MCP2515_Init(), only switch into normal mode can MCP2515 jump out this function.  This is confirmed by oscilloscope.

3 - Setting the CANCTRL REQOP bits.
  This is only excute in MCP2515_Init(), after this function, it goes to loop task. And in the loop task , it only read the CANSTAT register.   But I found MCP2515 REQOP bits will be changed every time it is readed. I do not know why?
loop task( excute once per second)
 
[style="color: #ff0000;"][style="color: #ff0000;"][style="color: #ff0000;"][style="color: #ff0000;"][style="color: #ff0000;"][style="color: #ff0000;"][style="color: #ff0000;"][style="color: #888888;"][style="color: #ff0000;"][style="color: #ff0000;"][style="color: #ff0000;"][style="color: #ff0000;"][style="color: #ff0000;"][style="color: #888888;"][style="color: #ff0000;"][style="color: #ff0000;"][style="color: #ff0000;"][style="color: #ff0000;"][style="color: #ff0000;"][style="color: #ff0000;"][style="color: #888888;"][style="color: #888888;"]

  
   
SPI_CS_Low();  
delay_us(100);  
 res = mcp2515_read_register(CANSTAT);  
 delay_us(1000);  
 res = mcp2515_read_register(CANSTAT);  
 delay_us(1000);  
 res = mcp2515_read_register(CANSTAT);  
 delay_us(1000);  
 res = mcp2515_read_register(CANSTAT);  
delay_us(100);  
SPI_CS_High (); 

OK, looks like an obvious bug, but I'm having to guess because you haven't supplied the majority of your code. 
  
Like the source for mcp2515_read_register(). 
  
Assuming it does what I think it does... 
  
Look at 'FIGURE 12-2: READ INSTRUCTION" in the MCP2515 manual. 
  
Note that "CS" goes DOWN, there are then three bytes in the SPI sequence (command, address, data) and then SPI goes UP to mark the end of the cycle. 
  
You code shows "SPI_CS_Low() and "SPI_CS_High" separated by 3.2ms with four "mcp2515_read_register()" calls in the middle. 
  
Which will probably result in 12 SPI bytes transferred between the CS LOW and CS HIGH. The MCP2525 should interpret that as a read of CANSTAT, followed by reads of the next NINE registers in sequence. The data in "res" at the end of that will not be what you expect, but will be the contents of RXF4EID0. 
  
Multiple-reading isn't shown in the diagram, but is detailed in "12.3 READ Instruction". In there: 

"The internal Address Pointer is automatically incremented to the next address once each byte of data is shifted out. Therefore, it is possible to read the next consecutive register address by continuing to provide clock pulses. Any number of consecutive register locations can be read sequentially using this method. The read operation is terminated by raising the CS pin". 
  
Obviously that's VERY useful for writing messages and reading messages. It means you can read 16 bytes of message ID and data in (2 + 16 = 18) SPI bytes rather than (16 * 3 = 48) cycles. 
  
If any of your other code is doing the same thing (multiple attempted transfers between SPI low and high) it could explain what you're seeing. You may be reading or writing the wrong registers. 
  
Tom