mghecea

VisualDSP++ 3.5 elf2aexe crippled executables FIX!

Discussion created by mghecea on Jul 29, 2018
Latest reply on Aug 4, 2018 by mghecea

TAPR.org (Now defunct) DSPx kit for ADSP-2185N

 

Imagine you downloaded Visual DSP++ 3.5 and got the trial license installed. You are hoping to get your 10 year old DSP Easy Kit Lite or now defunct TAPR DSPx running again, because you became nostalgic/melancholic a long time ago about the way ADI does things in a very unique and logical way. Plus you don't need the myriad of peripherals that the new kits have on them that are enough to make you lose your mind. You want something simple, DSP, SPORT and codec. You want to rehash the experience of what makes simple and efficient DSP code run efficiently and you love how ADI implemented it back in the day (approx a decade ago) on the ADSP-2185N. It sounds great, doesn't it, with one small problem. That issue is caused by elf2aexe.exe. This is ADI's elf loader utility which will scramble up the vector table entry point into a tangled mess. This will not work for you and you have no idea how to fix it. Well this article offers some glimmer of hope, dust off your kit, plug it in and lets go on a little journey of how to go about fixing it...I have included the attached utility I have created to fix this mess and I'm sharing it with you, because it helps me also work this out in a jiffy...

 

 

Inside the VisualDSP++ 3.5 directory there is a utility that supposedly helps users of the ADSP-2185N kits bring their code into the new compiler without issues. Instead if you search the 2185N related forums you will find strange excuses claiming that tech support does not understand the executable format of the file and has no idea why it does not work. I have taken some time to research the issues and have found the following issues with elf2aexe

 

 

Firstly, it does not work correctly without the new fitting of sections into the Expert Linker naming conventions...By adding the section names you see above, everything you see inside Expert Linker should gel with your code much better. This means that your old code needs to be modified and re-written from Legacy (-legacy) compiler option to the new format. That should at least make your jump table start to appear coherently inside the simulator. But will the converter utility still work correctly too ? Not exactly! Here is why...

 

In the Post Build Step or manually you tried something as follows : elf2aexe -x debug\c1sin.dxe debug\c1sin

 

The utility creates an executable as you expect it, but also does something unexpected like scrambling the Expert Linker vector sections on you inside the executable! This makes the EXE file unusable unless you remove all the unnecessary irrelevant garbage they wrote into the file (obviously not understood by the original monitor) and re-organize all the vector entries so that they are ordered correctly. Why ADI would do this in a released product, is beyond me and I find it surprisingly unacceptable. Seems some folks have discovered this very same exact issue and have gotten some head scratching answers from tech support. Here is the issue that this utility creates in VisualDsp++ 3.5 in this discussion thread: https://ez.analog.com/message/26332?commentID=26332#comment-26332 

 

I will also summarize this briefly below :

 

 

Here you can clearly see that the start vector is not zero and thus seems to start at 001C, which is erroneously incorrect. The only thing left for the hopeless user is to unscramble the mess, so I decided to take on that task myself. In fact the first task I performed was to do all this vector unscrambling manually inside the same file created by the loader utility. It took me forever and finally got the executable to load correctly. The next week, I embarked on a journey to create a helper utility which fixes all this for me auto-magically...Well almost. The issue that I was faced with is using the content of the splitter created .BNM file. My utility bnm2exe only understands Motorola SRec. format, so I wrote a C# parser application which does it all as long as you point to the .BNM file created by the spliter. This is easy to do, just go into your settings and choose as follows: 

 

Make sure that type is set to : Splitter file. next make sure that in the Load tab you select...

 

I know I said it does it all, but that is partially incorrect. You need to know the exact length of the PROM boot-loader section inside the .BNM file. I tried to estimate this from ADI documentation and got it wrong, so then I started the copy and paste into notepad++ method and copying bytes and counting and still got it wrong. My counting abilities must be crippled also, pun intended, so I decided to do it visually by decremented the -h[bytes] flag until it all went correctly into alignment. As you would imagine this method worked the best! I just visually inspect the .BNM file for the startup byte sequence I see in the startup code inside the simulator and use that as my visual cue. Within a few minutes, you get the hang of it and adjust accordingly in either direction, navigating through the .BNM file until correct alignment is reached! Consider you only have to get this alignment correct once for the lifetime of your development on these ancient kits. This part if unfortunately a necessary evil and something you have to get going correctly, at least this first time!

 

Thus, in Post Build I add an option : bnm2exe C:\dspx\code2\c1sin\Debug\c1sin.bnm -h1027

 

 

Finally, I do a clean followed by a build and my parser executable bnm2exe messages me back with an encouraging message...

 

 

Well, there you have it, so it seems the replacement loader worked correctly and the good news is you do not have to engage it from the Build Step either. You can do the very same thing manually. Just drop the executable into your directory of choice and engage the new loader via a terminal as such :

 

 

if you engage my tool without parameters, by simply typing : bnm2exe you will get an error saying that you must follow the convention that is clearly stated in the verbiage. The tool has very simple syntax that you must always specify or you will get nothing out of it. Make sure you read my instructions on the screen and understand them correctly, otherwise, contact me as a last resort...

 

 

As a last step, I load a tool such as ezload.exe and point it to the new exe location...

 

 

 

Here is what I see when ezload is all finished...

 

 

A further scope zoom-in of my messy desk reveals...This method works quite well!

 

 

Furthermore, if you do decide to use my tool : bnm2exe, please keep in mind that it has no mind of its own. It is your duty to drop it inside the adi folder where Visual DSP ++ 3.5 has been installed, in other words, navigate to :

 

C:\Program Files (x86)\Analog Devices\VisualDSP 3.5 16-Bit\

 

and drop it there...

 

 

That's about all there is to it folks...The rest is history like they say. I find the ADSP-2185N inspiring and a neat little chip to learn and exercise on. Whole DSP Ham Radios have been written on it with complex FFT implementations. It is not the fastest at 80 MIPS, but what a great chip for your grandsons to practice on if you still have the old kits around...

 

Please note that bnm2exe.exe is a .NET C# application that will require the .NET Run-time, so you might need to install that first if it is not already installed on your machine and you see complaints about it. Also, let me know if you run into trouble with it and I would be more than happy to assist, to a point. Please don't ask for the source, because I consider it part of my personal IP. Particularly, my own personal Motorola S-rec file parser which I wrote from scratch and further more the communication protocol that makes it all possible. I'd like to retain those IP's for future use... 

 

Now, I'm going to be pushing my luck over here and say that if you do like the tool, I will be enhancing it this week to include the RS-232 transport binding logic as well, so that the cumbersome ezloader.exe invocation is skipped all together and you never need to leave Visual DSP++ 3.5 to complete this entire process...That would be neat wouldn't it ?!

 

Happy DSP'ing...

Attachments

Outcomes