I was following the below app note and seem to have encountered a small issue:
Note: I am using the FRDM-KW36
I followed all the appropriate steps and had the app note up and running properly. I also disabled CAN FD by editing line 26 in the flexcan_interrupt_transfer.c file.
I then tried to detect the CAN messages by attaching another CAN enabled device to the CAN bus and it seemed that the messages I was reading were not valid (I know they are encrypted but this was an actual error). I hooked it up to an oscilloscope and measured the baud rate of the messages to be about 1250000, whereas it seems the example is configured for 1000000 as seen in the fsl_flexcan.c file.
I tried to reconfigure the baudrates and was getting the same issues. Below is a table
|Programmed Baud Rate||Actual Baud Rate (Scope)|
I configured the baudrate via the fsl_flexcan.c file (line 612). When I tried adjusting my other CAN enabled device to read the CAN message at the baudrate measured at the oscilloscope the message is successfully read.
I'm wondering if there is anything else that I need to configure such that the programmed baud rate is the same as the actual output baud rate. Thank you.
Ended up fixing the problem.
Did this by opening the Clocks for the project.
Went to the clocks diagram tab
Changed the OSCSEL value to be the system oscillator
Changed FRDIV block value to be 1/1024
Changed the FLL block, specifically the FLL factor to be 1280
Although this does fix the baud rate issue. I am a bit concerned as to what functionality it may effect. Are there any effects of changing the clock configuration as so?
If there is no change in the radio clocking and everything matches the Bluetooth LE specifications there should not be an issue, nonetheless, there will be the need to check and verify if everything works accordingly to meet the specs and necessities of the protocol.
By any chance, have you taken a look at this community thread?
I believe it's just what you are referring to and the solution to it.
I have taken a look at the thread. However I assumed that because I was just copying over the flexcan_interrupt file (which does not run into this baud rate issue) I didn't think that I would need to do more configuration. Am I wrong in assuming so?
What do you mean by mentioning by other configuration? When you mention copying the file do you mean by the drivers one or from the downloadable files in the Application Note software downloadable?
Also, it is important to take into account this note of the guide I sent you:
"Take into consideration that not all the baud rates are achievable and will depend on the flexcan clock and segment values used"
When mentioning another configuration I meant the flexcan_interrupt_transfer driver example that is one of the SDK examples that I can import. As mentioned the flexcan_interrupt_transfer does not run into the issue of having a different measured baud rate of that configured.
It is also my understanding that the app note for the ble can and lin bridge, basically, takes the flexcan_interrupt_transfer example and merges it into the wireless_UART example (with some modifications). So I don't see what would be configured differently that would cause this baud rate change. Looking through the guide you mentionedwould indeed require me to make some changes, but I don't see why these changes would need to be made if the baud rate issue is not happening in the flexcan_interrupt_transfer example, and the app note file copies most of that example.
Thank you for your help,
Yes the application note indeed merge both examples, nonetheless, the clock configuration you need to keep it't the Bluetooth LE instead of the flexcan one.
If you add the files in the application note when using two KW36, do you run with the same issue?
I see now that we need to keep the BLE clock configuration and that is probably causing the issue/mismatch. The app note example does work fine when configured on both boards, but I haven't had the chance to connect to that CAN network when it is established. I assume it works because the receive clock will be effected in the same way and thus cause their baudrates to match up.
In order to get a desired output baudrate would be just be best to test different programmed baud rates until the output is desired or is there a way to configure the clocks properly. Thanks.
I would recommend you to first try testing first the different application definitions and check if those get to the desired baud rates.
By different application definitions I assume you meant applying my test onto the app note examples themselves.
I ran the app note, with baud rate of 500000 and CAN FD on (even though for my application I am turning it off) and on the oscilloscope I still read a baud rate of around 588000 to 625000 (due to the limitations of the scope it can't be more accurate). So it seems that the app note by default has this baud rate issue. I've tried playing around with different programmed baud rates and here are the results.
Programmed vs Detected (via oscilloscope)
Does this simply mean that these baud rates are not achievable as you mentioned. It just seems odd to me because these are standard baud rates and I would expect the app note to have it configured correctly. It is also odd because as I mentioned the flexcan interrupt example worked fine.
Thanks for the assistance.