Setting the PC to an address/boot problem

Sean,

I am very sorry to hear that you are having trouble with your TMS320C6713B DSP. Please reply back with the complete device markings on one of the failing parts, and indicate what varies from there on a few other failing parts and a few passing parts. It may sound like an odd question, but did you buy the parts from a TI Authorized Distributor (no need to name them)?

I will start with pointers to an answer, then I have a lot of questions for clarification of this technical discussion.

To go back to 0:

1. Generally, you will have a label at 0, such as _c_int00. In your C code, you should be able to cast that as a function pointer to call it, or it might be as simple as

           c_int00();

2. If you do not have a label, you can create a function pointer variable, set its value to 0, and call through that function pointer. I am always hesitant about the syntax for using function pointers, so I will leave the syntax of that for this (and #1a) to your better judgement and study.

3. Write an assembly function that branches to 0, and call that assembly function in your code.

4. Use in-line assembly to do the same thing. We tend to steer away from in-line assembly because it causes the optimizer to get mad. The in-line assembly that should work (untested by me) is

           asm( " zero b0" );
           asm( " b b0" );
           asm( " nop 5" );

But, I am not sure this is going to do any good for you. I am confused about many things:

a. What is the typo in the title of your post? "nd" = ?
b. I can guess what you meant in your first line, but punctuation somewhere between 95% and 5% could make a technical statement less ambiguous.
c. "The DSP is going to the reset vector" This sounds like a good thing and the expected behavior. Maybe a little more information will help me understand this better.
d. About the reset vector being set, i) which boot mode are you using, ii) which version of DSP/BIOS are you using, if any?
e. I hope that you are not really guessing at how your reset is triggered. But without knowing the boot mode, it is hard to understand what the sequence of events may be. But I can say that no copying is going to be going on before RESETn is released.

Curiously, how did you determine that the DSP is going to the reset vector?

Regards,
RandyP

Hi Randy, 

Sorry for not being clearer in my first post.  We only have two prototypes and most of the time they boot and run with no issues but the small fraction of the time they don’t, they appear to go to the reset vector   So I don't believe the chips are faulty.  The full part number for the devices is TMS320C6713BZDP225 and the boards were assembled at a sub contractors who assemble all our boards and would only have used a trusted supplier.  IF it will help I can find out more information on Monday when I am back in the office.

It is my understanding that the reset vector is moved from address 0 which is where the EMIF, PLL setup and boot codes sits (I am booting from 16 bit flash).

The only things connected to the reset pin on the DSP are DCDC converters that supply the core and IO voltages so it is plausible that they could be resetting it before it is fully booted into main but after the reset vector has been moved. I don't think it is getting to main because I tried pointing the reset vector there and it didn't work.

To try and answer your questions:

1. ad = an I have corrected this sorry
2. I hope I have cleared this up above
3. I pointed the reset to a function in the BIOS which was just a loop to trap it then when the problem occurred I connected the debugger to it (without my GEL file) and it was in the loop.
4. 16 bit boot from flash.  I will have to tell you the version when I am in the office on Monday but it was the one downloaded with CCS5.
5. Like I said about the only external way for the reset to be triggered is by the DCDC converters so unless it is being triggered internally it seems like a logical guess and the only explanation I can come to from my understanding.

I hope this information make the problem more clear and hopefully you can tell me if you think I am going along the right lines or if you think the problem is something totally different related to the internal boot sequence causing a reset.

Many thanks

Sean

Sean,

If the problem is not with the DSP, then we probably will not need to know anymore about the additional package markings. But having them could help later, if you have chance to copy those down. My question about the distributor just seemed like a good question to ask, but it does seem kind of rude, so I appreciate your patience.

Section 5.1 of the C67x CPU & Instruction Set Reference Guide describes how the interrupt tables can be moved. The way they get placed and used depends on the support software you are using and how you configure it. But whenever the RESETn pin is asserted and released, the reset vector (or reset fetch packet) will always be at address 0x00000000; it is set to 0 by the reset hardware, and in your case the first 1K of your Flash gets copied to address 0 and then gets executed from address 0. This is usually a secondary bootloader since your whole program is probably bigger than 1KB.

Sean Bedford said:

The only things connected to the reset pin on the DSP are DCDC converters that supply the core and IO voltages so it is plausible that they could be resetting it before it is fully booted into main but after the reset vector has been moved.

If another reset occurs from the DCDC converters to the RESETn pin, it no longer matters what was done before, now everything is cleared to the reset states again and the copying and booting process starts all over again. But if you could have an extra reset occurring when your program is supposed to be running, you should be able to detect this with a scope, and if you suspect it then you should certainly be watching for it.

