Adapting dsp/bios application to custom board

More info about this issue, if I open the message log window of dsp/bios I obtain the next logs:

261296045   *** ERROR: 0x1f261f5c 0x1f261f5c ***

261296045   *** ERROR: 0x1f261f5c 0x1f261f5c ***

261296045   *** ERROR: 0x1f261f5c 0x1f261f5c ***

261296045   *** ERROR: 0x1f261f5c 0x1f261f5c ***

261296045   *** ERROR: 0x1f261f5c 0x1f261f5c ***

What would this mean?

Thanks

Are you running a User Init function inside DSP/BIOS (You specify this in the System->Global Settings->(right click) Properties)? Some of the other boards such as DM648EVM used this to configure TVP51xx registers before entering main, so if the device changed or disappeared the code would be stuck in I2C configuration.

I am not sure what the LOG_printf() errors mean if anything.

Hey Tim, thanks for you answer. Yes, it is calling a init function but there is no tvp configuration being done there. I would like to know, is this file the only configuration that is being done before main() starts? I forget to say, that the tests like ddr, and nor flash provided by TI, can be run without trouble in our custom board.

Could it be that you are using a GEL file with the EVM but not with your custom board?

Yes, I think about GEL issue too. But I am loading it too when I use JTAG (actually I am running too the same gel that EVMdm6437, but I think there could not be any trouble here). I would like to say that we are using dm6435(500Mhz) instead of dm6437(600Mhz), I have decreased the multplier in PLL1 in the gel file to obtain about 378Mhz (later I will increase it, just for safe I thought it was better to go lower).

Thanks for the answers

There is some basic BIOS initialization (I think this is called BIOS_start) done before main as with every BIOS project. This has been tried and true and should not ever cause any hanging. The User-defined init function is almost always directly responsible for the code not making it to main (assuming the boot completes successfully). I suggest putting a breakpoint inside the user init function and seeing if you can find where it breaks in there.

Additionally, you may need to tweak the configuration of the other peripherals (not just the PLL) if you have deviated from the design of the EVM. For example, a different DDR2 chip could require different timings in the DDR2 EMIF registers.

I had already commented the whole user init function called from dsp/bios with a breakpoint in the end, and nothing happens, it seems that is not reaching this init too. Maybe is the second thing that you suggest, some different hardware, but DDR2 is the same and its test runs well. Flash is a little diferent, but the test of flash (provided by TI) works too. As this project are not using DSP/BIOS (just c files) I think it could be something related with DSP/bios... anyway thanks a lot for your suggestions.

Any other idea?

After the boot fails, connect with CCS (remove the GEL file before connecting) and load the project symbols (File->Load Symbols->Load Symbols Only...). This gives you some insight into what the boot is going without disturbing anything because the GEL scripts are not executed. Loading the symbols should give you an idea of where the code has hung. I think you will need to debug the boot process to see what is not functioning. You may want to start with a small project that only fits in L2 and does minimal effort (something like Hello World! without the printf).

Correct if I am wrong, but I think you are talking about debug the project from flash, aren't you? I am not burning the flash actually, I am just trying to load a .out and run it through CCS. The test runs well in this way, I guess my application should work too.

Sorry, yes. I had assumed you were failing to boot out of flash. If the issue occurs when loading a .out file then everything is already in place to debug. You should be able to step through the process after loading the project and see where it gets lost.

Hello, I think the problem is in the .tcf file, I have just tried to run an helloworld project example that is using dsp/bios and only says "hello world" and it is not running. So I guess I will need to change something of evmdm6437 tcf configuration to adapt it to our custom board...

Make absolutely sure that the configuration done by the GEL file (or even in application code!) is appropriate for your custom board. Remember that the GEL files are designed specifically around the EVM so any changes to the board need to be reflected in the GEL. The Board Support Library could also be a culprit if you are working with any of the examples provided by Spectrum Digital for their EVM.

The TCF contents could potentially change as well, but this would be memory sizes for the most part.

