• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 626 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320C6412: SWI_inc BIOS API usage

Jim Paul
Prodigy 240 points
Part Number: TMS320C6412

Hi

I'm debugging legacy C6412 code that predominantly uses SWI's. 99% of the calls are SWI_post(), and there are a few SWI_or() calls. The version of RTOS is bios_5_31_02.

I'm changing a few SWI_post() calls to use SWI_inc() instead, and reading the mailbox (SWI_getmbox) inside the SWI object function to determine how many SWI interrupts are occurring. I'm making this change since I suspect that there is more than one SWI interrupt occurring when the problem occurs.

However, I can compile and link, and download onto target. The DSP loads and starts executing, but my application basically stops responding when it hits the first SWI_inc() call.

Note there is no issues if I use SWI_post() and SWI_getmbox in the SWI_object function - even though SWI_getmbox is of no use since SWI_post() doesnt modify the mbox. This is just extra info.

I have read and re-read the C6000 DSP/BIOS guides.

Is there anything subtle that I need to do to use SWI_inc() instead of SWI_post() ??

Could there be any issue because with SWI_inc we are treating the mailbox as a counter as opposed to a bit map (SWI_or) or not at all (SWI_post)?

Is there anything else I need to initialise before using SWI_inc, maybe in the tcf file?

Anything that needs initialised since I am using the mbox as a counter with SWI_inc()?

Just looking for ideas....

Thanks

Jim

  • 0
    TI__Mastermind 27355 points

    Hi Jim,

    Do you have access to the ROV view? In CCS, Tools > ROV Classic. Do you see any errors there? 

    I'm looping in the SYS/BIOS team to assist with this. 

    Regards,
    Sahin

  • 0 in reply to Sahin Okur
    TI__Guru* 96960 points

    Hi Jim,

    If you are not using the mailbox counters in the SWI, SWI_post and SWI_inc are essentially the same. I don't see any bugs related to this area (I checked the newer release notes and the actual code). As Sahin suggested, I'd look at ROV (or it might be called KOV...depending on your CCS version). 

    I'd check your logic around the use of SWI_getmbox to see if the incremented value is causing a different execution path.

    Todd

  • 0 in reply to Sahin Okur
    Prodigy 240 points

    Hi Sahin, no I dont have access to the ROV view. This is a bare bones application now running directly on the target.

  • 0 in reply to ToddMullanix
    Prodigy 240 points

    Hi Todd,

    I dont have access to ROV / CCS. Thanks for verifying the debug history and functionality of SWI_inc() and confirming that it is essentially the same as SWI_post().

    The problem seems to be when the SWI_inc() call is made. If I just assign the return value from SWI_getmbox in the SWI object function it doesnt cause an issue, the main problem is the SWI_inc() call, this call just stops my application.

    As a minimum, similarly to when I use a SWI_post(), I'd expect a SWI_inc() call to also land on the SWI_object function, so I can check there first of all.

    Is there anything else that I should check in the SWI_object within the SWI_object_function (apart from the SWI_getmbox)?

    Is there an issue if I use SWI_post() for say the first few SWI_object function calls, and then later on change to using SWI_inc() with the same SWI_object function?

    Thanks

    Jim

  • 0 in reply to Jim Paul
    TI__Guru* 96960 points

    Jim Paul said:
    Is there an issue if I use SWI_post() for say the first few SWI_object function calls, and then later on change to using SWI_inc() with the same SWI_object function?

    That is fine with the kernel.

    You might want to confirm the SWI object is valid. With the SWI_inc, it is changing an internal field, so if it is not a valid handle, corruption will occur. Of course, if the object was invalid, I'd be surprised that you did not see an issue with the SWI_post since it is using internal fields also.

    Is there anyway to enable logging? 

    Todd

    [8/26 update: Marking this as TI Thinks Resolved due to no response from original poster.]

  • 0 in reply to ToddMullanix
    Prodigy 240 points

    Hi Todd, thanks. I dont have access to enable logging. I will try and check the validity of the SWI object. Maybe also try some of the other SWI_** functions.

    Jim

  • 0 in reply to Jim Paul
    Prodigy 240 points

    Todd et al, in relation to this problem, if my code executes a SWI_inc() call and jumps to an ISR that subsequently makes a SWI_self() call, I assume that the SWI_self() will be the same as making another SWI_inc() call (and not a different type...ie SWI_post())?

    Thanks

    Jim

  • 0 in reply to Jim Paul
    TI__Guru* 96960 points

    Hi Jim,

    I'm not quite following what you are saying. Where are you calling the SWI_inc from? A HWI, SWI or TSK? A SWI_self just returns the handle of the executing SWI. 

    Todd

  • 0 in reply to ToddMullanix
    TI__Guru* 96960 points

    Did this get resolved?