Should I really increase OS_MUTEXCNT to exit forever loop?

Our embedded target board is ARM7 based Microcontroller. We used Keil tools, which include Keil RTX-RTOS.

/* Filename: RTX_lib.c */

static U32 nr_mutex;

int _mutex_initialize (OS_ID *mutex) { /* Allocate and initialize a system mutex. */

if (nr_mutex >= OS_MUTEXCNT) { /* If you are here, you need to increase the number OS_MUTEXCNT. */ for (;;); }

*mutex = &std_libmutex[nr_mutex++]; mutex_init (*mutex); return (1); }

/* Filename: RTX_config.c */

// Standard library system mutexes // =============================== // Define max. number system mutexes that are used to protect // the arm standard runtime library. For microlib they are not used. #ifndef OS_MUTEXCNT #define OS_MUTEXCNT 17 #endif

When I run from reset, I'm stuck in for(;;); line above. I hover on nr_mutex and value for nr_mutex is shown in the debugger as 0x80008000. How is this number getting assigned to nr_mutex?

How to resolve this issue?

Thank you!

--------------------------------------- Posted through

formatting link

Reply to
janii
Loading thread data ...

Our embedded target board is ARM7 based Microcontroller. We used Keil tools, which include Keil RTX-RTOS.

/* Filename: RTX_lib.c */

static U32 nr_mutex;

int _mutex_initialize (OS_ID *mutex) { /* Allocate and initialize a system mutex. */

if (nr_mutex >= OS_MUTEXCNT) { /* If you are here, you need to increase the number OS_MUTEXCNT. */ for (;;); }

*mutex = &std_libmutex[nr_mutex++]; mutex_init (*mutex); return (1); }

/* Filename: RTX_config.c */

// Standard library system mutexes // =============================== // Define max. number system mutexes that are used to protect // the arm standard runtime library. For microlib they are not used. #ifndef OS_MUTEXCNT #define OS_MUTEXCNT 17 #endif

When I run from reset, I'm stuck in for(;;); line above. I hover on nr_mutex and value for nr_mutex is shown in the debugger as 0x80008000. How is this number getting assigned to nr_mutex?

How to resolve this issue?

Thank you!

--------------------------------------- Posted through

formatting link

Reply to
janii

How does the rest of memory look? Is it just nr_mutex, or are things being clobbered generally?

Mel.

Reply to
Mel Wilson

Our embedded target board is ARM7 based Microcontroller. We used Keil tools, which include Keil RTX-RTOS.

/* Filename: RTX_lib.c */

static U32 nr_mutex;

int _mutex_initialize (OS_ID *mutex) { /* Allocate and initialize a system mutex. */

if (nr_mutex >= OS_MUTEXCNT) { /* If you are here, you need to increase the number OS_MUTEXCNT. */ for (;;); }

*mutex = &std_libmutex[nr_mutex++]; mutex_init (*mutex); return (1); }

/* Filename: RTX_config.c */

// Standard library system mutexes // =============================== // Define max. number system mutexes that are used to protect // the arm standard runtime library. For microlib they are not used. #ifndef OS_MUTEXCNT #define OS_MUTEXCNT 17 #endif

When I run from reset, I'm stuck in for(;;); line above. I hover on nr_mutex and value for nr_mutex is shown in the debugger as 0x80008000. How is this number getting assigned to nr_mutex?

How to resolve this issue?

Thank you!

--------------------------------------- Posted through

formatting link

Reply to
janii

Le 25/06/2013 22:48, janii a écrit :

How is nr_mutex initialized?

You should have such a statement called at initialization time somewhere:

nr_mutex = 0;

Reply to
Lanarcam

Your title is incorrect. You don't want to exit the forever loop -- you want to never enter it.

I suspect that the true value of nr_mutex has been optimized away, and that the 0x80008000 is something random.

What you want to do is figure out why your OS library needs more than 17 mutexes, then either decide that you're happy with it, or fix the problem.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

(oft-repeated message snipped)

Why do you feel you have to post this over and over? Once is enough.

Perhaps you don't realize that this is USENET, and that USENET has delays. Or maybe you didn't read the pop-up from embeddedrelated.com saying that your very first post will get moderated.

At any rate, post once, then WAIT.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

Our embedded target board is ARM7 based Microcontroller. We used Keil tools, which include Keil RTX-RTOS.

/* Filename: RTX_lib.c */

static U32 nr_mutex;

