Hi,
I am making some test code and I want to program one of my CAN channels to respond to all frames on the CAN bus with an ACK.
It does one time but ignores everything afterword.
I have initialized the driver and have the event and object callbacks. I do not do anything in the callbacks since I don't care about the data. I can put a break in the receive case and it does see the first frame. No more messages to the either call backs after that.
I tried setting the callback addresses to NULL in the initialize function ( the CMSIS documentation said you could if you dont need to process them ). This made a HW fault. Tracked that down to CMSIS code that was calling the NULL callback. So I guess you cant use NULLS.
I am not doing the OSSignalWait() / OSSignalSet thing. I am going to try that next.
So my question is... is there anything that needs to be done on each message reception to enable receiving the next?
Thanks, Tony
I set up an additional device on my CAN bus and have it sending frames every 250ms. My CMSIS device is acking just fine.
So some of the detail that I left out of my original post probably matters... although it has not dawned on me yet why.
Additional detail: Originally I was using the same hardware device to send and to ack... just different CAN channels. Channel 0 sends, channel 1 acks.
The drivers for channel 0 and channel 1 are setup in the same RTOS thread. The thread is seup to run every 250ms and send on ch 0. Channel 1 is ignored by my code. Maybe something is dawning on me while writing this... will the OSDelay( 250 ) make the callback not work if a message comes in while delayed? Hmmm
Maybe channel 1 needs its own thread?
It was nothing so involved as all of this... had a GPIO clobbered by another thread.
Just goes to show you... never touch GPIOs from threads that don't own them.
Just two comments as you have already solved your problem.
First: callbacks can be NULL, so this was a problem in driver implementation that you used (what device did you use, and which pack version)
Second: generally you should readout the message once you receive it (you can ignore the data) as reading it out frees hardware for further reception, of course hardware can be setup to overwrite any pending message in that case you should get ARM_CAN_EVENT_RECEIVE_OVERRUN in signal SignalObjectEvent function if you have set it up
Hi, Thanks for the info concerning the callbacks. I am using an NXP LPC1837 processor and have pack: LPC1800_DFP2.6.0 and the CMSIS CAN driver is: CAN 1.0
As far as I can tell from uVision Pack manager, those are up to date. I am using uVision 5.2.
I was expecting an overrun as you said but did not get one when my GPIO switched my transceiver off. I have not gone back and looked for the overrun now that things are working. This is not production code, just something to test early hardware... and to get some experience using the driver.
I forgot to ask, for future reference...
How does the driver know that any received data has been processed? Is it just the OSSignalWait / OSSignalSet handshake or is there something else? I didnt see anything in the driver documentation on this...or I missed it.
thanks again
The process of formulating a question often helps me with a solution and I think it did again. I went back to the doco and found the CAN_MessageRead() API call. So if I was interested in the message contents, I would make this call in the SignalObject callback... and handling this would prevent an overrun.
Yes, the example for MCB1800 board in \Boards\Keil\MCB1800\Middleware\CAN\CAN\ CAN.c file shows MessageRead.
BTW, providing NULL for signal functions was also corrected only problem is that new version of pack containing fixed driver hasn't been released yet.