Take the 2-minute tour ×
Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free, no registration required.
  1. I am going to control a few microcontroller-based units (approximately 30) from a master computer.
  2. They are going to be connected using a CAN bus
  3. The furthest lying unit may be approximately 10 meters away.
  4. I need to update the microcontroller's firmware from the master computer.

Above are my requirements of the system. Now come my questions:

  1. Is CAN bus communcations alone enough to update the firmware?
  2. How long can CAN bus communications run?
  3. Do I require a CAN transceiver or is the inbuilt thing is enough?
  4. If not, what other options are there to update the microcontrollers from the master? (other ways than by a use of a CAN bus)

(I do not have a strong base in microcontrollers (though an Electronics and communication engineer)).

share|improve this question
4  
The TL;DR; answer is "Yes you CAN"... but you need to ensure appropriate error checking and validation before over-writing what you have. I'll come back with a longer answer later –  Andrew Nov 21 '12 at 5:12
    
Do a web search for "can bus bootloader". It may save you some development effort if you can find a microcontroller that already supports loading code over CAN. (Sadly, as much as I love CAN, searching for related terms based on the keyword 'CAN' is really counter-productive) –  HikeOnPast Nov 21 '12 at 6:12
    
@DeanB Exactly... and Sadly, Google is case insensitive. So searching something related to CAN becomes a tedious task. –  Swanand Nov 21 '12 at 6:40
1  
Which type of microcontroller? –  starblue Nov 21 '12 at 10:26
    
Indeed, as starblue hints the capabilities of the microcontroller - self flashing, ability to run from ram, amount of available ram and flash, etc will be more central to a working solution than the fact that communication is to be done over CAN. Where CAN might matter would be in the degree of software complexity needed to talk on it, especially if doing so from a compact bootloader instead of the full firmware. –  Chris Stratton Nov 21 '12 at 16:05

5 Answers 5

We currently have a system with 10 microcontrollers on a CAN bus, and you can update the firmware on any of them over it. It works like this:

The firmware on each MCU is made of two parts, the Bootloader and the Application. On power up, the Bootloader runs first. It checks a byte in the EEPROM which says whether or not a valid Application is loaded into the FLASH.

If an Application is loaded (EEPROM = 0x42) the Bootloader jumps straight to it, and the Application runs as normal

If no Application is loaded, the Bootloader waits for instructions on the CAN bus. There are several types of instruction which can come from the master: Set Address, Write data, Read data, Finish. And the Bootloader can reply with: Hello, Data, Finished writing.

The Master sends packets of data for the Bootloader to write into the FLASH (always making sure that it's not being asked to overwrite itself). Since writing takes a while, it sends a Finished Writing message when it's done writing each block. Having sent all of the Application, the Master then reads it all back again to make sure that it has all written correctly. Lastly, it sends a Finished message to the Bootloader. The Bootloader writes 0x42 into the EEPROM and jumps to the Application code.

Of course, the Application also needs to be Bootloader aware. There must be some way to tell the Application to write 0xFF into the EEPROM, then reset the MCU. This will cause it to switch back to the Bootloader and wait for instructions.

share|improve this answer
    
thanks a lot.. u explained me more about the working.. –  Maharajan Nov 21 '12 at 12:08
2  
I take it the that 0x42 had something to do with the answer to meaning of life the universe and everything... –  Saad Nov 21 '12 at 12:53
    
@Saad - Bingo. The code was originally written by an intern who thought it would be fun. Actually, any value works. It just checks that the EEPROM is not 0xFF. –  Rocketmagnet Nov 21 '12 at 14:02
    
We use very simillar logic... Except 0x42 ;) –  Swanand Nov 22 '12 at 4:06
    
