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

Interrupts disrupt time-slicing tasks in DSP/BIOS

BryanHughes
Intellectual 570 points

I have an F2808 with four tasks set to the same priority, and they time-slice by calling TSK_yield() periodically. Each task is dedicated to handling input from the four SPI ports. After startup, they time-slice properly, switching between tasks very quickly and reliably. Once an interrupt occurs and after it has been serviced, all four threads no longer run. On top of that, the interrupt won't interrupt again on a second input. Any ideas why?

  • 0
    Intellectual 570 points

    So I have some more information:

    Whenever I disable all but one thread it works, but the instant I enable another thread (even if its unrelated, running at a lower priority), it gets messed up.

    it gets stuck at address 0x8BE4, which, according to the memory map, is part of the .bios section specified as  fxn.o28L. Digging further, in the global symbols section, it defines the address as FXN_F_selfLoop.

    I've gone through the DSP/BIOS wiki page on debugging tips, and it is none of those (stacks are fine, variables are initialized fine, etc).

    Any ideas?

  • 0
    Intellectual 570 points

    I finally figured it out! When I first started writing this code, I did it under CCS3.1 with DSP/BIOS 4.x. I've since migrated to the current versions and re-created the DSP/BIOS configuration in the process and I forgot to enable the HWI dispatcher. This meant the previous running contexts weren't being saved, which caused all the problems. As soon as I enabled it, everything started working beautifully! Why it worked at all when only one thread was running is still rather mystifying, but oh well.

    Moral of the story: make sure the HWI dispatcher is enabled if you aren't calling HWI_enter/HWI_exit yourself.