TTIG gateway bricked - how to repair?

Gateways TTIG - The Things Indoor Gateway
1

After some time of no use, I plugged in my TTIG-868 device again and it was working again. After some time (several days) I recognised that it’s down - so I power cycled it, but no reaction. It seems to be bricked - it lights up red, flickering green periodically. According to the manual this could mean “Scanning WiFi networks, setting up Config AP” - but there is no AP, it does not connect to my WiFi. It does not react to any of the buttons.

  • Now the gateway does not connect to the WiFi anymore (no assigned IP in the DHCP list)
  • It keeps the same blinking pattern, independent of pressing the setup/reset buttons (short, 5 s, 10 s)
  • No AP visible (with our without pressing the setup button for 10 s)
  • As power source I use the internal power supply (Euro plug). To be ensure that the supply is not faulty, I also tested USB-C instead (5 V/2 A) - it shows the same behaviour.

I assume the flash got corrupted for some reason. Is it possible to re-flash it? I would need the location of Vcc, Gnd, TxD, RxD and GPIO0 and a proper image which can be flashed to the ESP8266.

The serial logs seem to support my theory:
11500 baud (I removed most of the unreadable characters):

rllܟ|▒l▒|
l$d`▒mode : sta(2c:f4:32:56:78:9a)
add if0
1970-01-01 00:00:02.147 [SYS:INFO] Erasing FLASH
1970-01-01 00:00:02.629 [SYS:INFO] Restarting
del if0
usl
sul 0 0

 ets Jan  8 2013,rst cause:1, boot mode:(3,7)

load 0x40100000, len 2408, room 16
tail 8
chksum 0xe5
load 0x3ffe8000, len 776, room 0
tail 8
chksum 0x84
load 0x3ffe8310, len 632, room 0
tail 8
chksum 0xd8
csum 0xd8

2nd boot version : 1.6
  SPI Speed      : 80MHz
  SPI Mode       : QIO
  SPI Flash Size & Map: 32Mbit(1024KB+1024KB)
jump to run user2 @ 101000

r▒o▒▒▒B▒|
lll ▒mode : sta(2c:f4:32:56:78:9a)
add if0
1970-01-01 00:00:02.144 [SYS:INFO] Erasing FLASH
1970-01-01 00:00:02.626 [SYS:INFO] Restarting
del if0
usl
sul 0 0

 ets Jan  8 2013,rst cause:1, boot mode:(3,7)

load 0x40100000, len 2408, room 16
tail 8
chksum 0xe5
load 0x3ffe8000, len 776, room 0
tail 8
chksum 0x84
load 0x3ffe8310, len 632, room 0
tail 8
chksum 0xd8
csum 0xd8

2nd boot version : 1.6
  SPI Speed      : 80MHz
  SPI Mode       : QIO
  SPI Flash Size & Map: 32Mbit(1024KB+1024KB)
jump to run user2 @ 101000
[...]

76800 baud:


 ets Jan  8 2013,rst cause:1, boot mode:(3,7)

load 0x40100000, len 2408, room 16
tail 8
chksum 0xe5
load 0x3ffe8000, len 776, room 0
tail 8
chksum 0x84
load 0x3ffe8310, len 632, room 0
tail 8
chksum 0xd8
csum 0xd8

2nd boot version : 1.6
  SPI Speed      : 80MHz
  SPI Mode       : QIO
  SPI Flash Size & Map: 32Mbit(1024KB+1024KB)
jump to run user2 @ 101000

OS SDK ver: 2.0-dev(9ec59b5) compiled @ Feb 12 2018 11:02:32
phy ver: 1055_1, pp ver: 10.7

▒▒▒*▒▒+▒▒▒T▒UUT▒▒▒▒E▒TU▒T▒UTUT▒Q▒TQ▒▒▒UUUj▒▒▒BR+Z▒V▒▒U▒T▒UTUT▒Q▒TQ▒U▒UUUj▒▒▒BU▒▒T▒▒VQ▒*▒▒▒TZK▒▒j*QQQ▒*▒P*V▒▒ET▒▒▒▒T▒▒+▒▒u▒U+UZ▒Z▒T▒▒TQT▒QQ▒▒jP▒▒▒u▒▒▒▒▒ZT▒(E▒▒▒▒Q▒▒Eu▒▒▒▒▒QB▒▒▒▒▒▒▒Q▒ZT▒(E▒▒▒▒QXUEu▒▒▒▒▒UQB▒▒▒U▒▒▒UP▒Q▒ZT▒(E▒▒▒▒QTE▒j*QTEQT+▒▒u▒▒▒Zյ▒▒jUQ▒▒▒*U▒UT▒▒▒
                    ▒UT▒E▒▒▒uT
                              ▒▒▒▒▒▒UE▒▒▒TT▒U▒▒UU(ZUUR▒▒▒▒UQ*Q▒UT*E▒▒P▒P▒Vխ▒A▒Q▒EQ▒OS SDK ver: 2.0-dev(9ec59b5) compiled @ Feb 12 2018 11:02:32
phy ver: 1055_1, pp ver: 10.7
[...]

So it seems to continuously reboot very early in the boot process.

2

hi @holly,

thanks for the logs. Actually, flash corruption seems unlikely from this log. Your TTIG is behaving as if the RESET button is constantly held pressed. I’m assuming you are not actually pressing the RESET button during this sequence. In that case, this points to an electrical or physical fault with the effect of the RESET button being constantly ‘active’. If you have the tools (and the TTIG housing opened) an easy test could be to probe the ports of the reset button with a scope while you engage the button.
I think you’d be best advised to try and get a replacement unit. You should reach out to your vendor.

3

Hi @bei,

thank you for your reply!
Unfortunately my unit is not covered by warranty anymore.
Correct, the log was performed without pressing any button.
I have a multi-meter, but I am not sure how the button works. I see two contacts at the front and three at the back. I guess it’s a “make contact” switch. It seems all contacts are shorted for SW2 (reset), but it’s hard to measure, since there is also a metal body on the tiny switch. By chance, are there any test points which can be used?

4

Does anyone know how GPIO0 of the ESP8266 can be accessed on the PCB?

I assume the reset button is connected to a GPIO rather than the reset pin of the ESP8266.
Since I have no schematic, checking the hardware is quite tricky. But a quick sanity check could be flashing a small test program.
J1 connects to Vcc, Gnd, TxD - the fourth connection could be RxD.

5

Unfortunately I was not lucky with this gateway - it became a paper weight.

On one hand is is nicely engineered, small form factor, power supply by mains or USB-C.
On the other hand there is no recovery functionality in case of a flash corruption and quite some other disadvantages (e.g. limited RF performance, full dependency on the manufacturer w.r.t. firmware).

So I cannot recommend the TTIG gateway - better spend a little bit more money and buy another one! Although not everybody will be so unlucky that it breaks, but if it breaks (outside the warranty period), there is no way for recovery.
Even reading the debug messages on the serial interface (for basic diagnostic) requires opening the case and some basic electronic equipment and skills. And there is no (officially documented) way to recover the firmware in case of a failure.

It’s a pity, because it even seems to have a CP2102 USB-serial bridge and a pressure sensor (DPS310) on the PCB. Also the main processor ESP8266 is very easy to program and great for open source projects. But as long as there is no documentation and schematics available, there will be no alternative firmware possible without reverse engineering.

I have good experience with these gateways instead:

  • IMST iC880A-SPI (also available as complete set with a Raspberry Pi and a metal case “Lite Gateway”)
    Pros: Good performance (SMA antenna connector), full flexibility with the software, since it can be used with an arbitrary host device, like an Raspberry Pi.
    Cons: More expensive than the TTIG gateway, does not work out of the box (requires manual installation of the software/packet forwarder).
  • Dragino LPS8
    Pros: Good RF (SMA antenna connector) and CPU performance, router-like hardware, open source software.
    Cons: More expensive than the TTIG gateway (I recently bought them around 130 € incl. VAT, now it seems the supply situation lead to an increased price).
6

You do not know this to be true, either in or out of warranty - all you know is that you were unable to recover it.

How many other devices do you own that are like that? Your washing machine? I bet your car has an ODB port that requires a special device to read the diagnostic data.

There is no publicly published document but I suspect it would be rather hard to create the device if it couldn’t be flashed.

So whilst you’ve had a negative experience, you’ve had just one experience of a TTIG and there is a large body of users who have a TTIG that just works. So your recommendation should only be taken in context.

7

@holly: I’ve already answered a similar post from you; Advantages and disadvantages of the TTIG gateway - #16 by KrishnaIyerEaswaran2

If you do have a hardware failure, our TTIG team would like to take a look at that unit.

1 Like
8

You are right, I need to be more precise: In case of a firmware corruption it is not possible to fix it in a documented way. For sure it was flashed during production, but since it is not documented it is not available for an end user in fact.
I also partially agree that some skills and equipment is required for diagnostics. But I am not aware of any other gateway, which does not offer a firmware recovery possibility. Also similar devices, like routers, often can be flashed via TFTP in case of a corrupted firmware for instance.

So I don’t doubt that in general it works flawlessly (otherwise it would not be sold anymore I guess). But I wanted to mention some disadvantages in case of a problem. Although it hopefully will be very rare, I think a missing firmware recovery is a flaw.
And it could be some motivation to make it better - like activating the already present USB-serial bridge for debugging and maintenance, provide more documentation and so on.

9

Hard to say what causes this problem. @bei’s assumption was a shorted reset button (which could explain such a behaviour I guess), but the button did not get stuck or wet, so I think it’s caused by something else, although I cannot be sure. I tried to measure it, but the design is not obvious and without schematic this does not make much sense.
Often such devices can be revived by a new firmware, but I cannot test this in this case.

So, I am sorry, I can’t tell you whether the problem is caused by a hardware failure. If you would like me to test something, please let me know.
Also if you want to have a look on the unit (but as mentioned, I can’t say whether it is a hardware failure).

10

@KrishnaIyerEaswaran2 has now said twice that he wants to look at the unit - you are getting the ultimate attention here - please just get on with a private message to arrange some form of post / courier etc