[Ovmsdev] CAN-3 broken again?

Mark Webb-Johnson mark at webb-johnson.net
Thu Jan 11 08:35:04 HKT 2018


Another issue, that seems strange, is:

can::can()
...
xTaskCreatePinnedToCore(CAN_rxtask, "CanRxTask", 2048, (void*)this, 10, &m_rxtask, 0);

That is creating the CAN_rxtask on core #0.

$ fgrep -r xTaskCreatePinnedToCore *
components/can/can.cpp:  xTaskCreatePinnedToCore(CAN_rxtask, "CanRxTask", 2048, (void*)this, 10, &m_rxtask, 0);
components/canopen/src/canopen.cpp:    xTaskCreatePinnedToCore(CANopenRxTask, "COrx Task", 4096, (void*)this, 5, &m_rxtask, 1);
components/canopen/src/canopen_worker.cpp:  xTaskCreatePinnedToCore(CANopenWorkerJobTask, m_taskname, 4096, (void*)this, 5, &m_jobtask, 1);
components/obd2ecu/src/obd2ecu.cpp:  xTaskCreatePinnedToCore(OBD2ECU_task, "OBDII ECU Task", 6144, (void*)this, 5, &m_task, 1);
components/ovms_server/ovms_server.cpp:  xTaskCreatePinnedToCore(OvmsServer_task, "OVMS Server", 6144, (void*)this, 5, &m_task, 1);
components/retools/src/retools.cpp:  xTaskCreatePinnedToCore(RE_task, "RE Task", 4096, (void*)this, 5, &m_task, 1);
components/simcom/src/simcom.cpp:    xTaskCreatePinnedToCore(SIMCOM_task, "SIMCOMTask", 4096, (void*)this, 5, &m_task, 1);
components/vehicle/vehicle.cpp:  xTaskCreatePinnedToCore(OvmsVehicleRxTask, "Vrx Task", 4096, (void*)this, 10, &m_rxtask, 1);
main/ovms_housekeeping.cpp:  xTaskCreatePinnedToCore(HousekeepingTask, "Housekeeping", 4096, (void*)this, 5, &m_taskid, 1);
main/ovms_netmanager.cpp:    xTaskCreatePinnedToCore(MongooseRawTask, "NetManTask", 7*1024, (void*)this, 5, &m_mongoose_task, 1);
main/task_base.cpp:  BaseType_t task = xTaskCreatePinnedToCore(Task, name, stack, (void*)this, priority, &m_taskid, core);

Every other task is created on core #1. Supposedly our App runs on core #1, and wifi/bluetooth run on core #0. Why is can::can CAN_rxtask running on core #0?

Regards, Mark.

> On 11 Jan 2018, at 8:31 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> 
> The design of the system is as follows:
> 
> The can object CAN_rxtask listens on the rx queue to receive instructional messages from canbus drivers. These can be:
> CAN_frame: simply passes an entire incoming can frame to the IncomingFrame handler.
> CAN_rxcallback: an instruction for the CAN_rxtask to call the RxCallback task repeatedly.
> CAN_txcallback: an instruction for the CAN_rxtask to call the TxCallback once.
> In the case of CAN_rxcallback, the canbus object RxCallback function is expected to return FALSE to indicate nothing should be done and RxCallback should not be called again, or TRUE to indicate an incoming frame has been received and should be passed to IncomingFrame.
> The system is arranged so that individual bus driver interrupt implementations can be fast and efficient.
> The driver can choose to receive the frame in the interrupt handler itself, and pass it with CAN_frame to CAN_rxtask. The esp32 can driver uses this option.
> Or the driver can choose to delay the reception of the frame to the RxCallback stage, and merely pass an indication with CAN_rxcallback. The mcp2515 driver uses this option.
> The true/false response from RxCallback is designed to allow the callback to signal it received a frame or not. If it received a frame, then it is called again.
> This approach is used in order to be able to centralise the reception of CAN frames to one single task (avoiding having to run individual tasks for each canbus, hence saving stack RAM).
> 
> The RxCallback should definitely ONLY return true if an actual can message has been received, and is being passed back in the frame pointer parameter.
> 
> I suspect the issue is that the mcp2515 RxCallback is being faced with multiple error flags. Changing that to a return true (as Greg has done) has the undesired side-effect of issuing a spurious IncomingFrame (with garbage/blank frame), but also causes the RxCallback to be called again (clearing the error flag). Perhaps the solution is to put a loop in RxCallback so that if an error condition is found, it should be cleared, but then loop again and keep clearing errors until no more are found, then return false? I think that in the mcp2515 case, this error clearing loop can be simply handled in the RxCallback itself.
> 
> The alternative is to change the RxCallback logic so that the return bool value means simply ‘loop’ (call me again, please), and have the RxCallback itself call IncomingFrame(), rather than passing a frame as a parameter. If Michael/Greg think this is a better approach, I am happy to make that change - it is pretty trivial.
> 
> Regards, Mark.
> 
>> On 11 Jan 2018, at 7:30 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>> 
>> Greg,
>> 
>> please check the receive flow chart, that's not the way the MCP2515 is supposed to work with RXB0CTRL.BUKT=1 and no filters -- if the documentation is correct.
>> 
>> Your change still will produce wrong IncomingFrame() calls caused by the return true from the error handler. You need to change the RxCallback() return type (or
>> use the frame buffer for an auxiliary result tag) and call loop to add the "don't send but keep calling" case.
>> 
>> Regards,
>> Michael
>> 
>> 
>> Am 10.01.2018 um 23:27 schrieb Greg D.:
>>> The functioning of buffer overflow, I believe, is working as it should. 
>>> I see that most of the time, frames come in on buffer 0.  When I cause
>>> the overflow by starting wifi, I see a single frame received in buffer
>>> 1, along with the status of a buffer overflow from buffer 0, but the
>>> interrupt status only shows buffer 1 as being full: status from register
>>> 2C is 0x22, not 0x23.  The error status was 0x40, indicating the single
>>> overflow, as expected.  My guess is that the timing is such that buffer
>>> 0 was being read at the time the next frame arrived, so it went into
>>> buffer 1, and that buffer 0 had emptied by the time buffer 1's interrupt
>>> was seen.  I have not seen a buffer 1 overflow (which would indicate
>>> that a frame was actually lost), so the buffer 0 overflow is totally not
>>> an issue.  At most, it's a warning that the system is under load.  No
>>> surprise there; it was.
>> 
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180111/49037b9d/attachment.htm>


More information about the OvmsDev mailing list