2

I have a raspberry CM3 running a custom Linux version created by buildroot (kernel: 4.19.44-v7). The CM3 is configured to be part of a measurement system that is used on a quad-bike (so a lot of vibrations).

I have several peripheral enabled:

  1. ENC28J60 for ethernet connection on SPI0 (GPIO pins 9,10,11, no CE, int_pin=25)
  2. Serial console on UART0 (GPIO pins 14 and 15)
  3. Sensor measuring at 5 hz on UART1 (GPIO pins 32 and 33)

code snippet from my config.txt:

ENC28J60 network interface:
Default int_pin = 25
dtoverlay=enc28j60,int_pin=25 

# Core Freq must be set to static for the miniUART
core_freq=250

# Enable UART:
enable_uart=1
dtoverlay=uart1,txd1_pin=32,rxd1_pin=33

Now I am experiencing a problem that when I unplug the ethernet cable my sensor that is reading from UART1 experiences an error in the communication with the sensor. What I see from the data collected:

  1. The command that requests data from the sensor is not sent
  2. The next data packet received from the sensor has additional bytes (1-5).

My conclusion from this is that there is interference on the UART communications from the interrupt caused by the ethernet disconnect event.

I have found that there can be interference betwen SPI1 and the UART1 LINK . However since I am using SPI0 I would not expect this. To make sure That Above behavior is not caused by UART1 being the inferior UART (miniuart). I have checked if something would change by switching the UARTS (putting gpio 14/15 in ALT5 and 32/33 in ALT3). Still the same issue.

At this point I am not sure how to solve this issue, or even collect more information on this issue. Some help in where to look to solve this issue would be very helpful.


Final note: I am using serialport in NodeJS to read and write to the sensor port through the UART. Since the issue happens at a disconnect event from the ethernet I do not think this part is the issue.


Edit 1: Why this is a problem is because the measurement system is used on a quad-bike. For some reason (probably vibrations) the 'unplugging' event of the ethernet cable randomly happens causing this error. This means I am losing measurements, which is the real problem I want to solve.

  • 1
    So you guess that unplugging from SPI Ethernet controller module causes an interrupt which messes up things. I would first verify your guess by doing the following: (1) first close the SPI channal using the method spiPortXyz.close() (2) then unplug Ethernet plug, (3) reopen SPI channal. (4) check UART sensor measurement log that sensor measurements were interrupted, but no faulty measurements were logged. Just brainstorming, to continue, ... – tlfong01 Jun 12 at 9:02
  • 1
    @DmitryGrigoryev I changed it to make it more clear: you are correct that I mean the next data packet received from the sensor – Steven Jun 12 at 9:20
  • @tlfong01 I managed to disable the interface ifconfig eth0 down and then unplugging it causes no faulty measurements. This indeed would indicate that it is caused by the interrupt. Maybe this is caused by the ethernet driver? – Steven Jun 12 at 9:22
  • I see. So we are now pretty sure that (1) manually unplugging causes interrupt, (2) interrupt causes faulty measurements. We can either use (a) ifconfig eth down/up or (b) spiChannel.close/open, or (c) ask UART to take a break when the human is pulling the plug. But "pulling the plug" to switch off TV set is of course bad manner. :) Anyway, I think how to pull a plug "softly" is is a hard problem, and may take my subconscious mind a long while to eureka. I think I would stop here and there is little hope for me to suggest anything useful soon. Good luck. :) – tlfong01 Jun 12 at 9:45
  • @tlfong01 Thank you for your help. This indeed has narrowed it a bit more down with certainty. I added some info to the question which explains why I want to solve this issue (unplugging randomly happens) – Steven Jun 12 at 9:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.