Unable to connect to the Raspberry Pi Zero W

Hi @calischs

@akaspar and I have been trying to program the Raspberry Pi Zero W following your tutorial for the past few days but we are unable to SSH into it from our Macbooks or the lab Linux computers. We've tried to disable the authentication (turning off the fields that require passwords and reject empty passwords) and we've also tried to generate a public key to prevent it from rejecting our access attempts but we haven't been successful.

Do you have some time tomorrow to help us in lab?

Thanks!

So, we found a way to connect to the pi by bypassing authentication using public-private keys which we had inserted from the ext4 partition on the sdcard.

We are now trying to install openocd. We had to share the computer's connection and that seems to be working right now per your suggestion.

Hi there, Are you using one of the kits I prepared, or starting from a fresh install?

If so, you should be able to ssh using the login credentials I wrote on the sd card case, simply by plugging in a usb cable to the usb port (not the power port!). Unless I'm forgetting, these kits included regular Pi Zeros (not with wifi). You also won't need to install openocd because I did this already on those SD cards.

If not, it's hard for me to debug your connection, but you can follow one of the guides online. Usually, easiest is just plugging in a monitor and keyboard to grab the IP address.

sam

We just realized that the password was written on the SD card case, which explains why the common/default password we found on the internet didn't work. We also didn't know that the SD card had been pre-programmed... Sadly, I think we overwrote the card so we are having to redo all of your steps from scratch.

@calischs Can you give us the backup SD card file that you made in case we do it wrong?

Patching and building openocd can take quite a while -- I'd focus your efforts for this week elsewhere or borrow another one of the kits (I believe Tomas is working with the nrf52 right now in E15). I'm happy to give you a new sd card tomorrow.

The sd card image is 4gb -- too big to post here.

I think we successfully reprogrammed the SD card. Trying to load openocd.cfg onto the NRF52 rn

We got the output below from openocd:

pi@raspberrypi:~/nrf52/openocd $ sudo openocd
Open On-Chip Debugger 0.10.0+dev-00169-ge760ac88 (2017-12-05-00:43)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
BCM2835 GPIO config: tck = 11, tms = 25, tdi = 10, tdo = 9
adapter speed: 10000 kHz
cortex_m reset_config sysresetreq
BCM2835 GPIO nums: swclk = 25, swdio = 24
BCM2835 GPIO config: trst = 7
BCM2835 GPIO config: srst = 18
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : JTAG and SWD modes enabled
Info : clock speed 4061 kHz
Info : SWD DPIDR 0x2ba01477
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* nrf52.cpu          cortex_m   little nrf52.cpu          running
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x000008e4 msp: 0x20000400
Warn : Unknown device (HWID 0x000000e3)
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
** Programming Started **
auto erase enabled
Info : Padding image section 0 with 1692 bytes
Info : Padding image section 1 with 362808 bytes
Warn : using fast async flash loader. This is currently supported
Warn : only with ST-Link and CMSIS-DAP. If you have issues, add
Warn : "set WORKAREASIZE 0" before sourcing nrf52.cfg to disable it
Warn : Adding extra erase range, 00000000 to 0x00000013
Warn : using fast async flash loader. This is currently supported
Warn : only with ST-Link and CMSIS-DAP. If you have issues, add
Warn : "set WORKAREASIZE 0" before sourcing nrf52.cfg to disable it
wrote 499948 bytes from file feather52_bootloader_v050_s132_v201.hex in 9.037545s (54.022 KiB/s)
** Programming Finished **
** Verify Started **
verified 133376 bytes in 0.600548s (216.885 KiB/s)
** Verified OK **
shutdown command invoked

Does it seem fine? There's something about ST-Link which we don't understand, and it's mentioned as "unknown device".

Also, the LED was lit up and is now stopped.

That looks great! Looks like you didn't overwrite the sd card after all? What was the change?

Not sure which LED you're talking about. On the Pi or on your target board?

We did overwrite the card but we went through the whole downloading and make process that you detailed here: https://gitlab.cba.mit.edu/pub/hello-world/nrf52/blob/master/openocd/RaspberryPi.md

Now it seems to work...

The LED on the target board stopped lighting up after the programming finished. Should we be concerned?

Currently we are trying to load the INO code from https://gitlab.cba.mit.edu/pub/hello-world/nrf52/tree/master/modules/uarte with some help from instructions here: https://github.com/sandeepmistry/arduino-nRF5 but we're not sure how to actually program the target board via FTDI. Is there somewhere you can point us to for detailed instructions?

I feel like although we used the hex file of a feather board, our board is quite different, isn't it? Does it correspond to any "standard" board we can use to program with Arduino? Or are there specific instructions for programming it somewhere?

Once you've successfully flashed the feather52 bootloader, from Arduino's perspective you are programming it just as you would the feather52. That means you can plug in an ftdi cable, select that port in arduino, compile code for the feather52, and program your board. You need to hold and release the reset button on your board. This puts it into a mode to be programmed for about a second. Getting the timing right can be tricky at first.

Note, you'll need to install adafruit's libraries for Arduino first: https://learn.adafruit.com/bluefruit-nrf52-feather-learning-guide/introduction

I would not start with uarte. Start with a simple sketch using Arduino's Serial object to say hello. :)

@natalie, not sure about the led -- it shouldn't be lit unless you've told P27 to be driven low... It's this board, right? https://gitlab.cba.mit.edu/pub/hello-world/nrf52/blob/master/bc832-ftdi/bc832-nrf-ftdi-fab-layout.png

Yes it's that board. Regardless of the LED, my board was successfully programmed by the Raspberry Pi and then the LED stopped lighting up, so maybe that's ok...

With respect to the reset button timing: when should we start pressing it? And what should we see upon release? We don't see a difference pressing the button or not :/

You'll want to press the button to reset the chip, then release it just before the chip is getting programmed. So, I like to release it as the last compilation related printouts happen, just before the programming related printouts start. Did you see me do this in recitation last week?

Happy to keep helping, but I need more detail. What code are you flashing? Are the Port and Board set correctly? What does the output say?

We were able to successfully program it with the basic hello world script without touching the button!

Thanks for all your help Sam!

We did have to press the button to program using SPI.ino after the "Upgrading the target..." text though

closed