Is my GPY Bricked??

[Stevo52]

I have a GPY fitted to an Expansion Board 3. Connected by USB to a laptop running Windows 10 Pro. This setup has been running flawlessly as a test unit for a couple of months now, without issue. It doesn't run a set program but is used to test various bits of code and ideas before I put it into the real device code. Quality USB cable and good prototype pinned cables are used for any temporary connection.

The last testing has been trialing a number of timer controlled operations, to measure the impact of starting/stopping the GPY's LTE service. This had been running for two days without issue. Results being printed to the REPL with no data being stored.

As usual this was left overnight, running the test loop and was quite happy at 11:00pm but at 5:30am this morning I found the REPL screen showing rapid garbage. I use Atom, but was unable to stop this happening and after restarting Atom I tried to upload the current code again (several times) but got all sorts of strange information returned - to fast to capture it all. I closed Atom and thought perhaps a firmware update would resolve the issue.

I disconnected the USB and backup battery then set up the GPY/Exp by restoring all the jumpers and connecting G23 to Ground. I then connected via USB and made sure the Com Port was available.

Started Pycom Firmware Updater, reset the GPY and tried to 'upgrade' the firmware using 115200 baud and initially without Erasing Flash File System - this was returned:

Did some searching to confirm I had the upgrade - couldn't see any error in my procedure.
After several attempts, with and without the Erasing Flash File System but no change.

After closing the Updater I tried connecting to the GPY with Atom again, and now see this: :

repeating rapidly.

Closed Atom and confirmed the same response using Putty.

What is the problem, what else can I try? Or is this GPY bricked and I need to replace it (will probably go with a FIPY)? Any suggestions as to a cause (the same code with only comments removed, plus a lot more, has been included in the code and running happily in the prototype device - for an even longer period).

Any comments or suggestions would be gratefully received.

EDIT: So frustrating, I turned it all off and went for a walk with the dog! Sat down again on my return and put the GPY/Exp Board back to the configuration it should be, connected up USB and fired up Atom. A few odd things came up in REPL but ended with the >>> prompt. That looked promising! At the prompt I did a listdir('/flash') and noted a couple of unusual file names (like swear words out of comic speech bubbles). So I removed the ones I didn't recognise. Did the same with /flash/lib and removed 3 similar files.
Back at Atom Pymakr, I then uploaded the project again and thankfully it completed and is running again. So corrupted files would be my conclusion but how/why I don't know, I'll check UPS and other logs to see if there were any glitches but the other device was/is fine, on the same power setup.. Will it happen again - only time will tell. But at least I have a strategy for any repeats!

[robert-hh]

@stevo52 Yes, from the distance, it sounds like a hardware problem with the board. Maybe a broken wire or a bad solder point at the P2 pin.

[Stevo52]

@xykon I eliminated that scenario early on, the problem is the same with or without the SD Card. I removed the GPY from the expansion board and put it in a proto board (tried 3 different ones - different brands) and tried connecting with a USB to UART TTL RS232 cable - wire ends. That removed the expansion board completely but still no go as far as flashing goes but I can talk to the GPY and upload code files OK.

[Xykon]

@stevo52 Do you have anything else connected to the Expansion Board, especially on port P8? Do you have an SD card inserted in the expansion board?

[Stevo52]

@robert-hh Hi, a number of sensors on the I2C buses are powered from that 3.3V Output pin without issue.. confirmed it with a DMM as well just to be sure..

[robert-hh]

@stevo52 That's strange. I suggested that P2/GND connection to rule out any problem in the Expansion board. Since the RGB led works, there is no problem with the module-internal connection to GPIO2. Did you check, whether there is a 3.3v at the 3.3v output Pin of the GPY (next to GND)?

[Stevo52]

@robert-hh nearly missed this, it seems to be appended to my own reply to you..
"You could try to contact not at the expansion board, but directly at the module, top sort out any connection problems of the expansion boards.
Also, when the device is powered, pulling G23 low a few times should cause some flicker of the RGB LED. The led is too connected to G23/P2. If that does not happen, then there is a connection problem between the G23 pin and the module's internals.'

Soldered a wire on to this point, and also one from ground, to a switch but no difference in what I am seeing when they are connected. Repeated grounf of G23/P2 does not cause any flicker of the LED that I can see.

But I am curious why I even need the G23 to Gnd jumper - hasn't the PIC on Exp Bd 3 taken that requirement away?

Are there any 'error code' sequences produced on the Expansion Board 'batt' led? On occassions I am seeing a continuous series of short flashes, or a sequence of 6 ~ 8 short flashes, a 2 sec gap the short flashes again? Haven't found any reference to these.

[Stevo52]

@robert-hh That is where I have connected.You could try to contact not at the expansion board, but directly at the module, top sort out any connection problems of the expansion boards.
Also, when the device is powered, pulling G23 low a few times should cause some flicker of the RGB LED. The led is too connected to G23/P2. If that does not happen, then there is a connection problem between the G23 pin and the module's internals.

[robert-hh]

@stevo52 The pin which is labelled G23 on the expansion board and P2 in the pinout of GPy. It is the 4th pin from the edge at the opposite side of GND.

[Stevo52]

