If there a way to debug after booting, with emulator?
I am having some problems trying to debug my custom application and init-code on a custom BF536 board with the HPUSB-ICE debugger.
I have used the VisualDSP++ configurator program to change the HPUSB-ICE debugger to "Do not disturb" and used the VisualDSP++ IDE's "Session->Disconnect from target" menu command to disconnect my debugger (I don't physically disconnect the debugger, I just disconnect the USB cable and the power from the debugger). I then reset my board and it starts running the init-code (I have put a JUMP 0 in my init-code so that the init-code does not load the application). I connect the power to the debugger, plug in the USB cable and then use VisualDSP++ IDDE's "Session->Connect to target" which should, from what I have read, stop the code running at the JUMP 0. However it appears that the VisualDSP++ IDDE resets the BF536 because when I look at the PC and Disassembly window, the code is at FFA00000, which is not where my JUMP 0 is, and all the registers have been reset to their default state.
From a hardware perspective, we have a pulldown 4K99 ohm resistor on the TRST pin of the BF536. Is that all there needs to be?
JUMP 0 method is only a mechanism to control code execution - by giving an 'Edit-able' infinite loop. VDSP Configurator is a different entity; JUMP 0 is not required to see whether VDSP is performing a reset or not.
Was the code booting properly earlier - say if you do not re-connect VDSP or use JUMP 0?
Can you boot some simple small code - it could be just few lines and with no init-code - is the behavior still the same?
I am not sure how valid this is from emulator perspective - but try with the most recent release of the IDDE -> VDSP 5.0 Update 7.
The hardware recommendations are given in EE68 Application Note. But since you can actually connect to the IDDE, I do not suspect any particular hardware/board problem. EE-68: Analog Devices JTAG Emulation Technical Reference
The code appears to run okay in standalone mode except that it runs the init-code and never loads the application code. After looking at the code generated by VDSP++, it appears that the init-code is going into an infinite loop in something called __lib_prog_term, which is added by VDSP++? I'm not sure why it is adding this but I will look in the documentation to see if I can determine how to get rid of this. No matter what code I try (even the simplest application possible, which does nothing) it still adds this loop. It seems to me that this is something that the final application would want to add but would not include in init-code.
I think the above issue is separate from the debugger's resetting of the processor on connection. Is there nothing else to change other than the debugger to "Halt" or "Do not disturb" mode? As soon as I connect the debugger, even in do not disturb mode, VDSP++ resets the processor and says it is "Halted".
I will try installing VDSP++ Update 7, but I didn't see anything in the release notes that stated a problem with the Blackfin's JTAG debugger. I will have to get our hardware people to look at EE68 to make sure that they are following all the recommendations.
Thanks for your help...
Your Init Code application should not contain a "__lib_prog_term" symbol, so I think this may provide a clue to the problem you are facing when booting your application.
Have you created your own Init code from scratch, or did you base it on the examples located in "...\Blackfin\ldr\init_code"? The examples all link against customized LDFs, which ensure that none of the C Runtime objects are linked in; I suspect that your project may be linking against a standard C/C++ LDF, and therefore getting the "__lib_prog_term" symbol (as well as a lot of other stuff) in there that is not needed.
I would recommend starting with one of the example init codes, and modifying it appropriate for your target.
The VisualDSP++ tools will only reset your target if the session instructs it too. It may be worth creating a new session from scratch, and ensuring that the settings are being applied correctly.
I would recommend entering the Configurator, and creating a new platform (based on one of the templates if you like). Set the processor(s) to "Do Not Disturb", or "Halt", but also make sure to give the platform a distinctive name so that you can identify it in the Session wizard (e.g. "BF536 via HPPCI-ICE Do Not Disturb"). Then, of course, create the new session via 'Session'->'New Session' and find the Platform you just created.
If that has no effect, please let us know how your hardware people get on with EE-68.
The problem with the init-code was the fact that I had some C library code linked in to the init-code project. This resulted in the generation of the CRT startup file which contains, as its last instruction, a call to _exit which has the infinite loop lib_prog_term. Removing the C library code removed the CRT startup file so the init-code is now loaded at FFA00000 (instead of the CRT startup code). The init-code now terminates and starts running the application code stored in flash.
I tried creating a two new sessions, one with "Halt" and the other with "Do not disturb". The "Halt" one still doesn't work (it halts the processor but resets it to FFA00000) but the "Do not disturb" one does, so I can at least start to debug my application code. I will look into why the one works but the other doesn't once I get my application code running.
Thanks a lot guys, I really appreciate it.
Retrieving data ...