These are chat archives for esp8266/Arduino

1st
May 2015
Ivan Grokhotkov
@igrr
May 01 2015 00:15
@ficeto it all boils down to how you will be building the code that will be uploaded
if this code needs to use lwip and other sdk libraries (directly or through wrappers), the linker needs to know where they are located in memory while building this plugin code
also if you have local or global variables in your uploaded code, these variables need to be placed somewhere in data ram. but data ram layout will not let you do this easily: first you have .data, .rodata, and .bss of your "loader" app
then you have the heap initalized by the loader app
you could get some space for sketch variables from the heap, but the problem is that you don't know the address range you will get from the heap beforehand, at link time
this issue is normally solved by introducing relocation tables
Ivan Grokhotkov
@igrr
May 01 2015 00:20
and you need a relocation table for the code as well
this is normally solved by the dynamic linker
so putting some stuff into flash memory over web of ftp interface is easy
the difficult (although completely tackable) part is being able to link the code that will actually run, while being able to use lwip and other libraries which are part of the "loader"
the "easy" way is to allocate a fixed amount of RAM for the plugin code and fixed amount of RAM for the "loader" but i don't like this approach as it is not really flexible
Ivan Grokhotkov
@igrr
May 01 2015 00:26
also if you duplicate the SDK libs — have one copy for the "loader" and one copy for the "plugin" then things become trivial
but we don't have that much flash, at least on 512K devices
so, i have part of the dynamic loader implemented, but the relocation handling needs some debugging. i didn't have time to do that yet...
Ivan Grokhotkov
@igrr
May 01 2015 01:18
@ficeto re ASCIITable sample: pulled your changes, still it runs okay for me without any modifications to the code.
things to check: i see you have removed GPIO initialization from initPins — you only initialize the interrupts. perhaps the RTS/DTR pins are not pulled up on your board, and they cause the output to stop? just an idea to check... btw i will add the GPIO initialization back if you don't mind.
Ivan Grokhotkov
@igrr
May 01 2015 01:36
also gpio interrupts seem to be broken (you are passing interrupt_handlers to ETS_GPIO_INTR_ATTACH instead of interrupt_handler — and tries to execute the code from data ram:
Fatal exception (2):
epc1=0x3ffe8f7c, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3ffe8f7c, depc=0x00000000
Ivan Grokhotkov
@igrr
May 01 2015 03:57
@ficeto merged
todo: update Readme to mention analogWrite, SD, new SPI
and update the i2c-related issues as resolved
ficeto
@ficeto
May 01 2015 09:08
oops :)
must have done this when I was renaming things base on a comment you had in the repo
no worries add the gpio initalization (do you mean the actuall init_gpio() call?)
I have branched my fork to have a "different-serial" thing. Take a look at it, as that does not have the issues and deals with the same GPIOs and all. I thing I do set more registers on init, which chould lead to my shit working better than yours... but not sure really. Branched it for that reason
ficeto
@ficeto
May 01 2015 09:18
when you described in your lengthy explanation on loading/reloading app over the wifi, you stressed on things I have been thinking about. Maybe only full reflash is a viable and safe option. I was thinking of maybe having small part of the code run as "bootloader-like" but actually being on there, that all it does is open a port for communication and do flashing like through the serial, but over network socket. That should not take much and can be running in background, then have a exptool handle that for uploads.
ficeto
@ficeto
May 01 2015 09:25
I saw you removed the bool(void) NotFoundHandler. Maybe you should have left it there as such. Maybe not... debatable :)
ficeto
@ficeto
May 01 2015 10:10
@igrr I think you might be on the right track about the gpio<->serial thing
now that you init the GPIO pins, the serial kicks the watchdog on begin
ficeto
@ficeto
May 01 2015 12:30
I tracked it down to GPIO3, which needs to be in mode for U0RXD
any other case leads to watchdog fail
here is how the pins are set after calling gpio_init()
except pin 2 which I use for devug output
GPIO0, EN: 0, OUT: 0, IN: 0, IE: 0, I: 0, WE: 0, D: 0, S: 0, FS: 0, PU: 1, SOE: 0, SS: 0, SPU: 0
GPIO1, EN: 0, OUT: 0, IN: 0, IE: 0, I: 0, WE: 0, D: 0, S: 0, FS: 0, PU: 0, SOE: 0, SS: 0, SPU: 0
GPIO2, EN: 0, OUT: 0, IN: 0, IE: 0, I: 0, WE: 0, D: 0, S: 0, FS: 2, PU: 0, SOE: 0, SS: 0, SPU: 0
GPIO3, EN: 0, OUT: 0, IN: 0, IE: 0, I: 0, WE: 0, D: 0, S: 0, FS: 0, PU: 1, SOE: 0, SS: 0, SPU: 0
GPIO4, EN: 0, OUT: 0, IN: 1, IE: 0, I: 0, WE: 0, D: 0, S: 0, FS: 0, PU: 0, SOE: 0, SS: 0, SPU: 0
GPIO5, EN: 0, OUT: 0, IN: 0, IE: 0, I: 0, WE: 0, D: 0, S: 0, FS: 0, PU: 0, SOE: 0, SS: 0, SPU: 0
GPIO12, EN: 0, OUT: 0, IN: 0, IE: 0, I: 0, WE: 0, D: 0, S: 0, FS: 0, PU: 1, SOE: 0, SS: 0, SPU: 0
GPIO13, EN: 0, OUT: 0, IN: 0, IE: 0, I: 0, WE: 0, D: 0, S: 0, FS: 0, PU: 1, SOE: 0, SS: 0, SPU: 0
GPIO14, EN: 0, OUT: 0, IN: 0, IE: 0, I: 0, WE: 0, D: 0, S: 0, FS: 0, PU: 1, SOE: 0, SS: 0, SPU: 0
GPIO15, EN: 0, OUT: 0, IN: 0, IE: 0, I: 0, WE: 0, D: 0, S: 0, FS: 0, PU: 1, SOE: 0, SS: 0, SPU: 0
so only 0,4 and 5 are GPIOs after that
12-15 are pulled-up in debug mode
1 and 3 are in UART mode
2 ... I'm unsure but setting it to whatever does not matter anyway before calling the uart_begin
doing what you do to initialize them (setting as inputs) works fine on all but GPIO3 and here is such output (except pin2 again)
GPIO0, EN: 0, OUT: 0, IN: 0, IE: 0, I: 0, WE: 0, D: 1, S: 0, FS: 0, PU: 0, SOE: 0, SS: 0, SPU: 0
GPIO1, EN: 0, OUT: 0, IN: 1, IE: 0, I: 0, WE: 0, D: 1, S: 0, FS: 3, PU: 0, SOE: 0, SS: 0, SPU: 0
GPIO2, EN: 0, OUT: 0, IN: 0, IE: 0, I: 0, WE: 0, D: 0, S: 0, FS: 2, PU: 0, SOE: 0, SS: 0, SPU: 0
GPIO3, EN: 0, OUT: 0, IN: 0, IE: 0, I: 0, WE: 0, D: 0, S: 0, FS: 0, PU: 0, SOE: 0, SS: 0, SPU: 0
GPIO4, EN: 0, OUT: 0, IN: 1, IE: 0, I: 0, WE: 0, D: 1, S: 0, FS: 0, PU: 0, SOE: 0, SS: 0, SPU: 0
GPIO5, EN: 0, OUT: 0, IN: 0, IE: 0, I: 0, WE: 0, D: 1, S: 0, FS: 0, PU: 0, SOE: 0, SS: 0, SPU: 0
GPIO12, EN: 0, OUT: 0, IN: 1, IE: 0, I: 0, WE: 0, D: 1, S: 0, FS: 3, PU: 0, SOE: 0, SS: 0, SPU: 0
GPIO13, EN: 0, OUT: 0, IN: 1, IE: 0, I: 0, WE: 0, D: 1, S: 0, FS: 3, PU: 0, SOE: 0, SS: 0, SPU: 0
GPIO14, EN: 0, OUT: 0, IN: 1, IE: 0, I: 0, WE: 0, D: 1, S: 0, FS: 3, PU: 0, SOE: 0, SS: 0, SPU: 0
GPIO15, EN: 0, OUT: 0, IN: 0, IE: 0, I: 0, WE: 0, D: 1, S: 0, FS: 3, PU: 0, SOE: 0, SS: 0, SPU: 0
This message was deleted
ficeto
@ficeto
May 01 2015 12:47
@ig
@igrr FOUND IT!
need to disable UART interrupt bits
U0IE = 0; did the trick
Iguess on boot espressiv enables them and if left enabled... we go down
Markus
@Links2004
May 01 2015 12:50
may you shut then call system_set_os_print(0); also to disable the serial usage from system stuff
ficeto
@ficeto
May 01 2015 12:51
did not work by itself
had to clear the INT bits
Markus
@Links2004
May 01 2015 12:52
yes but if you only do the U0IE the the system still try to use the uart
ficeto
@ficeto
May 01 2015 12:53
did :) how to refference a coomit?
Markus
@Links2004
May 01 2015 12:53
simply paste the full git url
ficeto
@ficeto
May 01 2015 12:55
ficeto/Arduino@9ec5d20
thanks :)
Markus
@Links2004
May 01 2015 12:57
does calling cpp Serial.end(); Serial1.end(); the same ?
ok add missing Links2004/Arduino@28a868d
uart_set_debug(UART_NO); call
Ivan Grokhotkov
@igrr
May 01 2015 13:01
okay so why did this fail on your side and didn't fail on my side again?
ficeto
@ficeto
May 01 2015 13:01
you sure it didn't fail? this is ater adding the setMode(INPUT for all pins)
and maybe if you use Serial1 like I do it will
ecause issue is in serial0 int
Markus
@Links2004
May 01 2015 13:03
it fails if Serial.begin is not called
ficeto
@ficeto
May 01 2015 13:05
how you pull down a ping? other than GPIO16?
ok I see it
was issing the register bits
Ivan Grokhotkov
@igrr
May 01 2015 13:06
It didn't fail before I added setMode(INPUT), after that I didn't try.
And I used Serial — just the example sketch with no modifications.
ficeto
@ficeto
May 01 2015 13:16
Yes it could have worked, because you used Serial in that sketch
using Serial1 or not using Serial at all will cause it
has nothing to do with your or my Serial implementation
Ivan Grokhotkov
@igrr
May 01 2015 13:21
Ah, okay, so you weren't using the unmodified sketch after all :)
This is clear now. Will clear the interrupt in the early init procedure.
ficeto
@ficeto
May 01 2015 13:32
it's already in the git :)
just need to pull it
and to explain I only change from Serial to Serial1
because I have a bluetooth adapter on Serial1 and it's always on my screen
then my "program" button is always on as well
no need to open console and reset the device to see results
BUT it does not matter which Serial number I use, the ASCIITable with all default and just yield added still shows half the result with your HardwareSerial...
Markus
@Links2004
May 01 2015 13:36
i also use Serial1 for all the debugging output same reason ;)
Ivan Grokhotkov
@igrr
May 01 2015 13:41
Okay, so then it's not clear why it doesn't work with Serial on your side and works on my side (no yield as well — didn't make any changes to the sketch).
ficeto
@ficeto
May 01 2015 13:43
Tested again with all new stuff
same result
changes to sketch:
bitrate 115200
Serial -> Serial1
continue -> yield()
output:
load 0x40100000, len 29060, room 16 
tail 4
chksum 0xc8
load 0x3ffe8000, len 2404, room 4 
tail 0
chksum 0xee
load 0x3ffe8970, len 1664, room 8 
tail 8
chksum 0x9c
csum 0x9c
RT.ASCII Table ~ Character Map
!, dec: 33, hex: 21, oct: 41, bin: 100001
", dec: 34, hex: 22, oct: 42, bin: 100010
#, dec: 35, hex: 23, oct: 43, bin: 100011
$, dec: 36, hex: 24, oct: 44, bin: 100100
%, dec: 37, hex: 25, oct: 45, bin: 100101
&, dec: 38, hex: 26, oct: 46, bin: 100110
', dec: 39, hex: 27, oct: 47, bin: 100111
(, dec: 40, hex: 28, oct: 50, bin: 101000
), dec: 41, hex: 29, oct: 51, bin: 101001
*, dec: 42, hex: 2A, oct: 52, bin: 101010
+, dec: 43, hex: 2B, oct: 53, bin: 101011
,, dec: 44, hex: 2C, oct: 54, bin: 101100
-, dec: 45, hex: 2D, oct: 55, bin: 101101
., dec: 46, hex: 2E, oct: 56, bin: 101110
/, dec: 47, hex: 2F, oct: 57, bin: 101111
0, dec: 48, hex: 30, oct: 60, bin: 110000
1, dec: 49, hex: 31, oct: 61, bin: 110001
2, dec: 50, hex: 32, oct: 62, bin: 110010
3, dec: 51, hex: 33, oct: 63, bin: 110011
4, dec: 52, hex: 34, oct: 64, bin: 110100
5, dec: 53, hex: 35, oct: 65, bin: 110101
6, dec: 54, hex: 36, oct: 66, bin: 110110
7, dec: 55, hex: 37, oct: 67, bin: 110111
8, dec: 56, hex: 38, oct: 70, bin: 111000
9, dec: 57, hex: 39, oct: 71, bin: 111001
:, dec: 58, hex: 3A, oct: 72, bin: 111010
;, dec: 59, hex: 3B, oct: 73, bin: 111011
<, dec: 60, hex: 3C, oct: 74, bin: 111100
=, dec: 61, hex: 3D, oct: 75, bin: 111101
>, dec: 62, hex: 3E, oct: 76, bin: 111110
?, dec: 63, hex: 3F, oct: 77, bin: 111111
@, dec: 64, hex: 40, oct: 100, bin: 1000000
A, dec: 65, hex: 41, oct: 101, bin: 1000001
B, dec: 66, hex: 42, oct: 102, bin: 1000010
C, dec: 67, hex: 43, oct: 103, bin: 1000011
D, dec: 68, hex: 44, oct: 104, bin: 1000100
E, dec: 69, hex: 45, oct: 105, bin: 1000101
F, dec: 70, hex: 46, oct: 106, bin: 1000110
G, dec: 71, hex: 47, oct: 107, bin: 1000111
H, dec: 72, hex: 48, oct
Markus
@Links2004
May 01 2015 13:50
can you add
 Serial1.setDebugOutput(true);
ficeto
@ficeto
May 01 2015 13:53
causes wdt reset
Fatal exception (2):
epc1=0x3fffdcb0, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3fffdcb0, depFatal exception (2):
epc1=0x3fffdcb0, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3fffdcb0, depFatal exception (2):
epc1=0x3fffdcb0, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3fffdcb0, depFatal exception (2):
epc1=0x3fffdcb0, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3fffdcb0, depFatal exception (2):
epc1=0x3fffdcb0, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3fffdcb0, depFatal exception (2):
epc1=0x3fffdcb0, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3fffdcb0, depFatal exception (2):
epc1=0x3fffdcb0, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3fffdcb0, depFatal exception (2):
epc1=0x3fffdcb0, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3fffdcb0, depFatal exception (2):
epc1=0x3fffdcb0, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3fffdcb0, depFatal exception (2):
epc1=0x3fffdcb0, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3fffdcb0, depFatal exception (2):
epc1=0x3fffdcb0, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3fffdcb0, depFatal exception (4):
epc1=0x40101253, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3fffdcb0, depFatal exception (2):
epc1=0x3fffdcb0, epc2=0x00000000, epc3=0x00000000, excvaddr=0x3fffdcb0, depFatal exception (2):
epc1=0x3fffdcb
 ets Jan  8 2013,rst cause:4, boot mode:(1,6)

wdt reset
0x40101253 looks promissing
Markus
@Links2004
May 01 2015 13:57

happens the same if you add

delay(10);

at the end of the loop

Markus
@Links2004
May 01 2015 14:02
if not i think we have an buffer overflow at some point
Ivan Grokhotkov
@igrr
May 01 2015 14:03
okay, weird issue again.
i took the latest changes, and the issue started happening for me as well
i rolled back to the commit which was before merging in the new GPIO code and the rest
ficeto
@ficeto
May 01 2015 14:04
and?
Ivan Grokhotkov
@igrr
May 01 2015 14:04
ASCIITable still failed
then i did erase_flash using esptool
ficeto
@ficeto
May 01 2015 14:05
we commited nothing that would break anything there
Ivan Grokhotkov
@igrr
May 01 2015 14:05
uploaded again
and it works
ficeto
@ficeto
May 01 2015 14:05
wtf?
so what's the command
let me try it
Ivan Grokhotkov
@igrr
May 01 2015 14:06
yeah, and in #130 we have also seen that we have commited nothing that should break anything ;)
$ esptool.py -p /dev/tty.usbserial-whatever erase_flash
$ esptool.py -p /dev/tty.usbserial-whatever erase_flash
Markus
@Links2004
May 01 2015 14:07
if i use the latest commit i have the same problem if i add delay(10) at the loop end it run
ficeto
@ficeto
May 01 2015 14:08
I can totally confirm this bullshit!
then again... what made my code work?
the different buffer?
Ivan Grokhotkov
@igrr
May 01 2015 14:09
different timing probably
ficeto
@ficeto
May 01 2015 14:10
timing?
Ivan Grokhotkov
@igrr
May 01 2015 14:10
like delay(10) — the issue is still there, just not being hit
ficeto
@ficeto
May 01 2015 14:13
I was looking at the code and the Write function
once hitting the buffer top, you wait for free space
and that blocks
the actuall hardware buffer is 128 bytes
Markus
@Links2004
May 01 2015 14:14
i think the problem happens when the internal FIFO buffer is full and we enable uart_arm_tx_interrupt
ficeto
@ficeto
May 01 2015 14:14
would it not be better to bypass the buffer and just use the hardware one
eliminating the need for TX interrupt
Ivan Grokhotkov
@igrr
May 01 2015 14:15
well, this code with two buffers used to work
ficeto
@ficeto
May 01 2015 14:16
it's working now on my side as well
but my question still stands
Ivan Grokhotkov
@igrr
May 01 2015 14:16
and it could deal with short (>300) strings relatively fast even at low baud rates
yeah, the real question is — why the hell did it stop working for me... and started working again when I wiped the flash?!
ah, perhaps it wiped WiFi config? let me add wifi to this sketch and try again.
ficeto
@ficeto
May 01 2015 14:19
seems like a memory exception
could a block on the memory be flagged as not-writeable or something?
Ivan Grokhotkov
@igrr
May 01 2015 14:20
no if it was an exception it would print Fatal Error: stuff but it just blocks for me
ficeto
@ficeto
May 01 2015 14:20
it did to me
Ivan Grokhotkov
@igrr
May 01 2015 14:20
in lx106 — no, there is no memory protection
ficeto
@ficeto
May 01 2015 14:21
you can see my output further up
Markus
@Links2004
May 01 2015 14:21
setDebugOutput(true); is needed to see the exaption
Ivan Grokhotkov
@igrr
May 01 2015 14:21
ah, sorry. my bad.
Fatal exception (2) is illegal instruction
something caused a jump into the data RAM
ficeto
@ficeto
May 01 2015 14:23
well wiping the flash stopped it
Ivan Grokhotkov
@igrr
May 01 2015 14:23
let me double-check that one
ficeto
@ficeto
May 01 2015 14:24
left over bytes?
Ivan Grokhotkov
@igrr
May 01 2015 14:24
ah, no it's InstructionFetchErrorCause
"Processor internal physical address or data error during instruction fetch"
ficeto
@ficeto
May 01 2015 14:28
well when it happened, it gave one address in the program meory
maybe objdump in that case can help find which method is that instruction in
Ivan Grokhotkov
@igrr
May 01 2015 14:28
that was after a bunch of exceptions, so I wouldn't trust that much
can you do objdump -S on the elf file you had for that upload?
just a thought: perhaps the upload/flash erase issue is not fixed completly? maybe now the tool doesn't erase all that needs to be erased prior to upload?
so we end up basically with broken flash image? need to do read_flash and check
ficeto
@ficeto
May 01 2015 14:32
it's in wdt_feed
that is what I thought
left over instructions
Ivan Grokhotkov
@igrr
May 01 2015 14:34
what is a left over instruction?
ficeto
@ficeto
May 01 2015 14:34
and if the prior was not properly terminated, it just kept going to the next address
or something of the sort
Ivan Grokhotkov
@igrr
May 01 2015 14:35
but why would a prior instruction be not terminated properly?
ficeto
@ficeto
May 01 2015 14:35
no clue.. not that good at assembly and below
but if a jump is missing, it would continue
Ivan Grokhotkov
@igrr
May 01 2015 14:36
yep, but i wouldn't count on hitting an issue in assembler
ficeto
@ficeto
May 01 2015 14:36
no no
Ivan Grokhotkov
@igrr
May 01 2015 14:36
even if we did, it would be 100% repeatable
ficeto
@ficeto
May 01 2015 14:36
it's it the write/erase thing
Ivan Grokhotkov
@igrr
May 01 2015 14:36
right
so will need to check the state of flash after upload and compare that to the uploaded binary
ficeto
@ficeto
May 01 2015 14:37
or erase on upload
Ivan Grokhotkov
@igrr
May 01 2015 14:38
that's an overkill
i mean — check state of flash after upload and compare — as a debugging excersise.
ficeto
@ficeto
May 01 2015 14:38
well, it surely will be faster than reading the flash and comparing
Ivan Grokhotkov
@igrr
May 01 2015 14:39
to see if there is an issue in eptool
ficeto
@ficeto
May 01 2015 14:39
lets do it :)
Ivan Grokhotkov
@igrr
May 01 2015 14:39
to see if there is an issue in esptool
ficeto
@ficeto
May 01 2015 14:39
i understand
Ivan Grokhotkov
@igrr
May 01 2015 14:39
yeah
ficeto
@ficeto
May 01 2015 14:39
now how to break it again...
Ivan Grokhotkov
@igrr
May 01 2015 14:39
but it's already late here and i need to get up early tomorrow to catch my flight... So perhaps i'll continue tomorrow night
ficeto
@ficeto
May 01 2015 14:40
have fun, there are a couple pulls waiting ;)