Bare-bones ATMega328P-PU
Bootloaded w/ Arduino and desired fuse-settings w/ "ArduinoISP" example in IDE.
(more detailed info on that process in this post)
Using this programming shield: Yet Another Programming Shield
Testing has shown this much to be working just great.
(I'm able to bootload w/ desired fuse settings no problemo)
My Problem:
If I upload my Arduino sketch via "upload using programmer" (aka: If I upload my sketch using the shield I am using for programming) there is an anomaly from when I upload my arduino sketch via ISP (aka: if I remove the freshly bootloaded chip, and upload a sketch via ISP with the FTDI Basic from Sparkfun)
Are these the same chip? The clock calibration would be expected to be different with different chips.
As for the lock bits you have 0xFF and 0xCF (I think: honestly, blurry screen shots of straight text is not helpful).
The value of 0xCF refers to BLB11 and BLB12 being programmed (set) - as they are zero, and zero is the programmed state. From the datasheet:
SPM is not allowed to write to the Boot Loader section, and 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.
That may be affecting the way the bootloader operates.
I am presuming the one you are having issues with is the one with 0xCF in the lock bits. Change the lock bits to 0xFF and it should be OK.
When you program a sketch using ISP Programming ("upload using programmer"), it starts by doing a "chip erase", which erases ALL of the flash AND resets the lock bits. So it is normal for the lock bits to be different after such an upload (compared to their value after "burn bootloader."
Also, that "erases ALL flash" includes the bootloader, so it's also normal that the bootloader ("upload") will no longer work, after you've used ISP programming.
"Upload using programmer" is somewhat broken when it comes it co-existing with bootloader-enabled chips; it also doesn't reset the "BOOTRST" fuse, and will cause execution to begin in the middle of a very long sketch that was uploaded to a chip that once had a bootloader (well, very near the END, I guess.) In general, you need to decide whether you're going to use the bootloader, or ISP programming, and not try to switch back and forth between them.
westfw:
In general, you need to decide whether you're going to use the bootloader, or ISP programming, and not try to switch back and forth between them.
bummer, but good to know.
I'll revert back to using ISP programming then.
The chip w/ Lock byte = 0xCF is allowing ISP uploads just fine,
but not allowing "upload using programmer".
"ISP upload" and "upload using programmer" should be the same thing?
I can't think of any reason that the differences you've shown would prevent "upload using programmer." (If your sketch is >32000 bytes long it might fail to work, but it should still upload.)