Pumpkin, Inc.

Pumpkin User Forums

Salvo Pro dspic 4.2.2: Resets While Mainline Scheduler

For issues specific to the PIC24 MCU and dsPIC DSC line of microcontrollers from Microchip, including compiler (e.g. MCC 30) and IDE (e.g. MPLAB) issues.

Salvo Pro dspic 4.2.2: Resets While Mainline Scheduler

Postby jc_hsfl » Thu May 29, 2014 6:27 pm

Aloha,

I'm starting to gather more data about a problem I'm having with our application code resetting. It looks like the reset problem we're having all has a common path, which is the scheduler running in the mainline code. We're using the stock dspic-4.2.2 library (libsalvolmcc30lit.a), compiling with XC16 v1.21 w/ [large code/data/scalar models, no optimization, 'define C macros' "OSMCC30_LARGE_CM"]

salvocfg.h:
Code: Select all
// Library Specification
#define OSUSE_LIBRARY        TRUE
#define OSLIBRARY_TYPE       OSL
#define OSLIBRARY_CONFIG     OSA

// Compile Time Options
#define OSCOMPILER              OSMPLAB_C30
#define OSEVENTS                6
#define OSEVENT_FLAGS           6
#define OSMESSAGE_QUEUES        20
#define OSTASKS                 25


We have a few main tasks we selectively turn on/off to see what conflicts with eachother.
Code: Select all
#define TASK_UART_RX_PROCESSING1_TCBP  OSTCBP(1)
#define TASK_UART_RX_PROCESSING2_TCBP  OSTCBP(2)
#define TASK_UART_RX_PROCESSING3_TCBP  OSTCBP(3)
#define TASK_UART_RX_PROCESSING4_TCBP  OSTCBP(4)
#define TASK_TASK1_TCBP  OSTCBP(5)
#define TASK_TASK2_TCBP  OSTCBP(8)
#define TASK_TASK3_TCBP  OSTCBP(9)
#define TASK_TASK4_TCBP  OSTCBP(13)
#define TASK_TASK5_TCBP  OSTCBP(20)


In the mainline code, the following causes a scheduler run in the mainline code to reset the MCU.
Code: Select all
// Create tasks.
OSCreateTask(task_uart_rx_processing_1, TASK_UART_RX_PROCESSING1_TCBP, 5);
OSCreateTask(task_uart_rx_processing_2, TASK_UART_RX_PROCESSING1_TCBP, 5);
OSCreateTask(task_uart_rx_processing_3, TASK_UART_RX_PROCESSING1_TCBP, 5);
OSCreateTask(task_uart_rx_processing_4, TASK_UART_RX_PROCESSING1_TCBP, 5);
OSCreateTask(task_task1, TASK_TASK1_TCBP, 5);
OSCreateTask(task_task2, TASK_TASK2_TCBP, 5);
OSCreateTask(task_task3, TASK_TASK3_TCBP, 5);
OSCreateTask(task_task4, TASK_TASK4_TCBP, 5);
OSCreateTask(task_task5, TASK_TASK5_TCBP, 5);


Commenting out certain combinations of tasks will result in successful runs. Eventually, combinations of these tasks can be found in where every individual task is successfully run. Inside the tasks, there are OS_Yield() and OS_Delay() calls, and all variables are either global, global volatile, or static.

The mainline scheduler code is being run as provided in the CSK example:
Code: Select all
    while (1) {
        OSSched();
    }


Another interesting behavior is that sometimes a working combination can be broken (resulting in the same reset after returning to the scheduler), if within a task, OSDelay() functions are introduced or moved within previously successful code.

Here's an example output of the OSRpt(). The task numbers aren't matching up with the TCBP numbers.
Code: Select all
Salvo 4.2.2  Ticks: 7677
EligQ:
DelayQ:    ,     Total delay: 70 ticks
task stat prio    addr   t->  e->  d-> delay
  4  stop   6  00000000    .    .
  6  stop   0  00000000
  7  elig   5  00000000    .  n/a