Thank you for the new answer. Well with my application I burned into flash in EVM and in our custom board. And it works only in EVM, as this mode does not use gel file, I would discard that is due to it. In the other hand as the HelloWorld example does not use BSL (I would need to check it in my app) and it hangs too, I would discard it too. So... tcf file? So what should I check in the tcf file? Should I build my own tcf? I have seen a document of how to build it (starting from a tci file) but I didn't have all the resources (for example, document ask me for check in a table my processor, but dm634x was not in this table)... so I am now a little lost about what to check and which way to follow.

EDIT: forget about lines below, it is now really pointing to DDR2, but still does not reach main(). There is something that I do not understand, if the init function of dsp/bios is completely commented, where the code is supposed to be pointing? I mean, what is it executing? Because Tim talked about BIOS_start, but he says too that I should work without trouble...

Ok, more news, I was wrong the helloWorld really works, so starting over. I have tried it too burned in flash and works too, so no problems with gel. What I see now is that when I stop the program (after some time of running, and as I said in this time never reaches main) is that the PC is pointing to some address belonging to L2RAM/Cache (0x1080xxxx). Why should be pointing there? I have nothing allocated there, all code should be in DDR. Should this means something significative?

Hi again, it seems that my code is stuck in GBL_init... I hope this gives some idea to someone and gives me some clue about something :) I would like to remark again, I am using dm6435 instead of dm6437 should it be this matter?

    .global BIOS_init, _BIOS_init
    BIOS_init:
    _BIOS_init:
    GBL_preamble
    GBL_init
    SEM_init

Hi James,

Please check the user init function again. This function is called by GBL init. There might be something there that is incompatible with your board.

"Using the configuration tool, check the box labeled, “Call user init function” under the “Global Settings Properties.” Then enter the name of the user initialization function. This function will be called by the GBL_init macro, which is the first macro executed in the BIOS_init() function. In addition to calling the user function, GBL_init performs chip-level initialization, such as setting up various possible caches and initializing system buffers."

Hey Mariana, thanks for your answer.... butttttttttttttt....I have the whole user init commented, and anyway there is not anything related with hardware not presented in our custom board. Without user function, I am still able to run to main() in the EVM, but not in our board.... weirdddddddd.......! :(

What version of DSP/BIOS are you using?

Hi again, 5.31.07, this is the dsp/bios that requires my application. I am not sure that if it would work with another. What really seems odd to me is that helloWorld.pjt works in our custom board, and it is using dsp/bios, but unfortunately not my application.

Thanks again for your support

Try to compare the cache/ memory configurations (.tcf) in your application project with the heloworld project...

Hi again, I have some new about this problem:

             -I have seen that if I allocate some sections (for instance .sysint) in DDR2 the helloWorld stops to work in my custom board. Buf in evmdm6437 still works properly. Should I guess that there is some trouble in DDR of my custom board? This would be weird, as I have been able to pass succesfully a ddr test project from TI in my custom board

Yep, narrowing the issue, it seems that there is a problem with your DDR. Please double check it. Please also check the Memory interface configurations/registers.

Hi, I got my custom board two weeks ago, and now I have the problem as you remark, have you solved the problem?  Could you tell me how to solve it?

Hello TimHarron,I want to ask that what is the "user init funtion",and what contents are included in the  "user init funtion"? Thank you very much!

The user init function is something you can add or not. So if you add a "user init function" you will make the function and its' contents.

Please see page 164 of the TMS320C6000 DSP/BIOS 5.32 Application Programming Interface (API) Reference Guide.

Thank you very much,Mariana.  Now I want to ask that how to write the "user init function"? Because I will use it in my project ,and the DSP I using is TMS320DM642,thank you very much!

Shanjun,

This function is usually filled with initialization code you need to run before reaching 'main.' For a processor like the DM642 this is typically something like initializing the video decoder via I2C. Keep in mind that this is just an example, and your function may be completely different.

Shanjun,

I'm not sure if we are understanding your question. In the tcf file, you check the box that says "Call User Init Function", put the function name in the field "User Init Function" preceded by _, for example _function. The function should be in your source code. This might not be what you are asking, as Tim said in his post, you should put the relevant initializations in this function.