ESP IoT pHAT problems


#1

Hi
Im having some annoying issues with my new ESP iot pHAT
when i try to go minicom to use the AT commands im no longer able to type in the main window, i can press CTRL-A Z for help, and change stuff there but not type anything in main window, i tried enable echo ctrl+a e but after typing AT hitting enter it just go to new line, so ctrl + j is ineffective.
all this began after i followed a tutorial on making #16 high in the pHAT, i cant go make it low again :(

flashing firmware results in error Invalid head of packet (’\x04’)
Help is greatly appreciated :)

pi@PiZERO:~/Pimoroni/espiotphat/firmware $ ./flash-mp-firmware.sh

mp-esp8266-firmware-latest.b 100%[===============================================>] 495,68K 625KB/s om 0,8s

2016-07-19 09:55:46 (625 KB/s) - ‘mp-esp8266-firmware-latest.bin’ gemt [507576/507576]

Chip is in write mode
Erasing flash
esptool.py v1.1
Connecting…
Erasing flash (this may take a while)…
Chip is in write mode
Writing flash
esptool.py v1.1
Connecting…
Running Cesanta flasher stub…

A fatal error occurred: Invalid head of packet (’\x04’)
Chip has been reset
pi@PiZERO:~/Pimoroni/espiotphat/firmware $


#2

What happens if you try to flash the AT firmware back by running the

flash-at-firmware.sh

… when I get to the lab I’ll check that the current MP night build causes no issue but that’s a possibility.

other than that, pin16 does not have any particular significance unless it is bridged to the reset pin for deep sleep function. It’s more likely you set pin 15 high, which may lead to some undesirable side effects (partly why it’s not broken out on the pHAT)?

Edit: MP night build works here, though your download speed is considerably higher than mine, perhaps something is getting messed up in the download process?


#3

i tried downloading fw from adafruit micropython and unzipping it to be flashed, its the same issue. i edited the flash-at-firmware.sh # out the part where it downloads and deletes, to use the one it already have in the directory, its the same issue.
what bugs me is it fact that i had a working minicom where i enabled the #16 to turn on a LED, that LED is now always on, and only turns off when i power off the pi, and i cant disable the pin since minicom wont take my AT commands :(


#4

hum, it sounds like you don’t have the latest repo firmwares, there is no need to edit anything in the AT firmware script, we supply the exact same one as we ship currently and no download is taking place.

So run:

curl https://get.pimoroni.com/iotphat | bash

and say yes when asked to replace resources.

… it could be the timing in fact. I added some pauses to avoid choking one of my ESP8266, which was timing out much more easily than the others.


#5

another thing that comes to mind though is: how are you powering your Pi Zero? if you are starving your Pi+ESP then it’s quite possible that some pins state can’t quite be set ‘high’. This would certainly lead to a bunch of issues.


#6

