[Ovmsdev] Problems with IncomingFrameCan when registering two can buses.

Michael Balzer dexter at expeedo.de
Sun Dec 31 17:54:12 HKT 2017


Geir & Greg,

first of all, I did an over-optimization mistake in the RxCallback: the return after fetching the frame must always be true -- fix is pushed.

That has caused frames to get lost so you should apply this fix first.


Am 31.12.2017 um 01:00 schrieb Geir Øyvind Vælidalo:
> I did a test where I created three counters.
> One went into MCP2515_isr and counts every interrupt.
> One was added as the first code line in mcp2515::RxCallback.
> And the third one was added to RxCallBack, but right before we read the CAN frame via SPI that will end up in IncomingFrame. I.e. should be a count of every
> CAN frame.  
>
> This is what I got:
>
> OVMS >can can2 status
> CAN:       can2
> Mode:      Active
> Speed:     100000
> Rx pkt:                      82
> MCP2515_isr:                 239
> RxCallback1:                 320
> RxCallback2:                 295
> Rx err:                       0
> Tx pkt:                       0
> Tx err:                       0
> Err flags: 0x2040
>
> These numbers puzzles me. Shouldn’t *RxCallback1* and *RxCallback2* be less or equal to *MCP2515_isr*? Where does these extra 81 calls come from? I’m missing
> something here...

No, that's expected behaviour. The MCP2515 has two RX buffers plus error conditions. The framework is designed to loop RxCallback over an IRQ event until all
buffers and error conditions have been processed, so RxCallback counters should always be >= ISR count.

> Also*, RxCallback2* is much bigger than *Rx pkt, *which means not all frames are sent to IncomingFrame.

That's in part due to my bug, but it also can happen under normal conditions, as an error IRQ will also trigger the RxCallback but not return a frame to be
processed.

>
> What does the 0x2040 means? And where do that number comes from? 
>

That's constructed in line 293 from the error interrupt flags and the error register. The lower 8 bits are in the image I sent, the upper 8 bits are

      //  MERRF 0x80 = message tx/rx error
      //  ERRIF 0x20 = overflow / error state change

Regards,
Michael

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20171231/c2fd5843/attachment.html>


More information about the OvmsDev mailing list