Pumpkin, Inc.

Pumpkin User Forums

Bug in MPLab-C18 standard libraries?

If you think you've found a bug or other mistake in your Salvo distribution, post it here.

Bug in MPLab-C18 standard libraries?

Postby aek » Wed May 14, 2003 2:59 am

Hi Gerard.

Before I forget,

code:
#define OSBYTES_OF_EVENT_FLAGS 1

should not be in your salvocfg.h, as it works only on source-code builds. Please remove it.

Also, please do not copy salvomem.c (or any other Salvo source files) to your project directory. When adding Salvo source files to a project, please link to the Salvo file in salvosrc.

quote:
No.

You are using a Salvo library with Salvo's global objects qualified as "far", i.e. not in the access bank.


I must apologize for the gruffness of my previous response -- your
quote:
should be CLRF 0x17, 0 (0=access,1=BSR)
comment is correct, as it has nothing to do with Salvo or banking per se -- it's the compiler getting ready to use a 2-byte temporary variable.

Now that I've looked at the code, your assessment

quote:
It looks to me like a compiler error when the library was built
appears to be correct. I cannot get it to generate the correct code (CLRF 0x17,0) despite several changes I've made on-the-fly to the source code in salvosrcmsgq.c. Perhaps you can see a way to "code around" this MPLAB-C18 bug?

Tip: You can always add a Salvo source file to a library build as long as the relevant configuration options in your salvocfg.h match those that affect the file when the library was built. In your case, it's safe to add salvomsgq.c to your project as a node (with your current salvocfg.h). Then, you can edit OScreateMsgQ() in yourprojectmsqq.c to see if there's any way to get the compiler to generate the right code when setting the mqcb's endPP. I did this, for instance, by changing the line to

code:
lMqcbP->endPP = msgPP+size;

but to no effect.

Right now, I'm concerned with finding you a way to work around this problem. And so far, short of a real bang-up job on the mqcb, I don't see a way to do it ...

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

-------
aek
aek
 
Posts: 1886
Joined: Sat Aug 26, 2000 11:00 pm

Re: Bug in MPLab-C18 standard libraries?

Postby aek » Wed May 14, 2003 4:03 am

Hi Gerard.

I have good news and bad news ...

The good news is that MPLAB-C18 v2.20 (released a few days ago) fixes this problem

code:
00043c   0ef8     MOVLW     0xf8               lMqcbP->endPP     = &msgPP[size];
00043e 6a17 CLRF 0x17,0x0
000440 34db RLCF 0xdb,0x0,0x0
000442 0bfe ANDLW 0xfe
000444 3617 RLCF 0x17,0x1,0x0
000446 6e16 MOVWF 0x16,0x0
000448 0ef9 MOVLW 0xf9
00044a 50db MOVF 0xdb,0x0,0x0
00044c 2416 ADDWF 0x16,0x0,0x0
00044e 6e14 MOVWF 0x14,0x0
000450 0efa MOVLW 0xfa
000452 50db MOVF 0xdb,0x0,0x0
000454 2017 ADDWFC 0x17,0x0,0x0
000456 6e15 MOVWF 0x15,0x0
000458 d8da RCALL 0x60e
00045a 0e07 MOVLW 0x7
00045c d933 RCALL 0x6c4
00045e d8f0 RCALL 0x640

The bad news is that the source-level debugging seems to be off in MPLAB -- one jumps to places that clearly aren't correct while single-stepping the code.

I will follow-up with strategies for you to use until we release Salvo v3.2.

Regards,

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

-------
aek
aek
 
Posts: 1886
Joined: Sat Aug 26, 2000 11:00 pm

Re: Bug in MPLab-C18 standard libraries?

Postby gerardlt » Wed May 14, 2003 5:58 am

Hello,

I am using slc18sfa.lib.

In file msgq.c, Revision: 3.4, dated 2002-09-19 23:53:46-07, in the function OSCreateMsgQ() the line that reads:

code:
    lMqcbP->endPP     = &msgPP[size];

shows as the following assembly language:

code:
MOVLW     0xf8
CLRF 0x17,0x1 ****
RLCF 0xdb,0x0,0x0
ANDLW 0xfe
RLCF 0x17,0x1,0x0
MOVWF 0x16,0x0
MOVLW 0xf9
MOVF 0xdb,0x0,0x0
ADDWF 0x16,0x0,0x0
MOVWF 0x14,0x0
MOVLW 0xfa
MOVF 0xdb,0x0,0x0
ADDWFC 0x17,0x0,0x0
MOVWF 0x15,0x0
MOVFF 0xfde,0xfe9

MOVFF 0xfdd,0xfea

MOVLW 0x7
ADDWF 0xe9,0x1,0x0
MOVLW 0x0
ADDWFC 0xea,0x1,0x0
MOVFF 0x14,0xfee

