I have been using CAN1 on an LM3S2965 CAN evaluation kit connected to a CAN transceiver chip to send messages to a car. The code related to the CAN controller is mostly copied from the simple tx example. I recently had a board made that has an LM3S2616 on it instead of a 2965 but I have it connected to the same CAN transceiver in exactly the same way. I am also using the same code with the exception being that the ports/pins are different and I am using CAN0.
The problem I am having is that when I call CANMessageSet I do not get any activity at all on the CAN TX line. It does not even start to try to send anything. Even if there was no transceiver connected the CAN TX line would move when initiating a transmit, I confirmed this with the 2965 board. Examining CAN registers seems to show that CANMessageSet did what it was supposed to...except is NewData supposed to be set in the CTL register? I never get a CAN interrupt even for an error. I have double checked the ports/pins many times and I am definitely using the right ones. Is there any register value I can check that would reveal if there was any problem setting up the CAN? INIT is not set...
Any help will be appreciated!
Am half, "out the door" - is it possible that your new MCU requires use of GPIOPinConfig() and GPIOPinType()? Seems that you've covered your bases - have past experience - so prime suspect may well be, "special care/handling" of any/all differences between new and old MCU. Sorry so short - breakfast Sales call duty lurks...
Thank you for the response! That is a very good suggestion and in fact I made that mistake setting up a UART on a Blizzard class device a couple weeks ago...but it was my understanding that the Dust Devil class does not have any pin muxing to take care of and in fact the 2616 does not appear to have a PCTL register so calling PinConfigure would not do anything. There is a difference between the device classes in that the CAN on the 2616 is clocked from the system clock and is not set at 8MHz like the 2965....but that seems to be the only difference in the configuration required. I am going nuts trying to figure this out!
So....I am embarrassed to admit that the problem this whole time was with the CAN transceiver which is not the exact same part we had been using before. The part we ordered for this board is pin compatible with "improvements" that I do not yet understand. When I took that transceiver off and put the one we had used before on everything started working. I do not yet know exactly what the new transceiver was doing to make it not work but at least now I know the source of my sorrow!
Thank you - sorry that offering not on target. Applaud you for mastery of "class" - far beyond most (certainly my) limited ability...
So then - next most likely suspect would be some special, "blocking" of your chosen CAN pin. (i.e. may default into some special mode - require special care/handling to instead configure as you desire. Alternate Function GPIO Reg should highlight/reveal. Along with - of course - that Port's GPIO Registers - look for something unusual.
As a temporary aid - might you switch to a different CAN incarnation on your new MCU? You simply seek to confirm that your understanding, set-up/config of the CAN port is correct/proper. If you can get one Port to work - evidence building that your chosen (failing) Port may be some, "special actor" - require unique treatment.
Good luck... (look fwd to your report...)
Ai Carumba - posts just crossed! Ratz - hate when that happens.
You, Sir - now have the joy of being confirmed problem creator and solver - one fell swoop... (shall direct my torment elsewhere...)
Torment renews: unless you connected MCU's CAN Out to CAN transceiver's CAN Out - hard to imagine how the xcvr could "swallow" the CAN Tx signal. If you've used a newer CAN Xcvr - might there be a change in pinout between CAN xcvr's - say SOIC and smaller package - which caused pinout error?
Also of interest (and possibly demands further thought) is the earlier reported change in register loading/behavior - when you attempted CAN xmission...
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.