drivers: can: mcp2515: Add driver for MCP2515 CAN controller #8304

karstenkoenig · 2018-06-10T20:11:25Z

The MCP2515 is a CAN controller that can be connected via SPI to an
host MCU. This driver adds support for the MCP2515 as a new driver in
the CAN subsystem.
As it is a SPI peripheral it uses a thread for its interrupt
handling and the received message filtering is done inside this
interrupt thread, as the MCP2515 filter capabilities are not sufficient
for the Zephyr CAN interface.
The driver was validated with an external CAN logger and the adjusted
CAN sample application.

Signed-off-by: Karsten Koenig [email protected]

karstenkoenig · 2018-06-10T20:30:14Z

@alexanderwachter
Heihei, please also review this. I know you have plans for changing the CAN interface further, and I am open for discussions and changes.

Some notes on this driver:

filtering is done on the host mcu, the mcp2515 doesn't have filtering that matches the CAN rx interface and is generally a lot weaker
dts not straightforward, reintroduced timing configuration in KConfig.mcp2515 for now
currently no error feedback, messages will be retried forever until error condition is cleared

codecov-io · 2018-06-10T20:39:04Z

Codecov Report

Merging #8304 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #8304      +/-   ##
==========================================
- Coverage   52.93%   52.92%   -0.02%     
==========================================
  Files         309      309              
  Lines       45268    45268              
  Branches    10451    10451              
==========================================
- Hits        23961    23956       -5     
- Misses      16542    16544       +2     
- Partials     4765     4768       +3

Impacted Files	Coverage Δ
subsys/testsuite/ztest/src/ztest.c	`68.59% <0%> (-4.14%)`	⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5900a6f...63dcd27. Read the comment docs.

alexanderwachter · 2018-06-10T20:53:59Z

@karstenkoenig The timing should be in in the device-tree to have the ability to set different speeds on multiple CAN controllers. Moreover for various boards with different clock speeds its annoying to change the Kconfig for every board.
The error feedback is a little bit tricky. Maybe we could use the timeout for the int_sem too and delete the message from the buffer if a timeout is triggered. But for now the timeout is only for waiting for an empty message box.

For the filtering you can maybe use a clever masking to reduce the number of interrupts.
Like xor all the id's together and or this with all masks to get kind of a master mask and set the filter id to the first index?

karstenkoenig · 2018-06-11T06:41:55Z

Having CAN timing information in device tree files is straightforward for on MCU devices, as you can just toss the information into the existing board files, but right now for 'external peripherals' it is harder to provide a straight forward sample until dts overlays/shields are enabled. Most sensors etc all still have that sort of information in KConfig files
#6837

I am not really sure under which circumstance the stm will feedback tx errors now, won't it also try forever? Or will it pretty much report the error and still have transmitted the message?

The XOR filter idea is really nice, but to configure the filters on the MCP2515 it needs to be put out of operation into configuration mode, so everytime the filters get changed it needs to be recalculated and applied while stopping actual operation, so it might also create unexpected behavior.

alexanderwachter · 2018-06-11T07:57:47Z

Now I get your point with the device-tree. I think it's ok for the external controller to have this in Kconfig.

There is no error feedback. The controller will try sending forever as long as there is no ACK . I think that is the behaviour recommended by the ISO standard. The API for reading the bus states (Error active, Error passive and bus off) is still pending. Also recovery from bus off is not possible with the current API.

Could you use the Acceptance Filter as they are and just "or" the masking together? In my opinion it is sufficient ho have only six filter banks. The stm32 driver stops operation of the filters too for the short period of changing them. Not using the hardware filtering at all will result in a heavy CPU load depending on the overall bus load.

tbursztyka · 2018-06-11T13:05:14Z

drivers/can/mcp2515.c

form line 16 to here, you could move that to a dedicated header file.

tbursztyka · 2018-06-11T13:06:32Z

drivers/can/mcp2515.c

About all the above spi related function: would there be a way to make it in one function? (just asking, and if you prefer that way, just keep it.)

I thought about it, but the methods are quite different and I don't want to throw distinguishing it to the callers. I renamed them with cmd to indicate they are doing remote calls on the mcp2515.

tbursztyka · 2018-06-11T13:07:29Z

drivers/can/mcp2515.c

rewrite that:

