#avr Logs

May 28 2022

06:27 AM specing_ is now known as specing
08:50 AM qu1j0t3: ok, the avrs have finally betrayed me
08:50 AM qu1j0t3: pulled out my duemilanove which i need for a project
08:51 AM qu1j0t3: appears dead and i don't see clock on pins 9/10
08:51 AM qu1j0t3: happen to have a new 168, so i got a bootloader on to it with avrisp ii and avrdude ... system has the right serial drivers for that isp
08:52 AM qu1j0t3: put in the arduino board ... yes there is clock now
08:52 AM qu1j0t3: no usbserial port, so i installed ftdi driver, rebooted, now i get serial port
08:52 AM qu1j0t3: but can't program.
08:52 AM qu1j0t3: the error message that i hate most: avrdude: stk500_recv(): programmer is not responding
08:52 AM qu1j0t3: Vdd is 4.95v about what i'd expect
08:53 AM qu1j0t3: but the isp does not see valid voltage most of the time which it's never done before
08:54 AM qu1j0t3: anyway that message is from arduino ide and its embedded avrdude. i wonder if it's worth debugging the duemilanove board further
08:58 AM qu1j0t3: caps??? idk. is that even likely if Vdd is ok
09:04 AM twnqx: hm. i have no 1/3N sized batteries... fml
09:05 AM twnqx: i can't test my NiCd-sized mainboard battery replacement board like this :(
11:21 AM rue_mohr: qu1j0t3, what baud rate are you using
11:21 AM rue_mohr: common is 115200, but 19200 is also out there
11:31 AM qu1j0t3: Using Port : /dev/cu.usbserial-A6008hFI
11:31 AM qu1j0t3: Using Programmer : arduino
11:31 AM qu1j0t3: Overriding Baud Rate : 19200
11:31 AM qu1j0t3: avrdude: stk500_recv(): programmer is not responding
11:31 AM rue_mohr: hmm
11:32 AM rue_mohr: oh
11:32 AM rue_mohr: try 57600
11:32 AM rue_mohr: arduinoinstall0:
11:32 AM rue_mohr: avrdude -c arduino -P /dev/ttyUSB0 -b 57600 -p m328p -e -U flash:w:$(PRG).hex
11:32 AM rue_mohr: genuineard0:
11:32 AM rue_mohr: avrdude -c arduino -P /dev/ttyACM0 -b 115200 -p m328p -e -U flash:w:$(PRG).hex
11:32 AM rue_mohr: fakeard0:
11:32 AM rue_mohr: avrdude -c arduino -P /dev/ttyACM0 -b 57600 -p m328p -e -U flash:w:$(PRG).hex
11:32 AM rue_mohr: fastarduinoinstall0:
11:32 AM rue_mohr: avrdude -c arduino -P /dev/ttyUSB0 -b 115200 -p m328p -e -U flash:w:$(PRG).hex
11:32 AM rue_mohr: arduinoinstall1:
11:32 AM rue_mohr: avrdude -c arduino -P /dev/ttyUSB1 -b 57600 -p m328p -e -U flash:w:$(PRG).hex
11:32 AM rue_mohr: fastarduinoinstall1:
11:32 AM rue_mohr: avrdude -c arduino -P /dev/ttyUSB1 -b 115200 -p m328p -e -U flash:w:$(PRG).hex
11:32 AM rue_mohr: arduinoinstall2:
11:32 AM rue_mohr: avrdude -c arduino -P /dev/ttyUSB2 -b 57600 -p m328p -e -U flash:w:$(PRG).hex
11:33 AM rue_mohr: arduinoinstall3:
11:33 AM rue_mohr: avrdude -c arduino -P /dev/ttyUSB3 -b 57600 -p m328p -e -U flash:w:$(PRG).hex
11:33 AM qu1j0t3: i will, but i've never had to touch that before even with the same board, which i've used a lot
11:33 AM rue_mohr: ok
11:33 AM qu1j0t3: stand by
11:54 AM qu1j0t3: rue_mohr: can't seem to change it in the ide, looks like i need to do some standalone avrdude'ing
11:54 AM qu1j0t3: bbiab
11:54 AM qu1j0t3: my polulu isp is suddenly unable to go Green on Vdd test
11:55 AM qu1j0t3: but dmm shows definitely 4.95 or 5v, usb or coax
11:55 AM * qu1j0t3 sighs
11:59 AM twnqx: ground broken?
12:00 PM twnqx: https://imgur.com/a/jeNSPRr low tech or high tech? hm
12:00 PM qu1j0t3: good question
12:15 PM Igloo: If I want to wait until SPI isn't busy before sending, rather than waiting after sending, then does `do { SPDR = data; } while (SPSR & _BV(WCOL));` do what I want? I'm not clear on what happens with a write collision. Does everything continue as if the second write had never happened?
12:16 PM Igloo: All the example code I can find seems to poll SPIF after sending, which seems like it is the slowest way to work, as you can't do anything useful while data is being sent
12:25 PM twnqx: spi can't have write collisions as there's exactly one sender and one receiver
12:26 PM twnqx: sender generates clock, data is transmitted in both directions at once
12:26 PM twnqx: if you want fast, you use an interrupt routine for transmission
12:32 PM Igloo: The atmega328 spec says "Bit 6 – WCOL: Write COLlision Flag" "The WCOL bit is set if the SPI Data Register (SPDR) is written during a data transfer."
12:32 PM twnqx: well
12:33 PM twnqx: don't write to it while a transfer is in progress, then?
12:33 PM twnqx: this is a programmer failure, not something external
12:33 PM Igloo: How do I know whether a transfer is in progress, other than writing to it and seeing if I get a write collision?
12:33 PM rue_mohr: qu1j0t3, do you know where your hex file is?
12:33 PM rue_mohr: if so, try one of these
12:34 PM Igloo: I /think/ that that is the right way, I was just hoping someone could confirm my understanding
12:34 PM rue_mohr: avrdude -c arduino -P /dev/ttyUSB0 -b 57600 -p m328p -e -U flash:w:$(PRG).hex
12:34 PM twnqx: let me open the datasheet, that's not the kind of avr i usually work on
12:34 PM rue_mohr: avrdude -c arduino -P /dev/ttyACM0 -b 115200 -p m328p -e -U flash:w:$(PRG).hex
12:34 PM rue_mohr: change the -P argument to whatever your serial port is
12:34 PM rue_mohr: and change $(PRG).hex to the name of your hex file
12:34 PM Igloo: thanks!
12:35 PM rue_mohr: I'm gonna bet you put a program on it where you need to release the reset button just as its trying to program tho
12:35 PM twnqx: Igloo, page 172 actually has an example...
12:35 PM twnqx: and that's not blindly writing
12:36 PM twnqx: it just polls SPIF from SPSR
12:36 PM Igloo: That example is waiting while the transfer is happening. I want to be doing useful work at that point
12:36 PM twnqx: so?
12:37 PM twnqx: it's the same thign at any point
12:37 PM twnqx: personally, i set a aside a send/receive buffer, and let an interrupt handler do the transmission
12:37 PM twnqx: then i just check for completion occasionally
12:38 PM Igloo: I don't think it is. If the last SPI thing you did is to wait for a read, then if you do that polling before sending then I don't think SPIF will be set
12:38 PM twnqx: you never read
12:39 PM twnqx: to read, you write a 0
12:39 PM twnqx: there's never, ever "only reading" in SPI
12:39 PM twnqx: (well, you write whatever)
12:39 PM Igloo: Sure, but if the last thing I did was read, then I will have cleared SPIF when I wait for the value to arrive
12:39 PM twnqx: to read, you write a value still
12:40 PM twnqx: no write, no clock, and thus no read
12:40 PM twnqx: you ALWAYS, without exception, write to the SPI engine, even if you only want to read
12:40 PM Igloo: Right. So reading means writing 0, and waiting for it to complete (which resets SPIF).
12:41 PM Igloo: So now my write code needs to be have differently depending on whether the last thing I did was a write (which didn't wait for completion, and didn't clear SPIF) or a read (which did)
12:41 PM twnqx: well, you need to figure what to write ;)
12:42 PM twnqx: but that will be in the data sheet
12:45 PM twnqx: weeeee third level of stacked PCBs reached in this project
12:58 PM Igloo: Ah, I found https://ww1.microchip.com/downloads/en/AppNotes/Atmel-2585-Setup-and-Use-of-the-SPI_ApplicationNote_AVR151.pdf which says "The write operation will not be executed in this case and the transfer continues undisturbed"
12:59 PM Igloo: Although it also suggests that I shouldn't be doing that
02:16 PM qu1j0t3: twnqx: doesn't seem to be a ground problem. with the two connected, dmm black lead on isp gnd pad, dmm red lead at arduino 5v, = 5.02V
02:16 PM * qu1j0t3 tears out remaining hair
06:27 PM specing_ is now known as specing