posted May 23, 2003 10:30            

Here's a curious fact regarding the "CLRF 0x17,1" bug.

When I removed the msgq.c in my project's src directory from the project, and added the one from salvo's src directory, the bug manifested itself. When I switched back to the one in my project's src directory it disappeared.

I suspect it may have something to do with the relative directory names in my include path. Or maybe it's the phase of the moon... :-)

posted May 16, 2003 20:26            

Well, I don't understand why it "cleared up" in your installation whereas in mine the bank bug remained until I upgraded to v2.20. Maybe I missed something in the process ...

As you know, all of MPLAB-C18's upgrades have been free (which is nice). The only problems I see with v2.20 so far are the procedural abstraction problem (use -Opa- on all files that have Salvo tasks in them) and it appears that va_arg is broken in v2.20.

Yes, it would be helpful if you might identify how the problem disappeared. I don't like "hanging, mysterious" explanations.

The wierdness in debugging is almost certainly due to the optimizer. For reasons unknown to me (marketing?), MPLAB-C18's defaults to having its optimizations all ON. Most compilers play it safe and default to OFF. So that's probably what I was seeing ...

posted May 16, 2003 15:43            

I would hope the demo is no different from the full version, but there's no knowing...

I've got a full version 1.10 (I hope the 2.20 upgrade will work on that), which I've been holding off installing since your report of problems.

Given that we now have a workaround, I'll probably go ahead and install that. Since I've been able to work productively with the existing compiler, I could continue with it until I can identify the reason the problem disappeared if that would be helpful?

With respect to:

quote:

---

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

---

Regards,

posted May 16, 2003 13:57            

quote:

---

Well, when I added the msgq.c file to my project, it compiled correctly.

---

My tests with v2.1 showed the same problem. My tests with v2.2 solved the problem, but introduced the problem of the procedural abstraction optimization (enabled by default) -- see SB-17 for more info.

Regards,

posted May 16, 2003 13:09            

I have found the problem with MPLAB-C18 v2.20 and Salvo ... it's in the procedural abstraction optimization.

Specifically, if the Salvo context switcher OSCtxSw() is procedurally optimized, the code dies. See my post at microchip's dev tools forum for more info.

For now, MPLAB-C18 v2.2 Salvo users must apply the -Opa- switch to all source files that contain calls to OSCtxSw(), i.e. all source files with Salvo tasks in them.

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

posted May 15, 2003 02:37            

My guess is that I haven't set some options correctly, but there's obviously a workaround here somewhere.

I wonder if you could email my project back to me with the file included, so I can compare with my results.

Regards,

posted May 15, 2003 01:31            

Sorry it's taken a while to reply, it was getting a tad late here, and I'm trying to avoid all night debugging sessions. :-)

quote:

---

I must apologize for the gruffness of my previous response

---

That's ok. I might have been mistaken.

Problem re. MPLab versions seems a bit tricky.
I'll have a play around with compiler/linker options and see what happens. I think my time zone is ahead of yours, so I should have a few hours to muck around before you get this.

Many regards,

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

posted May 14, 2003 22:36            

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\tut\tu6\tu6.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.

posted May 14, 2003 17:03            

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

---

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

Regards,

posted May 14, 2003 15:59            

Before I forget,

code:

---

#define OSBYTES_OF_EVENT_FLAGS 1

---

Also, please do not copy \salvo\mem.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 \salvo\src.

quote:

---

No.

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

---

quote:

---

should be CLRF 0x17, 0 (0=access,1=BSR)

---

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

quote:

---

It looks to me like a compiler error when the library was built

---

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 \salvo\msgq.c to your project as a node (with your current salvocfg.h). Then, you can edit OScreateMsgQ() in \yourproject\msqq.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;

---

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 ...

posted May 14, 2003 12:37            

quote:

---

I'll have to send a cut down version

---

Regards,

posted May 14, 2003 12:20            

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,

posted May 14, 2003 12:12            

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

---

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

---

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 ...

posted May 14, 2003 12:04            

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,

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

posted May 14, 2003 11:48            

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

posted May 14, 2003 09:24            

quote:

---

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

---

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 \salvo\mem.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,

posted May 14, 2003 06:58            

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