• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 82 subscribers
  • Views 188 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.

TMS320F28388D: Debugging Hwi_unPluggedInterrupt being called during Task_restoreHwi

Joseph Keene
Intellectual 255 points
Part Number: TMS320F28388D
Other Parts Discussed in Thread: C2000WARE, SYSBIOS

Tool/software:

Hi TI Support,

I get a Hwi_unPluggedInterrupt about 1-2 times a day when running my code for 8 hours periods. The time is takes to generates this Hwi_unPluggedInterrupt varies each time. I do have Hwi and Swi enabled in my SYS/BIOS project. I am constantly triggering these Hwi and Swi that I created to pass information between the C28 and the Cortex M4, perhaps as fast as 1 msec. It is weird to me that I would randomly get a Hwi_unPluggedInterrupt. What are some causes to trigger this error? I have tried enlarging my stack sizes for my tasks, enlarging the .stack size, but none of it has helped. Whats even more weird is that it never does print the error statement its supposed to when you get a Hwi_unPluggedInterrupt, or the error statement for System_abort("xdc.runtime.Error.raise: terminating execution\n"); Don't know if thats related, but thought I'd state that. I'm happy to share my app.cfg file and my functions that are called in Hwi and Swi if needed. Here are some snapshots I captured using ROV of my heap and stack sizes, showing that they do look relatively safe. Thanks!

Code Composer Studio 9.3

Compiler: TI v20.2.3 LTS

C2000Ware 3.3.0.00

SYS/BIOS 6.83.0.18

XDCTools 3.62.0.08_core

  • 0
    TI__Guru 54265 points

    What interrupt is causing the Hwi_unPluggedInterrupt? Even if it's not printing the expected message, I think the function should have an intNum variable in it you can look at to find out? Knowing which interrupt is triggering it should help us figure out the cause of the issue.

    Whitney

  • 0 in reply to Whitney Dewey
    Intellectual 255 points

    Hi Whitney,

    I have set a breakpoint inside of that Hwi_unPluggedInterrupt function. The few times I have looked at the intNum variable, it seemed like it was garbage, because the intNum variable was >800. I'll try to get the exact number the next time it happens. As a side note, we discovered we weren't supplying enough amperage to the board, so we have increased that. We will continue running it and see if it happens, and if it does happen, I'll get the exact intNum, but once again, it was above 800 so I thought it was garbage. 

    Thank you!

  • 0 in reply to Joseph Keene
    Intellectual 255 points

    Hi Whitney,

    The intNum was 3367.

  • 0 in reply to Joseph Keene
    TI__Guru 54265 points

    That doesn't seem right as an interrupt number, but it might be the address in the vector table? 0xD26 is the address of the illegal instruction (ITRAP) interrupt. So it seems likely that the CPU jumped to some location that doesn't contain valid code, and since you haven't registered an ITRAP handler, it went to the Hwi_unPluggedInterrupt routine instead.

    Stack overflow/corruption is a fairly common cause of ITRAPs, but it's not the only possibility. Is ROV not reporting any errors?

    Whitney

  • 0 in reply to Whitney Dewey
    Intellectual 255 points

    Hi Whitney,

    Thanks for pointing me towards the ITRAP interrupt. I captured some more data for you. This picture below has a lot of data. To summarize, it shows my current breakpoint right after we set IntNum inside of Hwi_unPluggedInterrupt() in Hwi.c. The value of intNum is still 3367, which you pointed out to be the address of the ITRAP interrupt. Looking at the value of the PC register, I can see that its currently at 0x0A7CB2. I pulled up the memory location in the memory browser and can see that it looks like valid data is there. In the second picture below is a snippet of the relevant section in my memory map (.map). It looks like that address should be in this function: 000a7c8e    00000052     sysbios.ae28FP64 : BIOS.obj (.text:ti_sysbios_family_c28_Hwi_unPluggedInterrupt__I). 

    Let me know if I am debugging that wrong, but I thought after an ITRAP interrupt was generated, the memory location from where it was generated from would be stored in the PC register? 

    ROV is not reporting any error. My stack sizes all appear to be normal, as you can see in the bottom right in my ROV View in the first picture. Please let me know if you have any other ideas. I'm wondering if I should think about upgrading my version of SYS/BIOS, as I am using one from a few years ago. Thanks!

  • 0 in reply to Joseph Keene
    TI__Guru 54265 points

    Hi Joseph,

    Thanks for you patience. Were you able to make progress on this?

    You might be able to create a Hwi for the ILLEGAL interrupt (interrupt number 19) and then in your Hwi function you could call Hwi_getIrp().

    There's some discussion on this subject at the thread below:

    https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1538037/launchxl-f28p55x-how-to-get-instruction-return-pointer-in-f28p55x/5919056#5919056

    If you can't create a Hwi, you could plug a regular ISR, and use the stack method I mention in that post.

    Whitney

  • 0 in reply to Whitney Dewey
    Intellectual 255 points

    Hi Whitney,

    No, we haven't made any progress on this. I have been trying older revisions of my code, but I am still getting this error. I tried to make a HWI for interrupt number 19 using app.cfg, but the app.cfg is throwing an error: ti.sysbios.family.c28.Hwi : Vector ID = 19 is not a valid vector ID 

    Looking at Hwi.xs, I can see that it will throw an error if I try to register an interrupt between 16 and 31: 

    Here is my relevant section from my app.cfg:

    Let me know if I'm doing it wrong.

  • 0 in reply to Joseph Keene
    TI__Guru 54265 points

    I'm not sure why it doesn't support those interrupts. You might just have to use Hwi_plug() or write it to the vector table yourself instead. In that case you probably won't be able to use Hwi_getIrp, but as mentioned above, in the case of a regular interrupt, the return location can be found on the stack.