evnt type t->    value
  1  BSem   .        0
  2  BSem            0
  3  BSem   .        1
  4  BSem            0
  5  dstr
  6  dstr


Would these all be good indicators that the task control blocks are being corrupted? The report used to come out quite coherent for the small code/memory model library.
jc_hsfl
 
Posts: 16
Joined: Fri May 23, 2014 2:25 am

Re: Salvo Pro dspic 4.2.2: Resets While Mainline Scheduler

Postby aek » Thu May 29, 2014 7:06 pm

Code: Select all
OSCreateTask(task_uart_rx_processing_1, TASK_UART_RX_PROCESSING1_TCBP, 5);
OSCreateTask(task_uart_rx_processing_2, TASK_UART_RX_PROCESSING1_TCBP, 5);
OSCreateTask(task_uart_rx_processing_3, TASK_UART_RX_PROCESSING1_TCBP, 5);
OSCreateTask(task_uart_rx_processing_4, TASK_UART_RX_PROCESSING1_TCBP, 5);


should be
Code: Select all
OSCreateTask(task_uart_rx_processing_1, TASK_UART_RX_PROCESSING1_TCBP, 5);
OSCreateTask(task_uart_rx_processing_2, TASK_UART_RX_PROCESSING2_TCBP, 5);
OSCreateTask(task_uart_rx_processing_3, TASK_UART_RX_PROCESSING3_TCBP, 5);
OSCreateTask(task_uart_rx_processing_4, TASK_UART_RX_PROCESSING4_TCBP, 5);
-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: Salvo Pro dspic 4.2.2: Resets While Mainline Scheduler

Postby aek » Thu May 29, 2014 7:22 pm

BTW, if you write task_uart_rx_processing() properly, you can ultimately do this:

Code: Select all
OSCreateTask(task_uart_rx_processing, TASK_UART_RX_PROCESSING1_TCBP, 5);
OSCreateTask(task_uart_rx_processing, TASK_UART_RX_PROCESSING2_TCBP, 5);
OSCreateTask(task_uart_rx_processing, TASK_UART_RX_PROCESSING3_TCBP, 5);
OSCreateTask(task_uart_rx_processing, TASK_UART_RX_PROCESSING4_TCBP, 5);


In task_uart_rx_processing(), you need to use pointers to the various objects you're working with (e.g. incoming Rx buffers, local buffers, other SFRs, etc.). You can do this by e.g. having an array of pointers, that you access via OStID(), which gives you a unique index (for the task you're in) ...

It's an advanced topic, to be sure, but if your code is essentially identical across the four functions, then it cleans things up nicely.
-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: Salvo Pro dspic 4.2.2: Resets While Mainline Scheduler

Postby jc_hsfl » Thu May 29, 2014 7:34 pm

Thanks, that does make sense.

Unfortunately in our case, we've got 4 unique protocol processing routines to tie different things together, so we couldn't do a sleek design like that. Live and learn I suppose.

Meanwhile, I've started experimenting with dspic 4.2.2-rc6 and 4.3.0-rc1, and am on the way to getting the source compilation attempted again with the new distributions. I'll post an update if the different libraries helped.
jc_hsfl
 
Posts: 16
Joined: Fri May 23, 2014 2:25 am

Re: Salvo Pro dspic 4.2.2: Resets While Mainline Scheduler

Postby aek » Thu May 29, 2014 8:56 pm

