CCS/EK-TM4C129EXL: I2C (master_slave_loopback)

Greetings,

Young (outsider) staff (also working today) wish to, 'Agree w/vendor Bob's (infinite loop) suggestion' - yet note:

• often such 'infinite loop' as Bob describes may, do little (i.e. nothing) shown just below
  •  while(1)  { }
• however - it is believed that, 'Regularly performing brief, especially low power tasks' - may prove (even more) advantageous:
  • Scanning a Keypad
  • Reading key ADC Channels
  • Monitoring a 'Key I/O Port' for, 'Change of Status'
  • Toggling an Led to confirm 'System's Heartbeat'

As always - every system design proves 'unique' - and the choice & selection of 'activity level' must match, 'Overall Design Objectives.'

HI Bob,

I saw the same exit too in another example. Yet had expected the CPU instruction pointer to start over at flash address 0x0 when the stack pointer rolls to 0x0 and not exit.c as it did. Seemingly this is an ARM Cortex behavior? 

"while(1){} what" was the question in my mind, main.c=(1)?

Again makes one question how safe a practice placing an infinite loop inside function where MOSC clock source was configured. It would seem a safer alternative the CPU should poll the accumulator and wait for next instruction cycle. Perhaps being invoked by ARM embedded linker Symbol rather than sit in (main.c) function loop where it may some how go rogue if somehow while(0).

What ensures main function will never change to while(0) and re-launch SysCtlClockFreqSet()?  I'm fairly certain I have witnessed just that occur and thought Watch Dog had invoked a simulated POR. Why not properly park the CPU via instruction and let the peripherals direct AHB traffic? Is that considered AI where the ARM cortex becomes self aware of what the application is up too.