• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 513 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.

LM3S9D92 interrupts not running. sys/bios is stuck in idle.

Mike Volzer
Intellectual 990 points

Hello,

I'm having an issue with an LM3S9D92 part where in the NVIC there are interrupts enabled and pending but none of them are being serviced. More details below...

I'm running SYS/BIOS 6.34.04.22 and using the dispatcher for all of my interrupts. There are multiple interrupts being used in this system and many are pending. The System Control Block INTCTRL register VECPEND bits indicate that vector 24 (I2C0) is the highest priority pending interrupt. The I2C0 peripheral also thinks that there is an interrupt pending.

With that in mind I would expect the I2C0 interrupt handler to run. This however, doesn't seem to be happening. To test this I put a breakpoint at the address in the vector table for I2C0 (which ends up being the SYS/BIOS dispatcher) and it never stops there.

The processor is still running but because none of the hardware interrupts (including the timers that make the SYS/BIOS tick run) are being serviced SYS/BIOS will not leave the idle thread.

I currently have the board in this state if anyone can help me come up with some ideas on what to look at I would greatly appreciate it. Is there some reason none of them are being serviced? Maybe there is some register that could explain this that I am overlooking?

For reference here are some of the registers and their values, these were pulled using the "Registers" window in CCS:

NVIC_EN0      0x00280180
NVIC_EN1      0x00000580
NVIC_PEND0    0x00280100
NVIC_PEND1    0x00000500
NVIC_ACTIVE0  0x00000000
NVIC_ACTIVE1  0x00000000
NVIC_INT_CTRL 0x00418000

Board/Processor/Tool specs:

LM3S9D92
Custom board
TI-RTOS 1.1.0.25
CCSv5.5

Thanks!
Mike

  • 0
    TI__Expert 8175 points

    Hi Mike,

    A couple of things could be an issue here, firstly ensure in your code that you didn't globally disable interrupts with Hwi_disable() and forgot to re-enable them. You can go to your register view when you expect your I2C0 interrupt to be serviced and send me a screen shot of these registers:

    It will be helpful if you can also send a snapshot of the detailed ROV view for your Hwi module and if I can I see the snippet of code where you set up a Hwi instance for I2C0?

    Moses

  • 0 in reply to Moses Isang
    Intellectual 990 points

    Moses,

    I am running a custom bootloader (also uses SYS/BIOS) on the part and I do call Hwi_disable() before going into/out of the bootloader. Would I need to call Hwi_enable() when the other application runs or will SYS/BIOS handle this in the startup routine?

    As requested here are the registers and the detailed Hwi screenshots. I am using the TI-RTOS drivers for I2C and the TI supplied drivers create the Hwi instance.

    I noticed that Primask was set so I changed it to '0' using my debugger and this solved the problem. Any idea what I need to do to prevent this from happening?

    Thanks,
    Mike

  • 0 in reply to Mike Volzer
    TI__Expert 8175 points

    Mike,

    I don't believe any of our code messes with the PRIMASK register, so check your Bootloader to ensure it's not doing anything unintended. The Hwi_disable from your Bootloader should be negated when you call BIOS_start for your main application as it runs the Hwi_startup function which re-enables the Hwi.

    Also, I'd like to know how you're using the Bootloader, my expectation is that your Bootloader runs and exits and then jumps to _c_int00 for the application to start. How were you able to call Hwi_disable before running the Bootloader as Hwi_disable can only be called from a BIOS program.

    Also try calling Hwi_enable after the Bootloader to see if it fixes it.

    Let me know if this helps

    Moses

  • 0 in reply to Moses Isang
    Intellectual 990 points

    Moses,

    Both the bootloader and main application are SYS/BIOS applications. I was merely stating that both of them call Hwi_disable() before attempting to jump to the other.

    You are correct, the bootloader jumps to _c_int00 of the main application and the main application can also jump to _c_int00 of the bootloader.

    In some testing here I've noticed that if PRIMASK is set when the main application comes up then it will never recover (I assume this would be the same for our bootloader). We do use IntMasterDisable() (which is a StellarisWare call) before programming the internal flash that sets the PRIMASK is our bootloader. I think our bootloader is sometimes leaving PRIMASK set.

    Thanks for your help in identifying the problem, I have enough information to fix our code.

    Mike

  • 0 in reply to Mike Volzer
    TI__Expert 8175 points

    Mike,

    Great that you can identify the problem. It's usually not encouraged to mix the Stellarisware calls, especially the ones that control interrupts with the SYS/BIOS ones.

    Moses