@Rocketmagnet: My preference in boot loader designs is to, when practical, have the boot loader watch for a certain sequence to be received via the bus within a very short period of time after booting and only run the loaded application if the sequence is not received and the application is valid. Otherwise, if a bad application gets written to firmware it may be impossible to get the unit back into bootloader mode to fix it. –  supercat Nov 28 '12 at 16:11
  1. Updating firmware doesn't depends on choice of bus. Bus is only responsible for transferring data from one node to another. Code in your units should be capable of updating code from whatever data recieved over CAN. About data integrity, CAN Bus has decent CRC mechanism to avoid corruption. So it will be safe to transmit critical data over CANBus

  2. CAN is able to communicate upto 40mtrs at 1M Baud. More the baud, less is the distance and vice versa.

  3. There are many controllers which has inbuild CAN Transceiver. You don't need additional ones. If your controller doesn't have on chip CAN transceiver, you definately need one.

share|improve this answer
    
thanks a ton... –  Maharajan Nov 21 '12 at 5:51
    
While this addresses the trivial CAN component, the challenge to engineering a solid system will be in the firmware update mechanism itself. –  Chris Stratton Nov 21 '12 at 16:03

The way I've approached it is this:

I have a master node. This device is the mothership, sending out commands and telling everyone else what to do. For the sake of this conversion, I'm using an LPC1769 (Cortex-M3) which has two on-board CAN controllers, so I have two TJA1050 transceivers to make the connections to the actual CAN buses.

My peripheral devices that sit on the bus use a LPC11C24. It's a Cortex-M0 with a built-in CAN transceiver, so I can keep the external component count nice and low, and in turn, keep the peripheral boards and enclosures even smaller.

Every time the peripherals boot up, they go to the bootloader. They check if they need to be programmed. If so, they request to be programmed by the master which follows similarly to Rocketmagnet's answer above. The only twist is that if they are programmed, they check to see if they are up-to-date. If the master has a newer version of firmware than they do, they will also request to be updated.

This approach allows me to not only stick a fresh peripheral on the bus and have it "just work," but it allows me to push new firmware to them as well all through the master. All the updates come from the same place. To update firmware on my master device, I make it present itself as a USB mass storage device and I can drag-and-drop files on to it.

You could use whatever protocol you wanted to... 1-Wire, I2C, SPI, CAN, etc. The operating parameters and the length limitations are clearly documented with a simple Google search. Realistically, CAN is probably the best choice. It was designed with long runs in bad environments in mind. It's relatively fast considering that most firmware for a microcontroller is only a few kBs, maybe tens of kB. Also, it only requires two wires, which means you could daisy chain devices with as few as four wires. 1-Wire would only need 3, and I2C would only need four, but they're pretty "meh" compared to CAN. :P

Now, if you had all devices with an LPC1769, it supports Ethernet with a small helper IC. You could have all the devices connect over Ethernet and transfer lots of data to bootstrap themselves from the master. It sounds like you are just looking to do simple firmware transfers... but it's some food for thought. :)

share|improve this answer

Updating the firmware over CAN is indeed possible. It is already done on many production cars.

The maximum length of the CAN bus depends on several factors including:

  • bit rate
  • delays through the physical layer (esp. if there are opto isolators)

The ACKnowledge from the furthest node has to make it all the way from the end of the bus and through the delays before the sampling point of the "nearest" node. Hence the rate/length/delay tradeoff

Also:

  • quality of the clock sources used within each of the systems attached to the bus - the more jitter you have, the shorter the bus has to be to ensure the nodes can stay in sync.
  • quality of the bus wiring (I've seen a 10m long bus fail when the wires are only vaguely twisted and then work when replaced with properly specified cable)
share|improve this answer

Is CAN bus communcations alone enough to update the firmware?

Yes, CAN bus is more than enough to update the firmware. A typical CAN bus used for cars is around 1Mega baud and for air planes is 10 Megabaud which is more than enough for bootloading firmwares.

How long can CAN bus communications run?

A CAN bus communication can easily run for your needs. As far as I have tested, its a 100m at 250 kbps and I think it is possible upto 1000m.

Do I require a CAN transceiver or is the inbuilt thing is enough? If not, what other options are there to update the microcontrollers from the master? (other ways than by a use of a CAN bus)

Go for automotive microcontrollers. Most of them have Can ports inside them. Eg-> freescale 9s12/9s12x

Another thing that you can look into is LIN. LIN is cost effective solution for CAN and it works similarly to a CAN bus. The only issue is that the distance is limited but I reckon 10m shouldnt be an issue.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.