MOVFF 0x15,0xfed


The second line (marked with asterisks) clears address 0x17 using the BSR. Considering the use of address 0x16 and 0x17 in the following lines, I believe that it should actually clear address 0x17 using the access bank.

The register actually being cleared (address 0x117) is the status byte in the tcb of my fourth task, causing predictable side effects!

My salvocfg.h looks like:

code:
#define OSEVENTS                3
#define OSEVENT_FLAGS 1
#define OSMESSAGE_QUEUES 2
#define OSTASKS 4

#define OSBYTES_OF_EVENT_FLAGS 1

#define OSUSE_LIBRARY TRUE
#define OSLIBRARY_TYPE OSL
#define OSLIBRARY_CONFIG OSA
#define OSLIBRARY_VARIANT OSNONE
#define OSLIBRARY_GLOBALS OSF


I hope that I'm being stupid and have made a mistake, but it looks like the generated code is from the library specified, so I am assuming that this is a bug.

Can someone at pumpkin confirm/correct me on this?

------------------
Gerard Thornley
Electron Software

[This message has been edited by gerardlt (edited May 15, 2003).]

Gerard Thornley
Electron Software
gerardlt
 
Posts: 14
Joined: Tue May 13, 2003 11:00 pm
Location: Lancaster, UK

Re: Bug in MPLab-C18 standard libraries?

Postby aek » Wed May 14, 2003 8:24 am

Hi Gereard.
quote:
The register actually being cleared (address 0x117) is the status byte in the tcb of my fourth task, causing predictable side effects!
Have you included salvomem.c as a node in your project and ensured that it is pulled in by the linker "ahead" of the library?

You must always do this if your LE or Pro project's OSTASKS or OSEVENTS exceed the default in the library (see Chapter 8 * Libraries in the Salvo User Manual for more information).

I suspect you forgot to do this.

What happens is the library's mem.obj module expects the task and event objects (the tcbs and ecbs) to be in a particular place and of a particular size (3 taks, 5 events). Since an OSTASKS of 4 does not match the library's mem.obj, what's happening is your 4th task's tcb is "overlayed" with the first few ecbs. Thus the behavior you describe above.

So, add salvomem.c as a node in your project, ensure that the linker pulls it in instead of the mem.obj in the library (this is an "order" issue in MPLAB v5.x, dunno about MPLAB v6.x), and rebuild. Then you should be fine.


IOW, the library is built correctly, it's just a linker / module issue that you need to address.

Regards,

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

-------
aek
aek
 
Posts: 1886
Joined: Sat Aug 26, 2000 11:00 pm

Re: Bug in MPLab-C18 standard libraries?

Postby aek » Wed May 14, 2003 9:36 am

Hi Gerard.

I have more bad news -- while MPLAB-C18 v2.20 fixes the access bank problem, it appears that they have changed the calling convention and/or stack frame, and the existing Salvo context switcher no longer works.

I tested MPLAB-C18 v2.2 on salvo ut u6 u6.pjt and it no longer works. It's probably a relatively simple fix, but before we can issue a new release we need to fully characterize the new compiler to ensure that we've handled it properly.

So, for now, the only known problem with MPLAB-C18 v2.1 is the one you have exposed. Unfortunately, migrating to v2.2 to fix this problem introduces a host of new problems. We will not have a fix for v2.2 an earlier than next week.

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

-------
aek
aek
 
Posts: 1886
Joined: Sat Aug 26, 2000 11:00 pm

Re: Bug in MPLab-C18 standard libraries?

Postby gerardlt » Wed May 14, 2003 10:48 am

Yes, I have included mem.c as a node. As evidence that mem.o is being linked correctly, changing the number of events and/or tasks IS changing the size and location of OStcbArea and OSecbArea.

Overlaying of tcbs and ecbs is what I first expected. That is not what is happening. The event and message queue data is being written to the correct locations by OSCreateMsgQ(). I've stepped it through line-by-line and watched the file registers in symbolic mode in MPLab!
The register being changed is a side effect, rather than a direct effect of the function.

The four registers 0x14, 0x15, 0x16 and 0x17 are being used by the compiler for temporary data, and there is no reason for 0x17 to be accessed using the BSR.
On the other hand, given the way the 0x17 is used, there certainly IS every reason to want to clear it at that stage in the code.

In the following annotated disassembly, FSR2 is the frame pointer, FSR0 is used for pointers to RAM

code:

// Position of "size" in frame
MOVLW 0xf8

// should be CLRF 0x17, 0 (0=access,1=BSR)
// 0x17 is going to be the top byte of (size * 2) in a moment
CLRF 0x17, 1

// get "size" from frame, roll it left, putting top byte into Carry flag
RLCF PLUSW2, 0, 0

