AVR Freaks

You have mis-understoof how to use asm() - it's actually far more complex than you think. Remember how a C compiler actually works...

You write C, you may well litter it full of #include's and #define's which are pre-processor macros.

You "compile" this but what that really means is the foo.c file is first passed to the C pre-processor. It reads things like #include/#define/#if/etc and acts upon them. Some #defines may be multiply nested - it can cope with finding and expanding out all of them. It writes what it comes up with to a foo.i file (i = intermediate). A "symbol" such as "NVM_CMD" might turn from:

	NVM_CMD = 0x5A;

to:

(*(volatile uint8_t *)(0x01CA)) = 0x5A;

so "NVM_CMD" really means 0x1CA with some sugar on top.

The file now passes to the C compiler itself. That simply reads raw C sequences from the .i file and generates Asm sequences from them. It writes the Asm out to a .s file. In the special situation when it comes across asm("...code ...") within the C it pretty much just lifts all the text in the parenthesis and dumps it verbatim into the .s file. What is within "..." is not subject to C preprocessing.

Finally the .s file is passed to the Assembler which turns the directives and mnemonics it finds there into opcodes. If the assembler comes across text sequences it does not recognize like "NVM_CMD" then it will assume this is a reference to an external symbol and that somewhere else there's likely to be Asm source that assigns the label NVM_CMD to some .data or .bss (or whatever) location. So in the file it outputs foo.o (where o = "object") it will put a "fixup marker" that says "I came across something called NVM_CMD, as yet I don't know what that is so can you fill it in later ("fix it up") when you find the other file where it is defined.

This .o file and any others from other compilations are now all presented to the linker to join (link) them together. It takes in all the .o files, pools all the data and all the symbol information and then makes sure it has everything to write out definitions of .text, .data, .bss in the final foo.elf output file.

If during that linking process it finds one file (foo.o) makes a fix up reference to something called NVM_CMD and in all the other .o files presented at the same time it cannot find anything to say "NVM_CMD means this" then it outputs the message "undefined reference to NVM_CMD".

All this started to go wrong when you used NVM_CMD within the body of asm("...code.."). The correct way to do it as shown in the asm cook book:

https://www.nongnu.org/avr-libc/user-manual/inline_asm.html

is some horrendously tortuous syntax like:

asm volatile("in %0,%1" "\n\t"
            "out %1, %2" "\n\t"
            : "=&r" (input)
            : "I" (_SFR_IO_ADDR(port)), "r" (output)
);

now, while STS in your code suggests "NVM_CMD" is _SFR_MEM_ADDR() not _SFR_IO_ADDR() the fact is that you have to use something like the above to pass the NVM_CMD symbol name (really the numeric value 0x1CA after preprocessing) across the border from the C to and into the Asm. Within the Asm  the %1 (in this example) will then be replaced with the value (0x1CA) so all the assembler ever sees is "sts 0x1CA, r1"

The difference is that the bits outside of "" in asm() are processed by the C preprocessor when this code is built. So if you used something like:

            : "I" (_SFR_MEM_ADDR(NVM_CMD)), "r" (output)

then this part of the asm() statement will be pre-processed and all that NVM_CMD stuff will just result into 0x1CA being passed to asm() to replace %1 within the ".. code .." string.

Personally I think this is detestable. It's like learning a whole new language! The very simplest solution would have been to forget asm() all together as it seems to me you are just trying to write:

NVM_CMD = 0;

so do just that and the C compiler (and preprocessor) will convert this to "STS 0x1CA, r1" anyway!. If there is some special time dependent sequence of opcodes that must be performed and it HAS to be in Asm then my next choice would be to put the whole implementation of write_flash() in a .S file as a callable Asm function.

Note that the avr-gcc compiler driver makes a distinction between foo.s and foo.S. If you put Asm in foo.s and ask to build it then it goes straight to the assembler so there's no chance of any pre-pro macros being expanded. If the file extension is upper case S not lower-case S then it is treated differently. Such a file is passed first to the C prepprocessor (so #include, #define and so on are processed) then a .i file that creates is passed to the assembler.

So if you do use separate Asm source files then, unless you have a string reason otherwise, always make them .S not .s files.