i tried the curl and replaced all files, im running my zero on a 5v2A powersupply, still no luck :(
i would like to reset the pin manually is that possible when i cant type anything in minicom?
Edit: im using OSX-terminal connecting to 192.168.1.5 (my wifi usb dongle) i dont know if its the reason? i can see you
made the guide in the pi desktop, i now tried log on desktop and open a terminal but its the same ting.


#7

… if you are sure that you did not enforce a state on pins that are not broken out on the pHAT I’m not convinced your issue is of that nature. There’s really is no reason you’d end up with such issues by merely toggling pin16 in any case.

Instead I’m thinking that maybe your soldering came loose (either on the pHAT or the zero header). What is the board activity like when you attempt to flash the board?

EDIT: to be sure I just tried flashing over the network through ssh, as expected that was not a concern with a couple of boards.


#8

When i flash it, the FirmWare LED blinks several times and all looks okay in terminal untill it pops at the end and tells the invalid head of packet (’\x04’) error…

what i did was i followed the Polling I/O values via serial part of your tutorial.
first
AT+CIOADC it worked!!
then
AT+CIOREAD=16 it worked too, LED is on

i took a break and when i wanted to log back in minicom i couldn’t type anything…
solderings still look ok on both the pi and the pHAT.
could i have bricked the board or something?
im thinking about trying plugging one of my esp8266 chips on a breadboard and test if thats different
_EDIT: i trested program PICOCOM and its the same problem :(
pi@PiZERO:~ $ picocom /dev/ttyAMA0 –emap crcrlf
picocom v1.7

port is : /dev/ttyAMA0
flowcontrol : none
baudrate is : 9600
parity is : none
databits are : 8
escape is : C-a
local echo is : no
noinit is : no
noreset is : no
nolock is : no
send_cmd is : sz -vv
receive_cmd is : rz -vv
imap is :
omap is :
emap is : crcrlf,delbs,

Terminal ready
_


#9

right, but you must use a baud rate of 115200, 9600 won’t work I would suspect.
What happens if you use

minicom -b 115200 -o -D /dev/ttyAMA0

… I can’t explain why you can’t reflash though, that should work, unless you use a different baud rate that might not be suitable for the job.

EDIT: at this point it’s quite likely your chip is blank with no firmware though, so I guess whether that was the problem initially is a moot point.


#10

Same happens with 115200b i cant type anything :(
if the chip is blank the resets wiped out the firmware i guess, and since i cant upload new, i cant use it
i see the esp-07 chip looks like the one on the pHAT, and that one can be flashed trough arduino IDE, would that
be possible with the pHAT? rx + tx + gpi0 gnd trough a resistor like on the picture:


#11

The pHAT uses a ESP-12 and is wired appropriately for flashing, exactly like what’s pictured there.

There is no reason you couldn’t wire a button to force a reset, but the output of the flash script indicates it is all working fine, otherwise the first half, which erases the chip, wouldn’t work.

Again, my feeling is that your chip is timing out, and that usually occurs in low stability power situation. But you already confirmed you are using an adequate PSU… well I assume you’re not using a phone charger or something like that, but a proper official PSU.

What you can do is increase the sleep times from 1 to 2-5 seconds in the flash script and see if that helps. You can also separate the erasing and flashing steps - the former is not necessary at this point where I believe your chip is blank.

If all fails, then you can shoot support an email and we’ll exchange the board, though bricking a ESP8266 while not impossible would be very hard to do. That said there’s a bunch of pins that can lead to either permanent boot mode, or difficulty entering it, neither of which I think is your problem.


#12

i test another psu 5v 3A that i use to drive my pi3 OSMC, and set sleep to 5 sec in the flash script and it still make the error :(

Chip is in write mode
Erasing flash
esptool.py v1.1
Connecting…
Erasing flash (this may take a while)…
Chip is in write mode
Writing flash
esptool.py v1.1
Connecting…
Running Cesanta flasher stub…

A fatal error occurred: Invalid head of packet (’\x04’)
Chip has been reset


#13

Are you able to post a picture of your setup? … perhaps it will spark a further thought, but otherwise I’m out of ideas I’m afraid :(


#14

I tested the setup at the tv by hdmi and did take some pictures, m not sure thats what you requested?


#15

right, I have found what the problem is. The baud rate used by the flash script is too demanding for the zero. Just replace -b 460800 by -b 115200 and you should be able to refhash a firmware on the ESP!

I am going to change the script to avoid this in the future and set a safer rate for all potential hardware… it will take a bit longer on other hardware but hopefully nobody else will fall for that one again.

Sorry, I should have caught that one and test on a zero when you first reported, it just wasn’t clear that an initial attempt flashing firmware was when you first ran into trouble. Well, either that or somehow your original firmware got corrupt, but that hasn’t happened to me so I can’t comment on whether that’s a likely cause.


#16

you are so awesome man… :D
it is alive

tested flashing MP and AT firmware
can type commands in minicom and all works :D

esptool.py v1.1
Connecting…
Running Cesanta flasher stub…
Flash params set to 0x0020
Writing 512000 @ 0x0… 512000 (100 %)
Wrote 512000 bytes at 0x0 in 44.4 seconds (92.3 kbit/s)…
Leaving…
Chip has been reset


#17

Flashed MP
can you point me in the right direction?

it pings and i can open ws://192.168.1.250:8266
and high/low a LED
but i can’t open SSH or VNC on the ip address, only with my usb wifi in.


#18

You mean to access the Pi? that’s not really the idea of the ESP8266 pHAT… what are you trying to do?


#19

i wanted to try use the hat as network connection, is tcp/ip connection possible ? i read somewhere that it cant replace a usb because of lower transfer speed, but they didnt say its impossible to do :D


#20

No, it’s not impossible to do but the ESP IoT pHAT link to your Pi is over the UART interface solely, for programming and data logging or processing. In other words, as noted on the product page, it’s not a WIFI adapter replacement.

For that you’d need to interface with the Pi differently - an entirely different approach for a product. Fortunately (or unfortunately for your wallet) such a product exists: https://www.tindie.com/products/ajlitt/wifi-power-pants/

The project that led to its existence can be found here: https://hackaday.io/project/8678-rpi-wifi … there’s even instructions on how to build such a WIFI bridge yourself, but it’s not for the faint of heart.

Good luck!