[SOLVED] Ic880a stopped responding to RESET on pin 22

Gateways
21

Hi, I made those interface boards. A while ago I received a batch of pin headers (the 20x2 type) that seemed to make bad contact when stacked. I noticed it while testing the boards (I test every assembled board manually before shipping) and tried to replace all pin headers with good ones, but maybe some still slipped through. (I threw them all in the thrash now, to be safe :laughing:) .

You say that the same issue happens if you wire up the iC880A board with jumper wires. In that case this should not be the cause, but maybe it was just a coincidence?

Could you use this test script to turn on all LEDs and then wiggle around the board slightly to see if some of them turn on/off? If you have good connection between the pin headers, the LEDs should never flicker.

22

I tried your script and all the leds work fine and so does the button. Its difficult to ā€˜wiggleā€™ the backplane as its screwed down tight on standffs.
I have pin 22 (RESET) jumpered to the blue led so I know when the RESET pulse is sent but the ic880a doesnā€™t react to it at all.
I donā€™t think its a backplane or a hardware issue as exactly the same thing happens with my ā€˜testā€™ gateway which is just an RPi3B jumpered to an ic880a. When I re-boot, the ic880a fails to respond to the RESET signal and the gateway doesnā€™t start.

23

UPDATE

Just now the ic880a ā€˜sawā€™ the RESET pulse and the gateway started up all by its own.

Now thatā€™s magic!

24

Hah, thatā€™s a good idea :slight_smile:

Yeah, not sure what the cause could be in that case. Maybe formatting the SD card and setting up the whole OS + gateway config again might help.

25

Done that umpteen times - no joy.

I wouldnā€™t mind if it was just one gateway that was misbehaving like this but both of them are doing it.

26

I have two batches of ic880s and so far it only did that on one (OLDER batch)ā€¦ the other (belonging to a different/newer batch) is still aliveā€¦ waiting for it to (knock on wood) ā€˜misbehaveā€™. the one that ā€˜misbehavedā€™ before had # 0488 on the small square label and # 003609 on the large label ~13.2mm x 11.2mm. the NEWER batch that is still working have # 0038 on the small label and # 003892 on another, the label being ~13.2mm x 7.0mm. Iā€™ll do some more tests (run the gateways in parallel to see if behavior is different for each one).

27

Iā€™m glad (sort of) that Iā€™m not the only one with this problem.

When I raised a ticket with IMST, I was given these instructions to take some diagnostics -

ā€¢ Please clone / download the github repositry located at: GitHub - Lora-net/lora_gateway: Driver/HAL to build a gateway using a concentrator board based on Semtech SX1301 multi-channel modem and SX1257/SX1255 RF transceivers.
ā€¢ Edit the file lora_gateway/libloragw/library.cfg at master Ā· Lora-net/lora_gateway Ā· GitHub and set the ā€œDEBUG_HALā€ option to 1
ā€¢compile everything by using the ā€œmakeā€ command in the main directory
ā€¢modifiy the lora_gateway/reset_lgw.sh at master Ā· Lora-net/lora_gateway Ā· GitHub script:ā—¦change the reset pin to your needs
ā—¦remove line 37 / make sure to keep the reset signal as output
ā—¦OR: disconnect the RSET line and do a manual reset sequence

ā€¢enter the lora_gateway/util_pkt_logger at master Ā· Lora-net/lora_gateway Ā· GitHub directory, start the tool and log the output
ā€¢enter the lora_gateway/util_spi_stress at master Ā· Lora-net/lora_gateway Ā· GitHub directory and ā€œplayā€ a little bit with this tool while logging the output.

Iā€™ve set the DEBOG_HAL to 1 and all I get is - 31.07.17 21:53:10 (+0000) ERROR: FAIL TO CONNECT BOARD

I donā€™t know how to do the last 2 steps - start the tool and log the output and ā€œplayā€ a little bit with this tool while logging the output. I canā€™t find these 2 directories in my resin build. Maybe they are not there and I need to adjust my /dev/build.sh file to get them complied - I donā€™t know.

The white labels on the board are Batch and Serial numbers.
Mine is 0350 and 003959 on one
and (canā€™t see it) and 003506 on the other.
I was asked for these when I opened a ticket.

28

Same error with me until I discovered that fysical pin 22 (RPi) has to be GPIO25. Problem solved

29

Yes - thatā€™s how my backplane is physically wired but the ic880a still doesnā€™t respond to the RESET pulse.

30

In your log there is a pin 22 mentioned (physical pin), instead of 25 (gpio number of pin 22):

This is a part of the Resin.io log -
31.07.17 22:49:09 (+0000) [TTN Gateway]: Resetting concentrator on pin 22
31.07.17 22:49:10 (+0000) *** Multi Protocol Packet Forwarder for Lora Gateway ***

So I presumed that was the same configuration typo as I had, I changed in my configfile reset-pin 22 in reset-pin 25 and it worked like a charm

31

OK - I set the GW_RESET_PIN to 25 and now I get this error as pin 25 on the RPi3 is a GND pin -

16.08.17 23:52:01 (+0000) INFO: [main] Starting the concentrator
16.08.17 23:52:01 (+0000) ERROR: [main] failed to start the concentrator
16.08.17 23:52:13 (+0000) [TTN Gateway]: Resetting concentrator on pin 25
16.08.17 23:52:13 (+0000) Canā€™t interpret 25 as a valid pin number.
16.08.17 23:52:13 (+0000) *** Multi Protocol Packet Forwarder for Lora Gateway ***
16.08.17 23:52:13 (+0000) Version: 3.0.0

32

Can you find a non-LoRa way to toggle the GPIO pin up and down (from the raspberry pi) and confirm as far into the Ic880a board as you can that you see it go to a logical 0 and 1? (With a multimeter and the other lead going to a rPi ground.) Maybe its something easy like a loose solder joint somewhere. (It happens, especially with this sort of low volume stuff.)

Iā€™d suspect easy things like voltages, physical connections, and such before suspecting higher levels like silicon being bad or software being bad. (Are you sure that power supply doesnā€™t have current limiting mode enabled? Have you take a multimeter to it and looked to see how much AC ripple is on it? How far down does the 5Vdc line go down when thereā€™s load? (If at all.) )

Iā€™m fairly certain the pin 25 is translated to the appropriate GPIO. (But adding that into the debug text output should have been done to avoid this kind of confusionā€¦)

33

OK - I will check the voltages to see whatā€™s going on.

34

Is it possible to lower the SPI speed as a config parameter? On several fora this is mentioned as a solution to look into

1 Like
35

SPI communication speed is fixed in the sources. To change a recompile of the code (libloragw, setting is in the concentrator specific include file, so libloragw/inc/imst_rpi.h for iC880a) will be required.

@basswildens any pointers to the forums?

36

This topic on GitHub has some testing on SPI speed vs error rate

1 Like
37

Yes it is.

I just done it - and it works!! :laughing:

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

I then rebuilt the code on resin.io and pushed it to both my gateways and now they start first time - even after a re-boot!

Job done!

2 Likes
38

Also some interesting stuff on SPI clock speed on de raspi docu. Looks like clockspeed isnā€™t just the rounded number in our config file

And some behavior-as-expected from the developers of raspi Linux

1 Like
39

Hi Mr.
I have exactly the same problem as you have, I think to change the SPI speed might be solution for this problem. Since I am not understand very much about what you re discussing, would you mind show me how to change the speed in more details ?? thank you in advance.

40

this topic is ā€˜solvedā€™
pls start a new topic and describe exactly YOUR problem :sunglasses: