#avr Logs

Dec 18 2020

04:36 AM Miyu is now known as hackkitten
05:40 PM rue_mohr: Kabriel, hi
08:22 PM Kabriel: hi
08:22 PM Kabriel: ^ rue_mohr
08:31 PM rue_mohr: hi
08:32 PM rue_mohr: so, whichyou working on?
08:32 PM rue_mohr: cant read a program byte?
08:37 PM Kabriel: I have an atmega 2560, it has a bootloader, ostensibly a derrivative of AVR109 (some of the source they gave me has headers from AVR109).
08:37 PM Kabriel: There is a serial communication setup in the application that is running, and I added a command to read back to me sections of flash memory.
08:38 PM Kabriel: So I can issue a command with an address, and it responds with the bytes at that address.
08:39 PM Kabriel: It works for all of the application code, which is, let's say from 0 to 0xf2ff.
08:39 PM rue_mohr: ok
08:39 PM rue_mohr: can it read program memory byte 0 ok?
08:39 PM Kabriel: The fuse bytes indicate that the bootloader section is from 0x1f800 - 0x1ffff.
08:39 PM Kabriel: Yes. I have verified that it can read addresses correctly from 0-0xf2ff.
08:39 PM rue_mohr: ok
08:40 PM rue_mohr: and not beyond that?
08:40 PM Kabriel: When I ask it to read the bootloader section, it returns all ones for every address (0xff)
08:40 PM rue_mohr: is there a protection bit being set?
08:40 PM Kabriel: I'm not sure. Let me check.
08:41 PM rue_mohr: it kinda sounds, not that I have ever worked with it, that the bootloader is being written with a protection flag
08:46 PM Kabriel: this is from the atmel datasheet:
08:46 PM Kabriel: 1. no restrictions for spm or (e)lpm accessing the application section
08:46 PM Kabriel: (probably why I can read those bytes)
08:47 PM Kabriel: 2. further programming and verification of the flash and eeprom is disabled in parallel and serial programming mode.
08:47 PM Kabriel: The boot lock bits and fuse bits are locked in both serial and parallel programming mode.
08:48 PM Kabriel: 3. spm is not alled to write to the boot loader section, and (e)lpm executing from the application section is not allowed to read from the boot loader section. If interrupt vectors are placed in the application section, interrupts are disabled while executing from the boot loader section.
08:49 PM Kabriel: -- so there it is.
08:51 PM Kabriel: So the lock bit bytes (specifically BLB11 and BLB12) are programmed (statement #3) above, which is why my application cannot read the bytes of the bootloader section.
08:54 PM Kabriel: I went down this road to solve a different problem, so let me back up to the real issue.
08:54 PM Kabriel: I'm trying to communicate with the bootloader via Linux. I was given a compiled program to communicate with the bootloader on Windows. And I was given the bootloader source code.
08:55 PM Kabriel: However, I have since determined that the bootloader source code does not actually match what is programmed on the chip.
08:56 PM Kabriel: I determined this by connecting to the chip before the application starts up, and I can read a series of characters (an introduction string) during the brief period you can try to interact with the bootloader.
08:57 PM Kabriel: However, those characters (or that string) do not appear anywhere in the bootloader source that I have. Plus, the command I need to send to enter the programming section menu (and prevent the bootloader from starting the application) doesn't work.
08:58 PM Kabriel: So I am convinced they gave me the wrong source. I'll probably get the correct source after Christmas, but in the meantime, I was trying to figure out if I could determine the magic keystroke to enter the programming mode.
08:58 PM Kabriel: I had the idea of reading the bootloader bytes and then reverse engineering those instructions, at least for the part to enter programming mode.
09:00 PM Kabriel: This might be a dumb question, but is there a way to programmatically pull a pin low via sending a signal over the TWI?
09:26 PM Kabriel: Thanks rue_mohr for the pointer. I'm off for the evening.