You missed the solution to your problem (see above, viewtopic.php?f=21&t=2530#p5977).
-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: Salvo Pro dspic 4.2.2: Resets While Mainline Scheduler

Postby jc_hsfl » Thu May 29, 2014 9:37 pm

Oh!

Thanks, looks like I slipped up while troubleshooting (and reading the post).
jc_hsfl
 
Posts: 16
Joined: Fri May 23, 2014 2:25 am

Re: Salvo Pro dspic 4.2.2: Resets While Mainline Scheduler

Postby jc_hsfl » Fri May 30, 2014 1:15 am

Update:

I tried out the precompiled libraries for dspic 4.2.2-rc6 and 4.3.0-rc1, and I kept on having the OsRpt() giving essentially a corrupted task table. I tested this by emptying out my entire program, adjusting OSTASKS, OSEVENTS, and other library build options. I then started slipping in simple tasks like this one:

Code: Select all
void simple1(void)
{
    while(1)
    {
        uart2_msg("Simple1");
        OS_Delay(200);
    }
}


The task table indicated incorrect information as soon as I used OSTCBP(2). I tried up to OSTCBP(7), and still had a bad task table.

After hunkering down and figuring out how to compile from source, I was able to get everything to compile. Compiling Salvo 4.2.2-rc6 from source has now resolved my resetting issue. Here's what my task table now looks like with my actual application code (vs the troubleshooting code):

Code: Select all
Salvo 4.2.2  Ticks: 32103
EligQ: t13,t20,t2,t3,t4,t8
DelayQ: t1  Total delay: 20 ticks
task stat prio    addr   t->  e->  d-> delay
  1  wait   3  0000FB0E    .  e 1    .    20
  2  elig   5  0000FBA6  t 3  n/a
  3  elig   5  0000C316  t 4  n/a
  4  elig   5  0000C6FC  t 8  n/a
  8  elig   5  0000E716    .  n/a
 13  elig   5  0000D9EA  t20  n/a
 20  elig   5  0000624C  t 2  n/a


Things are working so perfectly now, that I believe my issue is now resolved. Still not sure what was the issue with the libraries, but at least I can move past this!

Thanks for your suggestions!
jc_hsfl
 
Posts: 16
Joined: Fri May 23, 2014 2:25 am

Re: Salvo Pro dspic 4.2.2: Resets While Mainline Scheduler

Postby jc_hsfl » Fri May 30, 2014 1:53 am

For anyone troubleshooting the same problem, here's another note to help confirm the same or similar issue:

I'm using the CubeSatKit PPM D1 (PIC24FJ256GA110). When resetting, the RCON register shows TRAPR=1 with no other set flags.

Attempts to catch those traps were unsuccessful with the following code:
Code: Select all
 void __attribute__ ((interrupt,no_auto_psv)) _AddressError(void) // Address error trap
 {
    INTCON1bits.ADDRERR = 0;
    Nop();
    Nop();
    Nop();
    #ifdef GLOBAL_DEBUG_TRAPS
    asm (".pword 0xDA4000"); // Break
    #endif
 }

 void __attribute__ ((interrupt,no_auto_psv)) _StackError(void) // Address error trap
 {
    INTCON1bits.STKERR = 0;
    Nop();
    Nop();
    Nop();
    #ifdef GLOBAL_DEBUG_TRAPS
    asm (".pword 0xDA4000"); // Break
    #endif
 }

void __attribute__ ((interrupt,no_auto_psv)) _MathError(void) // Address error trap
 {
    INTCON1bits.MATHERR = 0;
    Nop();
    Nop();
    Nop();
    #ifdef GLOBAL_DEBUG_TRAPS
    asm (".pword 0xDA4000"); // Break
    #endif
 }

void __attribute__ ((interrupt,no_auto_psv)) _DefaultInterrupt(void) // Address error trap
 {
    //INTCON1bits.MATHERR = 0;
    Nop();
    Nop();
    Nop();
    #ifdef GLOBAL_DEBUG_TRAPS
    asm (".pword 0xDA4000"); // Break
    #endif
 }


I confirmed that the _DefaultInterrupt ISR was set in both the interrupt vector table, and alternate vector table.

Wasn't sure what else I could do to figure out where the processor was getting reset. The program counter just ends up at 0 while debugging, just after entering OSSChed().
jc_hsfl
 
Posts: 16
Joined: Fri May 23, 2014 2:25 am


Return to PIC24 & dsPIC

Who is online

Users browsing this forum: No registered users and 1 guest

cron