int _mutex_initialize (OS_ID *mutex) { /* Allocate and initialize a system mutex. */

if (nr_mutex >= OS_MUTEXCNT) { /* If you are here, you need to increase the number OS_MUTEXCNT. */ for (;;); }

*mutex = &std_libmutex[nr_mutex++]; mutex_init (*mutex); return (1); }

/* Filename: RTX_config.c */

// Standard library system mutexes // =============================== // Define max. number system mutexes that are used to protect // the arm standard runtime library. For microlib they are not used. #ifndef OS_MUTEXCNT #define OS_MUTEXCNT 17 #endif

When I run from reset, I'm stuck in for(;;); line above. I hover on nr_mutex and value for nr_mutex is shown in the debugger as 0x80008000. How is this number getting assigned to nr_mutex?

How to resolve this issue?

Thank you!

--------------------------------------- Posted through

formatting link

Reply to
janii

Why did you submit this question 4 times? Did you run into a technical issue of some sort on EmbeddedRelated? If you did, please use the contact form to report the issue:

formatting link

Stephane

--------------------------------------- Posted through

formatting link

Reply to
stephaneb

arm

problem.

Thank you for correcting my title. Your input is helpful and appreciated.

--------------------------------------- Posted through

formatting link

Reply to
janii

arm

problem.

I never make it to my main() because it looks like static variable nr_mutex never gets

intialized.

// Filename RTX_lib.c .. .. static U32 nr_mutex; . .. .

int _mutex_initialize (OS_ID *mutex)

{ /* Allocate and initialize a system mutex. */

if (nr_mutex >= OS_MUTEXCNT)

{

/* If you are here, you need to increase the number OS_MUTEXCNT. */

for (;;);

}

*mutex = &std_libmutex[nr_mutex++];

mutex_init (*mutex);

return (1);

}

I enter forever loop because 'nr_mutex' has bogus value 0x00800080. I should never

enter this forever loop.

When __main() starts running, there is a lot of code. I can see assembly language code.

What portion of this code is responsible for intializing static variables? My peer runs to

our main() function. How might my build environment different than his. There must be

something different. Please advise! Thank you!

--------------------------------------- Posted through

formatting link

Reply to
janii

The declaration of static U32 nr_mutex; in file RTX_lib.c has

  1. file scope for the name nr_mutex (it is not visible in any other compile unit).
  2. no initializer; it is only a space reservation in the '.bss' (non- heap static data area). There is no implied initialization to 0 at the address allocated to nr_mutex; the executing code sees and uses whatever unsigned 32bit integer it finds at that address. Could be 0 ; could be garbage.

If you have access to the source of RTX_lib.c, you could do a one-time initialization: static U32 nr_mutex = 0; That will have a zero preloaded into the location on the first execution of your program. On rerunning the code (without having reloaded), nr_mutex will present whatever the last value was stored in that location prior to the run.

Solution: Make your main routine initialize nr_mutex before doing any other work. If your main routine has declarations with initializers that call functions with side effects (making use of nr_mutex, e.g.), then you want to write a 'supermain' wrapper function that does 3 things:

  1. initialize nr_mutex to 0
  2. call the main routine
  3. return the value returned from the main routine. and tell the compiler/linker that 'supermain' is the start point.

You can also call the main routine 'old_main' and the new 'supermain' can now be named 'main' instead.

Regards, =Aaron

Reply to
Aaron Sawyer

Quoth the standard: §6.7.8, paragraph 10:

"If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static storage duration is not initialized explicitly, then: ? if it has pointer type, it is initialized to a null pointer; ? if it has arithmetic type, it is initialized to (positive or unsigned) zero; ? if it is an aggregate, every member is initialized (recursively) according to these rules; ? if it is a union, the first named member is initialized (recursively) according to these rules."

Of course, if eg. custom start-up code that doesn't zero the bss segment is used, anything can happen.

-a

Reply to
Anders.Montonen

Except that, actually, there is. The definition of the C programming language strictly requires initialization to zero for such variables, and it has done so pretty much since day one. The only cases in which this initialization would be skipped are

1) some part of the code or build configuration explicitly turned off this required feature, for at least this particular variable, or in some non-standard pre-main() special function, or 2) the tools are seriously broken

In the OP's case, however, I'm pretty sure neither of these is the case. Whatever he's looking at is not actually the variable he's looking for.

Pardon the French, but that's just nonsense.

Reply to
Hans-Bernhard Bröker

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.