u8_t opcode_buf = { ..., ... };

Apply that comment everywhere. (you did it properly in soft-reset function above actually)

tbursztyka · 2018-06-11T13:08:34Z

drivers/can/mcp2515.c

0x07, 5: could you create macro to these with relevant names?

I tried to do my best, there is currently 3 functions left where it is still using unnamed bit positions and masks
mcp2515_convert_can_msg_to_mcp2515_frame
mcp2515_convert_mcp2515_frame_to_can_msg
mcp2515_configure

They won't really become easier to read nor to follow, as you need to look at the datasheet if you want to know the details, and then it is easier to check for correctness when having the bare positions spilled out instead of double checking defines.
I can change the rest too if it is policy or just frowned upon.

tbursztyka · 2018-06-11T13:09:09Z

drivers/can/mcp2515.c

Never declare a variable in the middle of a code block, always a the beginning of it. Apply that everywhere.

tbursztyka · 2018-06-11T13:09:49Z

drivers/can/mcp2515.c

add an empty line after '}' unless it's another } etc... Apply that everywhere.

tbursztyka · 2018-06-11T13:10:58Z

drivers/can/mcp2515.c

too many if imbrications.

I guess you could reverse that test and use continue, to reduce indentation of the lines below.
If necessary, it's also a good idea to create an inline function to de-clutter the code.

tbursztyka · 2018-06-11T13:15:01Z

drivers/can/mcp2515.c

