• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Subscribers 83 subscribers
  • Views 3070 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.

RTOS/TMS320F28377S: Source of Hwi_unpluggedInterrupt intr#19

Ruta Bhave
Intellectual 440 points

Part Number: TMS320F28377S
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

I am running a  SYSBIOS 6.75 project on my TMS320F28377S LaunchXL.

When I run the debugger, the code initially goes straight to reset vector 0x3FE493.

Then, I click on the Pause/Resume and do a CPU reset and restart. This time, the code executes up to main() and the instruction pointer enters the first line of main()

At this point, when I single-step into the main, eventually I land up with the ti_sysbios_family_c28_Hwi_unPluggedInterrupt__I(): being triggered and the console displays:

[C28xx_CPU1] enter main()
ti.sysbios.family.c28.Hwi: line 1032: E_unpluggedInterrupt: Unplugged interrupt flagged: intr# 19
xdc.runtime.Error.raise: terminating execution

I read on previous forum posts that intr#19 indicates an illegal action happened. Please note that at this point in my execution, I am:

-disabling the watchdog (in the main code and it is also disabled in the BIOS config)

-initializing system clock

-initializing GPIO ports and device peripherals.

I pulled the disassembly from the debugger and noticed the Timer Prescale executions before the unPluggedInterrupt() occurs. Is something wrong with the timer settings? I am using the same device clock configurations as in the device.c/.h files for the F28377x family, specific to LaunchPadXL.

Would appreciate some insights on the topic. 

  • 0
    TI__Guru* 96960 points
    Hi Ruta,

    What is interrupt 19? Did you configure it to run? If so, how did you do it?

    SYS/BIOS manages the vector table. You should use Hwi_create (or Hwi_construct) to create managed interrupts. If you want an interrupt to be unmanaged, you need to use Hwi_plug (and a couple other things) so the kernel knows about the unmanaged interrupt so it does not interfere with it. There's more details here about unmanaged interrupts (also called zero-latency since the kernel adds zero latency to then): processors.wiki.ti.com/.../BIOS_for_the_28x

    Todd
  • 0
    Intellectual 440 points
    software setup:
    CCS v8.3.0
    Compiler version TI 18.1.5.LTS
    SYSBIOS v6.75.01.05
    XDCTools v3.51.01.18
  • 0 in reply to Ruta Bhave
    TI__Guru* 96960 points
    Thanks for the info, but can you answer the questions I posted above?
  • 0 in reply to ToddMullanix
    Intellectual 440 points
    Hi Todd, Interrupt 19 implies an illegal action occurred. I checked the PIE vector address (0xD26 - Illegal Instruction/TRAP). I am not sure what is causing this illegal instruction based on the disassembly. I wonder if the timer configuration setup has anything to do with it?
    I am using an interrupt for the I2C_A module and I have configured the interrupt accordingly in BIOS- using Hwi_create([interrupt number], [&isr], [HwiParams]); and I can see the interrupt enabled in the PIEIER registers. I would like some help from the disassembly to figure out if a timer configuration is causing this illegal action trap.
  • 0 in reply to Ruta Bhave
    Intellectual 440 points
    Reference for PIE vector address - lit SPRUHX5F Delfino Microcontrollers Technical Reference Manual Section 3.4.6 [Vector Tables] p.90
  • 0 in reply to Ruta Bhave
    TI__Guru* 96960 points
    I doubt the timer has anything to do with it. I expect it just happens to be next to it.

    The kernel does not plug the illegal interrupt and you aren't either, so that's why the message is coming out. So what's causing the illegal operation? Can you try simplifying your code and see if it goes away? It sounds like you never make it to BIOS_start...is that correct?

    Todd
  • 0 in reply to ToddMullanix
    Intellectual 440 points
    Hi Todd, that is correct. I never make it to BIOS_start().
    Is there any way to "plug" this interrupt to avoid the issue? For now I cannot pinpoint the source of this illegal operation.
  • 0 in reply to Ruta Bhave
    TI__Guru* 96960 points
    You can create a Hwi for it. It will just get called when the illegal operation happens though. I'm not familiar with the debugging from there though. I'll ping the C2000 team to chime in since this really does not sound like a kernel issue.

    Have you tried removing code from main() to help isolate the issue?
  • 0 in reply to ToddMullanix
    Intellectual 440 points
    Ok.

    I will try removing code from main(), however all I'm doing in main() is calling some functions to initialize the board - disable watchdog, initialize system clock and board peripherals (which I need for the feature drivers I'm developing).
  • 0 in reply to Ruta Bhave
    TI__Guru 55105 points
    When you single step through the code, does the ITRAP happen at a consistent place? Can you narrow it down a specific function or line of code?

    One of the most common causes of this is calling a function in ramfuncs before it has been copied from flash to RAM. Do you have any functions like that?

    Whitney
  • 0 in reply to Whitney Dewey
    Intellectual 440 points
    I see. However I am actually doing the copy from flash to RAM before calling any functions in ramfuncs. The only thing that's done before the copy is disabling the watchdog.
    Also, the code behavior is not consistent. The first time the debugger is launched, it goes straight to the reset vector (0x3FE493). Upon resetting CPU and restarting, I am able to single step. The interrupt occurs just after enabling the peripheral clocks on the device and the code never enters BIOS_start()
  • 0 in reply to Whitney Dewey
    Intellectual 440 points

    Is it possible to narrow down on the cause of the reset by reading the RPC register?

    I am attempting to read the value of RPC register using a few assembly commands. I have included a few assembly instructions in a .asm file as such:

    <getRPC.asm>

    .global _getRPC
    _getRPC:
    PUSH RPC
    POP ACC
    LRETR

    and then declaring the function as an extern in one of my source files

    extern uint32_t getRPC(void);

    Now should this function be called in main()? Or if the reset occurs due to one of the functions called by main, should it be called locally within that function?
    Or is there any place I should set up a breakpoint to check the contents of RPC?

  • 0 in reply to Ruta Bhave
    TI__Guru 55105 points

    Have you made any progress in your debug? Getting the RPC should happen in the Illegal ISR. Have you plugged an ISR for interrupt 19 like Todd suggested?

    Also keep in mind that the RPC is where you're returning to, so the code that caused the issue is likely the line before the one corresponding to the RPC.

    Whitney

  • 0 in reply to Whitney Dewey
    Intellectual 440 points

    Thanks for the pointers, Whitney. 

    Since it was necessary to progress in my implementation, I created a new BIOS project and used/modified the correct linkers and ported my source files over to the new project. It seems to have been a problem with the linker files in the previous project, most likely an incorrect memory access.