Run time storage and usage of system register pointers

Warren Woolsey

Hi All,

So I am looking for an explanation here more than anything. When the hardware layer for the hercules is set up, all of the memory mapped system registers are given a macro symbol in the following fashion:

#define systemREG1 ((systemBASE1_t *)0xFFFFFF00U)

Now, whenever I need to access this register I can use it like a pointer and deallocate it anywhere in my application code like this:

systemREG1 -> MSINENA = 0x1U;

In reality, what the compiler doing is this:

((systemBASE1_t *)0xFFFFFF00U) -> MSINENA = 0x1U;

My question is: at run time, how is ((systemBASE1_t *)0xFFFFFF00U) stored and used? What does the compiler do to that symbol?

The reason I am asking this is because I am using the PBIST, and after I execute the March13N algorithm whenever I dereference systemREG1 I get a garbage value. BTW, I already have a fix for this that was answered in this post: e2e.ti.com/.../1730430. I am looking for an explanation as to what exactly happens to systemREG1 after the March13N algorithm is used, and how does the compiler treat a Macro such as systemREG1.

Thanks!

- Warren

over 10 years ago

0 Anthony F. Seely over 10 years ago

TI__Guru 68990 points

Warren,

To find out you can look at the disassembly window when you step through the code (assembly step) that uses the pointer. Or you could generate an interlist file during build.

But in either case, it'll depend so I can't answer exactly. Initially that pointer has it's value stored in flash somewhere and there will be code that reads it from flash into a register. Whether this gets pushed onto the stack and then restored from the stack later, so that while *on* the stack a PBIST operation wipes it out, really depends on too many variables to talk about here.

But I think you can safely say that the compiler doesn't comprehend PBIST .. so if you PBIST the RAM array holding your stack or heap or anything critical like that your runtime is going to 'crash' ..

If you can only run PBIST during startup - this will likely be the path of least resistance.

0 Warren Woolsey over 10 years ago in reply to Anthony F. Seely

Intellectual 526 points

Anthony,

Sorry for the delayed response, I have been busy working on other things. Here is what I have found out using the disassembler; using the #define memory mapped register pointers works as expected. I can read and write values from the memory mapped registers without problem, even after performing the PBIST. So things like:

      while (!((systemREG1 -> MSTCGSTAT) & 0x1U))
      {
         // burn loop, wait for memory self test to complete
      }

      pbistREG -> PACT = 0;     // disable PBIST & ROM clocks
      systemREG1 -> MSTGCR = 0x5U;  // disable the PBIST self test module

work just fine.

What doesn't work is writing anything to RAM. So things like:

      {
         unsigned int n = 0;
         n = systemREG1 -> MSTGCR;
         n += 1;
      }

don't work. The variable n will only be filled with the pattern the PBIST has inserted into RAM at whatever location n is stored at.

- Warren

Arm-based microcontrollers

Arm-based microcontrollers forum

Run time storage and usage of system register pointers