RTOS/MSP432P401R: Delay Getting Mailbox Items

Have you looked at this tutorial?

EDIT : Also, there is an example here: 

You will see the messages being passed between overSampleADC.c and firDecimation.c.

Regards,

Chris

I took a look. It seems pretty basic. I actually went through the one at 

https://training.ti.com/ti-rtos-workshop-series

Eric went into much more detail and was specific to the TI RTOS. (Your example doesn't even have the correct number of arguments to mailbox_pend!) I used SYSBIOS in a past life and I'm just trying to get it working properly on the MSP432. 

Actually I was looking for a tutorial for the system analyzer. I'd like to know where the CPU is during the 100msec. 

Kevin,

What version of TI-RTOS are you using?

Is it possible for you to post your test case so we can look at it?  If not, can you post some snippets showing your app configuration and your calls to the mailbox APIs?

Thanks,
Scott

I'm using 3.10.0.8 of simplelink. The XDC is 3.55.0.11

I declared an HWI for this function to generate the mailbox event:

/* Serial command UART */
extern ti_sysbios_knl_Mailbox_Handle radio_uart_mbox;
void USCI_Serial_Cmd_ISR(void){
uint32_t status = MAP_UART_getEnabledInterruptStatus(EUSCI_A2_BASE);

// Process any rx
if(status & EUSCI_A_UART_RECEIVE_INTERRUPT_FLAG){
// Process any rx
char c = UCA2RXBUF;
Mailbox_post(radio_uart_mbox, &c, BIOS_NO_WAIT);
}
// Process any tx
if ((status & EUSCI_A_UART_TRANSMIT_INTERRUPT_FLAG) &&
radio_tx_head_ptr != radio_tx_tail_ptr){
// Move data to TX
UCA2TXBUF = *radio_tx_tail_ptr++;
radio_tx_fifo_rollover(radio_tx_tail_ptr); // Fix rollover
// See if we have anymore data
if (radio_tx_head_ptr == radio_tx_tail_ptr){
radio_disable_tx();
}
}
}

And from the body of the hi priority task, I loop getting the mailbox events. (I wiggle the LED when I get a character so I can watch on a logic analyzer when the characters arrive and know how long the delay is. I have some timeout code in place for abnormal conditions (verified on the login analyzer) and neither of my timeouts fire. (which is good)

// Get the message body
// See if the message has arrived
index = 0;
while (index < mm.len){
if (!Mailbox_pend(radio_uart_mbox,
&mm.data[index],
10)){
// Failed to get the rest of the message
PUTS_HAP("Message micro-timed out");
return;
}
DEBUG_LED_TOGGLE();
index++;
// Check for the complete timeout
if (timer_elapsed(msg_timer)){
PUTS_HAP("Message macro-timed out");
return;
}
}

The declaration of the HWI from the .cfg file:

var m3Hwi2Params0 = new m3Hwi.Params();
m3Hwi2Params0.instance.name = "serialCmdHandler";
Program.global.serialCmdHandler = m3Hwi.create(34, "&USCI_Serial_Cmd_ISR", m3Hwi2Params0);

And the declaration of the mailbox from the .cfg file: 

var mailbox1Params = new Mailbox.Params();
mailbox1Params.instance.name = "radio_uart_mbox";
Program.global.radio_uart_mbox = Mailbox.create(1, 100, mailbox1Params);

It almost acts like the ISR is not calling the RTOS at the end which would mean the context switch after the post was not happening. But I stopped in the ISR and singled stepped to see if I went to the RTOS and it did indeed go there. (And the call stack was consistent with having the RTOS in front of my ISR routine.

I will try to reduce my code to the minimal to try and focus the effort and so I can send the entire thing.

Kevin,

Thanks for sending these.  

The only thing that I notice is that there is no check of the return value of Mailbox_post() in the ISR.  It looks like there are 100 messages allocated, and you are expecting bursts of 20 characters, so this seems sufficient.  But still, if you add a check to be sure Mailbox_post() is always returning TRUE, does that make a difference?

Also, for your SDK version, I don’t know of a recent tutorial.  There are some tutorials from a few years back (processors.wiki.ti.com/.../System_Analyzer_Tutorials_(CCSv6)) but I don’t know what may have changed since then.  Have you reviewed the System Analyzer User’s Guide (software-dl.ti.com/.../spruh43f.pdf)

Thanks,
Scott

I didn't check the return because all I could do in that situation is drop the character, which is what happens (the mail message box doesn't get posted). Since my messages get through in their entirety, they are posting correctly.

Initially I had only room for a few messages. I thought that because the task was the highest priority, it would empty the queue immediately; no need for much storage. But then I discovered I was dropping characters because the RTOS wasn't calling my task in a timely fashion.  So I added storage and the messages are getting through but there is still a delay. 

Wow CCSv6 is three major releases old! But I did get the system analyzer running. It hasn't been too helpful quite yet. I need to study what its telling me to understand it better. (Its why I started being worried about the ISR calling the RTOS. It is though.)

Step 2 can't be selected (its a menu section and not an item). Was there an item I was supposed to select?

Step 3. does nothing when I select "Interrupt Profiling"

I was using CCSv8.  I just tried with CCSv9 and see that step 2 is no longer necessary.

If you select “Tools->Hardware Trace Analyzer->Interrupt Profiling“ nothing happens at all?  Or you are not seeing any data in the views?

With CCSv9 I select interrupt profiling then get this:

I click Start and then this pops up:

Then the views open at the bottom of the CCS window.  There is no data yet until I run, wait, halt.

If you are seeing nothing at all, can you tell me your CCS version number (Help->About Code Composer Studio)?

I installed a new copy of code composer without improvement. But then I created a new workspace and imported the project there and it worked. Code composer has always been rather "brittle" but I think this is the first time the issue was with the workspace itself. I did discover I still had the ADC enabled but after correctly shutting it down, nothing has changed. 

What is PENDSV? it has one of the highest counts. Otherwise I think it looks ok.

Any other suggestions? 

The System Analyzer, Interrupt profiler, and ROV are the primary tools used to help debug/visualize program execution.  If those aren’t helping then adding SW instrumentation and/or GPIO toggling can sometimes help.  And also to try to simplify the application to reduce possible trouble spots.  You mentioned putting together a test case that we could debug.  Is this still possible?

pendSV is an exception that is often used by OS kernels to manage context switching.  With SYS/BIOS it is used by the Hwi dispatcher to trigger execution of a Swi that is posted from a Hwi, or to trigger Task preemption if the Hwi has made a kernel call that readies a Task of higher priority than that of the interrupted Task.

Kevin,

Can I mark this as resolved?

Todd