Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
19 years ago

NIOS program deadlocks

Hello folks,

I have an interrupt-based NIOS II program and I'm using the DE2 board. My program works ok sometimes but it seems to deadlock randomly when pushbuttons are pressed or inputs from an external circuit connected to the DE2 board are implemented.

I have commented out the printf statements in my interrupt handler function thinking it would solve the problem. It has not. It runs ok for a while and then terminates.

I was wondering if my hardware in SOPC had anything to do with it. I'm using SDRAM memory and my reset and exception addresses point to SDRAM. In SOPC builder, I get a warning: "reset address points to volatile memory, execution of undefined code may occur upon reset".

I don't know if that should be a problem because I have the reset input permanently tied to VCC and since it's a negative reset, it shouldn't technically reset.

I noticed that in the DE2 examples, FLASH memory was used and the reset address points to FLASH and the exception to SDRAM.

This is for my senior design project and any suggestions would be deeply appreciated.

Thanks.

1 Reply

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    19 years ago

    Hello, I have a few recommendations.

    1. Get your reset address out of volatile memory.

    - Point it at external flash, or at a pre-initialized "onchip" memory.

    2. Get in and out of your ISRs as quickly as possible.

    - Do a minimal amount of processing to determine the cause of the interrupt.

    - Push any action off to the main loop of your code or a task (if using an OS).

    - Follow the example(s) in Count Binary and Board Diagnostics for ISR creation, etc.

    3. Are you sure your processor is deadlocked?

    - It could be that you've set one of your input PIOs to generate level sensitive interrupts....and that level happens to be the default level of the input signal(s).

    - It could also be that you're (somehow) generating a spurious interrupt. (This would be tricky, unless you're manually enabling an interrupt that does not yet have a handler).

    Finally, it might help if you post some code illustrating where you suspect the problem(s) to be.

    Best Regards,

    - slacker