intr# 19 on TMS320F28335

Nathan Smith

Other Parts Discussed in Thread: TMS320F28335, SYSBIOS

I am using:
TMS320F28335, CCS Version: 5.4.0.00091, BIOS 6.40.02.27

and I am getting the following error:

ti.sysbios.family.c28.Hwi: line 947: E_unpluggedInterrupt: Unplugged interrupt flagged: intr# 19
xdc.runtime.Error.raise: terminating execution
ti.sysbios.gates.GateMutex: line 97: assertion failure: A_badContext: bad calling context. See GateMutex API doc for details.
xdc.runtime.Error.raise: terminating execution

My idle forces an eCAP interrupt, and the ISR sets a flag variable and clears the interrupt. I can step through the code and get it to trigger the interrupt once, but after that it throws the above error. I have looked at other posts about this error, but I'm not using a print in my interrupt and I'm using SysMin. I think it might have to do with conflicting memory locations, but I'm not familiar enough with the chip or SYS/BIOS to change things from the default (I'm not using any external memory).

I'm happy to provide more information. Do you have any suggestions?

over 11 years ago

0 ToddMullanix over 11 years ago

TI__Guru* 96960 points

Are you

1. Letting SYS/BIOS completely manage the interrupt (e.g. Hwi create and not a zero-latency interrupt)

2. making it a SYS/BIOS zero-latency interrupt (e.g. Hwi create and a zero-latency interrupt)

3. Not having SYS/BIOS do anything with the interrupt (e.g. using the interrupt keyword)

If #2, make sure are not using any SYS/BIOS calls in the interrupt.

#3 is not allowed in a SYS/BIOS application.

GateMutex is not allowed to be used in any interrupt. It calls a Semaphore_pend which might be blocking and is therefore not allowed in an interrupt. I think is error is a fall-out of the unplugged interrupt.

Todd

0 Nathan Smith over 11 years ago in reply to ToddMullanix

Intellectual 620 points

It was #3: I was using the "interrupt" keyword in my function declaration.

0 Jawwad Hafeez over 9 years ago in reply to ToddMullanix

Intellectual 870 points

Hi,

I got here after searching through posts because i face a similar problem. I could not find a document that clearly states what u stated above. To me it means that if I have to use Sysbios I must use choice 1, bec 2nd puts a hard limit of not using semaphore, events etc calls. 3rd is not allowed.

Is my understanding correct. I am porting an existing non sysbios project that uses a lot of interrupts to sys bios. So i have to make number of changes even for interrupts that have nothing to do with sysbios timers apparently.

plz comment, i will highly appreciate your help and info, links what ever that can expedite my porting work.

Regards

Jawwad

0 ToddMullanix over 9 years ago in reply to Jawwad Hafeez

TI__Guru* 96960 points

Can you please start a new thread? You can reference this one.

Todd

0 ScottG over 9 years ago in reply to ToddMullanix

TI__Mastermind 26780 points

Jawwad,

If your ISR will be posting Semaphores or making other SYS/BIOS API calls that trigger scheduling, yes, you are limited to option #1.

You said:

Jawwad Hafeez said:

I am porting an existing non sysbios project that uses a lot of interrupts to sys bios. So i have to make number of changes even for interrupts that have nothing to do with sysbios timers apparently.

If these interrupts do not make SYS/BIOS API calls that trigger scheduling you can use option #2, zero-latency interrupts.

With a runtime function call, option #3 can work too, again as long as the ISRs don’t make SYS/BIOS API calls that trigger scheduling. During app startup you can call Hwi_plug() to install your interrupt-keyword ISR function directly into the vector table. You can find some documentation for Hwi_plug() by navigating to the "docs" subdirectory of the SYS/BIOS installation, opening "Bios_APIs.html", and then navigating to the module: ti.sysbios.family.c28.Hwi

If you have additional questions or issues please open a new forum thread.

Thanks,
Scott

Processors

Processors forum

intr# 19 on TMS320F28335