• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 83 subscribers
  • Views 674 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Concerto F28M36x - IPC setFlag does not work always

Andreas Unterberger
Expert 1140 points
Other Parts Discussed in Thread: SYSBIOS

Hi,


a while ago I developed an IPC driver on basis of the lite-IPC example.

I reduced the functionality only to setting an IPC flag and waiting for an IPC flag on the other core.

As I'm testing it at the moment intensively I experience that sometimes the C28 core does not set the IPC flag correctly. My program hangs then in waiting for IPC-flag on M3 core.

Is there any way to secure that the IPC flag is set correctly?


EDIT: I just found out that it apears exactly on the 41st try to set the Flag, if after that the software tries to set the flag again, then it works again.

kind regards

Andreas

  • 0
    TI__Guru** 115881 points

    Hi Andreas,

    As I'm testing it at the moment intensively I experience that sometimes the C28 core does not set the IPC flag correctly. My program hangs then in waiting for IPC-flag on M3 core.

    Flag should get set unless other core is clearing the flag. Are you seeing this issue with any specific flag or all with all the flags?

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Expert 1140 points
    I only tested it for now with flag 17.
    In the program of core M3, it is just waiting for a set flag of this flag 17.

    Seems to be a bit strange... (I think so too that it should be set regardless of any other circumstances (except the clearing))
    But it can only be cleared if it is seen already as set by M3 isn't it?
    What is very strange is, that it occures always at the same number of IPC message transmissions.

    By the way, I also experienced sometimes a GateMutex Error of SYSBIOS but I don't use any GateMutexes ...
    My program only consists of one Task, which is never terminated. Only on the C28 core an ISR for the IPC is configured but not via the SYSBIOS app.cfg, only by setting the ISR to the corresponding vector table.
    I think this is a separate error which maybe has to do with the ISR, but do you think this has maybe something to do with it?

    regards
    Andreas
  • 0 in reply to Andreas Unterberger
    Expert 1140 points

    Update:
    I now tested it with a small demo project on the C28 core side. The same error occured but after about 190 transmissions.
    I then modified the IPC driver a little bit to separate the flag checking from the flag aknowledging into two different functions. There it seems to work without any problems after that.

    I then copied it to the main project and it now seems to work also here.

  • 0 in reply to Andreas Unterberger
    Expert 1140 points
    I suppose this is some problem with the pipeline, how can I utilize a fence for this?
  • 0 in reply to Andreas Unterberger
    TI__Mastermind 30255 points
    Andreas,

    Would you be willing to provide the small demo project which demonstrates the error you resolved by modifying the driver? This would help us look further into this issue and enhance our driver library.

    Best Regards
    Chris
  • 0 in reply to Christopher Chiarella
    Expert 1140 points
    Hi Chris,

    after the weekend I found out that this was not the solution, sorry. The code was in some ciricumstances waiting for the same flag 2 times but it was set only one time...
    In fact I don't know why it was working on friday with that solution.

    regards
    Andreas
  • 0 in reply to Andreas Unterberger
    TI__Guru** 115881 points

    Andreas,

    Does that mean you still have this issue? If yes, would it be possible to share the project which we could run on our setup to check the issue.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Expert 1140 points
    Vivek,

    no that means, I found the solution for this problem. But it was not the suggested answer from last week.
    The other core was clearing the flag very fast as it was not in debug-halt. But there was a second line where it was waiting a second time for the same flag, but as it was cleared already befor it was stuck in that place.

    regards
    Andreas