Running a blank microcontroller - what's actually executing?

[HwAoRrDk]

As I was lying in bed this morning, a curious thought suddenly popped inside my head... (What do you mean, thinking about microcontrollers during your Sunday lie-in isn't normal? )

Take a fresh-out-of-the-bag microcontroller - for sake of discussion, say an AVR - that has never been used before, and is blank/empty, with nothing programmed on it. You hook it up to power in an appropriate manner, and turn it on. What will it actually be doing?

What I mean by that is, from an external viewpoint it may be sitting there doing nothing, but what's actually executing on the CPU?

Would it simply depend on what the default contents of the flash memory is? Is the flash memory just pre-filled with null bytes? That would make sense for an AVR, as 0x0000 is the NOP instruction. But then how would it keep looping so forever? Would it keep executing instructions until it reaches end of program memory, then wrap around to the beginning?

Or, is there some other behaviour? Perhaps some kind of special value pre-programmed in that tells the CPU to halt or sleep straight away?

[Andy Watson]

I suspect that the programme memory will default to either all ones or all zeros. The next time you take a microcontroller fresh-out-of-the-bag you could try reading its contents before you overwrite them. It shouldn't take too long to figure-out what the op-codes are doing.

[george.b]

A fresh-out-of-the-bag microcontroller would (should) be blank. A blank EEPROM is actually full of 1s, not null bytes. Your hypothetical blank AVR would be executing 0xFFFF. I don't know what it does on an AVR, but 0x3FFF on a PIC (which has a 14-bit word, hence 0x3FFF) is ADDLW (Add Literal to W register) 0xFF... which, externally, would be unnoticeable.
I'm not sure what happens when the program counter overflows. I suppose it wraps around.

[sleemanj]

1. NOP
2. NOP
3. NOP
... [ a lot more of the same ] ...
n. NOP
GOTO 1

To add to this, on the AVR 0xFFFF is debatable I think, some will say it is an invalid instruction and becomes a NOP, other say that it's actually behaving as a skip instruction (skip the next, execute the one after), end of the day it serves to move the program counter forwards until it wraps.

[schmitt trigger]

As I was lying in bed this morning, a curious thought suddenly popped inside my head... (What do you mean, thinking about microcontrollers during your Sunday lie-in isn't normal? )

Sorry to break the news to you my friend, but you are now addicted.

Don't attempt a withdrawal cold turkey; it is painful.
My advice to you, find a proper 13 step program in your city and register immediately!

[laneboysrc]

On the NXP LPC812 (and other) the MCU has a tiny ROM that runs after reset. It checks whether the flash contains a program through checking a magic value at a certain flash location, and if that is not found it stays in a ISP (in-circuit serial programming) function.

Quite useful feature to bring up new boards.

[krho]

A fresh-out-of-the-bag microcontroller would (should) be blank. A blank EEPROM is actually full of 1s, not null bytes.

Usually it's 1s, but I had a stm32L0 on the desk the other day and blank was full of 0s.

[Mechatrommer]

Code: [Select]

goto (PC)everywhere, no i'm not sure its none of my business...

[Jeroen3]

Erased flash condition is 0xFF, if they perform production test on flash, they most likely erase it again, expect 0xFF.

From the ARM docs it looks like it will continuously run the SWI instruction with an invalid condition field.
But, it will most likely encounter an error before even starting anything since your reset vector will be 0xFFFFFFFF. I don't know precisely to be honest.

For NXP chips the bootrom actually inhibits the user code, perhaps more chips do this.

[JPortici]

But, it will most likely encounter an error before even starting anything since your reset vector will be 0xFFFFFFFF.

why would it? Isnt' the reset vector just a memory location? it could be a goto or it could be anything (like a NOP) then at the end of the program space it could either wrap around or generate and address error trap and reset

[ejeffrey]

What happens is going to depend on the MCU in question.

ARM cortex-M processors start by loading the stack pointer and PC from the values at address 0x0 and 0x4.  This is generally the first 8 bytes of internal flash.  If those are 0xFFFFFFFF it will presumably generate a hard fault trying to execute at an invalid address.  What happens then I have no idea -- it might trigger a reset for a fault happening during PC initialization, or it might try to execute the hard fault hander stored in early flash -- which will also be invalid.  It might give up and shut down, or just keep reseting itself.  All of that is assuming that the MCU even starts up -- there could be vendor specific  rules that fail before the ARM even initializes, such as configuration bits that set the initial clock source or that control memory mapping -- for instance to selectively map internal or external flash at address 0x0.

Some MCUs come pre-flashed with a bootloader, or have a ROM with a bootloader.  In that case, they probably detect the lack of a valid program, and sit waiting to be programmed.

[C]

Way back in the TTL logic day, An output low could supply more current then and output high. You also had TTL open collector logic which used a pull-up resistor which you could create a wired-OR.
This leads to Pull-up resistors on tri-state signals if you want a known condition.
Pull-up resistors on Inputs to have a known state when nothing is connected.

For a Z80, 8085, 8080
00H is a NOP. Address bus counts 0H to FFFFH and pc wraps to 0 and does it again again
FFH is a RST7, a one byte call to an address. Calling PC address is push pushed on stack, but stack register is unknown at power up.
Address bus shows a fixed address followed by decreasing by 2 address that wraps.



For 68000
68000 reads 4 bytes starting at 0H to PC, Next 4 bytes to SP and jumps to PC address.
16 bit insturctions
0000H ORI   Inclusive-OR of data register 0 , the data is the low-order byte of the immediate word  So internal address bus counts 0 to FFFFFFFEh by 2 bytes with only A1-A23 on pins a counter that wraps if allowed to execute.
FFFFH is a coprocessor instruction if valid.
Low address area is mot used for instructions but software traps & hardware interrupt vectors  ( pointers to software). Trying to run Instructions in this area  this area could be a software trap
So what happens is a question, for someone that cares enough.

Have no
     

[Ian.M]

There's also the matter of the default non-programmed settings of non-volatile configuration registers (aka 'Fuses').   E.g. many Microchip PICs and (ex-Atmel) AVRs wont run unprogrammed in many typical application circuits because their default clock mode isn't compatible with the clock circuit components present.

[legacy]

halt
and
get
fire

 

[legacy]

FFFFH is a coprocessor instruction if valid.
Low address area is mot used for instructions but software traps & hardware interrupt vectors  ( pointers to software). Trying to run Instructions in this area  this area could be a software trap
So what happens is a question, for someone that cares enough.

Tried on a CPU32 system which I happen to have attached to a LA: I haven't put to much attention on LA, what I see from the outside, well it fetches NOPs until it resets, and then it begins the same in circle 

Oh well, it doesn't explode, at least 

[@rt]

For a given micro you might find out by writing instructions to every location other than the reset vector that
set an output bit for a digital pin perhaps, assuming you may not have to set port direction.
Or maybe see if the watchdog resets that sort of program if it doesn’t run,
or allow execution to fall off the end of an otherwise valid asm program into the blank memory space,
and check the reset register to find out why the previous reset occurred (if it did reset).

[Bruce Abbott]

on the AVR 0xFFFF is debatable I think, some will say it is an invalid instruction and becomes a NOP, other say that it's actually behaving as a skip instruction

0xFFFF is supposed to be an invalid opcode, but has the same effect as SBRS 31, 7 (skip if bit 7 set in register 31) and so in this situation is effectively a NOP.

http://www.avrfreaks.net/comment/83257#comment-83257

So what happens when an AVR tries to execute 0xFFFF? If you look in a recent instruction set, you will find that no instruction corresponds to 0xFFFF. However, in early databooks (May 1997), SBRS is given the opcode of 1111 111r rrrr Xbbb, X meaning dont-care. This means that 0xFFFF corresponds to SBRS r31, 7!

[NivagSwerdna]

Take a fresh-out-of-the-bag microcontroller - for sake of discussion, say an AVR - that has never been used before, and is blank/empty, with nothing programmed on it. You hook it up to power in an appropriate manner, and turn it on. What will it actually be doing?

It is watching you, wondering what you have planned for it.

Seriously, I think this is a great question (maybe I have the addiction already).  The initial register and pin states is normally well documented.  I would imagine that anything that changed those states would be potentially hazardous (assuming you are building an ACME GunTurrentMaxoMatic).  I'm surprised it isn't explictly stated in the datasheet.

[Sal Ammoniac]

ARM cortex-M processors start by loading the stack pointer and PC from the values at address 0x0 and 0x4.  This is generally the first 8 bytes of internal flash.  If those are 0xFFFFFFFF it will presumably generate a hard fault trying to execute at an invalid address.  What happens then I have no idea -- it might trigger a reset for a fault happening during PC initialization, or it might try to execute the hard fault hander stored in early flash -- which will also be invalid.

A fault while running the hard fault handler results in a CPU lock-up.

[HwAoRrDk]

Performed an experiment: took an unused Atmel ATtiny13A that was still sealed in it's anti-static bag, popped it in the breadboard and hooked up my AVR ISP MkII, and read the flash memory from it.

The entirety of the flash memory defaults to 0xFF, as you can see from the dump:

Code: [Select]

:10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0
:10002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:10003000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD0
:10004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0
... etc ...
:1003B000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4D
:1003C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3D
:1003D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF2D
:1003E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1D
:1003F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0D
:00000001FF

I also managed to find a reference in the ATmega328P datasheet about what happens when the chip is erased. In the section on Serial Programming, it says:

The Chip Erase operation turns the content of every memory location in both the Program and EEPROM arrays into 0xFF.

It seems both Jeroen3 and Bruce Abbott were right on the money.

So if 0xFFFF is interpreted as SBRS 31,7 - which by the way turns out is 'skip if bit in register is set', not 'set bit in register' - then that means it will always be testing for a bit that will never be set (assuming R31 defaults to zero); at every step it will simply skip to the next instruction, forever and ever. Effectively equivalent to a NOP, really.

Interesting to also hear that more sophisticated microcontrollers with integrated bootloaders and such actually check to see if they have a program.

[Jeroen3]

From the LPC1788 user manual:

37.3.1.1 Criterion for Valid User Code
The reserved Cortex-M3 exception vector location 7 (offset 0x001C in the vector table)
should contain the 2’s complement of the check-sum of table entries 0 through 6. This
causes the checksum of the first 8 table entries to be 0. The boot loader code checksums
the first 8 locations in sector 0 of the flash. If the result is 0, then execution control is
transferred to the user code.

[technix]

Here is what I have observed from a STM32F407ZG after a fresh erase: the processor tries to jump to address 0xFFFFFFFF, hits a hard fault and loads the hard fault handler, which is once again 0xFFFFFFFF, and it just loops there.

[NorthGuy]

From the LPC1788 user manual:

37.3.1.1 Criterion for Valid User Code
The reserved Cortex-M3 exception vector location 7 (offset 0x001C in the vector table)
should contain the 2’s complement of the check-sum of table entries 0 through 6. This
causes the checksum of the first 8 table entries to be 0. The boot loader code checksums
the first 8 locations in sector 0 of the flash. If the result is 0, then execution control is
transferred to the user code.

PIC24 won't run neither. It requires a "goto" instruction at the reset (0x0) location. If there's anything else it won't run.

[cv007]

assuming R31 defaults to zero

Wrong assumption. R0-R31 are not initialized by hardware, and could be any value when powered on.

A more interesting question for an AVR, is what happens when a push/pop is executed when the stack pointer points to an address outside of the ram addresses (either above or below). Also what happens when an XYZ pointer is used which points to a location above ram.

I do have the answer.

[HwAoRrDk]

assuming R31 defaults to zero

Wrong assumption. R0-R31 are not initialized by hardware, and could be any value when powered on.

I thought that might be a possibility, hence that parenthetical remark.

If the bit tested happens to be 1, no real difference I suppose - it'll just do the jump and carry on to yet another SBRS instruction.

[legacy]

Well, on my HDL-softcore (fpga), I have designed the register file to have a full initialization to zero on every hw-reset event. Thus, I am sure that all registers are actually zero 

[technix]

Well, on my HDL-softcore (fpga), I have designed the register file to have a full initialization to zero on every hw-reset event. Thus, I am sure that all registers are actually zero 

I wonder if that kind of rigidity is necessary. Maybe you can design most the register file to be uninitialized.

AFAIK for AVR only the program counter (default to either zero or the beginning of the bootloader area, determined by a fuse) and the stack pointer (default to the end of RAM) have defined reset values. For ARM Cortex-M there is no initial value for all registers and the only guaranteed reset state is that the pipeline resets into the state as if loaded the instruction “ldm 0, {sp, pc}”

[legacy]

I wonder if that kind of rigidity is necessary

Good practice on HDL-design.

[technix]

I wonder if that kind of rigidity is necessary

Good practice on HDL-design.

I would consider those additional rigidity a lower priority component, which can be axed when yield is dipping or cost is getting a bit too high.

[eugenenine]

We always said it was executing go jump in the lake instructions after having an early college professor who explained that microprocessors are stupid, if you tell them to go jump in the lake they will.