Posts by vpruess

Unfortunately the link given in your post is broken. Can you fix it ?

Regards

Volker

We didn't change anything in the section of the file mach-netdcu14.c regarding the CAN initialization. The relevant section is as follows

Yes, the backported driver solves the problem we had with the driver included in the multiplatform release V2.0. There are at least two changes you didn't mention but that may address critical flaws :

threaded irqs must provide a primary handler or set the IRQF_ONESHOT flag (I'm not sure whether the data handling is based upon threaded IRQs) :
http://git.kernel.org/cgit/lin…3b3b38429da6f70a913f89b04

repeated frame problem :
https://lkml.org/lkml/2012/9/16/120

But I definitely don't know exactly what change finally solved our problems with the driver included in the multiplatform release V2.0. But I can say that - after applying the patch mentioned above - our NetDCU14 application works at least stable when attached to the CAN bus. So this solves one problem but this doesn't solve the steady loss of CAN messages I mentioned in some of my other posts. Please don't mix these two problems.

Quote

However, as you already have a version of this driver running, and other people can download your version here, too, I don't see any immediate need for action. The solution is already available here in this thread.

I would expect that other people aren't forced to collect all those patches floating around in this forum to finally get a working multiplatform release V2.0 +, especially in case these other people spent a lot of money to buy hundreds of your boards.

Regards

Volker

Sorry but I don't get the point of your post.

There definitely is a problem with the 'original' driver and you cannot get a better proof for that than observations from two different customers. If you are not able to reproduce these problems I can only assume that your test setup differs from ours (both CAN devices are in use, 16 participants communicating with each other). Perhaps MWeber can sketch his test setup and we can try to find the common ground.

Regards

Volker

We noticed that gcc (both official toolchain versions '4.6.3' and '4.7.2') hasn't been configured with option '--enable-libstdcxx-time=yes'. This results in some C++11 features not available, noteably std::this_thread::sleep_for and std::this_thread::sleep_until. There is an easy workaround (just defining the switch _GLIBCXX_USE_NANOSLEEP) but it would be nicer to let the compiler define this.

So far we had no luck integrating the alternative driver for the MCP2515. So we are back to square one, hoping for a new release fixing all our problems.

Regards

Volker

(Sorry, this is a bit off-topic for Windows Embedded > NetDCU > NetDCUA5. Move the thread if you like)

So you were able to enable the internal CAN devices for the Linux platform ? That sounds great and I can't wait to give this solution a try.

Regards

Volker

Hello !

I was just asking myself about the way the NetDCUA5 provides CAN support. Is the NetDCUA5 equipped with two Microchip MCP2515 attached via SPI or is this solved by using the Vybrid A5 internal CAN interfaces ?

Regards

Volker

As I said we're using V2.0 and some patches, more precisely the following :

* NetDCU14-Correct-UART-configuration.-UART0-with-RTS-.patch
* Activate-TOUT1-PWM.1-via-backlight-system.patch
* Add-hwmon-support-to-read-ADC-channels.patch
* linux-mcp251x-20130423_plus.patch (The one I mentioned somewhere above)

So we definitely have IRQF_TRIGGER_LOW | IRQF_ONESHOT set in our mach-netdcu14.c and I checked that.

I also made a quick glance at the SPI driver and it seems to me that this is a not so easy task. Additionally these changes may interfere with some other changes made by the F&S team (spi-s3c64xx.c). Another approach I tried was to generate a patch based upon the changes made by F&S in respect to stock 3.3.7 and to apply these changes to 3.6.11 which of course returns with a lot of errors.

The one option left together with multiplatform 2.0 I can see is trying the alternative driver mcp2515.c which I will do next.

Can you give us a quick report about the progress for the next Multi-Platform release ?

Regards

Volker

I definitely know that we didn't apply all the changes provided after the release of V2.0 but we did apply those patches that are important for us. This includes the patch you mentioned. I also double-checked that before answering. Interestingly the statements about IRQF_TRIGGER_LOW differ a bit. I've read the following :

Quote

'Note that the "IRQF_ONESHOT" flag is only required for kernel 3.6. For kernel 3.2 you should remove it. Adjust the GPIO pin used for interrupt (here 25), the SPI frequency (here 10MHz) and MCP2515 oscillator frequency (here 20MHz) to your setup.'

(<!-- m --><a class="postlink" href="http://elinux.org/RPi_CANBus">http://elinux.org/RPi_CANBus</a><!-- m -->)

But I don't know enough to decide which is wrong and which is right.

Hello F&S-support,

Q1 has passed and nothing has happened in respect to the next version. In the meantime we integrated our boards in the system and ran into some serious problems. Some of these we were able to handle (see my other postings according to CAN interfaces).

Now we observe CAN message losses when running the CAN bus at 500 kHz and roughly 10 % busload. Checking the throughput we discovered CAN message loss, about 3 % depending on the CPU load (3 % is the best case we observed with the CPU running idle). candump reports rx overruns.

Searching the internet reveals that this is a common problem with the MCP2515 in combination with some 3.x kernels and the default kernel driver. There are also some solutions out there including improvements to the SPI interface and an alternative driver.

In my opinion this is a really serious bug in the board support package that must be addressed and fixed as fast as possible.

Regards,

Volker

Hello again !

The last days we tried a backported version of the driver mcp251x and it seems to solve our problem. So I strongly recommend to try this too. I would attach our patch for the Multiplatform Linux V2.0 but I can't find any option in this forum to attach anything. So I placed the patch here : http://pastebin.com/yDcf660A.

Regards

Volker

First of all, I would like to wish you all a good start in this New Year !

I must admit that I didn't track the CPU roadmap of most developers but I noticed that there is quite a lot going on. I saw that TI tries to provide a longer time-on-market with their Sitara processor series and some manufacturers provide a drop-in replacement, for example Allwinner. I also noticed that TI is remarkably active in respect to the Linux support, even an SDK for the PowerVR SGX530 is available and support for OpenGL is on the way (something we will IMHO never get for the Samsung S5PV210 CPU, at least not for the Multi-Platform Linux). Even CAN seems to be on-board. Possibly this could be an option for the next NetDCU version.

Unfortunately we cannot wait until the successor of the NetDCU14 is released. I'm afraid we cannot even wait until end of Q1/2014. So I hope we will see a new version a little bit sooner. In the meantime I backported some bugfixes applied to the mainstream driver for the MCP251x mainly to exclude observerations that may be reported due to outdated drivers (also seems to solve the problem described in this topic : <!-- l --><a class="postlink-local" href="http://www.forum.fs-net.de/viewtopic.php?f=60&t=3362">viewtopic.php?f=60&t=3362</a><!-- l -->). So I would recommend to pick at least kernel 3.12, even 3.13 if possible for the new version of the Multi-Platform Linux.

Regards,

Volker

Hello !

Unfortunately I can confirm that we sometimes observe the same problem in our application. We're unsure whether or not this is a problem triggered by a CAN bus wiring failure.

Worse than that is in case this situation arises it seems that the whole system is under such a high workload it is no longer responding. We managed to enter via the debugging console and found out that sometimes the system stabilizes after pulling the CAN connectors.

I saw that in newer kernel versions the driver mcp251x contains at least one bugfix addressing a silicon bug in MCP2515 Rev. B which is described as "repeated frame problem". Unfortunately I was unable to disclose the silicon version of the MCP2515 used in the NetDCU14 design (The errata document is dated 2007 so I would expect the NetDCU14 uses an already fixed version of the MCP2515).

UPDATE: According to the errata document (http://ww1.microchip.com/downloads/en/DeviceDoc/80179g.pdf) Revision B4 is the latest revision and in production since 2005 so I would recommend to update the driver (even though I don't expect that this solves our problem).

Regards,

Volker

Shame on us !

The measuerement we've done wasn't in the correct environment. The mouting holes are indeed not connected (at least not to any of the connectors we measured in our second try ). But we found a problem with another component we will try to solve first. If this doesn't help I would discuss into the details according to the peak frequencies.

Thanks a lot for your help

Volker

Hello hpb,

unfortunately we cannot use plastic based bolts as the device must be ruggedized.

Regards,

Volker

Hello F&S support team,

unfortunately we observed EMC issues with our designated setup because we're using metal-based bolts to combine the several components of our device. We assume (and hope) this is due to one of the small but crucial differences between the NetDCU8 and the NetDCU14 because the NetDCU8 didn't expose the ground layer around the mounting holes.

The solution we came up with is to enlarge the mounting holes (currently 3 mm) to 4-5 mm, place a plastic jacket around the bolt screw and plastic washer on both sides. This would separate the ground of the NetDCU board from the case ground.

Is it safe to do so or would we cut into vital parts of the board layout ?

Regards,

Volker

Hello !

We just noticed that the latest sample we took from our stock had a different hardware revision than our engineering samples. I checked the documentation area and didn't find any notes about hardware revisions. Where can I find the list of changes between Revision 1.10 and 1.20 ?

Regards,

Volker

Hello F&S-support,

according to some entries in the forum there are open items in release 2.0 of the Multi-Platform package. I was wondering whether there will be an update containing all those patches floating around/promised in the threads.

Regards,

Volker

Hello F&S Support Team,

we're looking for an easy way to update our multiplatform-based system (NetDCU14) and stumbled over the file install.scr which seems to perfectly fulfill our needs. Everything seems clear except that there is a 72 byte magic header at the beginning of the script :

Do we have to use some extra tool to construct this header ?

Kind Regards,

Volker

Any updates about this issue ?

We have ongoing problems with PWM signal from TOUT1 - FS Bus J4, especially a colleague of mine tried to activate the signal and failed too.

To activate the signal we applied the patch and executed the following commands

Any help would be highly appreciated

Kind Regards,

Volker

BTW: You mentioned the 'next release'. Is there a release planned in the near future ?