#avr Logs

Sep 01 2019

12:05 AM day__ is now known as day
05:28 AM Thrashbarg_ is now known as Thrashbarg
05:41 AM diip: Hi
05:42 AM Smidge204: ahoy
05:43 AM diip: I have a some deek-robot pro micros, and whenever I flash them, they brick
05:43 AM diip: yyy
05:44 AM diip: I can reflash them again, but the same thing happens
05:44 AM Smidge204: Well that sounds fun
05:44 AM Smidge204: What are you using to program them?
05:44 AM diip: I am using avrdude on linux
05:45 AM Smidge204: hmm
05:45 AM Smidge204: Are you messing with the clock settings at all? Intentionally or otherwise?
05:46 AM diip: no, definately not intentionally, other pro micros work fine
05:47 AM Smidge204: Just the deek ones?
05:47 AM diip: yes, all the deek-robot ones brick
05:47 AM diip: tried 3 so far
05:48 AM Smidge204: huh
05:49 AM Smidge204: Do you have some non-bricked ones left?
05:50 AM diip: yes, the pc sees them till I flash them, then nothing but the power light
05:51 AM Smidge204: Okay
05:51 AM Smidge204: Try hooking up one of the good ones, and reading the program to file using avedude
05:51 AM Smidge204: avrdude*
05:52 AM Smidge204: That should give you a dump of a known good config
05:52 AM diip: i.e. reading the contents of the pro micro?
05:52 AM Smidge204: Yeah, saving it to a file
05:52 AM Smidge204: You can then try writing that to one of the bricked ones and see if it comes back to life
05:53 AM diip: ok but that might take a while
05:53 AM diip: will try
05:53 AM Smidge204: If it does, then there's some kind of special sauce (bootloader or fuse configs) that you're trampling
05:54 AM Smidge204: If not, start by making sure your physical wiring is 100% right and avrdude is using the correct device IDs etc.
05:55 AM Smidge204: What hardware ar you using to flash it?
05:55 AM diip: they are not wired up, using usb
05:56 AM Smidge204: So you're going right to the USB socket on the board
05:56 AM diip: yes
05:56 AM Smidge204: what is your avrdude command line?
06:06 AM ThatDamnRanga: I'd go with their xtals are substandard, and you're flashing normal fuses which clobber their 'workaround' fusing
06:11 AM Smidge204: Far from impossible
06:11 AM Smidge204: Although if it's possible to reflash them via the USB socket, they're not actually, truly bricked so it seems less likely
06:11 AM diip: sudo avrdude -p m32u4 -P /dev/ttyACM0 -c avr109 -U flash:w:hexfile.hex
06:12 AM Smidge204: ^
06:13 AM ThatDamnRanga: if it wasn't you'd need an ICSP
06:13 AM Smidge204: This is good news since you're not truly hurting anything, they're just being misprogrammed
06:13 AM Smidge204: So either your source file is not compiled for the target chip, or " -p m32u4" is wrong
06:14 AM Smidge204: My thinking goes there, anyway
06:14 AM Smidge204: -U flash:r:flash.bin:r
06:15 AM Smidge204: where "flash.bin" is the filename you want, including path
06:34 AM diip: ok, I can't seem to read from a new one, but I can read from a bricked one and the file is different from what I flashed it with
06:37 AM Smidge204: I'm really suspecting the chip is not what you think it is
06:40 AM Smidge204: Also I didn't think of it before, but the written file needs to be in the same format if you expect them to be the same; -U flash:r:flash.bin:h
06:40 AM Smidge204: The h is for hex. My bad.
06:40 AM diip: aha will try again
06:45 AM diip: the files are still different
06:46 AM Smidge204: Are they at least in the same format?
06:46 AM diip: I
06:47 AM diip: I think so, it spits out a whole bunch of hex code
06:49 AM Smidge204: But if you compare the overal structure of the two files they should be the same
06:49 AM Smidge204: They might not be the same physical size if that's all you're going by
06:54 AM diip: used diff and vimdiff
06:55 AM diip: they might not be the same , not sure but the structure is definately different,
06:56 AM diip: tried flashing with -p atmega32U4 , no change
06:57 AM Smidge204: You're sure the file you're flashing is actually hex, and is being interpreted at avrdude as hex?
06:58 AM Smidge204: -U flash:w:hexfile.hex:h for example?
07:00 AM diip: how would I know if it wasn't hex?
07:01 AM diip: on vim diff , flash.bin is 0x## seperated by commas and the .hex file is numbered lines
07:02 AM Smidge204: Yeah that's hex. Maybe add ":h" to the writing command so avrdude knows
07:02 AM Smidge204: I know there's a :a for auto-detect but I don't know what the default behavior is
07:04 AM diip: it would seem that did it, what exactly did the :h do?
07:05 AM Smidge204: in the context of the -U command with :w:, it tells avrdude that the input file is in hex format
07:05 AM Smidge204: So basically avrdude was not interpreting the input file properly and writing junk to the program memory
07:12 AM diip: so why would it work fine for other pro micros?
07:13 AM diip: which is hex , the one with commas or the one with line numbers?
07:14 AM diip: worked for the other flashed ones at least they are recognised by the pc
07:14 AM diip: Thanks
07:14 AM Smidge204: I have no idea
07:47 AM diip: hmmm, does the read program read backwards? now the flash.bin file starts with about 4000 0xff. I know there was some space left at the end of
07:47 AM diip: the flash storage, that would account for it
07:48 AM diip: will have to test how the pro micros work later
07:52 AM Smidge204: reading would dump the entire memory, even the unused portion at the end, so the output file would be the entire memory size
07:54 AM cehteh: formatting is sometimes off and .hex support RLE for ranges filled with zero (or 0xff)
07:55 AM diip: RLE?
07:55 AM cehteh: when you want to read back and compare you better read as binary image OR use avdude's verify command
07:56 AM Smidge204: run-length encoding (A lightweight compression method)
07:57 AM cehteh: unprogrammed, zero or 0xff areas are compressed, only start and end address is in the .hex irrc (i dontk now the exact details)
07:57 AM cehteh: most annoying is that the text fromatting can be different
07:57 AM cehteh: thus comparing rarely works
07:57 AM cehteh: use binary if you really want that
08:00 AM diip: so I would need to coverthe hex file to binary
08:01 AM diip: convert the̤*
08:01 AM diip: good to know, thanks
08:06 AM cehteh: i havent followed what you try to do
08:11 AM diip: just compare the original file to the file read from the pro micro
08:11 AM diip: now they seem to be working
08:12 AM cehteh: then use the avrdude verify command
08:13 AM * cehteh includes version information in the binary, and recently i added an 'archive' facility to my makefiles, whenever i flash a firmware it archives that exact one, tagged with date, version, md5sum ...
08:14 AM cehteh: $ ls ARCHIVE/
08:14 AM cehteh: 2019-08-23_10:28:45_97295a0_5eb91d0-dirty_submodule-317-gebc303a-dirty.hex
08:14 AM cehteh: 2019-08-23_13:45:04_226627c_5eb91d0-dirty_submodule-319-g81d6240-dirty.hex
08:14 AM cehteh: ...
08:15 AM cehteh: bit elaborate, but for various reasons its good to have old versions around
08:15 AM cehteh: recently some update (gcc or libc) shoot me into the foot :D
08:15 AM Smidge204: Working is the important part
08:16 AM cehteh: working i irrelevant you can note that elsewhere, but able to compare and reproduce some things is important
08:17 AM diip: so is verify flash:v:filename ?
08:17 AM cehteh: looks right, but RTFM for yourself :)
08:20 AM Smidge204: https://www.nongnu.org/avrdude/user-manual/avrdude.html#Top
08:20 AM Smidge204: Bookmark it :)
08:20 AM diip: Smidge204: I can't test it now as it would mean disassembling pluging and reassembling hopefully this is faster
08:24 AM cehteh: ISP stands for "In System Programming" .. when you cant do that, then you designed something wrong :D
08:24 AM diip: looking at it now, but it ha -V and -v and :v: [which I find abit confusing especially now the -U formats seem to make a huge difference depending on the board]
08:25 AM cehteh: avrdude is very much parametized and flexible
08:27 AM diip: that is great but I would have thought [hoped?] two similar boards with similar chips would not need different inputs
08:28 AM cehteh: for what definition of 'similar'?
08:28 AM diip: it is the boards that are the issue luckily avrdude is flexible enough to solve it
08:28 AM diip: same design, same chip
08:29 AM cehteh: normally its pretty much the same avrdude input, only the parts for the programmer and part may change
08:29 AM diip: two pro micros from usb with avr109
08:33 AM cehteh: should be the same then
08:43 AM diip: so it is not verifying, except when I flash it without the :h option and then it does not work
08:44 AM diip: and I can't verify with the :h option it does not read the hex file
08:45 AM Smidge204: My command string in Atmel STudio uses:
08:45 AM Smidge204: -Uflash:w:"$(ProjectDir)Debug\$(TargetName).hex":i
08:45 AM Smidge204: This writes and verifies the program
08:46 AM Smidge204: "i" means Intel Hex
08:46 AM diip: just saw that, about to try
08:47 AM Smidge204: Bear in mind that Intel Hex format looks like: :10000C006AC138ED20E0309334002093600038ED65
08:48 AM Smidge204: Which is not what you described before, saying your file contains "0x..."
08:49 AM diip: still not working
08:49 AM cehteh: sometimes i wonder why i use hex, i should use .elf and done
08:49 AM Smidge204: Would you be willing to pastebin the first few lines of the file you're trying to flash?
08:52 AM diip: https://pastebin.com/FPHTAqdG
08:55 AM Smidge204: huh
08:55 AM Smidge204: Certainly not what I was expecting. try "a" for auto?
08:58 AM diip: tried :a didn't work
08:58 AM diip: and the file read with :h seperated by commas
08:59 AM diip: so is it not reading a hex file?
08:59 AM diip: these files are from qmk
09:01 AM diip: I used hexdump to get the pastebin
09:02 AM diip: but like I said it is only deek-robot it does not work with so I doubt it is the files
09:05 AM Smidge204: Did you compile this code yourself?
09:05 AM diip: no I got the hex from qmk
09:06 AM diip: https://config.qmk.fm/#/handwired/dactyl_manuform/6x6/LAYOUT_6x6
09:07 AM diip: do you[anyone] use deek-robot?
09:08 AM Smidge204: I have no idea what that site is or how it works, or if it's reasonable to expect that a hex file downloaded from it would work on any specific device
09:08 AM Smidge204: I've actually never heard of it but an ATmega32P is an ATmega32P (unless it's a dubious Chinese fake, which is actually rare)
09:09 AM diip: it works fine on all the others maybe I should compile myself?
09:10 AM Smidge204: WOrth a try
09:10 AM cehteh: i had some clones marked DEEK ROBOT, the silkscreen was wrong, ISP header mixed some pins and one GND was marked GDN
09:10 AM cehteh: otherwise it worked
09:10 AM diip: would a fake actually flash?
09:10 AM cehteh: dunno but i think that was a geniue avr
09:11 AM Smidge204: You were able to reflash the dumped program from another device, and got it working again right?
09:11 AM diip: no, I could not dump the file from an unused one
09:12 AM cehteh: cloing chips is expensive the do it for profit thus at least most if not all functionality should work, unless its a scam where you get disfunct devcies, but i havent heared that for mcu development boards yet
09:12 AM Smidge204: okay so maybe it's not flashing right at all
09:12 AM cehteh: soemtimes preprogrammed/fused AVR'S come into the market, those behave strangely until you blank them completely
09:13 AM diip: and when I flashed it with the :h it showed up on the pc [unlike other times] but I didn't test it as that would mean rewiring the keyboard
09:13 AM cehteh: flash the usual 'blink' example
09:14 AM cehteh: verify it works, check fuses, check frewquency, sometimes the OSC is wrong configured
09:14 AM diip: but how will I test it?
09:14 AM diip: OSC?
09:15 AM cehteh: clocksource
09:15 AM cehteh: check chip signature
09:16 AM cehteh: very rarely avrdude reads the chip signature wrong, often because misconfiguration or bad cabeling
09:16 AM diip: ok will try doing those but that won't be today
09:16 AM cehteh: and very rarely because the AVR' errs on that, the chip signature iirc is on some hidden flash section usually not modifyable, but i heared rumors that it may flip some bits
09:17 AM cehteh: its very unlikely that you see such
09:17 AM diip: yes but reading it wrong on one chip is one thing, from 3 chips from 2 differnt vendors is another
09:17 AM cehteh: check your cabeling
09:17 AM cehteh: i once has a problem with a bad usb cable
09:18 AM diip: then it would not work with other [non deek] pro micros
09:19 AM diip: so I doubt it is the cable
09:19 AM diip: no worries like I said
09:19 AM cehteh: could be that signal quality is on the brim and below the sane treshold on those boards
09:20 AM diip: the others are working so it is just a curiousity
09:20 AM cehteh: but if you ask me about what are the worst avr devel boards i ever seen i would say that are these DEEK ones
09:20 AM diip: maybe will try another cable
09:21 AM cehteh: that was years ago and they worked, but the sikscreen fuckup gave me some wtf first because i couldnt flash them
09:21 AM cehteh: so flash blink, verify that, check fuses
09:23 AM Smidge204: Try using avedude in terminal mode?
09:40 AM diip: only ever used terminal mode
09:41 AM Smidge204: oh
09:41 AM Smidge204: Then what's with all these command line shenanigans?
09:41 AM diip: I have to admit I know very little about the avr
09:41 AM diip: no sorry not terminal mode
09:42 AM diip: will explore these deek-robots properly when I can, for now I guess I just won't be getting more
09:43 AM Smidge204: yeah
09:43 AM Smidge204: Something really seems amiss with those devices
09:43 AM diip: btw tried another[Nokia] cable and still no go
09:44 AM Smidge204: Since you're using the USB port and it works *at all* it's definitely not the cable
09:44 AM Smidge204: Nor would I suspect a OSC misconfig because that would break USB
09:45 AM diip: and maybe learn about terminal mode :-)
09:49 AM diip: thanks for all the help
06:06 PM Smidge204: Exerimenting with sleep modes now. In the main loop I set it to power down, and I have interrupts on three pins (three buttons) that will wake it up
06:06 PM Smidge204: Before it goes back to sleep it toggles an output pin to light an LED as a marker it's working
06:07 PM Smidge204: But it only works if there is a sizable delay
06:19 PM Smidge204: I need a delay of 2.8ms for it to work
06:20 PM Smidge204: I know it takes a finite amount of time for it to wake up from sleep, but I woldn't thing a delay *before* the sleep instruction would help
06:21 PM Smidge204: It's almost as if it's going back to sleep before the interrupt routine returns
06:21 PM Smidge204: ...
06:22 PM Smidge204: Actually that might be exactly what's happening, because I'm using the UART hardware to send a command, it might be getting the last byte out becore it powers down
06:28 PM Smidge204: That is *exactly* what's happening. That's kind of amazing.
06:28 PM Smidge204: A nice little trap; Make sure all your buffers are empty before entering sleep mode
06:42 PM cehteh: :D
06:43 PM cehteh: also there is this fetch/instruction interleave and other things, main loop will advance at least one instr before anoter ISR can be served ...
06:44 PM cehteh: when you are not careful you get a lot spurious wakes or no sleep
06:53 PM Smidge204: I really only need to wake on button press
06:55 PM Smidge204: And I'm one pin short at this rate, so I might be abandoning the UART hardware and goign bitbang so the unused RX pin is free
06:55 PM Smidge204: Which would solve this problem as well