AnsweredAssumed Answered

Start code, LDF File

Question asked by mDan on Apr 24, 2013
Latest reply on May 16, 2013 by SachinV



I've got another question regarding the BF504F. We are using a start-code, that jumps into the bootloader or into the application after a reset. (processor pin reset -> bootloader; watchdag reset -> application).

We used this LDF File for the BF533:


<post-build-command><![CDATA["$(ADI_DSP)\easmblkfn.exe" .\src\init_code.asm -proc ADSP-BF533 -l .\Debug\init_code.lst -file-attr ProjectName=init_code -g -si-revision 0.5 -o .\Debug\init_code.doj -MM

"$(ADI_DSP)\ccblkfn.exe" .\Debug\init_code.doj -T .\bl-533.ldf -L .\Debug -flags-link -e -add-debug-libpaths -flags-link -od,.\Debug -o .\Debug\init_code.dxe -proc ADSP-BF533 -si-revision 0.5 -flags-link -MM

"$(ADI_DSP)\elfloader.exe" -b FLASH -f HEX -Width 16 -init ".\Debug\init_code.dxe" -proc ADSP-BF533 -si-revision 0.5  -o ".\Debug\014010_00090000bl.ldr"  ".\Debug\014010_00090000bl.dxe"



For the BF504F we changed the LDF File to this:


<post-build-description><![CDATA[Assemble init code and Link with bootloader... (Post-build action)]]></post-build-description>

<post-build-command><![CDATA["$(ADI_DSP)\easmblkfn.exe" .\src\init_code.asm -proc ADSP-BF504F -l .\Debug\init_code.lst -file-attr ProjectName=init_code -g -si-revision 0.0 -o .\Debug\init_code.doj -MM

"$(ADI_DSP)\ccblkfn.exe" .\Debug\init_code.doj -T .\bl-504F.ldf -L .\Debug -flags-link -e -add-debug-libpaths -flags-link -od,.\Debug -o .\Debug\init_code.dxe -proc ADSP-BF504F -si-revision 0.0 -flags-link -MM

"$(ADI_DSP)\elfloader.exe" -b FLASH -f HEX -Width 16 -init ".\Debug\init_code.dxe" -proc ADSP-BF504F -si-revision 0.0  -o ".\Debug\014018_00000002bl.ldr"  ".\Debug\014018_00000002bl.dxe"



When adding this LDF File, the bootloader won't work any longer in debugging mode while it works on the BF533. The settings in visual DSP are the same (except for the processor of course).

Also, the processor doesn't "jump" into the application on the BF504F (or the application jumps immediately back to the bootloader). Without the bootloader the application works flawlessly in the debugger.


Maybe there is any obvious mistake I made?