CTU CAN FD IP Core issueshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues2019-12-06T07:52:49Zhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/341Port direction mismatch2019-12-06T07:52:49ZIlle, Ondrej, Ing.Port direction mismatchhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/342Debug nightly run2019-12-06T12:36:12ZIlle, Ondrej, Ing.Debug nightly runhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/343PCI driver exception when signature not found.2019-12-09T12:59:36ZPavel PisaPCI driver exception when signature not found.When core is reload but PCI bus is not scanned again then reads from stale regions return 0xff.
Return value of ctucan_probe_common() does not return negative value in such case which leads
to attmpt to setup multiple instances.When core is reload but PCI bus is not scanned again then reads from stale regions return 0xff.
Return value of ctucan_probe_common() does not return negative value in such case which leads
to attmpt to setup multiple instances.Pavel PisaPavel Pisahttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/344Update Debian DKMS driver package for separated PCI module.2019-12-09T16:04:43ZPavel PisaUpdate Debian DKMS driver package for separated PCI module.Pavel PisaPavel Pisahttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/345Include driver documentation from Martin Jerabek's theses.2019-12-10T08:30:28ZPavel PisaInclude driver documentation from Martin Jerabek's theses.Pavel PisaPavel Pisahttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/346Include check_path in linux driver build2019-12-13T15:10:14ZIlle, Ondrej, Ing.Include check_path in linux driver buildhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/347Update driver documentation and Jaroslav Beran copyright.2019-12-12T16:48:24ZPavel PisaUpdate driver documentation and Jaroslav Beran copyright.Pavel PisaPavel Pisahttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/348Driver documentation acknowledge the project funding2019-12-18T06:07:20ZPavel PisaDriver documentation acknowledge the project fundingPavel PisaPavel Pisahttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/349Documentation clarification of TXCE in section 3.1.38 of Progdokum.pdf2020-01-08T18:57:23ZJan CharvátDocumentation clarification of TXCE in section 3.1.38 of Progdokum.pdfTXCE Activates "set_empty" command. Transits frone TX Done, TX Error or TX Aborted to Done.
It should be Empty instead of Done.TXCE Activates "set_empty" command. Transits frone TX Done, TX Error or TX Aborted to Done.
It should be Empty instead of Done.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/350Improve readme2020-01-13T19:42:05ZIlle, Ondrej, Ing.Improve readmehttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/351Resolve synthesis warnings2020-03-27T11:18:58ZIlle, Ondrej, Ing.Resolve synthesis warningsResolve warnings from Xilinx VivadoResolve warnings from Xilinx Vivadohttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/352Simultaneous RRS=1 and FDF2020-04-04T12:58:09ZIlle, Ondrej, Ing.Simultaneous RRS=1 and FDFAccording to ISO TC 7.1.4 IUT shall be able to receive CAN FD frame where RRS bit is high.
In current implementation RTR flag is sampled in position of RRS bit and this is used to decide
that no data field will be contained in that fram...According to ISO TC 7.1.4 IUT shall be able to receive CAN FD frame where RRS bit is high.
In current implementation RTR flag is sampled in position of RRS bit and this is used to decide
that no data field will be contained in that frame (as if RTR frame). In case of CAN FD frame
(FDF = 1), this information shall be ignored however.ISO conformance testinghttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/353Split Err_Ovr_delim_too_long2020-10-31T21:16:26ZIlle, Ondrej, Ing.Split Err_Ovr_delim_too_longPC FSM state indicating Error / Overload delimiter is too long is common for both Error flag and Overload flag.
After this state, PC FSM goes to Error delimiter regardless of the fact whether this was Error or Overload flag!
In this sta...PC FSM state indicating Error / Overload delimiter is too long is common for both Error flag and Overload flag.
After this state, PC FSM goes to Error delimiter regardless of the fact whether this was Error or Overload flag!
In this state, even after too long Overload delimiter, device will signal that DUT is transmitting Error frame (which
is not true) in status registers.
Strictly speaking this does not mind, because behaviour of DUT with respect to standard is met (in both cases error counters
are incremented accordingly) -> TODO: What if device is not transmitter nor receiver in case of overload flag? Can this happen?
This should be resolved like so:
1. [ ] Create two PC fsm states for too long flag (Overload/Error)
2. [ ] Describe changes in PC FSM diagram in spec.
The behaviour of overload too long will be nearly the same as Error too long, with following differences:
1. Error will signal Error frame is transmitted, Overload will signal overload is transmitted.
2. After this states ends, Error too long will go to error delimiter, Overload will go to overload delimiter.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/354Fix Overload delimiter lenght2020-04-14T17:52:10ZIlle, Ondrej, Ing.Fix Overload delimiter lenghtOverload delimiter should have length of 8 bits, not 7!Overload delimiter should have length of 8 bits, not 7!ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/355Fix REC decrement2020-04-17T19:39:42ZIlle, Ondrej, Ing.Fix REC decrementAccording to ISO11898-1:2015 REC shall be decremented by 1 upon succesfull reception of frame. This means up to succesfull transmission of ACK bit!
This point in CAN frame is different than Frame validation which is one bit before end of...According to ISO11898-1:2015 REC shall be decremented by 1 upon succesfull reception of frame. This means up to succesfull transmission of ACK bit!
This point in CAN frame is different than Frame validation which is one bit before end of EOF! This means that Frame can be
"succesfully received", REC decremented (after ACK) and e.g. form error occuring in first bit of EOF causing the frame not to
be validated (no valid reception will be signaled, no frame will be stored in RX Buffer)!
In CTU CAN FD, the moment of REC decrement is the same as the moment of frame validation and that is last bit of EOF.
7.6.7 of ISO16845-1 2016 is specifically designed to catch this issue as it expects first decrement of REC after ACK and then increment by 1 due to form error on ACK delimiter, thus leaving REC unchanged after the frame is over!
In current implementation of CTU CAN FD the point of decrement will never occur, and REC will only be incremented. This is a bug.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/356Documentation review2020-04-18T18:04:49ZIlle, Ondrej, Ing.Documentation reviewhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/357Non-synchronisation on dominant transmitted bit2020-05-06T19:40:16ZIlle, Ondrej, Ing.Non-synchronisation on dominant transmitted bitAn exception to re-synchronisation rule is not to perform resync with positive phase error
when node does transmitt dominant bit.
In current implementation, this exception is driven in protcol control fsm when
node is transmitter and it...An exception to re-synchronisation rule is not to perform resync with positive phase error
when node does transmitt dominant bit.
In current implementation, this exception is driven in protcol control fsm when
node is transmitter and it does transmit dominant bit.
This however does not cover all cases of dominant bit transmission! E.g. when node
transmitts an error frame it also does transmitt dominant bit (it does not even have
to be transmitter) and it should NOT perform positive resynchronisation!
This should be fixed although there is no test for this in compliance sequence
(if e.g. node is receiver).ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/358Protocol exception feature test2021-02-18T22:16:02ZIlle, Ondrej, Ing.Protocol exception feature testAdd Protocol exception test to verify all combinations of Protocol exception.
This includes following:
1. CAN 2.0 - no protocol exception
2. CAN FD Tolerant - protocol exception on Recessive FDF.
3. CAN FD Enabled - no protocol exception...Add Protocol exception test to verify all combinations of Protocol exception.
This includes following:
1. CAN 2.0 - no protocol exception
2. CAN FD Tolerant - protocol exception on Recessive FDF.
3. CAN FD Enabled - no protocol exception - form error on recessive r0 in CAN FD frames.
4. CAN FD Enabled - protocol exception on Recessive r0 in FD frames.Test improvementshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/359Prescaler bug-fixes2020-05-23T09:31:40ZIlle, Ondrej, Ing.Prescaler bug-fixesFollowing issues should be resolved in prescaler:
1. [x] When detecting negative phase error should there be a -1 in calculation?
2. [x] When detective negative resynchronisation with phase error <=Following issues should be resolved in prescaler:
1. [x] When detecting negative phase error should there be a -1 in calculation?
2. [x] When detective negative resynchronisation with phase error <=ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/360Fix TX/RX simultaneous trigger2020-07-09T13:46:25ZIlle, Ondrej, Ing.Fix TX/RX simultaneous triggerIf PH2 is shortened to 0, prescaler trigger_generator module shall delay consecutive TX trigger
by 1 clock cycle. This is not working properly, fix this.If PH2 is shortened to 0, prescaler trigger_generator module shall delay consecutive TX trigger
by 1 clock cycle. This is not working properly, fix this.ISO optimizations