MPLAB-C18 v3.01, 'mem.c', OStcbArea at address 0

[tyski]

Despite the precautions taken in mem.c to keep the linker from placing the TCB array at memory location zero, I found a setup that does it anyway.

This bug was found while using MPLAB-C18 v3.01 (this also means MPLINK v4.01 which is the real culprit I suspect).

Roughly defined, the setup is as follows:

- 2 tasks (TCB structure is 7 bytes)
- OSMPLAB_C18_LOC_ALL_NEAR = FALSE
- OSENABLE_STACK_CHECKING = FALSE
- OSGATHER_STATISTICS = FALSE
- OSLOGGING = OSLOG_NONE
- 2 events, 1 event flag
- no delays/timeouts
- no non-Salvo global variables (except c18 library globals)

My first thought was that the problem was because the TCB array was roughly the same size as the rest of the global variables (i.e. the OSVars section) and in mem.c, it is the first "completely declared" section. However, I've tried adding more tasks (many more in some cases) and restructuring the order of the mem.c file, all to no avail. The only time when I could get the linker to not place the TCB array at location zero was when the the TCB array was very large enough to take up most of a 256 byte RAM bank by itself (i.e. large number of tasks). So, I believe the best solution is to simply do the following:

In mem.c, change the declaration of OScTcbP to:

code:

---

#if OSENABLE_TASKS
#define __OSCTCBP_MEM_C
#include <salvoprg.h>
OSgltypeCTcbP OScTcbP;
#undef __OSCTCBP_MEM_C
#endif

---

In salvoprg.h, change the MPLAB-C18 section to:

code:

---

#if   defined(__OSCTCBP_MEM_C)
#pragma udata OSVarsCTcbP = 0
#elif defined(__OSTCBAREA_MEM_C)
#pragma udata OSVarsTcbArea
#elif defined(__OSECBAREA_MEM_C)
#pragma udata OSVarsEcbArea
#elif defined(__OSEFCBAREA_MEM_C)
#pragma udata OSVarsEfcbArea
#elif defined(__OSMQCBAREA_MEM_C)
#pragma udata OSVarsMqcbArea
#else
#pragma udata OSVars
#endif

---

This will explicitly place OScTcbP at location zero.

I should note that this is not the ideal solution simply because I'm sure that someone out there needs to use location zero in the RAM bank.

Also, if the original setup DID work to keep the TCB array out of location zero, then the real culprit is the latest incarnation of Microchip's linker, MPLINK v4.01.

Tyrel

------------------
Tyrel Newton
Electrical Engineer

Tethers Unlimited, Inc.
11807 North Creek Parkway South, Suite B-102
Bothell, WA 98011-8804, USA
425-486-0100 x836 425-482-9670 FAX
newton@tethers.com
http://www.tethers.com/

[aek]

Hi Tyrel.

Thanks for this info -- I suppose another option is for the user to declare a single byte-sized variable to be located at address 0, and then the Salvo vars will fall into place after them. Unfortunately there doesn't seem to be a way to alert the user to when this problem happens.

BUT, isn't this problem a problem only when the Salvo vars are located in the near / access bank? And that is relatively rare, as placing Salvo vars in the access bank "steals" space from all of the vars that the compiler wants to put there ... so only for the smallest apps would this be a problem. Correct?

------------------

[tyski]

Without investigating further, I can say this. The project that I tested didn't do much - the only global variables that were declared were Salvo's and the various ones used in the PIC18 library's. However, I was using the large memory model and did define OSMPLAB_C18_LOC_ALL_NEAR as FALSE, so the linker was free to place the variables wherever it wanted.

It actually struck me as a strage problem, because no matter what I did, the linker always placed the TCB array at location zero, unless the TCB array was large enough to take up a good portion of the access RAM.

The PIC architecture's access RAM is 256 bytes in length, 160 of those bytes are SFR's (special function registers). So 96 bytes are available to the linker for the user's global variables.

Although I'm not very familiar with any of Salvo's tutorial/demo programs, I'll go out on a limb and say that most, if not all of them will fit entirely within the access bank of the PIC (unless of course they utilize a large buffer - but this would be the first thing to be mapped outside of the access bank anyway).

Also, the access RAM can technically be accessed through the BSR (bank select register) by specifying a bank value of 0. So it is really no different than the banked RAM. This means that a pointer to something in the access bank is perfectly valid. Since mem.c declares everything in seperate sections and 96 bytes is large enough for probably most of the TCB, ECB, and EFCB arrays out there, there is nothing preventing the linker from placing one of them at location zero.

Although separating Salvo's globals into multiple, smaller sections makes it more flexible, it also increases the likliehood that the linker will place one of Salvo's arrays at location zero.

With all that said, I think the best and safest approach is to beat the linker to it by forcing something into address zero that is OK to be there, like the current TCB pointer. A configuration option may be nice though for the rare user who wants to specifically place his favorite color variable at address zero and only address zero.

Happy Bug Hunting,
Tyrel

------------------
Tyrel Newton
Electrical Engineer

Tethers Unlimited, Inc.
11807 North Creek Parkway South, Suite B-102
Bothell, WA 98011-8804, USA
425-486-0100 x836 425-482-9670 FAX
newton@tethers.com
http://www.tethers.com/