VisualDSP++ 5.1.2 Debug/Compile behaviour different


I have a very frustrating problem. I have a project that has been working for ages. I have debugged and compiled the code various times and the code compiled and loaded to DSP BF514F16 internal flash would always run the same as when I was debugging the code.

The problem I have now is, the code DEBUG's fine, but after compiling it and loading it to the DSP flash, part of the code does not behave right. My question is this, how can the DEBUG code and the compiled code (using the DEBUG) setting run different when loaded to teh BF514F16? Incedently, this also happens sometimes on the old BF512F4.

I usualy move a few variables around and this seems to sometimes fix the problem. But this time nothing helps. I've even compiled a release version. Nothing. But when I debug the code via HPUSB-ICE the code works fine.

Please help.

Kind regards,


  • It's been a while and no-one has answered this question?

    Anyone? Its quite a pain to have your code behave different than when its being debugged. Another setting or piece of information is, I keep the compile version to "DEBUG" mode. Although I have tried "RELEASE" mode and it behaved the same as above. The code does not behave the same once flashed to the internal flash and excecuting from internal flash.

    I also have another issue. I compile a binary and flash it. It runs. I take some variables out of my code that I dont need. Debug the code to check that it still works and compile without errors. And suddenly the code wont boot after being flashed in. I do have an external program that modifies the binary file to include extra information like CRC16 etc. But this is added to the end of the file and not in the code section. This also makes sure the file size is always the same. So how can the code boot and when a variable or something changes the code wont boot?

    Kind regards,

    Quintin.VisualDSP++ 5.1.2 Debug/Compile behaviour different

  • I have found out that changing the SPI_BAUD register in bfrom_SpiBoot call can help, if you are using that call when executing your application.

  • I will definitely try and change the SPI_BAUD and see if it helps me as soon I get back to the DSP again. Thank you for the feedback. I will also reply here or to the other post if I find anything.

  • 0
    •  Analog Employees 
    on Aug 2, 2018 3:09 PM
    This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.

    Thank you,
    EZ Admin