For all of these sem/mutex maybe you could try using K_SEM_INITIALIZER()/K_MUTEX_INITIALIZER(). It will generate a little less code then. (and it's faster to initialize).

These macros are flagged internal, does that mean I can use them in kernel drivers or is that just for really core components? Use throughout the rest of the tree seems to lean towards k_sem_init/k_mutex_init style initialization.

I more dislike the general amount of mutexes and semaphores, but couldn't come up with a smaller amount

It's ok to use these macros in native drivers, not in application.

Ok, I changed the initializers to be in the mcp2515_data_1 initializer, thanks!

tbursztyka · 2018-06-11T13:15:32Z

samples/can/prj.conf.mcp2515

you could split that into another patch.

karstenkoenig · 2018-06-12T06:54:24Z

Thanks for the great feedback so far! I tried incorporating everything from @tbursztyka and updated the pull request.
I will work on the filtering in another commit, @alexanderwachter your idea has some caveats such as filter 2-5 will overflow easier, but in general it sounds like a very sensible approach that should at least stem the message tide

tbursztyka

just some minor comments, rest is fine to me.

tbursztyka · 2018-06-12T07:35:33Z

drivers/can/mcp2515.c

tiny alignement issue (should be below last '(' + 1 space)

apply that rule everywhere (I probably did not notice it the first time)

Sorry I have to double check here, as the first time I did it checkpatch complained about space instead of tabs
You want any line breaks aligned under and after the last current open bracket right? It doesn't have to be exactly 1 behind the last open bracket, right? Anyways, I did just that and checkpatch didn't complain (but keeps seeing lines longer than 80 chars that aren't, does it tab extend to 8 space?)

tbursztyka · 2018-06-12T07:38:02Z

drivers/can/mcp2515.c

does that fit the 80chars limit?

alexanderwachter

Looks good. Some minor comments.

alexanderwachter · 2018-06-11T06:28:56Z

drivers/can/Kconfig

This option is specific to driver implementations and therefore should be kept in Kconfig.stm32 and Kconfig.mcp2515. Also the maximum in your driver is 32?

alexanderwachter · 2018-06-12T07:28:20Z

drivers/can/Kconfig.mcp2515

Do you want to merge CAN_PROP_SEG and CAN_PHASE_SEG1? There is no point to keep them separate because it wont change the sampling point.
I don't mind to keep them separate but in device-tree they are merged.

I wanted to avoid doing any unexpected math, and there is hard limits on the values, but I think you are right, I could just do the following to allow for full range and stay in the bounds, will keep it in mind when switching to dts proper
tq_prop = tq_prop_bs1 / 2
tq_bs = (tq_prop_bs1 / 2) + (tq_prop_bs1 % 2)

I had
tq_bs1 = (tq_prop_bs1 -1) & 0x07
tq_prop = tq_prop_bs1 - tq_bs1 - 2
in mind but its the same :-)

But I think you can keep it separate anyway.

alexanderwachter · 2018-06-12T07:37:55Z

drivers/can/Kconfig.mcp2515

this should be range 2 8
"PS1 is programmable from 1 – 8 TQ and PS2 is
programmable from 2 – 8 TQ" [MCP2515 datasheet]

alexanderwachter · 2018-06-12T07:52:04Z

drivers/can/Kconfig.mcp2515

Wouldn't it be better to call this INT Pin?

alexanderwachter · 2018-06-12T08:01:52Z

drivers/can/mcp2515.c

Could you write
u8_t cmd_buf[] = { MCP2515_OPCODE_BIT_MODIFY, reg_addr, mask, data };

alexanderwachter · 2018-06-12T08:02:28Z

drivers/can/mcp2515.c

and
.buf = cmd_buf, .len = sizeof (cmd_buf),

alexanderwachter · 2018-06-12T08:16:17Z

drivers/can/mcp2515.c

I would prefer sizeof (config_buf) instead of just 4

alexanderwachter · 2018-06-14T08:50:32Z

drivers/can/mcp2515.c

You could use ARRAY_SIZE(tx_buf) here

karstenkoenig · 2018-06-15T07:42:52Z

Thanks for all the reviews and sorry for silently pushing, took it a bit slow.

@alexanderwachter
I thought a bit more about the filter suggestions and would want to discuss a little more. My background is ebikes, and there isn't much CAN data flying around, so the filtering isn't really that critical and you can better judge the situation

As there is only two filter masks on the mcp2515 the actual filtering will be very limited. My worry with random or'ing the masks together will be unintended filters such as worst cases ending up with 0 masks that won't filter. What do you think would be a decent strategy that allows application developers to pick sensible filters and leverage the limited filtering the best way using the current can interface?

straight forward would be allow only two filters overall, that forces good filter decisions in the first place by the application developer and will make him/her aware to pitfalls
allow 32 filters but create a filter each for standard and one for extended frames on mcp2515, or the masks, xor the filters, try validating them such as checking for 0 masks, run final filter check on host mcu
allow max 6 filters similar to 2., but messy because first inbox of mcp2515 has 1 mask and two filters and the second inbox has 1 mask and 4 filters, especially confusing with standard and extended frames, final filter check on host mcu

I prefer either 1. or 2., as they are the easiest to explain what is happening and don't try to paper over limitations.
2. could lead to unintended results but is more powerful than 1. if different paths for messages is important

Should I open a discussion issue ticket for this? Might be a better place then drag it out in a pull request

alexanderwachter · 2018-06-15T08:44:00Z

@karstenkoenig I have to study the data sheet an think about the filters.
I will comment it next week

alexanderwachter · 2018-06-19T17:28:48Z

@karstenkoenig
2.) sounds good but seems to be complicated.
1.) is really restricted and does not utilize all the mcp2515 capabilities.
Actually I don't know what's better.

Please have a look at https://github.com/alexanderwachter/zephyr/tree/can_extend_api
This is the API extension for bus-state-handling. Do you agree on it?
Unfortunately I have no idea how to test it because I dont't know how to produce error frames on purpose.

karstenkoenig · 2018-06-23T16:40:22Z

@alexanderwachter
On the filters:
I checked with the messages I am usually dealing with and there is literally no way to sensibly put together one or two filters, the message id's are just so different there is barely a common mask possible, even looking at just a handful of messages.
To be honest I am prefering 1) now for the most simple use cases where people must be clever to pick their filters. Actually I think all those queues or callbacks for the filters are pretty massive and it seems easier to me to just dump it all into a single rx queue or callback that can dispatch messages by higher level logic. So not attaching a queue or callback to a filter. Why did you prefer to have a queue/callback per filter?

On the bus error conditions:
I didn't have to deal with bus errors so far

The get_state I'd rather name get_error_state. Right now there is no 'disable CAN device' function but there might be a future and that is properly the more relevant 'state'.

Also do you specifically need the recover method? Couldn't you just configure it to auto-recover? I'd rather not expose device features until there is a use case for it, because that will make sure it at least gets used and tested and I can't see why I wouldn't want my CAN controller to auto recover for the most time.

alexanderwachter · 2018-07-02T13:44:12Z

