I was able to find the WICED source and recompile the STM32F2xx_Peripheral_Libraries.a in debug mode with -O1. Now the source code shows up in the debugger when it hits a breakpoint in the can driver and I am able to step though the code. There seems to be a problem with the mapping to the memory and/or IO addresses though.
The problem was that the CAN device was not getting initialized properly and was only partially working. I compared your initialization code with the STM32 CAN example and noticed the difference. In can_hal.c you just need to do a
“RCC->APB1ENR |= (RCC_APB1Periph_CAN1 | RCC_APB1Periph_CAN2)”
instead of
“RCC->APB1ENR |= RCC_APB1Periph_CAN2;”.
application.cpp
…
Message.Ext = true;
Message.ID = 0x1234UL;
Message.rtr = false;
Message.Len = 8U;
Message.Data[0]=‘h’;
Message.Data[1]=‘e’;
Message.Data[2]=‘l’;
Message.Data[3]=‘l’;
Message.Data[4]=‘0’;
Message.Data[5]=’ ‘;
Message.Data[6]=‘W’;
Message.Data[7]=’!’;
Serial.println(“Writing CAN”);
…
Hello Teensy 3.1 CAN Test.
0x0000 0x1234 0x01 0x08 0x0000 0x68 0x65 0x6c 0x6c 0x30 0x20 0x57 0x21 |hell0 W!|
0x0000 0x1234 0x01 0x08 0x0000 0x68 0x65 0x6c 0x6c 0x30 0x20 0x57 0x21 |hell0 W!|
0x0000 0x1234 0x01 0x08 0x0000 0x68 0x65 0x6c 0x6c 0x30 0x20 0x57 0x21 |hell0 W!|
0x0000 0x1234 0x01 0x08 0x0000 0x68 0x65 0x6c 0x6c 0x30 0x20 0x57 0x21 |hell0 W!|
0x0000 0x1234 0x01 0x08 0x0000 0x68 0x65 0x6c 0x6c 0x30 0x20 0x57 0x21 |hell0 W!|
0x0000 0x1234 0x01 0x08 0x0000 0x68 0x65 0x6c 0x6c 0x30 0x20 0x57 0x21 |hell0 W!|
0x0000 0x1234 0x01 0x08 0x0000 0x68 0x65 0x6c 0x6c 0x30 0x20 0x57 0x21 |hell0 W!|
4 Likes
WOOT!!!
Great job!
1 Like
Wow, so glad I checked in on this again! You’ve just prompted my order for a couple more Photons thanks to seeing this (working on downsizing a ‘huge’ chipkit max32 unit I’m using currently, CAN support needed).
Looking forward to implementing this, thank you everyone for the effort!
Receiving is also working:
Hello Photon CAN Test - Expecting reversed message from Teensy
0x4321 0x01 0x08 0x21 0x57 0x20 0x6f 0x6c 0x6c 0x65 0x48 |!W olleH|
0x4321 0x01 0x08 0x21 0x57 0x20 0x6f 0x6c 0x6c 0x65 0x48 |!W olleH|
0x4321 0x01 0x08 0x21 0x57 0x20 0x6f 0x6c 0x6c 0x65 0x48 |!W olleH|
0x4321 0x01 0x08 0x21 0x57 0x20 0x6f 0x6c 0x6c 0x65 0x48 |!W olleH|
0x4321 0x01 0x08 0x21 0x57 0x20 0x6f 0x6c 0x6c 0x65 0x48 |!W olleH|
0x4321 0x01 0x08 0x21 0x57 0x20 0x6f 0x6c 0x6c 0x65 0x48 |!W olleH|
0x4321 0x01 0x08 0x21 0x57 0x20 0x6f 0x6c 0x6c 0x65 0x48 |!W olleH|
0x4321 0x01 0x08 0x21 0x57 0x20 0x6f 0x6c 0x6c 0x65 0x48 |!W olleH|
1 Like
I just confirmed that the CAN is reading and writing messages!!
I will work on getting the buffers and interrupts working now.
Ok, I think I have the CAN buffers, and the Rx/Tx interrupts all working!!
Could you update to my latest and let me know if it seems to work for you?
1 Like
I think I created a Git Pull Request for the CAN bus driver so this can be integrated into the photon!!
Please let me know if I messed it up.
So it looks like there is an automatic build that runs on pull requests and of course mine does not build… Probably because I started this branch in October…
It is running this command:
make -s clean all PLATFORM=newhal COMPILE_LTO=n
But what is PLATFORM=newhal? My driver only works with Photon…
a little help would be great!
Hi Brian,
I’m reviewing your CAN driver implementation. I’m thinking of moving the ring buffer from the HAL into the Wiring file to make the HAL code as small as possible.
Are you attached to the peek and flush functions in the CAN Wiring class? I think transmit and receive would be sufficient.
I’ll add some filter methods because on a busy bus you’ll overflow your buffer if you capture all traffic.
I’m also adding a setting to turn on the CAN loop back mode so the Particle continuous integration tests calls the CAN functions.
1 Like
This is my first contribution to the particle platform so I don’t mind if you move the buffers.
I started with the uart driver which had peek and flush so I implemented them. I see no reason to have them though. So yes remove them.
The filters are very nice but can be a pain to implement because of the variety of combinations (11 bit and 29 bit). You also need to be able to enable and disable specific ones. I use CAN on a daily basis at work and we usually do not filter because we have 10 ms or faster loop times. I have only implemented some very simple particle apps so I do not have a good feeling of the typical loop times on particle.
Loop back could be great for the continuous integration. So I agree here as well.
Great. Could you add me as a collaborator to your fork (https://github.com/bspranger/firmware/settings/collaboration)? This way I can add my changes to your branch and they will show up in your pull request. My GitHub user is monkbroc.
You should be set to contribute!
@mdma you put a message on git hub on my pull request asking if we could get rid of the CAN_Message_Struct. We cannot. There is a very strict format to CAN messages and you need to implement all the members of that structure to support it. CAN messages are also restricted to 8 data bytes, although higher level protocols such as J1939 allow you to do multi-packet messages to transfer larger amounts of data.
Perhaps we should work on getting this to compile with the trunk? Right now my pull request fails to compile. Since this is my first time contributing to particle and really using git (svn user) perhaps you could help me get this all wrapped up. Then we can work to improve the capabilities.
Please let me known when you have something that I can test with.
I’m working on making the code work with the latest firmware version. I plan to update @Bspranger’s branch on GitHub by next Monday.
This looks fantastic and I cant wait to try this out! Been lurking for awhile but most of my time has been spent dealing with modbus. Happy to test on some simulators and industrial equipment.
1 Like
Let me know if I can help.
1 Like
I posted an update to @Bspranger’s CAN pull request on GitHub with support for filering, 2 CAN channels on the upcoming Electron, additional tests.
I’m going to go try with real hardware now.
1 Like