I am migrating from VisualDSP++ 5.1.2 to CrossCore Embedded Studio 2.9.2. We have a BF538F target that is deployed in the field with well vetted code that was produced with VisualDSP++. Using Cross Core I made a relatively simple project DXE that I can run under Cross Core using the ICE-1000 emulator. I have been trying to create a binary LDR version of the code so that I can burn it to the 16 bit wide FLASH that resides at 0x2000 0000 of the target. It would seem that this should be a relatively easy process because I already have the required initSDRAM.DXE code that was created a while back using VisualDSP++
The process that I have tried seems intuitive and simple but it always fails
1. Convert init538SDRAM.DXE that was created with VisualDSP++ to a CCES compatible DXE using the ELF2ELF tool that is provided for this purpose. Below is the command I used and it seems to work fine
elf2elf init538SDRAM.dxe -o init538SDRAM_forCCES.dxe
The output file on the right is a converted slightly larger file than the file on the left. It is supposed to work with CrossCore
2.. Use the ELFLOADER to concatenate the init538SDRAM_forCCES.dxe and the DXE application that was created using cross core and runs with the emulator ICE-1000. When I say "concatenate" what actually is supposed to happen is the init538SDRAM_forCCES.dxe portion is "prepended" to the Application portion to create the total LDR. This should create a boot-loadable binary LDR that I can burn to flash and use to boot the target from flash.
Below is the command I used. The intent was to get a 16 bit binary LDR that I should be able to burn to flash and used to boot-from-flash.
elfloader -init init538SDRAM_forCCES.DXE my_app.dxe -proc ADSP-BF538 -v -b FLASH -f BINARY -Width 16 -o my_app.ldr
The above returns the following error. Try as I might I can't seem to fix it.
[Error ld0263]: Init code "init538SDRAM_forCCES.DXE" has no section in code memory range for target processor "ADSP-BF538".
It would seem to me that the init538SDRAM.DXE is "just a binary" that should easily be prepended to the CrossCore DXE once the conversion to the CrossCore DXE format has been made. I don't really know what "has no section in code memory range for target processor "ADSP-BF538" means. More important, I can guess what it means but have not been able to fix it. I have tried building the equivalent of the original init538SDRAM.DXE by importing the original VisualDSP++ project in to CrossCore and building it that way. I get differnt issues with the ELFLOADER that are equally inscrutable. I have even tried recreating the original initSDRAM project in CCES (rather than using IMPORT) that does not seem to work either.
Any guidance on how to fix this is appreciated. Many of the errors that get issued such as [Error ld0263] I can not find documentation so I am reduced to guessing the problem and the fix.
Hi,Apologies for the delay post. We are posting the response here for others to benefit.Thank you very much for your report. We have confirmed that the ld0263 error you encountered is a regression in CCES…
Hmmmm. This is interesting … and a bit concerning. I re-ran the exact same command that produced the
Except I changed the processor from ADSP-BF538 to ADSP-BF533. The ELFLOADER command string gave me the following "informational" BUT DID NOT FAIL. Further, when I burned the resultant LDR to flash and cycled the power it ran the code as I would have expected. The only thing I changed was the processor designation from 538 to 533. The source input DXE files were NOT changed.
So this makes me start to wonder if there is something anomalous about the CrossCore ELFLOADER in combination with BF538?
[Information ld0295]: Target processor 'ADSP-BF538' of input file init538SDRAM_forCCES.DXE' does not match loader target 'ADSP-BF533'.
So summary is, ELFLOADER command line with BF538 as the designated processor renders the Error ld0263. Same command line except change processor designation to BF533 and I get Information ld0295. Resultant LDR seems to work as expected. Also when I took a quick look using the LDRViewer the size of the prepended init portion of the LDR was about the correct size.
Is there some sort of anomaly with the CCES ELFLOADER regarding BF538 processor LDR file creation? I can't find any such anomaly but find it strange that I can concatenate BF538 DXE projects in to a working LDR if I use the INCORRECT BF533 designation but if I use the CORRECT BF538 designation I can never seem to get a proper LDR file out of the process.
Moving to CrossCore Embedded Studio and Add-ins Community
Thanks for moving this to where it should be. I don't come in to forums very often and when I do I am a bit clumsy at it. I hope that someone in the CrossCore Embedded Studio and Add-ins Community recognizes this issue and has an explanation. From my perspective it seems like a CCES ELFLOADER command line parser anomaly (or something like that). But it certainly could be I am doing something wrong. Would not be the first or last time I made a mistake. If no one recognizes the issue perhaps I should report it as an anomaly and then some one will either set me straight as to why it is not an anomaly (IE I did something wrong) or they will confirm "yeah, it should not work that way".
Thanks again for the help
Hi,We understand that you have already contacted our private support.To avoid duplication of efforts, please continue the discussion there.Regards,Nishanthi.V
Yes I will do as you request. They have reproduced my issue and are looking in to it. Perhaps I should report the resolution here if / when that happens. I appreciate their looking in to it.
Hi,Apologies for the delay post. We are posting the response here for others to benefit.Thank you very much for your report. We have confirmed that the ld0263 error you encountered is a regression in CCES 2.9.0, which causes initcodes for the ADSP-BF538 to be checked against the ADSP-BF532 memory map instead of the ADSP-BF533 memory map that the ADSP-BF538 is based on. We will fix this in an update.Informational ld0295 is an addition in CCES 2.9.0 to point out when the target processor of the loader file does not match that of the input DXE files, as that may indicate a mistake.For the workaround, instead of targeting ADSP-BF533, you may want to target ADSP-BF539 as the closest relative of the 538. Having said that, the loader stream format is the same for the three parts and the part number does not get recorded into the loader stream.Best Regards,Nishanthi.V