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.

DSP/BIOS problem in '5509A



Hi,

It seems my code is getting stuck in a DSP/BIOS routine - "FXN_newin" (every time I halt the debugger, it's in this routine at a branch instruction).  My code executes correctly up to a point, but apparently vectors off to this routine at some point.

I think it's probably due to something not being initialized correctly, but the same code ran fine on the last rev of the hardware. There were no changes to the '5509A hardware or connections between the two revs, although I did move some of the DSP/BIOS memory allocations from DARAM to SARAM, as my app was running out of room in DARAM.

Are there any specific rules concerning where the DSP/BIOS data and code should be allocated?

Thanks,

Bill

 

Correction: the function name is "LNK_newin".

  • I had a similar problem with my '5509A design when I ported the code to large model as required by a new release of DSP/BIOS. The debugger would randomly halt at someplace in BIOS code that I hadn't put a breakpoint. At one time there was KnowledgeBase and/or Errata entry on this, but both seem to have disappeared. The suggested solution was to move something into DARAM; it could have been the DSP/BIOS objects and data structures. This was supposed to make the problem less frequent. In my experience, it only helped a little. It wouldn't hurt to try, though: The actual data structures aren't that big if you leave the stack and RTDX buffers in SARAM.

    I've found two other things that seem to help, though I can't promise they'll work for you:

    1) When you start your code, use "run free" until all the initial BIOS and RTDX activity quiets down. Then halt and run normally.

    2) It seems like I've had far fewer debugger issues since I switched from using a Spectrum Digital XDS510USB pod to the newer XD510 USB Plus.

    David L. Rick

    Hach Company

  • Thanks, David.

    I posted this a while ago, and have since solved the problem - it was a s/w issue on my part, but how it ended up getting stuck in BIOS code is still a mystery.

    Your other two suggestions are things I already do/have, but are good none the less.

    Thanks again,

    Bill