Search code examples
assemblyembeddedavratmelatmega

What can cause the LPM instruction to always fail?

I have a self-modifying program which writes to the program flash area (it does not break the program flow because I write to another flash sector than the one my program is running in - it runs in the protected bootloader section).

The complicated part, writing to the flash, works. I can check it in the debugger, the values I have sent are successfully written to the flash.

However, when I try to check the contents with the LPM instruction, it always reads zero.

I identified the following causes when LPM can fail to read:

  1. When the lock bits are set, forbidding reading the flash. Not the case here, as no lock bits are set.
  2. The reading of the flash is locked because of a previous write instruction. Not the case here, as I set RWWSRE and wait until the green light with while (SPMCSR & 0b01000000) {}
  3. I miscalculated the address (the segmentation of the Z pointer can be tricky). Not the case here, as I also tried it with the very first word (at address 0) and it still doesn't work.

I use the following code for my test, reading the first two bytes of the flash (the writing instruction completed successfully, as Program memory at that position is not zero, checked with the debugger)

  lpm r0,Z+
  lpm r1,Z+
  movw r2, r0

Before that, I set the Z pointer to zero, and check it with the debugger that it is really zero (r30 and r31).

However, r2 and r3 will always be zero, regardless of what was in the flash.

Is there another situation where LPM fails to read?

Solution

  • I found the solution while running it step by step and checking the contents of all the affected registers. It turned out the problem has nothing to do with LPM, but I keep the question for future reference.

    the code part 

      lpm r0,Z+
  lpm r1,Z+
  movw r2, r0

    was in a C for loop, and the Z pointer was set before that loop. However, the loop comparison just happened to be compiled to use r30 as a temporary register, so it corrupted the Z pointer. Problem solved by placing the initialization of the Z pointer and the part with the LPM into the same #asm ... #endasm block.