Hi Brad,

thanks for your suggestions, but we solved the problem in another way.

Short explanation: don't always trust third party software :-). 

Long explanation: For the hardware init stuff we use a third party library
from a service provider. If the boot mode pin state is "flash boot" one of
the library function looks for a 32 bit "key number" which is generate
from the unique DSP ID (DEVCFG_AID0, DEVCFG_AID1). This number is expected
at the last flash address. If the number is wrong or doesn't exist, a
watchdog reset (or something like that) will be initiated. In other words,
we found a undocumented "easter egg". Anyway, now our board works fine!

Steve


>
>What does _main resolve to in the map file?
>
>I'd recommend stepping through the code with an emulator.  Put the board

>back into flash boot mode and hook up your emulator.  The trick is to 
>set a HARDWARE breakpoint at _c_int00.  If you set a software breakpoint

>then the 1k of data being copied into RAM from the flash will overwrite 
>the SW breakpoint and therefore you won't halt.  So do Debug -> Reset, 
>File -> Load Program -> Symbols Only, setup your HW breakpoint, and Run.

>  You should now be stopped at _c_int00 and able to step through your
code.
>
>One other thought would be that perhaps there's a mistake in the 
>assembly of your secondary bootloader.  For example, after executing a 
>load instruction you have to wait 4 cycles (delay slots) and THEN the 
>data appears in the register.  Did you perhaps load the address of main 
>from memory and try to branch to it immediately?  If that's the case 
>then it would make sense that upon executing the code a second time the 
>branch to main would work (i.e. the load would have long completed and 
>the correct address for main would be present).
>
>Brad
>

steffenl wrote:
> Hi experts,
> 
> we have an own video board based on a DM642 with flash, sdram, FPGA etc. 
> Our application firmware works fine in the CCS 3.1 with XDS510USB
> emulator. We use DSP/BIOS. For standalone operation we wrote the first
> bootloader, based on the TI app notes and a second one for the more
> expensive loading of the application. After program the flash with these
> three parts and power-up the board without emulator (boot mode pins in
> "high" state) the dsp shows the following behavior:
> 
> - 1st bootloader loads the second bootloader
> - 2nd bootloader does some init stuff (sdram configuration etc.) 
>   and loads the application in the SDRAM
> - 2nd bootloader jumps to the _c_int00 address
> - at this point the DSP never reaches the main() function, but jumps
>   to the address 0x0 (which means the reset vector) and the whole 
>   process begins again and again (indicated by LED)
> 
> In this state I opened the connection of the boot mode pins to VCC
> (disabling flash boot mode) and pressed the external reset button again,
> the application started correctly (Reset is important). I wonder if there
> is a difference in the DSP behavior depending on the boot mode pin state,
> putting aside the fact that the dsp boots from flash or not. 
> 
> The only difference I can see is that the 1st bootloader is still
> available in the internal RAM and is not reloaded from the flash. 
> 
> Another guess: it has something to do with the DSP/BIOS environment, but
> the 1st bootloader doesn't use the BIOS stuff.
> Hope anybody can give me a hint about this strange behavior.
> 
> Thanks in advance,
> Steve
> 

What does _main resolve to in the map file?

I'd recommend stepping through the code with an emulator.  Put the board 
back into flash boot mode and hook up your emulator.  The trick is to 
set a HARDWARE breakpoint at _c_int00.  If you set a software breakpoint 
then the 1k of data being copied into RAM from the flash will overwrite 
the SW breakpoint and therefore you won't halt.  So do Debug -> Reset, 
File -> Load Program -> Symbols Only, setup your HW breakpoint, and Run. 
  You should now be stopped at _c_int00 and able to step through your code.

One other thought would be that perhaps there's a mistake in the 
assembly of your secondary bootloader.  For example, after executing a 
load instruction you have to wait 4 cycles (delay slots) and THEN the 
data appears in the register.  Did you perhaps load the address of main 
from memory and try to branch to it immediately?  If that's the case 
then it would make sense that upon executing the code a second time the 
branch to main would work (i.e. the load would have long completed and 
the correct address for main would be present).

Brad

Hi experts,

we have an own video board based on a DM642 with flash, sdram, FPGA etc. 
Our application firmware works fine in the CCS 3.1 with XDS510USB
emulator. We use DSP/BIOS. For standalone operation we wrote the first
bootloader, based on the TI app notes and a second one for the more
expensive loading of the application. After program the flash with these
three parts and power-up the board without emulator (boot mode pins in
"high" state) the dsp shows the following behavior:

- 1st bootloader loads the second bootloader
- 2nd bootloader does some init stuff (sdram configuration etc.) 
  and loads the application in the SDRAM
- 2nd bootloader jumps to the _c_int00 address
- at this point the DSP never reaches the main() function, but jumps
  to the address 0x0 (which means the reset vector) and the whole 
  process begins again and again (indicated by LED)

In this state I opened the connection of the boot mode pins to VCC
(disabling flash boot mode) and pressed the external reset button again,
the application started correctly (Reset is important). I wonder if there
is a difference in the DSP behavior depending on the boot mode pin state,
putting aside the fact that the dsp boots from flash or not. 

The only difference I can see is that the 1st bootloader is still
available in the internal RAM and is not reloaded from the flash. 

Another guess: it has something to do with the DSP/BIOS environment, but
the 1st bootloader doesn't use the BIOS stuff.
Hope anybody can give me a hint about this strange behavior.

Thanks in advance,
Steve