Cyclic timer resets processor

[mattwhillock]

Hello,

Subject says it all. But a few more details. I set the project up in Rowley's CrossStudio 2.2.1 as a library build which as far as I can tell prevents me from putting anything useful in salvocfg.h unless I change the library settings from:

#include <msp430.h>
#ifndef __SALVOCFG_H__
#define __SALVOCFG_H__

// From Application Note AN-23
#define OSUSE_LIBRARY TRUE
#define OSLIBRARY_TYPE OSL
#define OSLIBRARY_CONFIG OST
// In Application Note AN-23 these are defined like this:
//#define OSLIBRARY_TYPE OSF
//#define OSLIBRARY_CONFIG OSA

to

#include <msp430.h>
#ifndef __SALVOCFG_H__
#define __SALVOCFG_H__

// From Application Note AN-23
//#define OSUSE_LIBRARY TRUE
//#define OSLIBRARY_TYPE OSL
//#define OSLIBRARY_CONFIG OST
// In Application Note AN-23 these are defined like this:
#define OSLIBRARY_TYPE OSF
#define OSLIBRARY_CONFIG OSA

Now I can put in salvocfg.h

#define OSENABLE_CYCLIC_TIMERS TRUE

without a compile error. Whether this has any effect who can tell?

The timer code looks like this (#includes assumed):

in timers.h:
#define TIMER_TASK_TC OSTCBP(10)
void tc_task_timer(void);

in timers.c:
void tc_task_timer(void) {
P6OUT ^= BIT0; // Lets get that little led flashing
}

in main:
... init Salvo etc
OSCreateCycTmr(tc_task_timer, TIMER_TASK_TC, 128, 128, OSCT_CONTINUOUS);
...
__enable_interrupt();
while(1) { OSSched(); }

It all compiles and loads and resets when the tc_task_timer code is called (I can see the led flash very briefly before I hit a breakpoint back in the start of main. A breakpoint set at tc_task_timer's only line of code is not hit though..., eh?).
Any thoughts? All I can think of is that as it's still really a library build then nothing fancy like timers are allowed (as I can't normally change anything in salvo cfg.h). Do I need to set up a source project which looks like a nightmare?

Cheers,
Matt

[aek]

I set the project up in Rowley's CrossStudio 2.2.1 as a library build which as far as I can tell prevents me from putting anything useful

No, No, No.

1. The t-configuration libraries (see page 4 of http://www.pumpkininc.com/content/doc/m ... -ra430.pdf) include all of Salvo's basic functionality (all event types, all time services, and cyclic timers, to name just a few). Users should always use the -t libraries unless they are severely restricted on program space ... then one can "work backwards" to use successively smaller libraries (with fewer features): -a, -e, -d, or -m.

2. The Salvo 4 documentation is consistent (I believe) in stating that for library builds, the only valid settings in the salvocfg.h are:

Code: Select all

#define OSUSE_LIBRARY TRUE
#define OSLIBRARY_TYPE OSF|OSL
#define OSLIBRARY_CONFIG OSM|OSD|OSE|OSA|OST
#define OSTASKS L
#define OSEVENTS M
#define OSEVENT_FLAGS N
#define OSMESSAGE_QUEUES O

where L, M, N & O are the numbers of corresponding tasks and events that you desire. Again, these examples are presented in http://www.pumpkininc.com/content/doc/m ... -ra430.pdf entirely consistently on pp. 6-7.

3. The only difference between a library build and a source-code build for most applications is the fact that library builds do not have some of the esoteric configuration options enabled (like OSENABLE_OSSCHED_ENTRY_HOOK). The only difference between the free (Lite) libraries (OSLIBRARY_TYPE = OSF) and LE/Pro libraries (OSLIBRARY_TYPE = OSL) is that the latter are unrestricted in the number of tasks and events that are supported, and that the latter (Pro libraries only) also include debug information that permits tracing through Salvo Source code when you're stepping through a Salvo application (and you have Salvo Pro).

When linking to a Salvo library, your salvocfg.h must include

Code: Select all

#define OSUSE_LIBRARY TRUE

. If you then invoke "illegal" configuration options, Salvo will flag it. But there are some other config options that aren't illegal that won't be flagged; given the way in which libraries are generated, there's not much that can be done about it. Therefore, the simple rule of thumb is up in #2 above -- those are the only entries you can have in your salvocfg.h for a library build. Building (successfully, even) with a salvocfg.h like you present will most likely lead to crashes at runtime, etc. That's because there is now a mismatch between the objects that the Salvo library expects to see and operate on, and the size / location / types of the Salvo objects that have been compiled into the application.

I would guess that 85% of Salvo Pro users use library builds ... starting with standard libraries, and then often building custom libraries, mainly to bump the size of delays up from 1 to 4 bytes (so you can do OS_Delay(THREE_MONTHS)). Very, very few users need the esoteric configuration options (which can be spun into custom libraries if need be).

Don't overthink it -- use a Salvo Lite -t library, use

Code: Select all

#define OSUSE_LIBRARY    TRUE
#define OSLIBRARY_TYPE    OSL
#define OSLIBRARY_CONFIG    OSF
#define OSTASKS      L
#define OSEVENTS      M
#define OSEVENT_FLAGS    N
#define OSMESSAGE_QUEUES   O

and enjoy all of Salvo's functionality. If you need the esoteric stuff, upgrade to Salvo Pro, and then do a source-code build or install Cygwin and build a custom library (see User Manual for more info).

[aek]

Sorry, that last salvocfg.h came through wrong, should be:

Code: Select all

#define OSUSE_LIBRARY    TRUE
#define OSLIBRARY_TYPE    OSF
#define OSLIBRARY_CONFIG    OST
#define OSTASKS      L
#define OSEVENTS      M
#define OSEVENT_FLAGS    N
#define OSMESSAGE_QUEUES   O

[mattwhillock]

Hi Andrew,,
Thanks for your reply. I think this bear with little brain is getting there...

So now I have in salvo cfg.h:
#define OSUSE_LIBRARY TRUE
#define OSLIBRARY_TYPE OSF
#define OSLIBRARY_CONFIG OST
#define OSTASKS 11
#define OSEVENTS 4
#define OSEVENT_FLAGS 4
#define OSMESSAGE_QUEUES 4

linking against Rowley's libsalvolra430x-t.hza.

The code compiles, links and runs except:
the firing of the cyclic timer causes a reset - see first post
events don't work - the receiving task never receives the event
message queues don't work - the receiving task never receives the message
but the tasks are whirring away quite happily in the test case without timers, events and queues.

What else do I need to do to get the timers and queues working?
To use size of delays of 2 or 4 bytes I need a source build - is that right?

Thanks for your help.

Cheers,
Matt

[aek]

Hi Matt.

1. You're using a Salvo Lite library, that is limited to 4 tasks and 8 events. I had to refer to the source code to find this, so I will see that future documents make this more clear.

2.

Code: Select all

#define OSEVENTS 4
#define OSEVENT_FLAGS 4
#define OSMESSAGE_QUEUES 4

Event flags and message queues are events -- you have a minimum of 8 events declared (4 eFlags + 4 msgQs), but have only allocated memory for four events.

3. The issue with cyclic timers on MPS430X targets is a real one and was identified by me back in January ... Salvo Pro users can get a source-code fix. Salvo Lite and LE users do not currently have a fix, and no timetable for said fix has been announced. If you have a non-X MSP430 (like an MSP430F1611), they will work on that target, as long as you link to a Salvo library that is for the non-X MSP430s.

[mattwhillock]

Hi Andrew,

1. You're using a Salvo Lite library, that is limited to 4 tasks and 8 events. I had to refer to the source code to find this, so I will see that future documents make this more clear.

2.

Code: Select all

#define OSEVENTS 4
#define OSEVENT_FLAGS 4
#define OSMESSAGE_QUEUES 4

Event flags and message queues are events -- you have a minimum of 8 events declared (4 eFlags + 4 msgQs), but have only allocated memory for four events.

3. The issue with cyclic timers on MPS430X targets is a real one and was identified by me back in January ... Salvo Pro users can get a source-code fix. Salvo Lite and LE users do not currently have a fix, and no timetable for said fix has been announced. If you have a non-X MSP430 (like an MSP430F1611), they will work on that target, as long as you link to a Salvo library that is for the non-X MSP430s.

1 Well that seems odd. We have Salvo Pro and I've had more than 4 tasks running I'm sure. I'll check again.

2 Aha. Yes, that will certainly play havoc with the code, thanks.

3 Eek! If I may please can I ask you for precise instructions for getting a source-code project working with Rowley 2.2? I've tried following an-23 but it really is too far out of date (for me to cope with anyway). Our program will need cyclic timers and long delays (not necessarily up to 3 months though ) so a Pro source code build is a must. We have the possibility of maybe a chance of using a 1611/2 instead of the 2618 so a non-x solution would get the cyclic timers but not the longer delays? (I think).

Thanks again for your help.

Cheers,
Matt

[aek]

Hi Matt.

1.

Code: Select all

#define OSLIBRARY_TYPE OSF

means that you have configured Salvo for a Lite library. However, you appear to be using libsalvolra430x-t.hza, which is a Salvo LE/Pro library. Please change your salvocfg.h to

Code: Select all

#define OSLIBRARY_TYPE OSL

for correctness.

3. I think for your sake, it would be easier to simply use a precompiled, custom library that supports cyclic timers properly on the MSP430X, and has 4-byte delays. I happen to have one for the MSP430F2618 handy (it also has a few extra hooks enabled -- you can simply create dummy functions for those). I will post the library, the salvoclc1.h and a sample, matching salvocfg.h to the Pro download area later today. Please review the section on custom libraries (mainly, how to use them) in the Salvo User Manual.

[mattwhillock]

Hi Andrew,

That's brilliant, thank you very much. My bacon has been saved

Thanks again,
Cheers,
Matt