Enabled peripherals on reset, are there any?

Luis Afonso said:

where can I find this info?

Might clues exist win:

a) your Start-Up file

b) your compiler

c) the "base program" (we know - it's never your "own creation" - instead (always) one pre-existing - might it be the culprit?)

Review of the specific Peripheral Register content - PRIOR to the execution of any Start-Up file - may provide further insight

And - for extra credit - I'll bet you that not all calls to Peripherals must wait for your (oft prescribed) 3 system clocks - after that peripheral is enabled...  (and why might that be?)

Hello everyone,

So please bear with me for a bit, I might say something stupid.

So I went and did some very small tests.

The tests were done just with the GPIO for now. I was monitoring PRGPIO register.

First test:

1. unplug USB from board and plug back
2. Upload main with clock set to 80Mhz and a while(1).
3. Run code and then pause it

So the code is inside the while(1) and all GPIO give unready status.

Second test:

First I uploaded this code:

#define SYSCTL_RCGCBASE         0x400fe600
#define base GPIO_PORTB_BASE
#define peripheral SYSCTL_PERIPH_GPIOB

int main(){
	  //Set clock to 80Mhz, just like I normaly start a code
	  SysCtlClockSet(SYSCTL_SYSDIV_2_5|SYSCTL_USE_PLL|SYSCTL_OSC_MAIN|SYSCTL_XTAL_16MHZ);

	  //1st break point
	  HWREGBITW(SYSCTL_RCGCBASE + ((SYSCTL_PERIPH_GPIOA & 0xff00) >> 8),
			  SYSCTL_PERIPH_GPIOA & 0xff) = 1;

	  //2nd break point
	  HWREGBITW(SYSCTL_RCGCBASE + ((peripheral & 0xff00) >> 8),
			  peripheral & 0xff) = 1;
	  
	  //GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3);
	  //3rd break point
	  HWREG(base + GPIO_O_DIR) |= GPIO_PIN_1;
	  //4th break point
	  HWREG(base + GPIO_O_AFSEL) &= ~(GPIO_PIN_1);


	  while(1){
		  /* more code here*/

	  }
}

So I first enable GPIOA just as a control. I don't do anything else with it.
Then I enable the GPIO of my choise (in here it was B) and proceed to write on some of the corresponding registers.

1. Didn't unplug board,
2. Upload code
3. Check registers before running - all GPIO unready
4. Add now break points to each direct register access to GPIO in the C code.
5. Run code
   1. 1st break point - no change
   2. 2nd break point - GPIOA ready
      1. Checked assembly code, it's in the next instruction after STR so supposedly just 1 cycle occurred
   3. 3rd break point -GPIOB ready
   4. Code gets stuck on 3rd break point even after removing it - after resetting without break points the code reached while(1) 

So it doesn't seem the GPIO need the delay at all!

Now the question "which peripherals are on from the get go?": None besides the hibernation module.

To add - I noticed with more testing that the peripherals keep their status of on after a reset - a power cycle is needed to completely reset them (or a peripheral reset of course). Edit: Like Amit referred.

I was doing a lot of messing around with the board and that did include Timer0 so he was already enabled when I tried to cause a Fault with it.
No test was made with other peripherals besides the GPIO so if any other needs the delay after enabling the clock is a mystery for me.

@Luis,

Paid IAR most definitely impacted our LX4F MCUs by running "start-up" file. (iirc - the actual code mechanisms were not easy to discover - but local TI FAE visited our facility - confirmed our findings. I believe that the PWM Registers were those (especially) impacted)

Further point - you tested Port A - but is not that port the recipient of "special handling" (i.e. defaults into UART, I2C, SPI etc.) and not the "best/brightest" port for such a test? Suspect your targeting a most general port will yield more logically defensible results...

Searching memory bit more - we noted a, "Lack of agreement" between LX4F's Peripheral Register Values - at Reset - w/in the MCU manual and that revealed under IAR.   It is possible that IAR (did something) even prior to the execution of the Start-Up file - and that TI FAE "tipped us" to the fact that we had to "break" prior to the start of "Start-Up" file.  This is 4-5 years past - but your post brought this back...

Yes! Thinking! I got to sometimes actually think. (before acting) 

Can I take a educated guess?

It didn't make sense to me at all the need for a delay! The peripheral should be ready right away.
Then it hit me. "Wait! Isn't there peripherals that don't get the clock from the system clock? There is! At least the ADC is one of them, let's check the clock tree!"
Further to that I just went on a hunch and check 80Mhz/16Mhz. Why? Well in the source files, it's commented to wait 5 cycles on SysCtlPeripheralEnable. Well 80/16=5! It's the number of cycles it take for the ADC to be ready in relationship to the maximum CPU speed!

Tried the "create a fault test" and it indeed it created a fault!

Peripherals that start off with different clocks will have the same problem.


Do I deserve a cookie?

Luis Afonso said:

Something like this? (ready to rain judgment on me)  

That's (perhaps) a bit harsh - "drizzle" judgment seems far more appropriate.

Amit's the real expert here - with his background and "insider knowledge" he's most qualified to read/review/comment.

Alas - some "drizzle" does dot  our windshield - we note that Port "A" (notorious for "enjoying" special configurations) still remains w/in your gpio example...  Gaining any (meaningful) conclusions from a "special port/pin" is outside best-practice - is it not?   (VCs surely think so!)  

Your summary here makes it far easier for Amit/interested others to read/review - thanks for that effort.