ESP8266 Community Forum

- Thu May 07, 2015 1:30 pm #16825

A bit more tinkering, still no joy.

I can flash different boot loaders, 1.1 or 1.2, and this is reflected in the boot message on the device, so I know it's in flash mode and flash is capable of being written to.

2nd boot version : 1.2
SPI Speed : 40MHz
SPI Mode : QIO
SPI Flash Size : 32Mbit
jump to run user1

Fatal exception (0):
epc1=0x402015a4, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000


I carefully removed the shield to that I could verify parts underneath. It does indeed have a 4Mbyte (32mbit) flash device, so now I'm setting that in the size in the flashing tool, though it has made no difference (nor did I expect it to).

I'd really like to light this thing up, but nothing gets past the user load.

I have a 1K pullup on reset, 10K on CH_PD. 10K pulldown on GPIO15, Vcc on GPIO2 (though booting is indifferent if I leave it floating). Have a switch to ground GPIO0 for flashing. Supply is regulated 3.3V, measures slightly higher than that at the Vcc and GND of the module when powered up, so no indication that it's under too much of a load and dropping off (plus, I doubt the radio module is using much power if not initialized).

I can't see any errors. It may simply be broken.
As a final attempt: I had an ESP-03 that behaved a bit like yours. I ran over the solder joints with the iron as a last attempt before scrapping it, reflowing them all - and that was what it needed to start responding.

- Fri May 08, 2015 11:49 am #16918 Are you suggesting I reflow the ICs and capacitors/resistors themselves, or the contacts on the carrier board that connect it to my dev environ. I've already done the latter and the only way I'm likely to accomplish the former is hitting it all with hot air from my rework station, which frankly is likely to blow the 0402 and 0201 parts around, unless I go mask them with Kaptan tape.

Nevertheless, I hit the device with my rework. In one iteration, even removed the SPI and replaced it with another - I actually have the same model of 32Mbit flash new in a tube - and the device behaves exactly as before.

Frankly, it'd be nice if there was a flash tester load (seeing as the loader installed at 0x00000 runs fine) that could test a pattern written to the rest of flash, or if the flash tool were able to read the flash out to a file for comparison The flash operations are all being done via the ESP uC itself in the first place...

There's obviously a loader in the ESP device itself - is there any way to upgrade that?

- Sat May 09, 2015 2:51 pm #17024 I'm still at a total loss with this unit. I can flash the device without any errors being reported, If I flash the 512K blank image at 0x00000, when I boot, it doesn't hammer the Tx LED, just outputs:

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

ets_main.c

(this at 74880 baud)

I've tried different programming speeds, the same rig I'm using to program this chip has been used to successfully load NodeMCU to another device (so voltages, resistors, and FDTI are good).

It's as if the processor itself doesn't like the code.

Of the various images I have available, since none seem to work, but all seem to blow out with different exception addresses, I located one which has an object listing, figuring if I can locate the exception address in there when THAT load is running, I'll at least have a better idea of what might be going wrong (but bearing in mind that I've done absolutely NO coding on this processor complex and don't even have the cross compile toolchain installed). I loaded that imageset to the device and then booted it.

Here's the boot on a console:

Connected to COM11 at 74880 baud


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

load 0x40100000, len 612, room 16
tail 4
chksum 0x12
load 0x3ffe8000, len 788, room 4
tail 0
chksum 0x50
load 0x3ffe8314, len 264, room 8
tail 0
chksum 0x4a
csum 0x4a

2nd boot version : 1.1
SPI Speed : 40MHz
SPI Mode : QIO
SPI Flash Size : 32Mbit
jump to run user1

Fatal exception (0):
epc1=0x40211558, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000

(the exception just fires endlessly)

Would be nice to know what the "room" and "tail" are, and where the load address determination is coming from.


So, from at_v0.20_14_11_28\at_v0.20_on_SDKv0.9.3\bin\user1.S, we have the following context for that instruction pointer:

40211550: 2e28 l32i.n a2, a14, 8
40211552: ff .byte 0xff
40211553: 3f .byte 0x3f
40211554: fea750 excw
40211557: 3f .byte 0x3f
40211558: fffe61 l32r a6, 40211550 <wdt_init+0x2f0>
4021155b: fffe41 l32r a4, 40211554 <wdt_init+0x2f4>
4021155e: 050c movi.n a5, 0
40211560: 07b467 bgeu a4, a6, 4021156b <wdt_init+0x30b>
40211563: 004452 s8i a5, a4, 0
40211566: 441b addi.n a4, a4, 1

all of this is in the wdt_init function. I have NO sources for this to know what the C code would have been.

I referred to the Xtensa architecture manual, and L32R is "Load literal at offset from PC" In reading up on that instruction, I note the following : Unless the Unaligned Exception option is enabled, the processor does not handle misaligned data or trap when a misaligned address is used;

Sadly, the architecture manual does not appear to identify specific values associated with the different type of exceptions, so I have no idea what an exception 0 even is on this device.

Elsewhere, I located an Extensa Instruction Set Architecture manual, and in there I found a list of exception values:

0 IllegalInstructionCause Illegal instruction [Exception Option]

The instruction in the listing seems to be AT the offset, implying it wasn't say vectored into part way through an operand I don't get it.

Exception 28 seems to be another exception that pops up in some threads I've read, though is not what I'm running into here:

28 LoadProhibitedCause A load referenced a page mapped with an attribute that does not permit loads [Region
Protection Option or MMU Option]


I'd like to get this device working - it seems so wonky that I can clearly re-flash, but there's something wrong in the initialization. I'm extremely leery of ordering more when #1 out the box is crap.


Refs:
http://ip.cadence.com/uploads/pdf/xtens ... ndbook.pdf
http://0x04.net/~mwk/doc/xtensa.pdf

- Sun May 10, 2015 3:04 am #17060 I have these errors on my esp12 - annoying, cannot run anything

But I can burn everything to it