@karstenkoenig I think 1) should the preferred solution or a Kconfig option to switch from your actual solution to 1) or just leave it as it is now.
I preferred one queue/callback per filter because the stm32 (and maybe NXP LPC series) have those hardware filtering capabilities. This helps reducing the interrupt flood when having high bus loads. I thought it's a "nice to have" when the dispatcher is hidden in the driver. Usually you need this kind of message dispatching anyway.

On the bus-state API:
In my opinion auto recovery is not always a good idea. A node is in bus-off state because it was disturbing the other nodes with sending error-frames and sending erroneous messages. An erroneous node could in a worst case block important frames from being sent.

I will change get_state to get_bus_state.

dwagenk · 2019-01-31T06:58:08Z

Hi,
Any chance of getting this PR back to live?
As far as I can tell not much has changed in the CAN subsystem, so it should be basically working. I've got a test setup here, using zephyr 1.13 release and sligtly modified commits from this PR, that can run the CAN Sample.

I'd be willing to help, at least with testing.

alexanderwachter · 2019-01-31T08:52:15Z

Sure.
@laperie @carlescufi @jukkar @tbursztyka What do you think?

jukkar · 2019-01-31T09:12:49Z

drivers/can/mcp2515.c

You should use the new logger as the syslog is deprecated.

Done, thanks

ulfalizer

Just some nits.

drivers/can/Kconfig.mcp2515

ulfalizer

Nits fixed.

karstenkoenig · 2019-02-24T20:56:05Z

@dwagenk apparently @alexanderwachter wrote some api test in tests/drivers/can/api, can you try running these as well please? Sorry I still don't have my stuff with me :-(

drivers/can/mcp2515.c

dwagenk · 2019-03-21T20:45:34Z

