I’m interested in adding CAN stack support for TI boards. I’m hoping for comments regarding the approach and testing setup. General advice is also welcome.
I have access to 2x tm4c123 and only 1x tms570lc43x (+ transceivers arriving in 3 days). Both have D-CAN controllers. TI already provides a HAL (“tivaware”) with a correct D-CAN API for the tm4c123. My plan:
Before the gsoc coding period: D-CAN driver for tm4c123
I expect D-CAN rtems driver for tm4c123 will take less time than D-CAN rtems driver for the tms570. I have already tested a simple loopback tivaware-CAN app on the tm4c123 and debugged hard faults (MR !1094). This will also be a good way to study the rest of the rtems CAN stack.
[tivaware-CAN app on tm4c123] ↔ [tiny_can_test.c on tm4c123]
I plan to write a smaller can_test.c i.e tiny_can_test.c that fits on 32 KB tm4c. Maybe 2 tasks rather than 6? Would they be equivalent?
[some rtems-CAN app on tm4c123] ↔ [tiny_can_test.c on tm4c123].
During the gsoc coding period: D-CAN driver for the tms570lc43x
[tivaware-CAN app] on tm4c123 ↔ [can_test.c on tms570lc43x]
[some rtems-CAN app] on tm4c123 ↔ [can_test.c on tms570lc43x]
Three nodes, 2x tm4c simple nodes and 1x tms570lc43x target node?
Would 1. and 3. be sufficient to demonstrate correctness of the D-CAN driver implementation? The tivaware-CAN apps cannot/need not be too complex.
I’m not sure what is meant by “correct D-CAN API”, I doubt the tivaware API will exactly match the RTEMS CAN API. Perhaps you just mean there is an implementation for managing the D-CAN. My recollection is that there is a difference between the controller of the TM4C boards and the BeagleBone Boards, while both use the D-CAN IP I’m not sure if a single driver would be satisfactory for both. That may need to be explored.
You will want to be able to show that you can run CAN applications on both hardware as part of your proposal. As I recall, the tms570lc43x requires you to do some soldering work in order to access the CAN controller pins.
There are some recent merge requests to start adding tests for the CAN stack, you can check in gitlab searching with the device::can label. Continuing to enrich the available CAN tests would certainly be necessary and in scope.
Thanks for the reply
The issue is that I only have one TMS570.
Yes. Tivaware only provides methods to read/write to registers, send messages, init the controller, etc. No buffering or any of the features of RTEMS CAN API. By “correct” I meant tivaware knows the register-map/datasheet of the tm4c123, and it can be used to write simple (single-process) CAN applications.
If I understand correctly, you’re saying even with tivaware as a reference, writing an rtems DCAN driver for the TM4C123 will require as much work as writing one for the TMS570?
Not sure, but it looks like its BSD. The source is freely available on the tivaware website.
Both hardware: TM4C+TMS570? or BBB+TMS570? I was planning to have tm4c and tms570 CAN transceivers connect via jumper wire, and have both MCUs individually connect to my laptop via uart-to-usb for debugging.
I have no significant preferences between TMS570 and BBB. But TMS570 is much harder target. With BBB it is easy to setup U-boot to load RTEMS over network from local TFTP server. It runs form SDRAM so no Flash wear etc. And RTEMS BBB support is probably much more tested. AM3358 has two CAN controllers so you can run all tests between them and then only some test for final interoperability with other controller or testing of the bitrate frequency and bit timing by oscilloscope would be required. I can find some BBB at our office so I can help with it.
As for TMSP570, these match well RTEMS target areas but overwrite of Flash for each development iteration would probably destroy chip quite early, only 1000 erase-cycles are guaranteed, if I remember well. I have TMS570LS3137 EDK as well as TMS570LC4357 one. But I have not worked with them for almost 10 years already.
I suggest to not use any intermediate layers between RTEMS CAN stack and registers. No XXXWare based on CCS and so… I would reuse only some set of registers definition under RTEMS compatible license. I have examples of our code running on TMS570 with own drier design for CCS FreeRTOS based (sic) Porstche and EATON projects. We have achieved great results on TMS5703137 with use of DMA and NHET timer to run whole time triggered communication schedule with clock skew adjustment fully offloaded from main CPU to DMA and NHET. See the thesis, but again in Czech language…
(From lc43x schematic, sheets 7, 9)
It turns out the TMS570LC43x has 4 DCAN controllers, and the launchpad makes one of them (DCAN4 tx/rx) available via gpio header pins. DCAN1-3 need soldering work and it should be possible to run multi-controller tests on a single mcu.
Regarding the flash wear problem, wrt @ppisa notes:
I’m using the lc43x launchpad and not the hdk, no sdcard or external sdram.
The lc43x has 512KB RAM compared to the ls31 256KB. lc43x lets us swap the mappings between ram and flash (lc43x datasheet, page 120). For binaries < 512KB we can use regular openocd: set BMMCR1 → load binary to internal sram → run. I can create an MR with a linker script for tms570lc43x launchpad.
For larger binaries, are sources for the xcp + freertos bootloader method available?
As for XCP, software is available from my previous university group GIT or I can send it. The final license is, I hope, some BSD like one. But it would require to update from 2016 CCS version and rewrite for TMS570LC4300. But even LC43 lauchpad has Ethernet so XCP loader update can be useful byproduct.
I will contact TI what is the state of OpenOCD support and their willingness to help with proper licensed F18 and F21 libraries or usable documentation.
There seems to be another project targeting D-CAN but on BeagleBoneBlack. See
My post is not intended as judging which proposal is better but running both in parallel independently is problematic. I strongly prefer that there will be only single D-CAN controller driver for all matching boards in RTEMS.
We should discuss what is the best approach. I think that D-CAN support development on BegleBoneBlack would be easier than on TMS570. On the other hand, TMS570LC4300 is the target matching exactly RTEMS most serious area of applications and there is lot of work which could be done on it. So I would suggest providing alternatives what would be done on TMS570 if the D-CAN project on BegleBoneBleck is accepted.
It would be great to revive our LwIP work done on TMS570LS3137 originally. The boot-loader work, XCP work, peripherals support etc. We have complete Matlab/Simulink target for TMS570LS3137, unfortunately, based on horrible CCS FreeRTOS code base due to our former group head insisting on this which lead to lot of lost time with broken TI LwIP etc. But fortunately, thanks to GSoC and Premysl Houdek’s thesis, we have saved some work into BSP for RTEMS which is available in mainline. So there is lot of potential even outside or D-CAN support.
Hello @ppisa@gedare
I agree. Whichever board is selected for gsoc, the d-can driver code can simply use different chip_ops methods for different boards.
I can try working on a proposal to revive lwIP work, but its unlikely to be in a useful state before the submission deadline.
We could do some of the TMS570LS3137 work you describe before the coding period starts. I have a dev workflow to write rtems binaries to TMS570 SRAM (512KB max size). For larger binaries, the xcp workflow will have to touch the tms570 boot,lwip and we might not need a full 3 month project.
I drafted my proposal keeping in mind the extra challenge in setting up a dev environment for the TMS570. We could have the first steps to the lwIP work as part of this gsoc project, and TMS570-specific work can be continued after that. I could do it as part of continued engagement.
We have some flexibility to modify/direct the project scope based on the accepted proposal and discussions with mentors and contributors. If you are comfortable working with lwIP, then pushing a bit in this direction for your proposal can help us to be more flexible if we have to choose between both proposals.