search

sbcshop / PiSquare

PiSquare is an RP2040 and ESP-12E-based board that allows you to use multiple Raspberry Pi HATs without stacking them on top of one other. PiSquare uses Socket programming to wirelessly communicate multiple Raspberry Pi HATs ("n" numbers of HATs).
MIT License
25 stars 5 forks source link

Unable to PiSquare into boot mode (BOOTSEL). #14

Open JDTucker-5696 opened 1 year ago

JDTucker-5696 commented 1 year ago

I have five PiSquares, and two RP2040 HAT Expansions, which all act the same. I have tried to put them into BOOTSEL mode to load my own code, but none of them will enter BOOTSEL mode and show up as . I have tried the 'boot' and 'reset' switch combo, the 'boot' switch and power-on combo, as well as 'picotool reboot', all to no avail. I must be missing something. Can anybody help?

JimT

sbcshop1 commented 1 year ago

Boot mode is for inserting firmware. already micro python there in this hardware. For boot, Press the boot button then connect the USB, don,t release the button until you connect the USB to the laptop. then you see a new device named "RPI-RP2" drag this file "firmware.uf2" to this device. did you do this?

JDTucker-5696 commented 1 year ago

Yes, I did exactly that. As I said, I also tried the 'reset' and 'boot' switch combo. I have other RP2040-based boards on which these procedures function as expected, so I DO know the proper technique. It is only the PiSquares and RP2040 HAT Expansions which won't go into BOOTSEL mode, and appear as a file system (device) named "RPI-RP2". I should note that all the boards behave as expected if I connect them with Thonny, or even minicom, i.e., micropython works, I can write trivial scripts which work as expected (e.g., 'blink'). I can also reboot the device using picotool. While I don't develop on Windows, I have tried this on such a machine, with the same results. (Note: I'm using Raspian Buster on a Pi4 as a development platform, with VSCode and Thonny as IDEs. While I am not new at programming or hardware development (started with the Intel 8008), I am new to Python (Don't care much for interpreted languages).)

JimT

misel228 commented 1 year ago

This is odd. I have a few PiSquares myself and they work as (you and I) expected.

If this also happens when connecting to the Raspberry Pi - assuming you run Raspian - can you please post an excerpt of /var/log/syslog at the time you connect the PiSquare? Ideally, once with pushing BOOTSEL and once without.

The latter should show the connection of a new serial device and the former of a USB mass storage device.

JDTucker-5696 commented 1 year ago

misel228; Thanks for the pointer; I don't usually delve that deeply into the gut of the OpSys. You are right - Raspian. devices-65-68.txt Here is the excerpt you asked for. Device 65 is one of PiSquares, connected without boot. Device 66 is the same unit (as you can see), but with the boot button pressed. For the sake of contrast, device 67 is another board (non-SBC RP2040-based board), using the same sequences (non-boot (device 67) and boot (device 68)), which responds as expected ( I've never actually watched that process before: Thanks again for the pointer!). To me, it looks like the boot switch is not working, or not being sensed. Can't tell which ATM. I'll have to check that the switch is working. I REALLY did not expect a hardware problem across all six of the SBC boards I have!

Must dig deeper...

JimT

misel228 commented 1 year ago

I just went to check one of my boards to compare it with your logs. I tried to mount it and the same thing happened to me, too. :smile: But it was only temporary it worked the second try, and the third and the forth...

The buttons are a finicky and I really had to use my finger nail to make sure to hear and feel the click and that it stayed that way when I inserted the cable. But I assume you already tried that.

If it's really a hardware issue you should be able to detect a faulty button with a multimeter. Or you create the short with flat headed tweezers around the button.

Finally, one thing I noticed in your log, the device manufacturer is listed as "Manufacturer: MicroPython" (see line 5). As far as I can tell, this is a device description directly from the device. That means that at some point MicroPython was successfully installed. I'm not sure, but I don't think they came shipped with MicroPython.

But this also means that it is probably already up-to-speed. Have you tried connecting to it with "Thonny". That's IMHO the best IDE for coding in MicroPython.

Ignore the last paragraph. It appears as if all fresh boards are detected like this.

JDTucker-5696 commented 1 year ago

misel228; "Great minds..." Yes, multi-meter time! I checked the pull-up resistors (1K / 10K to 3v3 in the SBC design. Pico has the 10K as a no-pop.) continuity to the switch (good), and to the other side (ground? should be, but I don't have a schematic of the PiSquare) of the switch (good when pressed). Two odd things. (1) Right after I read your post, I tried again, and pressed REALLY hard. It made it into BOOTSEL, as it should have, contrary to ALL previous trys! Next attempt, and all subsequent, FAILED! (2) The voltage at the top of the switch, when open is as expected, 3v3 or so, but when the switch (which itself seem quite reliable, even without much pressure, as long as I get the click) is activated, it only drops to 3v1 or so, not the 0v0 I would expect. Way too high to be detected as a logic low. I am looking through the boot code ATM, looking for where it looks to decide to go into BOOTSEL mode, but I haven't found it yet. A cursory glance at the QSPI_ registers suggests it should be readable through software.

My hardware hat is telling me that there may be a faulty via, or bad solder joint on the path from the bottom of the switch to QSPI_SS. As I understand it, the QSPI_SS pin (RP2040) and to the CS/ pin (flash), so there should be some way to read the current status...

(Time goes by, as I poke around with a DMM...) I'm beginning to think that the switch got contaminated during production: It is now operating reliably, according to the DMM. Good solid ground, as many times as I have tried it. I'll have to exercise the other boards to see what happens.

Thanks again for the help!

JimT

JDTucker-5696 commented 1 year ago

@sbcshop1 I think you may have a production problem. Specifically, all six of my SBC devices (see my first message) have or have had a problem with the boot switch apparently not making internal contact without many cycles being applied, and/or being subjected to contact cleaner. ireally do not expect that the problem is isolated to my six devices.

JimT

sbcshop1 commented 1 year ago

Hello, We are sorry for your experience. It could be a manufacturing issue. We will get all the pieces replaced. In the meanwhile, kindly try to troubleshoot by pressing the button several times. Sometimes, if not in use for a long period, the buttons may develop some rust on the inside. Regards, Team Support

JDTucker-5696 commented 1 year ago

@sbcshop1 Thanks for your response. Three of my boards have responded positively to repeated pressing of the boot switch (permitting me to get back to what I was pursuing prior to this side-quest), though requiring many hard activations (100+), slowing getting better and better, but still erratic. Contact cleaner seems to be effective (though messy), suggesting your rust theory is reasonable. I'll proceed on that basis, and work on the other three boards.

I'll keep you apprised.

JimT

JDTucker-5696 commented 1 year ago

@sbcshop1 Now that I have returned to my chosen path, which was running an SBC LCD HAT directly on a PiSquare, I discover that the tactile switches on it exhibit the same problem as on the PiSquare itself, i.e., only one switch actually makes the contact, and that one does so quite erratically. The other three don't make contact at all. I will note that I can hear the click, and feel the break-over, whether or not the switch actually makes the contact. The joystick, however, seems quite reliable in all of its five sets of contacts.

JimT