#avr Logs
Jan 21 2021
#avr Calendar
08:54 AM McDonaldsWiFi is now known as Guest19257
12:02 PM joakimk: I'm trying to find where and why my ATMEGA88 is crashing (and reseting) while communicating over serial (UART) with an ESP8266. The AVR is running nicely within the STK500, only connected to the ESP through PD0 and PD1. It has an external crystal, and everything works fine & stable -- until I start experimenting with the config (AT commands) to the
12:02 PM joakimk: ESP. Then, the AVR reboots at the same point in the "protocol" every time. So something is causing it to crash, perhaps some buffer overflow related to the UART
12:03 PM joakimk: So, how to debug this, when the UART is "occupied"... I've ordered an ATMEL-ICE, but until then I thought ,"what can I do" :) For instance, I see it's possible to write a software UART on an arbitrary pin, where I could `printf` line numbers or something, to try to home in on the last successful instructions.
12:05 PM vmt: well, led debugging or what does 88 have as icd err debugwire or what?
12:05 PM joakimk: But what else! If the AVR wasn't *restarting*, perhaps I could set LEDs (on the STK) to various bytes, and they would be "left" showing the last successful output? Is that a thing at all, that a crash could simply *not* restart the chip, but just "leave it hanging"?
12:06 PM joakimk: what happens now, is the AVR restarts and turns off all LEDs, won't it? All pins go low on reboot, or something? Or is that not necessarily what must happen (on crash/reboot)?
12:06 PM joakimk: The 88 supports the ATMEL-ICE, at least. Never tried in-circuit debugging before, so I'm looking forward to getting the device :)
12:06 PM vmt: well it starts executing...
12:06 PM joakimk: right
12:07 PM vmt: but really just isolate the issue
12:07 PM joakimk: I even looked (briefly!) into using the `noinit` section of the AVR to set some line number or whatever there, and read out "last successful entry" on chip start
12:07 PM joakimk: it's not so easy to isolate it. It might happen somewhere within the UART related interrupts, or subroutines
12:07 PM vmt: you could also use a simulator
12:08 PM joakimk: but not when the crash happens only while dealing with the ESP?
12:08 PM joakimk: if I play nicely with the ESP (only set up a TCP connection, no fancy stuff) then the chip gets the ESP up and running, and starts its main() loop successfully -- every time
12:08 PM vmt: have you verified the data from the espruinoduinopräinö is what you expect it to be?
12:08 PM joakimk: well
12:09 PM joakimk: it should be anything, right? I mean, the AVR should just accept what it sends. I'm guessing it, sometimes, sends a long string of garbage, and that's where the AVR crashes
12:09 PM joakimk: but I can't SEE what's going on, due to the UART being busy
12:10 PM joakimk: I have a second USB UART connected to the ESP, so I can see what *it* sends to the AVR. And that *looks* OK
12:10 PM vmt: so scope/la the uart?
12:10 PM joakimk: I don't have stuff like that ;)
12:10 PM joakimk: hobby project
12:10 PM joakimk: driving me insane ;)
12:10 PM joakimk: but I refuse to give up
12:10 PM vmt: a protip is to get a saleae clone off fleabay
12:10 PM joakimk: what's that?
12:11 PM joakimk: scope`?
12:11 PM vmt: LA
12:11 PM joakimk: ah
12:11 PM joakimk: yeah
12:11 PM joakimk: getting me a debugger tho
12:11 PM vmt: works with saleae's software. they're probably ~$10 or something, complete with test clips (albeit quite poor ones)
12:11 PM joakimk: so; is it possible to light up some LEDs (on say PORTB) and have them "left glowing" even if the AVR crashes/reboots? hehe
12:11 PM joakimk: does that make any sense?
12:12 PM joakimk: I want to output 11001100 -> 00010001 -> crash! And then be able to read off 00010001, and find where that happened
12:12 PM joakimk: maybe I need a high-speed camera ;)
12:12 PM vmt: well err... you could latch them for example
12:12 PM joakimk: yeah!
12:12 PM joakimk: how
12:12 PM vmt: https://www.ebay.com/itm/Logic-Analyzer-Device-USB-Saleae-24M-8CH-ARM-FPGA-For-3C-Digital-Support-1-1-16/133471685789?hash=item1f13884c9d:g:BrgAAOSwvIlfGBNy
12:13 PM joakimk: I had this idea: connect pins to relays, or something
12:13 PM vmt: well e.g. a flipflop
12:13 PM joakimk: external power source
12:13 PM joakimk: so they are *toggled* by the AVR, but left alight by the VCC
12:13 PM vmt: anyway, i don't think you need to go to these lenghts
12:13 PM joakimk: hehe
12:14 PM vmt: have you any pointers on where your chip goes to reset?
12:14 PM joakimk: here's essentially my program: https://www.electronicwings.com/avr-atmega/atmega16-interface-with-esp8266-module
12:15 PM joakimk: based off this tutorial; converted to ATMEGA88
12:15 PM joakimk: when I meddle with UDP, in addition to TCP, I get the crash in the `ESP8266_Start` method
12:15 PM joakimk: I get *into* it, but then it resets
12:16 PM joakimk: at least, it seems like this, from what I can see from the terminal. However, I'm afraid me writing to the UART messes with the ESP, creating additional errors. Not helping the situation, at least
12:16 PM vmt: i see sprintf i get sad
12:16 PM joakimk: hm
12:17 PM joakimk: how so
12:17 PM joakimk: https://stackoverflow.com/questions/3662899/understanding-the-dangers-of-sprintf
12:17 PM vmt: no. not because of that
12:18 PM vmt: because in general it's not that great of an idea to use it in embedded. especially this kind of thing where clearly you don't need it. it's not really meant for small mcus
12:18 PM vmt: anyway, beyond that. let's see
12:18 PM vmt: first off the memset + setting last byte to zero is redundant, but that isn't the problem
12:18 PM joakimk: I don't need to do that (e v e r y w h e r e)?!
12:19 PM joakimk: interesting
12:19 PM vmt: you're clearing the buffers to zero with `memset(ptr, 0, len);`
12:19 PM joakimk: yeah
12:19 PM joakimk: so I don't need to do *both*
12:19 PM joakimk: I see
12:20 PM vmt: well... i haven't probed around all of your code. i see no point in necessarily having c-strings in a small mcu program to begin with
12:20 PM vmt: i'd rather have lengths separately but that's again neither here nor there
12:21 PM vmt: as i imagine you're clearing them to zero for guaranteed termination or something like that
12:21 PM joakimk: yes
12:22 PM joakimk: here's my version, tho https://pastebin.com/0vEzH8NX
12:24 PM joakimk: modified for ATMEGA88, external crystal, and using Timer1 to blink some lights. The project is to receive bytes (from an app) and "blink" the corresponding "program", at some set tempo. Then I can change the patterns and the tempo from the app. Also, I want to have multiple such clients (AVR+ESP), with each their own 3 lights :)
12:25 PM joakimk: I'm going to try to use UDP to broadcast some (simple!!!) clock sync, so the blinking won't drift off TOO much
12:25 PM joakimk: yeah, it's stage lights ;)
12:26 PM joakimk: seemingly, somewhere around line 269 is the AVR crashing. But ONLY if I extend the code with UDP. The version pasted here doesn't crash (as far as I've seen)
12:27 PM vmt: well the sprintf arg passing is all frunked up
12:27 PM joakimk: please explain :)
12:27 PM joakimk: line 270/272?
12:27 PM vmt: oh wait no it isn't
12:27 PM joakimk: the command needs to contain quotes
12:28 PM joakimk: was that it?
12:28 PM vmt: no, it's fine
12:28 PM vmt: shouldn't compile otherwise anyway
12:29 PM joakimk: I'm guessing the ESP is unhappy with the new stuff I try to send it, and responds with some stuff. Do you see something in the *receive* (RX) part of the program that might cause buffer overflow, or similar?
12:29 PM joakimk: like the while-loop in line 83 -- can that buffer up too much bytes?
12:30 PM joakimk: it's got an `uint8_t EXPECTED_RESPONSE_LENGTH = strlen(_Expected_Response);` but maybe I'm sending something (UDP stuff) where I fail to set some expected response?
12:31 PM joakimk: or maybe the expected response is "OK", but the ESP gives me "CIPMUX and CIPSERVER can not be 0"
12:31 PM joakimk: \r\n
12:33 PM joakimk: does the Read method take into account the situation where you *expect* "OK" but get a tirade?
12:33 PM joakimk: please note, this is borrowed code... I'm trying to keep overview of what's going on, but I'm not very comfortable working in C
12:34 PM joakimk: (and it works "perfectly" for the happy path, of setting up TCP and receiving messages from the app)
12:36 PM vmt: in the main loop you seem to be doing a lot of unnecessary arithmetic and i'm too lazy to double check it
12:37 PM joakimk: hhee
12:37 PM vmt: for example, the call to strstr. just loop over the buffer yourself, and you'll instantly get the position of the desired character
12:37 PM joakimk: however, this is definitely not where the program crashes (I dare say)
12:38 PM joakimk: it doesn't get there, when I extend the config (in lines 473-479) with UDP
12:38 PM joakimk: but I'm sure you're right!
12:38 PM joakimk: C code..
12:39 PM joakimk: what's happening in the main loop,however, is I need to "unpack" the payloads from the app. Which start with "+IPD" -- and there may be several such "inline" in the same package...
12:40 PM vmt: not that call, the other one
12:42 PM vmt: anyway i can take a quick look at the readresp fn
12:42 PM joakimk: :D
12:46 PM vmt: no hell no this code is just sadface
12:46 PM vmt: there's vlas and everything jesus h. fucking christ
12:46 PM joakimk: vlas?
12:46 PM vmt: variable length array
12:46 PM joakimk: can you point at the case?
12:46 PM joakimk: (hoping it's not "my code" :P )
12:47 PM vmt: L81 is a vla
12:47 PM joakimk: right right
12:47 PM joakimk: why is that so bad :-|
12:48 PM vmt: well, these string handling functions and dynamic allocs (like vla) just make the code a fucking mess
12:49 PM vmt: just use static buffers, big enough, and have well-defined behavior within those params
12:49 PM joakimk: right
12:49 PM joakimk: because this is where I, too, think maybe the error occurs
12:49 PM joakimk: if you expect "OK", but get "on hell naaw you can't set that param on me"
12:49 PM vmt: and there's all kinds of wacky flags being set and the logic is really hard to follow, not to mention a lot of these functions are just useless
12:50 PM joakimk: they do give a *name* to the AT commands they're setting tho?
12:50 PM joakimk: as in, ESP8266_SetAppliationMode
12:51 PM joakimk: I've seen there's an ESP8266Wifi.h for C++... I plan on restarting the project with C++ and using that
12:51 PM joakimk: but first I'd like to learn why this is failing
12:51 PM joakimk: -- since it does work as-is. I just fail to "extend" it
12:53 PM vmt: no, the ones in the read response call chain
12:53 PM vmt: oh no i'd advise strongly against that
12:54 PM vmt: anyway, which parts did you implement yourself then?
12:54 PM joakimk: well, the main loop
12:54 PM joakimk: (the IPD "parser")
12:54 PM joakimk: handlePayload
12:55 PM joakimk: essentially everything below line 324
12:55 PM joakimk: except the config in lines 473-479
12:55 PM joakimk: I'll paste the current version, where I add UDP. The one that's actually crashing :) Hold on
12:56 PM joakimk: it's nearly identical
12:57 PM vmt: don't do pastebin.com please
12:57 PM joakimk: ok
01:00 PM joakimk: what do you prefer :)
01:01 PM vmt: anything plaintext
01:01 PM vmt: ix is pretty easy to use. there's others, but i forget
01:02 PM joakimk: but what about this https://pastebin.com/raw/fqwkXQ7p
01:02 PM vmt: this works
01:03 PM joakimk: you can see in the "config", that I'm trying to set up UDP?
01:03 PM joakimk: I've mangled the code, with switch interrupts, to try to see what's going on between the AVR and the ESP
01:03 PM joakimk: but that, too, doesn't work as I want it :(
01:04 PM joakimk: inputs are not debounced, so one "click" = 1000 clicks
01:04 PM joakimk: hehe
01:04 PM joakimk: so I get to `USART_SendString("jess");`
01:04 PM joakimk: but I never see `USART_SendString("nope");`
01:05 PM vmt: alright
01:05 PM joakimk: the new UDP stuff, then, is `ESP8266_StartUDP(1, UDP_DOMAIN, UDP_PORT);` -- which happens *after* "nope", so that's not the problem
01:06 PM joakimk: you can see I've added an "echo" in the ESP8266_Start method: `USART_SendString(_atCommand);`, but I don't see that *either*
01:06 PM joakimk: and, this is where UART debugging stops making sense, since I'm trying to debug on it WHILE using it to set up comms
01:06 PM joakimk: right?
01:07 PM vmt: mmmyeah
01:07 PM joakimk: so CIPMUX is set to 1, so it does `sprintf(_atCommand, "AT+CIPSTART=\"%d\",\"TCP\",\"%s\",%s", _ConnectionNumber, Domain, Port);`
01:07 PM joakimk: `_startResponse = SendATandExpectResponse(_atCommand, "CONNECT\r\n");`
01:08 PM joakimk: but what if it doesn't get CONNECT, but rather a 100 byte error
01:09 PM joakimk: the ESP tells me, "cipmux and cipserver must be 0"
01:09 PM joakimk: and ERROR etc
01:10 PM joakimk: I've described it here https://stackoverflow.com/questions/65798664/receive-tcp-and-udp-simultaneously-avr-esp8266
01:12 PM vmt: this is a pretty multivariable problem as it sure can be a protocol error as well. i've never meddled with espruinopröinös or at cmds
01:13 PM joakimk: yeah...
01:13 PM joakimk: but if the ESP causes the AVR to *crash* then it HAS to be over RX
01:13 PM joakimk: they're on separate boards, power supplies, separate grounds...
01:13 PM joakimk: only connected via PD0/PD1
01:14 PM joakimk: and it ONLY crashes if I set CIPMUX:1 instead of CIPMUX:0...
01:14 PM joakimk: so annoying!!
01:15 PM vmt: you should either probe the usart or then well, you could just modify the code to instead of waiting for exactly n bytes, to wait for some amount of bytes, then return and print that out
01:15 PM vmt: so you'll see wtf the esp is actually giving back to you
01:15 PM joakimk: i'll def look into that!
01:16 PM joakimk: only, printing it will send it BACK to the ESP ;)
01:16 PM joakimk: I might try the soft-uart
01:16 PM joakimk: what do you think about that? I have an external crystal, should be doable?
01:17 PM vmt: yes
01:17 PM joakimk: even at 115000 baud (or what it is)
01:17 PM vmt: well, don't know why you'd exactly need it anyway
01:17 PM joakimk: the extra uart?
01:17 PM vmt: also you could just ask for an impl. from rue_bed2, he probably has about 35 of them
01:18 PM joakimk: to print to a terminal, without interfering with the ESP
01:18 PM vmt: yes
01:19 PM vmt: can't you actually debug the esp anyway?
01:19 PM joakimk: how do you mean?
01:20 PM vmt: to debug it. some kind of icd? nothing?
01:20 PM joakimk: LCD?
01:20 PM joakimk: in circuit debugger?
01:21 PM vmt: sure. or some kind debug runmode over uart?
01:21 PM joakimk: I've ordered an ATMEL-ICE tho
01:21 PM joakimk: that might be fun :)
01:21 PM joakimk: don't have many tricks up my sleeve... embedded is so hard!
01:21 PM vmt: oh boy oh boy. with an stm32 you would have already solved this
01:22 PM joakimk: what's that?
01:22 PM vmt: an mcu actually worth using
01:22 PM joakimk: hehe
01:22 PM vmt: well, a family of them rather
01:23 PM joakimk: well, I would start over with a modern ATMEGA, with C++, and I hear there's a new ESP, too
01:23 PM vmt: with some $2 chinesium dev board and an stlink clone, you get basically everything you can ask off an mcu and a dev env
01:23 PM joakimk: but it's like, once I have a setup, I want to see if I can make it work ;) Hobby!
01:24 PM joakimk: ok, thanks a lot for taking an interest!!
01:24 PM joakimk: and the helpful help!!
01:25 PM joakimk: fixed buffer in Read! I have a feeling that could fix it ;)
01:25 PM vmt: well, it wasn't much help. you can clean it up a bit but at least i didn't see anything blatantly obvious
01:25 PM vmt: but yeah, i suggest you keep the usage of stdlib string handling to a minimum
01:27 PM vmt: will keep your code size smaller as well not having to link them
01:28 PM joakimk: would you recommend going to embedded C++ ?
01:28 PM vmt: no
01:28 PM vmt: there's really nothing you will gain from doing that
01:29 PM vmt: unless, and unless, you're doing this as a showcase project to get employed
01:29 PM vmt: then, you may present an argument for you know, getting a job
01:34 PM joakimk: hehe no
01:34 PM joakimk: just for fun
01:35 PM joakimk: and stage lighs
01:35 PM joakimk: I have a previous version, blinking lights through cable -- connected directly to the AVR -> triac -> optoconnector -> mains lights -- and it works great!
01:36 PM joakimk: want to make it wireless ;)
01:39 PM joakimk: well - -thanks again :)
11:18 PM giantmidget: Evening lads
11:19 PM giantmidget: Anyone here have experience with the STM32WL series of MCUs, or any dual core STM32's for that matter?