TMS320C6416T: about DSP C6416 Boot and Gpio interface problem

firstly  thank  Tsvetolin Shulev,  

    some boot logs and gpio configuration such as the following:boot 1K data logs, boot success data place left column,

    boot failed place right column,  file data_analysing .doc is comparing two data results

     gpio pin configure such as code，

      #define GPEN   *(volatile Uint32*)0x01b00000

      #define GPDIR  *(volatile Uint32*)0x01b00004

      #define GPVAL  *(volatile Uint32*)0x01b00008

     GPEN  |= ((1 <<8) | (1 <<9) | (1 << 10)|(1<<11)|(1<<12));

      GPDIR |= ((1 <<8) | (1 <<9) | (1 << 10)|(1<<11)|(1<<12));

      delay(1)   /*delay 1s*/

       /*pull pow*/

      GPVAL &= 0xE0FF;

       delay(1)   /*delay 1s*/

      /*pull high*/

      GPVAL |= 0x1F00;

two_group_data_comparae.docx

Is this bare metal or DSP/BIOS?  If bare metal can you post your vectors.asm file?

To Brad Griffis:

      Thanks reply,  we run DSP C6416 Porgram with bare metal, without DSP/BIOS, we use vectors.asm, please reference such as:

Don’t use VEC_ENTRY for vector0. B15 is undefined at reset and so it writes to and reads from a random address. This can cause boot failures. Instead do this:

Mvkl _c_int00, b0

Mvkh _c_int00, b0

B b0

Nop

Nop

Nop

Nop

Nop

Sorry my previous response wasn't very clear.  I was posting from my phone late at night to try to bridge the time difference between us.  Let me provide a more detailed response now.

First, here is the portion of your vectors.asm that needs to be changed:

heng ye said:

*------------------------------------------------------------------------------

.sect ".vector"

.align 1024

_vectors:

_vector0: VEC_ENTRY _c_int00

_vector1: VEC_ENTRY _vec_dummy

_vector2: VEC_ENTRY _vec_dummy

_vector3: VEC_ENTRY _vec_dummy

_vector4: VEC_ENTRY _c_int04

_vector5: VEC_ENTRY _c_int05

_vector6: VEC_ENTRY _c_int06

_vector7: VEC_ENTRY _c_int07

_vector8: VEC_ENTRY _vec_dummy ; Hookup the c_int08 ISR in main() for EDMA

_vector9: VEC_ENTRY _vec_dummy ; Hookup the c_int09 ISR in main() for DMA

_vector10: VEC_ENTRY _vec_dummy

_vector11: VEC_ENTRY _vec_dummy ; Hookup the c_int11 ISR in main() for DMA

_vector12: VEC_ENTRY _vec_dummy

_vector13: VEC_ENTRY _vec_dummy

_vector14: VEC_ENTRY _vec_dummy

_vector15: VEC_ENTRY _vec_dummy

*------------------------------------------------------------------------------

It's just the one highlighted line that is an issue.  The VEC_ENTRY macro itself is correct for "normal" interrupts, but the reset macro should not use that.  There is no need to use a macro for each of those vectors.  You can just insert 8 instructions instead.  Here's how it should look:

heng ye said:

Hi Brad Griffis：
vector.asm only cause usr application progrom runing fail, Whether also cause boot fail, we find no run second bootloader, program load completely??

Can you please post your secondary bootloader code too?

The failures are unpredictable. Some devices may fail more than others. I’ve seen many such cases. You could include the c_int00 source code in your project and change it to first call your bootloader and then call main, if it will still fit in the first 0x400 bytes with the extra code.

heng ye said:

question 1:

I means if I want to run second load program in C-run time environment,Can you give me more explicit reference?

There's not enough space to do this in 1KB.  The bootloader must be written in assembly code in order to function correctly.  An assembly bootloader was provided in the app note I referenced previously.

heng ye said:

question 2:

