Mailbox memcpy hangs

Hi Marshall --

Can you try making your messages length 4 or 8?   Be sure that the pointer you pass to Mailbox_get() points to a buffer of matching size.   I haven't seen a problem like this but maybe there's a problem with message size 1.

Are you creating the Mailbox in the C source code?  Or are you doing it in the configuration tool?

-Karl-

Thanks for the reply Karl!

I am creating the mailbox and tasks statically, in the configuration tool. I tried both length 4 and 8 messages and have the same symptoms. I assume by Mailbox_get() you mean Mailbox_pend()? I don't see any documentation on Mailbox_get().

Here's an example of my extremely simple task!

void exRead(Mailbox_Handle myMail)
{
   unsigned char message[8];

   while (1)
   {
      Mailbox_pend(myMail, &message, BIOS_NO_WAIT);
   }
}

//edit

I just changed priorities so that the Mailbox_post() runs first with message size 8. Post runs fine (with timeouts NO_WAIT and WAIT_FOREVER), but as soon as I run pend() it locks up. Does post() not use memcpy()?

Hi Marshall,

You should be passing message, not &message.

Mailbox_pend(myMail, message, BIOS_NO_WAIT);

What does your post look like?

Todd

Thanks for the reply Todd, After wrestling with my debugger all day trying to get it to connect to the target, I finally got to try the new fix. My Mailbox_post() is below. I corrected the &message here as well. I don't care what the data is at this point.

void exWriter(Mailbox_Handle myMail)
{
   unsigned char message[8];

   while (1)
   {
      message[0] = 0;
      message[1] = 1;
      message[2] = 2;
      message[3] = 3;
      message[4] = 4;
      message[5] = 5;
      message[6] = 6;
      message[7] = 7;
      Mailbox_post(myMail, message, BIOS_WAIT_FOREVER);
   }
}

I get the same results from before (stuck in memcopy of Mailbox_pend).

Hi Marshall,

Have you looked at the contents of ROV? Here is what mine looks like after I do one Mailbox_post. I statically created the mailbox with one message.

Can you check your system and Task stacks in ROV to see if they are blown?

Note: the Mailbox_post copies the message into the buffer and the Mailbox_pend copies it out into the supplied buffer.

Todd

Thanks for following up Todd.

I cannot for the life of me reproduce the error where I do a Mailbox_post() followed by the Mailbox_pend() where the disassembly hangs in memcpy. The biggest struggle has been the emulator connectivity and having to reset my whole system what feels like hundreds of times today. This alone makes me feel something with my setup is very wrong.

1) I can and did reproduce the memcpy hang by going straight to Mailbox_pend(). By investigating ROV my stackPeak cells in Tasks are red! This indicates the SP is out of range in my Writer and Idle tasks which have never run according to my breakpoints. So I bump them up from 2048 stack size to 32768. I include a full screenshot of CCS just for completeness if you can spot something else horribly wrong. All 3 tasks are reporting SP out of range with the increased size and the stack peak is nowhere near the max size.

2) Now secondly, Mailbox_post() is failing. As soon as it executes my program crashes and exits with abort().

If you hover your mouse over the redness, I suspect the text displayed is "Hwi Stack Overrun!", which indicates that your interrupt stack is too small.

If you switch to the Task Module ROV view, it will show you the size and current depth of the Hwi stack.

You can correct this by increasing the value you have for Program.stack in your config file.

Alan

I actually get a stack pointer outside of stack error:

My HWI stack looks fine:

Hi Marshall,

Did you get the ROV snapshots when you were in main()? It looks like something is fundamentally wrong with your application. Your instance and module views for Task don't make sense.

Are your tasks created dynamically (e.g. Task_create) or statically (e.g. in the .cfg file)?

Can you attach the .map file? If this is just a small example, can you include the source files (i.e. .c, .cfg, .cmd files) also.

Thanks,
Todd

Your previous ROV snapshot shows that you were halted within Task_SupportProxy_start().

This means that you were looking at the Task objects and Task module state before the Tasks had finished being initialized.

Please show us how the ROV views look after you've arrived at main().

Alan

ToddMullanix said:

Hi Marshall,

Did you get the ROV snapshots when you were in main()? It looks like something is fundamentally wrong with your application. Your instance and module views for Task don't make sense.

Are your tasks created dynamically (e.g. Task_create) or statically (e.g. in the .cfg file)?

Can you attach the .map file? If this is just a small example, can you include the source files (i.e. .c, .cfg, .cmd files) also.

Thanks,
Todd

Todd -

I have 5 breakpoints. One is on BIOS_start in main() (hello.c). I have 2 in Reader.c where Mailbox_pend() is (before and after). I have 1 in Writer.c on Mailbox_post(). I do hit BIOS_start and I do hit Mailbox_pend(). I never hit Mailbox_post() because my Writer task *SHOULD* never execute (lower priority).  I do NOT hit the breakpoint after Mailbox_pend(), but instead when I resume execution my program continues forever. I hit the pause button and here is [usually] where I am. SPKERNEL command in disassembly which if I scroll up I can see is in "memcpy". If I assembly step through Mailbox_pend() I can watch myself get to this point.

So to answer your questions:

No I was not in main(). I think I was in Mailbox_pend() in my Reader task. When I stop in main() my ROV looks identical without the SP out of bounds error.

Tasks are created statically, using the configuration tool. Same with my mailbox which is passed into the tasks as arg0.

The example began from the hello world example code. I then started to try to integrate a simple mailbox consumer/producer and that's where I am now. Yes it is small and attached is my whole project (the .map is in the Debug directory). This project was made fresh yesterday and I think I made it with more appropriate settings so that I didn't have to do the strange .cmd setting changes I mentioned in my first post (and there is no .cmd file in the project).

4011.MailboxExample.zip

Your previous ROV snapshot shows that you were halted within Task_SupportProxy_start().

This means that you were looking at the Task objects and Task module state before the Tasks had finished being initialized.

Please show us how the ROV views look after you've arrived at main().

Alan

Alan -

I'm halted on BIOS_start in main(). Please see above for description of how I got to the error.

Since my screenshots have looked like something is fundamentally wrong, I'm sure I have some crazy project setting wrong. I am connecting to an OMAP L138 in circuit. We currently have our solution for the DSP implemented in CCSv3.3 and are working on upgrading to CCSv5. We previously used Streams in DSP/BIOS but the way we use them doesn't look possible in SYS/BIOS anymore. Thus I am investigating using Mailboxes instead. I am connecting to our current solution (which probably has ARM code running unless the emulator does something to kill it when it connects). 

Thanks for your input!

Marshall

I removed a waiting for loop after Mailbox_pend() that I had added just to put a breakpoint after Mailbox_pend().

Now after when I execute the program I hit my breakpoint in main() on BIOS_start, then I hit my reader Mailbox_pend() and then I hit BIOS_start() again, following by Mailbox_pend() again??! After this the program must crash. When I hit pause it looks like I am now in Hwi_initStack.

This has become such a mess to perform something that should be so simple. I can't really get any consistent results or data so I feel like I'm just fire-hosing data at you guys, sorry for that.

Alan -

Yes! Mailboxes appear to be functioning as I expected now. I'm accustom to making changes to the config file in DSP/BIOS, but I thought the SYS/BIOS config tool was pretty nice to use. After making the source code change you gave me, I see that in the tool Argument 0 turns out to be "ti.sysbios.knl.Mailbox.Instance#0". I will remember this syntax for the future.

Don't apologize for the trouble, I was the one causing it. Thanks for your time and troubleshooting.

Marshall