Hi all,
I have a exactly the same problem as this topic below and the symptoms are also the same.
There is solution that have to change SPI speed ([SOLVED] Ic880a stopped responding to RESET on pin 22 - #37 by marssystems), however i don’t know how to change it, can anyone give me a instruction as detail as possible ? Thanks in advance.
from that topic:
You have to edit the lora_gateway/libloragw/inc/imst_rpi.h file and change the default #define SPI_SPEED 8000000 to #define SPI_SPEED 500000
did you tried that ?
[0#90]
the point is i am using resin.io build and i didn’t know where to find to change it. I think this repo is from another build.
I followed the build as below.
Modify run.py, find (at the end of the file):
subprocess.call("/opt/ttn-gateway/mp_pkt_fwd -c /opt/ttn-gateway", shell=True)
to
subprocess.call("/opt/ttn-gateway/mp_pkt_fwd -s 500000 -c /opt/ttn-gateway", shell=True)
-s <speed> allows you to specify the SPI speed.
I changed and tried to rebuild unfortunately everything still the same, the dashboard constantly show failed to start the concentrator.
Are you using the correct reset pin? Which adapter board are you using?
I am using Gonzalo Casas backplane
and i reset pin is 22.
I didn’t change anything but still can’t figure it out why the gateway suddenly fail after nearly a month of running perfectly fine.
A few of the usual Raspberry Pi Checklist:
Have you checked with a different power supply? If the red power LED Blinks at all the one you are using might be too low.
Have you done any updates? The RPf have released updates last Friday of which may have been automatically applied and affected it.
Have you tried re-seating the ic880a into the backplane and then the backplane onto the RPi?
The power supply one is rather common in causing odd results with the RPi. A good 5V 2A one should be used.
Could it be an early life component(*) failure? Have you been able to check/test by substitution? - Swap RPi, Swap i/f board, swap concentrator bd , swap PSU (per Ryan suggestion), etc. Minor/early pin/connector corrosion - try reseating/cleaning with switch cleaner etc., just more for the checklist! 
Also where in the world are you - parts of EMEA having a heatwave in recent days/weeks so is it temp related? May explain why fine originally but now a month later failing…and indeed once failing may continue to fail due to (*) 
Can the issue possibly be SD card (wear/malfuntion) related?
You could try redo from scratch with a different microSD card.
@BoRRoZ, I understand the problem comes from the SPI bus is not running at the expected 8MHz even though the #define SPI_SPEED 8000000 instruction was issued. This is caused by the variable VPU clock rate in the Pi3. As the VPU changes frequency the SPI speed changes. At the RP3 default VPU clock rate you correct by setting the SPI for 5MHz to obtain the required 8 MHz SPI speed. I also understand even with this correction the VPU can still change speed and the connection to the Lora chips stops working and a different correction factor is required. I went about this a different way, rather trying to account for this error I locked the VPU frequency by adding the line “core_freq=250” to /boot/config.txt By doing this the #define SPI_SPEED 8000000 instruction has the correct effect and sets the SPI speed to 8MHz.
it worked in my RP3B+ gateway with a RAK831
(some more detail I found. The VPU can switch from 250MHz to 400MHz in Turbo mode and will drop back under some conditions. The SPI clock rate is linked to the VPU frequency and as it steps up to 400MHz the SPI speed increases. Hence setting SPI to 8MHz means its actually running at 12.8MHz when the VPU is in Turbo mode, so setting it to 5MHz means its actually running at 8MHz (5MHz * 400/250 = 8MHz). The core_freq=250 instructions stops the VPU going into Turbo mode and the SPI speed is then set as expected)
Following on from my previous post, the RP3B+ will reduce CPU frequency as the Pi overheats. It may be the daytime ambient temperature that’s driving this, the reason it worked for a month then stopped. You may find it works at night but not during the day. If the enclosure housing the gateway’s electronics is exposed to direct sunlight (eg clamped to the antenna pole) you can expect temperatures inside the enclosure to be 20C higher than ambient air temperature and the chip temperature of the Pi is higher again. We experience ambient air temp (shade temp) of 45C, so think of this ALL the time.
Hm, that might be a very good point. My gateway stopped working last Friday and had auto security updates enabled… I haven’t found the time so far to debug it (it’s mounted on the roof and I don’t have power for a monitor up there).
Use Putty and ssh into the Pi from a PC. No need to fall off the roof trying to juggle a screen and keyboard 
I’ve updated however all of mine use a zero or B+ to avoid the SPI issues (And I have an abundance of older models).
I don’t have a traditional backplane to use with my RPi 3 so can’t debug further sorry.
Of course. The issue is that I don’t have direct access (it’s not my network). Instead, the Pi does a reverse SSH tunnel to a server of mine through which I can connect. That tunnel closed down on Friday and did not re-open after a power cycle, so something must be wrong.
It could be that one of the disk partitions is 100 percent full. Most likely the /var/log partition.
Ohh, that makes it difficult. Sounds like a site visit is about to occur.