Finally got to try out the current state of this PR, but didn't get it to work yet. It fails in mcp2515_set_mode and returns -EIO.
By what I see that could be just an SPI problem in my setup (it's the first read of MCP2515 registers), so I'll have to look into that before I can give more feedback on this PR.

karstenkoenig · 2019-03-31T17:56:46Z

I have access to my stuff again and fixed the driver.

@dwagenk you are right and probably ran into SPI chipselect issues, I made a mistake with the devicetree connection. Fixed it and provided an overlay dts file in the sample project for reference. To be honest the interworking of different parts of devicetree/kconfig etc are kind of hard to follow.... the cs-gpios dts struct has to be part of the spi bus and not the bus member, and when mapped to defines in the build process they lose the plural s and end up being CS_GPIO_xyz etc :-(

Anyways, I also ran the CAN api testsuite and it passes

dwagenk · 2019-04-01T10:17:46Z

@karstenkoenig great that you picked it back up and have your Hardware for testing. I'll keep trying it out and hope it helps if I just document my issues. Iwill comment directly on the files causing issues for me.

samples/drivers/CAN/mcp2515-dts.overlay

karstenkoenig · 2019-04-01T19:20:00Z

DeviceTree is so beautiful and so utterly frustrating at the same time...
I moved the bus-speed in the sample overlay dts file into the driver segment, and am now using the MCP2515_0_BUS_SPEED in the mcp2515.c driver. This works and does not need an existing 'can1' section at all in the dts.
To double check I just hooked it up and ran it on an nrf52_dk10040 board, the only thing that needed changing were the GPIOs in the sample config. Before I tested/validated it on a Nucleo L432KC. That already has CAN enabled through Alexanders work (and obviously wouldn't need such an inferior external controller in the first place)

codecov-io · 2019-04-01T19:58:05Z

Codecov Report

Merging #8304 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #8304   +/-   ##
=======================================
  Coverage   52.87%   52.87%           
=======================================
  Files         309      309           
  Lines       45267    45267           
  Branches    10451    10451           
=======================================
  Hits        23934    23934           
  Misses      16558    16558           
  Partials     4775     4775

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1eead93...241d869. Read the comment docs.

dwagenk · 2019-04-02T07:15:59Z

@karstenkoenig that fixed it! It compiles and runs the CAN sample in loopback mode now (stm32_min_dev board with external button).
Also tested with a modified sample app using a real can bus with both, 250k and 500k bus-speed and a CAN-USB dongle on linux as counterpart.

I'd propose merging it now and then doing little improvements later.

LGTM

dwagenk

suggested changes for a follow-up PR

dwagenk · 2019-04-02T07:34:15Z

drivers/can/Kconfig.mcp2515

+
+if CAN_MCP2515
+
+config CAN_MCP2515_OSC_FREQ


I guess these could/should go into device tree as well?

CAN_MCP2515_OSC_FREQ

CAN_PROP_SEG

CAN_PHASE_SEG1

CAN_PHASE_SEG2

CAN_SJW

Hm yes, the segment length ones are sort of defined already in the can devicetree, but seg1 and prop are merged together there but the mcp2515 allows specifing them independently. I'll try sorting out again why I didn't just use it before

@karstenkoenig it should be save to merge CAN_PROP_SEG and CAN_PHASE_SEG1. Even the CAN standard says so. I have no idea why this is separate in the mcp2515. They have the same effect.

dwagenk · 2019-04-02T07:36:24Z

drivers/can/mcp2515.c

+	/* CNF3, CNF2, CNF1, CANINTE */
+	u8_t config_buf[4];
+
+	if (bitrate == 0) {


Maybe we should make it more explicit somewhere, that bus-speed confgirued in device-tree will be ignored, if can_configure is called with bitrate != 0 ?

Indeed. This should be added in the API documentation.

haha actually I only found this because the api test tripped there and added it in after double checking with the stm32 can drivers :-)

dwagenk · 2019-04-02T07:41:08Z

samples/drivers/CAN/prj.conf.mcp2515

+CONFIG_CAN_1=y
+CONFIG_CAN_STM32=n
+CONFIG_CAN_MCP2515=y
+CONFIG_GPIO_LED_DEV="GPIOB"


already discussed earlier but noted again here as a to do for later:
use led0 and sw0 from the board's device tree.

dwagenk · 2019-04-02T07:42:33Z

samples/drivers/CAN/mcp2515-dts.overlay

 	status = "ok";
+	cs-gpios = <&gpioa 4 GPIO_DIR_OUT>;
 	mcp2515@0 {
 		compatible = "microchip,mcp2515";


If we give it a label properties can be changed in additional (e.g. application specific) overlay files.

&spi1 { /* ... */ mcp2515_can1: mcp2515@0 { /* ... */ }; }; /* in different file, overlay or position: */ &mcp2515_can1 { bus-speed = <250000>; };

karstenkoenig · 2019-04-02T20:05:25Z

@dwagenk Nice! Glad to hear it works for you as well!

alexanderwachter · 2019-04-02T20:30:26Z

@karstenkoenig @dwagenk next big change is #13262

The MCP2515 is a CAN controller that can be connected via SPI to an host MCU. This driver adds support for the MCP2515 as a new driver in the CAN subsystem. As it is a SPI peripheral it uses a thread for its interrupt handling and the received message filtering is done inside this interrupt thread, as the MCP2515 filter capabilities are not sufficient for the Zephyr CAN interface. The driver was validated with an external CAN logger and the adjusted CAN sample application. Signed-off-by: Karsten Koenig <[email protected]>

Adjusted the MCP2515 driver to switch from KConfig SPI configuration to DTS based configuration. Signed-off-by: Karsten Koenig <[email protected]>

Project configuration to run the CAN sample with the MCP2515 attached via SPI as the CAN controller. Signed-off-by: Karsten Koenig <[email protected]>

Fixed using chipselect with seperate chipselect GPIOs and how they were referenced from/in DeviceTree. Also configure the device during initialization so it's ready to go after init. Signed-off-by: Karsten Koenig <[email protected]>

karstenkoenig requested a review from erwango as a code owner June 10, 2018 20:11

alexanderwachter added the area: CAN label Jun 10, 2018

alexanderwachter self-requested a review June 10, 2018 21:48

tbursztyka requested changes Jun 11, 2018

View reviewed changes

karstenkoenig force-pushed the mcp2515 branch 2 times, most recently from ff8325b to b7dfbd1 Compare June 12, 2018 06:52

karstenkoenig force-pushed the mcp2515 branch from b7dfbd1 to 884738d Compare June 12, 2018 07:18

tbursztyka reviewed Jun 12, 2018

View reviewed changes

alexanderwachter requested changes Jun 12, 2018

View reviewed changes

karstenkoenig force-pushed the mcp2515 branch from 884738d to 755a676 Compare June 13, 2018 20:15

alexanderwachter reviewed Jun 14, 2018

View reviewed changes

drivers/can/mcp2515.c Outdated

Copy link

Member

alexanderwachter Jun 14, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could use ARRAY_SIZE(tx_buf) here

karstenkoenig force-pushed the mcp2515 branch from 755a676 to 266d37f Compare June 14, 2018 16:11

alexanderwachter approved these changes Jun 14, 2018

View reviewed changes

erwango removed their request for review October 8, 2018 09:06

jukkar reviewed Jan 31, 2019

View reviewed changes

karstenkoenig force-pushed the mcp2515 branch 2 times, most recently from 6c391db to 046eab9 Compare February 9, 2019 15:58

karstenkoenig force-pushed the mcp2515 branch 2 times, most recently from eaeb6f5 to 60e2785 Compare February 24, 2019 18:33

ulfalizer suggested changes Feb 24, 2019

View reviewed changes

drivers/can/Kconfig.mcp2515 Outdated Show resolved Hide resolved

drivers/can/Kconfig.mcp2515 Outdated Show resolved Hide resolved

drivers/can/Kconfig.mcp2515 Outdated Show resolved Hide resolved

karstenkoenig force-pushed the mcp2515 branch 3 times, most recently from d09e9c8 to 462ca4f Compare February 24, 2019 20:29

ulfalizer approved these changes Feb 24, 2019

View reviewed changes

karstenkoenig force-pushed the mcp2515 branch from 462ca4f to 4696554 Compare February 27, 2019 12:00

alexanderwachter requested changes Mar 14, 2019

View reviewed changes

drivers/can/mcp2515.c Outdated Show resolved Hide resolved

karstenkoenig force-pushed the mcp2515 branch from 4696554 to 63dcd27 Compare March 31, 2019 16:52

alexanderwachter approved these changes Mar 31, 2019

View reviewed changes

alexanderwachter added this to the v1.15.0 milestone Mar 31, 2019

dwagenk suggested changes Apr 1, 2019

View reviewed changes

samples/drivers/CAN/mcp2515-dts.overlay Outdated Show resolved Hide resolved

samples/drivers/CAN/mcp2515-dts.overlay Outdated Show resolved Hide resolved

karstenkoenig force-pushed the mcp2515 branch from 63dcd27 to 241d869 Compare April 1, 2019 19:14

dwagenk approved these changes Apr 2, 2019

View reviewed changes

karstenkoenig added 4 commits April 17, 2019 14:40

drivers: can: mcp2515: Rework for DTS SPI bindings

475706b

Adjusted the MCP2515 driver to switch from KConfig SPI configuration to DTS based configuration. Signed-off-by: Karsten Koenig <[email protected]>

samples: can: Added project configuration for MCP2515

359fb07

Project configuration to run the CAN sample with the MCP2515 attached via SPI as the CAN controller. Signed-off-by: Karsten Koenig <[email protected]>

drivers: can: mcp2515: Fixes for DT SPI cs

14905ae

Fixed using chipselect with seperate chipselect GPIOs and how they were referenced from/in DeviceTree. Also configure the device during initialization so it's ready to go after init. Signed-off-by: Karsten Koenig <[email protected]>

nashif force-pushed the mcp2515 branch from 241d869 to 14905ae Compare April 17, 2019 18:40

nashif merged commit c9090ca into zephyrproject-rtos:master Apr 17, 2019

drivers: can: mcp2515: Add driver for MCP2515 CAN controller #8304

drivers: can: mcp2515: Add driver for MCP2515 CAN controller #8304

Uh oh!

Conversation

karstenkoenig commented Jun 10, 2018

Uh oh!

karstenkoenig commented Jun 10, 2018

Uh oh!

codecov-io commented Jun 10, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

alexanderwachter commented Jun 10, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

karstenkoenig commented Jun 11, 2018

Uh oh!

alexanderwachter commented Jun 11, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

karstenkoenig commented Jun 12, 2018

Uh oh!

tbursztyka left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

karstenkoenig Jun 15, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexanderwachter left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

codecov-io commented Jun 10, 2018 •

edited

Loading

alexanderwachter commented Jun 10, 2018 •

edited

Loading

karstenkoenig Jun 15, 2018 •

edited

Loading

alexanderwachter Jun 15, 2018 •

edited

Loading