// Clear out any rubbish that came from Carry flag into bottom of value
ANDLW 0xfe

// Roll top bit from "size" into 0x17 - this needs 0x17 to be clear first
RLCF 0x17, 0x1, 0

// Put lower byte of result into 0x16
MOVWF 0x16, 0

// size * 2 is now stored in [0x17,0x16]

// Read address of msgPP from frame and add values from [0x17,0x16]
// Putting result into [0x15,0x14]
MOVLW 0xf9
MOVF PLUSW2, 0, 0
ADDWF 0x16, 0, 0
MOVWF 0x14, 0
MOVLW 0xfa
MOVF PLUSW2, 0, 0
ADDWFC 0x17, 0, 0
MOVWF 0x15, 0

// dereference lMqcbP
MOVFF POSTINC2, FSR0L
NOP
MOVFF POSTDEC2, FSR0H
NOP

// calculate address of endPP
MOVLW 0x7
ADDWF FSR0L, 0x1, 0
MOVLW 0
ADDWFC FSR0H, 0x1, 0

// write earlier result from [0x15,0x14] into endPP

MOVFF 0x14, POSTINC0
NOP
MOVFF 0x15,POSTDEC0
NOP


Clearly, CLRF 0x17,1 should actually be CLRF 0x17,0.

Unless the linker is doing things I didn't think it was capable of, the 1 in that line has come from the library file.
It looks to me like a compiler error when the library was built, but could also be a corrupted file (single bit changed from 0 to 1) - any chance of an MD5sum of the original file?


------------------
Gerard Thornley
Electron Software

[This message has been edited by gerardlt (edited May 15, 2003).]

Gerard Thornley
Electron Software
gerardlt
 
Posts: 14
Joined: Tue May 13, 2003 11:00 pm
Location: Lancaster, UK

Re: Bug in MPLab-C18 standard libraries?

Postby aek » Wed May 14, 2003 11:04 am

Hi Gerard.

Thanks for your detailed response.

1) Please .zip the project and send it to support@pumpkininc.com -- that way we won't make any false assumptions on our end.

2) Can you post the map file that includes the addresses of all the global objects? I still think it's a link-time issue and not a library bug.

3) Do you have Salvo Pro or LE? If Pro, you can do a source-code build to observe how the function OSCreateMsgQ() is compiled.

Regards,

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

[This message has been edited by aek (edited May 14, 2003).]

-------
aek
aek
 
Posts: 1886
Joined: Sat Aug 26, 2000 11:00 pm

Re: Bug in MPLab-C18 standard libraries?

Postby aek » Wed May 14, 2003 11:12 am

Hi Gerard.
quote:
// should be CLRF 0x17, 0 (0=access,1=BSR)
// 0x17 is going to be the top byte of (size * 2) in a moment
CLRF 0x17, 1
No.

You are using a Salvo library with Salvo's global objects qualified as "far", i.e. not in the access bank.

code:
#define OSLIBRARY_GLOBALS OSF

Therefore the Salvo objects (including the message queue control block) will be located in banked memory (not in access RAM). (See Libraries Chapter for more info).

Maybe what is happening is that there is a 'pointer type mismatch' between what the library code expects to see via-a-vis messages (everything in banked RAM) and what you application is presenting to it (apparently something in access RAM).

So, the problem is probably in a declaration somewhere. Whenever a compiler supports different memory models, pointer types, etc. this kind of thing crops up. I'm sure we can figure out what is wrong ...

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

-------
aek
aek
 
Posts: 1886
Joined: Sat Aug 26, 2000 11:00 pm

Re: Bug in MPLab-C18 standard libraries?

Postby gerardlt » Wed May 14, 2003 11:20 am

Hi Andrew,

In order to protect my client's privacy/IP, I'll have to send a cut down version. That should make it easier to see what's going on anyway. I may be a little while producing it though.

I'm using Salvo Pro, so I'll do a source code build and see what that throws up.

Cheers,

------------------
Gerard Thornley
Electron Software

Gerard Thornley
Electron Software
gerardlt
 
Posts: 14
Joined: Tue May 13, 2003 11:00 pm
Location: Lancaster, UK

Re: Bug in MPLab-C18 standard libraries?

Postby aek » Wed May 14, 2003 11:37 am

Hi Gerard.
quote:
I'll have to send a cut down version
Since it is immediately visible at the message-creation stage, you can probably cut it down to something really small, like just a series of OSInit(), OSCreateXyz() calls ... be sure to send the project file(s), too.

Regards,

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

-------
aek
aek
 
Posts: 1886
Joined: Sat Aug 26, 2000 11:00 pm

Next

Return to Bug Reports

Who is online

Users browsing this forum: No registered users and 2 guests

cron