C6455 Bootloader Hangup DSPBIOS

Raymond Franzen said:

"When booting we seem to be hanging up in the DSPBIOS init call “GBL_init”

 

This does not happen when we run from the emulator but, it does when we go through the boot sequence on the board."

This is something that could take a bit more debugging, but based on his second sentence regarding it working from the emulator but not when booting the board stand alone, my suspicion would be that the boot loader is not doing something that it needs to do. One of the biggest differences between loading from CCS/emulator and booting the board standalone from flash is that CCS typically has a GEL file associated with the board configuration which does some board initialization such as setting up PLLs or external memory controllers so that CCS can write to that memory. When you move to a stand alone boot, all these operations need to be managed by the boot loader code so that the processor is in essentially the same state as it is after CCS sets it up with the GEL file. This being said I would have them take a closer look at their boot code which runs before BIOS to ensure it is doing everything that is needed.

Here's a related wiki article:

http://wiki.davincidsp.com/index.php/Debugging_from_Flash

These are things we have been doing. 

A stand alone application will boot and run fine.

A DSP/BIOS application that has no more than a while(1) in main will not boot.

The GEL file has been removed.T

The DSP/BIOS and Linker are set to the ROM initialization model so there should be no "STYP_COPY" sections but, there are!

Does anyone know why?

Which version of BIOS are you using?

Which boot mode are you using?

Can you attach your simple BIOS project that won't boot including whatever means you are using? EDIT: That was supposed to be "whatever means you are using to generate your hex file for burning to flash, etc."

Please specify exactly where you are seeing STYP_COPY sections.

hi Steve,

The attached app note might help - not sure why this updated version isnt on ti.com but hopefully it will help. In particular the tables indicating what to do w/ the various code, data, udata BIOS sections should help. Its a bit old but looks quite relevant for your issue.

Cheers, Alan

Which version of BIOS are you using? RF: 5.4

Which boot mode are you using? RF: 8bit Boot Mode 4

Can you attach your simple BIOS project that won't boot including whatever means you are using? EDIT: That was supposed to be "whatever means you are using to generate your hex file for burning to flash, etc." RF: We wil get this soon.

Please specify exactly where you are seeing STYP_COPY sections. RF: What Steve noted (Steve please correct me) is that Loader does not support STYP_COPY. The only reason they are using it is because DSPBIOS states to do so. Steve seems to think this may be the problem.

Current process flow:

1) COFF file adds a header and trnamit code over Ethernet.

2) Downloads to Flash which then loads it. Again Download to FPGA and application works fine. 

I spoke to the customer today. The key  issue is that the customer is using a ROM initialization model (--rom_model) and expects that STYP_COPY flag is not set.

-          If they compile a non-BIOS code, they are able to successfully build it, covert to hex (using their utility)  and run from flash without any issue (as the STYP_COPY flag is not set as expected).

-          If they run a BIOS code,  the STYP_COPY flag is somehow getting set  and their hex conversion utility fails as it does not expect this flag to be set. As a result the load fails and the code does not run.

They claim that the previous versions of BIOS/Linker tools did not do this and they want to understand why this has changed in the present version.

They are currently using

BIOS    5.40.02.22
CODEGEN 6.1.9

I have sent an example project from them via email to the TI folks.

Thanks for your help.

Pradhyum

Raymond Franzen said:

Please specify exactly where you are seeing STYP_COPY sections. RF: What Steve noted (Steve please correct me) is that Loader does not support STYP_COPY. The only reason they are using it is because DSPBIOS states to do so. Steve seems to think this may be the problem.

Please give me specific evidence of DSPBIOS forcing you to use STYP_COPY. 

Raymond Franzen said:

Which boot mode are you using? RF: 8bit Boot Mode 4

OK, the EMIFA bootmode...  What does your bootloader look like?  The app note Alan mentioned should help.

Raymond Franzen said:

Current process flow:

1) COFF file adds a header and trnamit code over Ethernet.

2) Downloads to Flash which then loads it. Again Download to FPGA and application works fine. 

Normally this boot mode has a NOR flash hooked up.  How does the FPGA fit into this?  Are you using the hex conversion utility to create a boot table?  Have you written a bootloader that runs out of NOR flash and loads the boot table to the correct RAM locations?

Raymond Franzen said:

RF: What Steve noted (Steve please correct me) is that Loader does not support STYP_COPY. The only reason they are using it is because DSPBIOS states to do so. Steve seems to think this may be the problem.

One thing that is "different" with BIOS versus a normal program is that it uses the COPY section.  If you look at the linker command file generated by BIOS you will see 2 instances of the COPY section.  Ultimately the COPY section means that you will end up with data in the output file, but that data should be ignored by the loader and never actually written to the target.

More info is in this knowledgebase article if you're interested.

So specifically BIOS uses COPY sections for a ".printf" section as well as a ".vers" section.  The ".printf" contains static strings which are used by the real-time analysis tools.  Since only the host needs access to these strings these never get written to the target itself and so they do not unnecessarily take up memory.  Similarly the .vers section contains information related to the BIOS version that was used to generate the out file so that you could determine that info simply by querying an out file.  Again it would not take up any actual space on the target.

So bottom line, if you have a utility that is converting the out file into some other format then it should be able to recognize COPY sections and be smart enough to ignore them.

STYP_COPY sections are ignored by our converter and not put in our load module.

Since these sections are the only difference we've identified between a NON-DSP/BIOS program that load and runs properly; and a DSP/BIOS application that does not get out of Initialization. It is under suspicion.  

1.0             COPY Sections

COPY sections are rarely created directly by users.  They are created automatically by the code generation tools to support various features. 

When linking under the –cr switch for RAM model initialization of global variables in C, the .cinit section is a COPY section.  Linking with –cr is similar to the following example …

 We are using the –c or ROM initialization that should not include COPY sections. Not the -cr that the article refers to for the COPY section.

If you are saying no sections with the STYP_COPY  flag are the cause of the initialization failure for GBL_init when they are excluded then what does GBL_init require? 

Steve Goodheart said:

If you are saying no sections with the STYP_COPY  flag are the cause of the initialization failure for GBL_init when they are excluded then what does GBL_init require? 

I wasn't saying anything like that -- just making sure you knew that BIOS uses COPY sections in the linker command file for special purpose.  It might be related, but I wasn't thinking about it in the context of GBL_init...

One of the things that happens in GBL_init is cache configuration.  Have you thought about cache when writing your bootloader code?  Can you send me your bootloader code through Pradhyum?

If we allow are boot loaders to boot and reach _c_int00

Then load the application through code composer with NO GEL files. The application will run properly.

This is why we believe the issue is in the load of application.

Brad,

i believe i'm experiencing a similar problem with bios init.  

how exactly do i get rid of the glitch?

thanks for the clarity,

Mac

To be clear, the issue is not with BIOS_init.  The issue is with your hardware.  Either you've not properly tied off the NMI pin or something on your board is toggling the NMI pin. The solution is to understand how NMI is being toggled and to fix your hardware.