I now have spend nearly two weeks investigating the 4F232 stellaris device and it's pitfalls, but even with tools like Code Composer Studio like I use it's hard to emit one single trap ... I sometimes feel with this hardware like beeing the early bird which will be caught by bugs (unlike it should catch bugs/worms).
As many other forum members before I also have huge trouble to get the CAN functionality at stellaris M4 devices working.
I now have wasted 3 days with without having some kindof "break-through" ...
Like most other people I used the example "multi_tx.c" from StellarisWare\examples\peripherals\can and adopted it to my board-layout.
My intention was to use Port B4 and B5 for sending out CAN frames to external "CAN observation equipment" (software called CANoe).
For doing this I connected an external CAN transceiver board I once purchased [made by Atmel] which I used a long time without any problems together with a "mbed-device" to send and receive CAN message.
This board only needs tx, rx, gnd and vcc.
After I connected this with my eva-board nothing happened.
OK. I removed the external board - only see the scope catching traffic on the output pins would be sufficently I thougt. But there will be no traffic at the pins.
The result of this attempt is additional code in a legacy project called "TestPort_DoPWM_at_PL2" 3858.TestPort_DoPWM_at_PL2.zip
After more reading the forum I found that I maybe have trouble with multiple pin functions - especialy JTAG related - so some port could be locked and one should unlock it by hand. But this only seems to be happen with port F at M4 devices.
So I made an new project now called "CAN" 7673.CAN.ZIPwhich contains nearly nothing exept CAN. The aim of these is to play with different GPIO configurations by using of "#if defined" and observing the IO-lines by scope
Not only no traffic is coming out of the port pins also no CAN-controller related interrupt I can ever catch. I have added CAN_x_IntHandler(void) into my main module and of course populated it as extern in startup_ccs.c in common plus added the handler to the interrupt vectors list there.
The strange behave I see there is that this interrupt never seems to be catched because my breakpoint I have set in this handler will never become hit.
I also hade a timer interrupt in the main module of the former project "TestPort_DoPWM_at_PL2" started. These interrupt I can catch using breakpoints but no CAN related interrupt - neither in "CAN" nor in "TestPort_DoPWM_at_PL2".
Later one I read in the processor manual that CAN related interrupt is automatically cleared if one reads out the corresponding register. So I removed the register window in the debugger because if the debugger shows me all registers it will have to read them before - maybe this could be the source of this behave - but this was not the case.
So I looked further for some working examples regarding "stellaris + M4 + CAN" on the web but found nothing.
The ultimate wisdom the stellarisware manual should give I thought. So I reread it - now with focus "CAN". In the section 5 "Controller Area Network (CAN)" there are two examples. One of them for looping between CAN0 and CAN1.
I used them in an third project called "CAN_loop"8103.CAN_loop.zip.
This should be the most primitive test for CAN as with this one could have running code and observe it at same time from outside. This example also will not work wit me.
Not only that TI has omited to set up most basic things here like the bit timings of both controllers there (in common with the negligence to mention the needed tCANBitClkParm-parameters for constructing some valid bit-timing for 1MBd) and also has omited the propper configuration of the GPIO pins which have to transfere the traffic, they also never enabled the peripherals CANx there. So I have some fudamental doubts that this code was ever more the an academical effusion.
But if I do all these stuff which they have not mentioned and I assume to be needed I will get nothing out and the debugger behaves like crazy and jumps over some of the code-columns.
After the debugger reaches the first breakpoint at SysCtlClockSet, an F6 (Step Over) brings the cursor to the next breakpoint some lines below and not the the next column.
Switching off optimisation (-02 -> DISABLE) realized some more stringent behaviour of the code - the debugger not longer jumps crazy to lines which do not come next, but IO-traffic I will have neither.
There must be some deeper problem - maybe with compiler settings, maybe with my silicon, maybe with my own level of mastery - whatever I have no glue.
Please one could examine these two projects to give me some hints.
One simple+working project for looping CAN0 to CAN1 on M4 hardware would greatful be accepted.
I will have to find out if I the problem consists of some "silly silicon" or some "foolish operator".
The compiler setings of the regarded projects are as follows:
-mv7M4 --code_state=16 --float_support=FPv4SPD16 --abi=eabi -me -g --include_path="C:/Programme/Texas Instruments/ccsv5/tools/compiler/tms470_4.9.1/include" --include_path="C:/Programme/Texas Instruments/StellarisWare/boards/ek-lm4f232/timers/ccs/../../../../boards/ek-lm4f232" --include_path="C:/Programme/Texas Instruments/StellarisWare/boards/ek-lm4f232/timers/ccs/../../../.." --gcc --define=ccs --define=PART_LM4F232H5QD --define=TARGET_IS_BLIZZARD_RA1 --diag_warning=225 --gen_func_subsections=on --ual
