TI Free Sample came with pre-loaded code...

[tom66]

I recently sampled some TM4C123GH6PM microcontrollers in TQFP64 package. I just got my board working, before JTAG was fully connected, surprisingly I had one LED lit up on the board. I checked the crystal and sure enough it was oscillating at 16MHz. On the Tiva processors, like most MCUs, this will not happen until you write a program to turn the oscillator on.

What could cause this? The only conclusion I could make is that I got an already programmed chip which is a little worrying as the samples should have been straight from Digi-Key stock.

Odd, in the very least. It did work as expected when erased and reprogrammed. Perhaps I should have tried to copy the free sample program off.

[jeremy]

I presume it was some sort of bootloader. All ATMEGAxxUx come preprogrammed as well unless you specifically ask for them to be blank.

[tom66]

That sounds reasonable, odd though. What would happen if I installed it into a system with some safety controls? OK maybe that's a little out there and you'd be an idiot to program a system while it is dangerous but what if it failed to program and you tried to test it...

Seems kind of odd. Guess I'll get curious eventually and check the other chip, maybe it will have some code I can dump off it.

[ve7xen]

The bootloader on these is in ROM, and the datasheet at least says that it uses the internal oscillator. So yeah, kinda weird.

[Bored@Work]

It is not really odd. The MCU starts and probably executes from an empty FLASH memory, after the bootloader relinquishes control.

If the FLASH is empty, e.g. all FF, the MCU will try to interpret FF or groups of FF as opcodes. There might be a corresponding opcode or it might be illegal. Depending if the opcode has a meaning, how the MCU is build etc. a number of things might happen. E.g. the MCU running through memory, wrapping around, at some point maybe hitting the bootloader again. Or continuing triggering a reset because of a bad opcode, reseting into the bootloader. This and a bunch of other events can look like some program causing some periodic event happening.

MCUs in safety environments should of course not do that, so you pay extra for an MCU.

[Stonent]

I think it would be better to not connect to safety equipment until you've got your real program loaded.

[nctnico]

It is not really odd. The MCU starts and probably executes from an empty FLASH memory, after the bootloader relinquishes control.

If the FLASH is empty, e.g. all FF, the MCU will try to interpret FF or groups of FF as opcodes. There might be a

That is why most modern microcontrollers treat 0xff as NOP.

[tom66]

If the FLASH is empty, e.g. all FF, the MCU will try to interpret FF or groups of FF as opcodes. There might be a corresponding opcode or it might be illegal. Depending if the opcode has a meaning, how the MCU is build etc. a number of things might happen. E.g. the MCU running through memory, wrapping around, at some point maybe hitting the bootloader again. Or continuing triggering a reset because of a bad opcode, reseting into the bootloader. This and a bunch of other events can look like some program causing some periodic event happening.

That is odd, so the micro could have been executing random code that just happened to start the crystal, enable the GPIO port peripheral cloc for Port A, enable the port pin including drive strength setting, turn the port pin to an output -and- output a logic high? 

I'm not buying it...