I have modifyed vectors.asm according your last advising, delete B15 when it reset, contents such as
_vector0:
MVKL _c_int00,B0
MVKH _c_int00,B0
B B0
NOP
NOP
NOP
NOP
NOP
I want to know whether _c_int00 can run when power on reset only copy 1K byte cboot data to Local memory, cboot function such as:

void cboot(void)
{
register int code_i ;

code_i = 0 ;
for((code_i) = 0;(code_i)<0x30000;(code_i)++)
{
*(char *)(0x00000400+code_i) = *(char *)(FLASH_CODE_ADDR + code_i);
}
c_int00();
}

according the cboot program, excute external flash to Local memory copping with C run-time , Then C run-time How to Create?

You need an assembly bootloader.

heng ye said:

question 3:

I have also said only a few chip happen boot fail , How to make the best optimal way, make sure product run stable?

I don't know for certain that this is the issue, but it is the most common issue I've seen that fails in the way you've described.  I expect that fixing your bootloader will resolve the issue.

If you want to test further, here are a few things to check:

1. Are you able to connect with JTAG to a board that fails to boot, or does CCS throw an error?
2. If you are able to connect, where is the program counter?
3. Do you have boards that regularly fail to boot?  Is the behavior consistent related to questions 1-2, i.e. does it never allow you to connect, or is program counter consistently in the same location?
4. A test that you could run would be to create a "dummy program" which is simply an assembly instruction that branches to itself.  For example, if you locate vectors.asm inside the .bootload section and then change vector0 to load the address _vector0 instead of _c_int00, then the device should simply stick in that loop when it boots.  A good test is to see if you can consistently power-up the board and verify that you are inside that loop.  If that is the case, that will be strong evidence that something is happening in your software that crashes the device.  My assumption is that your C code is using uninitialized registers which is causing accesses (on some boards) to reserved memory locations.  This will crash the device.

Thanks Brad again, I  try to test again accroding your advising

cboot_asm_code.doc

I had a quick look at that document with the assembly code.  A few comments:

1. The first instruction shows up as ".word" meaning it does not disassemble to a legitimate instruction.  That's never good and can result in undefined behavior.  Why is 0xFFFFFFFF the very first instruction?  Is that part of the binary that was flashed, or is something improper happening at the bus level to read that?
2. Address 0x14 looks to be clearing bits 12:2 of register A0.  I'm not sure why only part of the register is being initialized. 
3. Address 0x14 appears to be comparing against A3, but I don't see anywhere that A3 was initialized.  That looks like it could have random results.

Rather than us trying to create and debug brand new assembly code for this task, I strongly recommend using the tried and true assembly code from the app note I referenced.

Hi Brad:

         sorry,I give your cboot asm code because of modifing  last time, please reference original file,   cboot_origianal_asm_code.doc

This is exactly the issue I have suspected all along.  The very first instruction is doing a "push".  The stack pointer (SP) is B15, and it is uninitialized coming out of reset.  So you're writing to a random address in the memory map as you come out of reset.

I think if you wrote this as an assembly function it would be fine.  Just copy all the same instructions except for the very first one.  You can also drop the last 3 instructions (the pop, NOP, and return) since those never execute.

heng ye said:

2. If you are able to connect, where is the program counter?
sorry,when I connect it successfully, I recoder the program counter , reset and restart load program.

You need to configure CCS a bit different when debugging boot issues than you do for normal development.  Please see this wiki article which is highly relevant to debugging your issue:

http://processors.wiki.ti.com/index.php/Debugging_Boot_Issues

Specifically, make sure your target configuration does not use any gel files whatsoever.  The gel files will reconfigure things and destroy the evidence we're looking for.  Also, you can do "load symbols" for symbolic debug, but never use "load program".

Finally, if you follow my main suggestion of writing a bootloader in assembly code, then it is easier to do things like inserting an assembly spin loop at the start of the bootloader like shown on that page.

If inserting the NOP (instead of the PUSH) doesn't resolve your issue, you're going to need to leverage all of these techniques to understand the root cause.

That points to your secondary bootloader as being the issue.