Sean Bedford said:

I don't think it is getting to main because I tried pointing the reset vector there and it didn't work.

This really does not make sense to me. There must be a whole lot of stuff I do not understand here, because you cannot just point the branch instruction at address 0 to main and expect it to work. It will not. The C environment is not setup yet, and the boot could not have completed unless the whole application is less that 1KB. What am I missing?

Sean Bedford said:

3. I pointed the reset to a function in the BIOS which was just a loop to trap it then when the problem occurred I connected the debugger to it (without my GEL file) and it was in the loop.

I really need to understand what you mean by "pointed the reset" to anything. What function in BIOS is just a loop? I would think that if you pointed the reset vector to a spin loop, then it should end up in that spin loop every time you release RESETn, and the application would never work because it is always going to the spin loop.

Sean Bedford said:

4. 16 bit boot from flash.  I will have to tell you the version when I am in the office on Monday but it was the one downloaded with CCS5.

DSP/BIOS6 and SYS/BIOS6 both ship with CCSv5. Which version of CCSv5 is it, too? And which emulator are you using? I'm getting nosy too much, but it could save a round of questions.

Sean Bedford said:

5. Like I said about the only external way for the reset to be triggered is by the DCDC converters so unless it is being triggered internally it seems like a logical guess and the only explanation I can come to from my understanding.

Many people do not like my support after this many questions and especially this many "what?" type questions. The first "it" in "it is being triggered" means a reset of the DSP. But the second "it" of "it seems like a logical guess" is one I cannot be sure what is referenced. I am not trying to be difficult, so I am sorry for not understanding even the simple stuff.

Sean Bedford said:

My first question at this point to help debug is when is the reset vector changed from address 0? i.e during the boot loader process copying from flash, during the bios setup code etc?

Going back to your original questions, I think my first post address the subject line of the thread and I have talked about how the reset vector is changed or at least where to read about the ISTP to understand it. And what you specifically asked was when it would be changed: without more details of your application and tools and stuff, I cannot tell you exactly when it will be changed or if it will be changed, but it would never be changed in the boot loading process but would be changed by BIOS if BIOS wants it changed.

Regards,
RandyP

Good morning Randy,

What I mean by pointed the reset is that I pointed the reset interrupt in the BIOS to a function.  So I put main as the function in the BIOS reset interrupt.  As mentioned previously at address 0 is my EMIF setup, PLL setup and boot loader code.

The application does work (95% of the time) when the loop is at the reset vector the bios points to.  I should stress I only put that loop there as a debug tool.

The version numbers that I am using for CCS, the DSP/BIOS and the compiler are:

·         CCS v5.1.0.09000

·         DSP/BIOS v5.41.11.38

·         Compiler v7.3.1

I think ultimately I am barking up the wrong tree with the DCDC converters causing the reset because if the reset pin always sends the device to address 0 then that is not the problem.

I will investigate and confirm that the device is going into the function that is called by the reset interrupt in the BIOS.

If it is as I as I suspect from previous investigation going to the reset vector as it is set by the BIOS then this means that something during boot up must be causing a software reset so it would be helpful to understand what could be causing this.

Please be assured I am greatful of any technical support you can give me and I do appericiate that there is a language barrier as I do not allways use/know the correct technical terms.

Many thanks

Sean

Sean,

In the 1KB code that initially gets copied from your Flash to address 0, what does it do after the boot loader operation is completed? Does it branch to _c_int00? Is this (EMIF setup + PLL setup + boot loader) assembly code you have written?

And it is probably time to take a step back. We started by trying to find a technique to create a code solution to a suspected problem.

What are the symptoms when your board fails?
Will both of the two boards fail from time-to-time?
When a board fails, are you able to get control through CCS? If so, is the program running in a similar place each time?
Do you have access to a GPIO pin that could be toggled at various points in your code to confirm where it is running? Different pulse widths can give you a recognizable signature to tell you a lot about where it is when it fails.
Can you raise or lower the temperature to see if that affects the failure rate?

Regards,
RandyP

Hi Randy,

I believe I can access it in CCS using an XDS510USB it has been a while since I did this so I will reconfirm this when I get some spare time.  Yes both boards fail as far as I am aware temperature isn't a factor but I can investigate this in our enviromental chamber but this is likely to take a week or so to be done properly.  There is a GPIO pin connected to an LED that can be used, is there some simple assembly code that I could put in my bootload program so that I can confirm that that completes when it fails?

The bootload code I am using was example code but I changed the EMIF and PPL values to suit my application.

Thank you

Sean