@robert-hh You advised to connect to G23, that is what I connected to GND at the Expansion Board? Double/triple checked many times. But there is a lot of confusion around module and Expansion Board pin assignments.. What pin (all associated pin ID's would help) on the Exp Bd 3. should I be connecting to GND?

[robert-hh]

@stevo52 G23 (Board) is the same Pin as P2 (Module). Are you sure you connected GND to the right Pin?

[Stevo52]

@robert-hh Hi again.. with G23 to Gnd and pressing reset:

So not the same as what you suggested I might see..

I can upload files to the GPY and those then run, but some other things happen - like the timer triggering twice at the same time and odd, mixed up thread ID numbers.. it feels like there are two copies of the same code running at the same time if that makes sense..

I tried esptool and also pycom-fwtool-cli (pretty much the same tool I think) but no luck with a full erase, or a firmware upload using either. I think I will have to get a replacement GPY/FIPY.. or try removing the uP from the expansion board and trying to flash etc, via an FTDI cable. Running out of ideas with this one.

[Paul Thornton]

@robert-hh said in Is my GPY Bricked??:

@stevo52 said in Is my GPY Bricked??:

Is it not possible to re-flash with the same version of firmware?

Older versions are available here as tar packages: https://software.pycom.io/downloads/GPy.html. The most recent versions are not. There was an indication that Pycom will change that.

Can confirm. How we deliver firmware files is something being actively worked on :)

[robert-hh]

@stevo52 I never had the case that re-flashing did not work after a full erase, unless there is a hardware problem. That can be at any place between the ESP32 chip and you PC. This "failed to connect" message tells, that the expected ESP32 response is not seen by the loader, which can be cause by many reasons. You could verify, that, when you connect G23 to GND and push reset, you get something like the following message in Atom or Putty:

rst:0x1 (POWERON_RESET),boot:0x23 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download

[robert-hh]

@stevo52 You can do so. Only the scope is different. _thread.get_ident() is called within the thread, while returning the thread ID when creating would return it to the creating task. So furher actions depend on where you need it.

[Stevo52]

@robert-hh OK, so I should use the _thread.get_ident() command instead?

[Stevo52]

@robert-hh Any pointers for doing this? If I do a full erase using esptool.py what will happen if I still have the same issues with the Pycom Firmware Update tool - next step will be a new FiPY?

[robert-hh]

@stevo52 said in Is my GPY Bricked??:

No thread ID is generated (returns 'None') for the _thread.start_new_thread

Yes, that matches the code. The documentation is wrong.

[robert-hh]

@stevo52 No, you cannot use esptool.py with Atom. It is a python script for the PC's command line. And I do not know whether it works on Windows.

[Stevo52]

@robert-hh It's odd that's for sure but I can't do any sort of flash using the Upgrade Tool. I did find the older firmware versions earlier today but can't flash those either :-)

I'll see what I can do with esptool.py but haven't used that before, can I run that from Atom?

I suspect I have an issue with the GPY. You might recall I have being testing timers and threads. I have encountered odd problems with those too.. using a simple set of codes, I am starting a new thread, which triggers a 15 sec timer, which in turn prints some details to the REPL.

In main.py:

# Start with importing required core modules etc.
import gc, audfuncs, cfgfuncs, hkpfuncs, netfuncs, rtcfuncs, senfuncs, pwrfuncs
import _thread
from utime import sleep

dosplthrd = 0                           # First Run of Base SLM thread

# # Next thread will run SLM sampling continuosly in background
if dosplthrd == 0:
    thrdSLM_id = _thread.start_new_thread(audfuncs.runaudSLM, ())
    if rvrb == 1: print("Initiate SLM Sampling",thrdSLM_id)
    dosplthrd = 1                 # SLM thread started

in audfuncs,py:

# Start with importing core modules for features, interfaces etc.
from pycom import rgbled
from utime import localtime, sleep, sleep_ms
import gc, uos, math, _thread
import cfgfuncs
from machine import I2C, Timer

class slmTMR:
    # Setup timer for collecting SLM data
    def __init__(self):
        self.cnttrg = 0
        self.__alarm = Timer.Alarm(self._slm_trig, 15, periodic=True)

    def _slm_trig(self, alarm):
        self.cnttrg += 1
        if rvrb == 1: print("SLM Sample", self.cnttrg, _thread.get_ident())
        audSLM()

def runaudSLM():
    runSLM = slmTMR()
    runSLM.__init__()

def audSLM():
    # Function to sample audio from mic/AGC via i2C adc, continuosly
    rgbled(0x0B0B0B)                            # Mid Red/Blue/Green
    # if rvrb == 1: print("SLM sample", slmtrg, _thread.get_ident())
    # add write to log file as activity record
    sleep(0.2)
    rgbled(0x000000)                        # Off

    return ""

Not overly complex I thought, but I get two funny results

1. No thread ID is generated (returns 'None') for the _thread.start_new_thread in main.py; but there is one (doesn't look right to me) in the audSLM print statement.

2. The slmTMR alarm returns the print statement twice in very close order then waits the set 15 seconds. There is an alarm counter in the slmTMR timer so I can see what is happening, there are no repeated numbers, so the alarm is actually triggering twice I think.

There might be more code there than I need, but I have been trying a few ideas to fix the issues. Note sure if you would have the time to run the code to confirm code/hardware issue? I don't have another GPY to try at the moment - will need to get one in next week if necessary (probably go with a FiPY if I need to). Hope there is enough info here.