• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 81 subscribers
  • Views 237 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.

TMS320F28069: external interrupt handle with SYSBIOS (acknowledge issue ?)

Sebastien Jacquart
Prodigy 50 points
Part Number: TMS320F28069
Other Parts Discussed in Thread: SYSBIOS

Hello 

I am currently facing some HWI overflow inside SYSBIOS scheduler and I cannot understand what would cause it.

My development is handling SPI communication through McBSP module to an external component. This component acts as slave on the SPI bus and indicates that data are ready to be read with dedicated "data_ready" interrupt wired to GPIO19. The GPIO is configured as asynchronous input with pull up enabled.

With a simple implementation on bare-metal using PIE and while loop this works fine.

  • HWI is configured using XINT to trigger some ISR that sets a flag and returns; IT is a pulse signal going low for ~20µs from 3.3V to 0V, issued periodically every 16ms.
  • The state machine inside while loop is pending on flag set by Hwi  (@16ms) then retrieve the data (6 * 32bits words) through SPI with SPICLOCK @500kHz and pend for next data_ready. 

I aim at importing this feature on another project with Sysbios activated (this is not my first sysbios project and I reused some existing project that is working fine), and CPU running at 36MHz.

I kept configuration of the XINT on app side : 

  • GpioIntRegs.GPIOXINT3SEL.bit.GPIOSEL =  GPIO19;
  • XIntruptRegs.XINT3CR. bit.ENABLE = 1

The HWI is configured through SYSBIOS Hwi (ti.sysbios.family.c28) with IT number 120 (XINT_3).

  • Automatically acknowledge IT option is selected.
  • IT is disabled at startup, enabled inside code through Hwi_enableInterrupt(120) once configuration is completed.
  • ISR function call is simplistic. As expected, I removed the interrupt keyword as well as any reference to PIE. I used to post semaphore inside this ISR but removed it to try to get to the bottom of my issue and replaced it with boolean flag bDataReady to TRUE.

On task side, my initial implementation was using a dedicated task with while loop and pending semaphore. It would end with the semaphore posted but the task preempted and sysbios lost in hwi scheduler.

To try to simplify this, I moved my function to Idle task with test on boolean flag bDataReady instead of semaphore to read data. 

The symptom of my issue is as follows: as long as the HWI is disabled, everything runs smoothly. When I activate the HWI (Hwi_enableInterrupt(120) + XIntruptRegs.XINT3CR. bit.ENABLE) then the sysbios keep spending time inside the sysbios low level feature and does not manage to service my application.

Breakpoints inside my tasks are not reached anymore ; only the one inside the Hwi toggles.

When I hit the pause button, I end up inside sysbios features such as Hwi scheduler (Hwi__epilogue.h, Hwi.c or assembly related features).

I manage to restore proper behavior if I manually disable the XINT HWI inside the ISR and enable it back once data were retrieved.. but this does not seem really sane behavior. It would seem that the IT is not properly acknowledged.

I attempted to add some qualifier to the GPIO with no success. 

I attempted to use the CPU load module from sysbios. It states in red 102 on the Hwi side.

What I am missing ? Is there some condition/configuration to ensure that sysbios properly ACK the XINT related Hwi ? 

Thank you for your time and best regards,
Sebastien

  • 0
    TI__Guru 50615 points

    Does calling the Hwi_ack() yourself in the ISR make any difference? The enableAck option should handle it for you but worth a try. Is setting the bDataReady flag the only thing your ISR is doing currently? There's no function calls or anything in there that could be taking an unexpectedly long time to execute?

    You said you were able to look at the load module--did you also look for any errors elsewhere in ROV? I think under BIOS -> Scan for errors... it can give a summary.

    Enabling the qualifier for the GPIO was a good thought. Are you able to look at the signal on an oscilloscope? Does it seem to be behaving as expected?

    I don't have a F28069 with me currently, but I quickly set up a Hwi for XINT3 on a different device and it behaved as expected. Setting hwiParams.enableAck = true was enough to handle the ISR. There shouldn't be anything special about it...

    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 50 points

    Hello and thank you for your answer.

    The ISR function is only setting the flag ; no function call or any other operation.

    I added the manual acq using ti_sysbios_family_c28_Hwi_ack(Hwi_getHandle(120));

    It was the closest I could find to some manual Hwi_acq function. This does not solve the issue though.

    The BIOS->scan for errors only reports the issue that I was already seing in the load module : "Error: Swi load computation resulted in out of range number: 102.35410622260052"  I don't use any specific Swi but this number 102 appears inside the Hwi_load section of the Load module, while Swi_load displays 0.0 (and cpu_load also is showing 0.0). 

    Is the ISR triggered by Hwi considered as an Swi  somehow? These functions are not defined as Swi anywhere but only defined in my application and reported as function calls of the Hwi instances.

    I activated the SWi module inside sysbios but nothing is instanciated there. So I would think this error message is itself incorrect and the out of range data corresponds to Hwi_load instead. 

    I don't have an oscilloscope at home but checking the signal's shape was the first thing I did last week when I first encountered the issue in the office. And the data ready signal was looking quite fine (no noise, period of 16ms and pulse of 20µs).

    As per my previous tests, I also tried to change the XINT from XINT1 to XINT3 to modify the PIE group involved and the priority. This did not modifiy the behavior.

  • 0 in reply to Sebastien Jacquart
    TI__Guru 50615 points

    You could also just write to PIEACK directly instead of calling the corresponding Hwi module function but it should essentially be the same thing. When you're stepping through the ISR and look at the PIE and IFR registers in the CCS Registers view, what do you see?

    I believe the Clock module will create a Swi even if you haven't created one of your own. That should show up in the Swi section of ROV. I wouldn't think that would have any impact on your Hwi though.

    Do you mind sharing the cfg file for your project?

    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 50 points

    Hello

    Looking into PIE as you suggested showed that the PIE IFR was always set.

    I had built a simplified cfg file to share with you (removing everything but this communication module triggered through XINT data_ready, and it was still failing) when I finally found the root cause.

    As it turned out, there was nothing wrong with sysbios nor with my implementation of it. The board routing was simply not the one I had been specified. Data_ready signal was indeed rooted to the test point that I had checked in oscillator, but was not routed to the specified GPIO. This GPIO was instead fed with high frequency signal causing the deadlock. 

    The previous "functioning" version without sysbios had been executed on another board and I was not aware of the differences. 

    So now that I use the proper GPIO, everything is working fine as expected.

    At least it gave me the occasion to dig into more details of sysbios configuration and module handle (even though this does not account to all the time lost). 

    Many thanks for your help my apologies for this non-existant issue. Knowing that it should work helped me reconsider other causes and question the specs I had. 

    Best regards

    Sebastien