Hardware reset issue C6713B

Sean,

Hardware reset should do the same things as power up, in fact the reset pin will be held active during power up until all clocks and power supplies are stable.

There have been some discussions on the forum within the past couple of months about C6713 reset issues. Search for "C6713 reset" (no quotes, or maybe with the quotes).

Sean Bedford said:

The reset line is connected via a resistor to the DCDC converters as on the DSK board.

Is this a modification you made or a statement about the schematic for the DSK?

Which boot mode do you use?

Regards,
RandyP

Hi Randy,

Sorry it has taken me so long to get back to this we have had other priorities.  it is a statment as to how the reset line is connected on our board (the same as with the DSK).

We have now connected the reset line directly to a PIC on our new board revision and cannot connect to or get the DSP to work at all.  This obvisly makes the issue much more pressing.

The boot mode we are using is from a 16bit flash but now that we cannot even debug this doesnt seem relevent.

With the new board revision CCS connects to the DSP but when you load to program it says its runing and gives this error when you try to pause it.

TMS320C671X: Trouble Halting Target CPU: Error 0x80000020/-1060 Fatal Error during: Execution,  An unknown error prevented the emulator from accessing the processor in a timely fashion. It is recommended to RESET EMULATOR.  This will disconnect each  target from the emulator.  The targets should then be power cycled or hard reset followed by an emureset and reconnect to each target.

with the old boards that worked with debug once the program has loaded it would be paused at the start of main so the program clearly isnt being loaded properly. 

Here is a list of the changes that were made between the two revisions that could effect the DSP.

1. Replaced jumpers for 16 bit programming with perm links direct to 3V3/GND
2. Disconnected DSP reset from DCDC converters connects directly to header to be controlled by PIC
3. DSP reset MSB of flash address (previously grounded) and SPI line now connected directly to the header

So it seems to me that the reset ine could be the only one that is causing the issue.  We had hoped that by conecting the DSP reset to a microcontroler we could solve the previous reset issues but it seems to have made it worse.

any idea or things I can try will be much appericaited.

Thank you

Sean

Just to add to the above.  I have now connected to rest line via a 10k resistor to 3V3 to remove the microcontroller from the equation.  I also discovered that out flash programing software loads and runs when I connect to the DSP but our main software crashes it.  I have just checked and the same peice of software works fine with the last revision of or board which I find very strange.

There is also a change I forgot to mention.  We changed the RAM chip used from a IS42S16160D-7BLI to a IS45S16400F-7BLA1 which is a smaller RAM but has identical pin out to the old one except that there are less address lines.

Thanks

Sean

Sean,

Your change #3 is not clear to me.

Recommendations:

1. Connect with the same emulator + CCS to an EVM or one of your old boards to confirm that the emulator and CCS are still working correctly.
2. Try the no-boot bootmode. This is useful for debug and allows the emulator to get control without worrying about what the DSP might be executing.
3. Look at the reset and clock lines to the DSP. Since you changed the reset, that is the most likely problem.
4. A reset going over a header could be picking up noise which will cause problems in the future; noise would not explain this consistent failure but it is something to be concerned with.
5. Look at the EMIF signals. Problems on clock and RDY can hurt the operation of the EMIF interface.

The Stellaris Cortex-M3 line of MCUs would be a good choice for your microcontroller.

Regards,
RandyP

Please delete posted twice

Thanks you

Hi Randy,

Change 3 is that the SPI lines and reset from the DSP are connected to a header which goes to a diffrent board than to a microcontroler.  The MSB of the flash (which is one above the amount the DSP accepts, gos to the microcontroller also (this is to allow two diffrent bootable programs.

I have tried 1 and everything still works fine with our old boards.  Could you please explain what the no-boot boot mode is and how I enable it?

The reset line is at a steady 3V3 and the CLK line is oscilating cleanly at 50Hz between about 1.2 and 2 volts which I belive is normal.

This signals are not easy to probe would a EMIF problem cause the DSP to crash completly and not respond to the debugger?

Thanks

Sean

Sean,

Sean Bedford said:

goes to a diffrent board than to a microcontroler

This is one of those cases where a typo cannot be repaired by context. I think you meant "then", but "than" also has a valid discriminating meaning here.

No-boot is also called emulation boot. Please see page 98 of the datasheet.

What did the reset line do relative to clocks and power when everything started?

Sean Bedford said:

the CLK line is oscilating cleanly at 50Hz between about 1.2 and 2 volts which I belive is normal

That does not sound normal, but I will assume you have read the Hardware Design Guide and you know this better than I do.

Sean Bedford said:

This signals are not easy to probe would a EMIF problem cause the DSP to crash completly and not respond to the debugger?

You can do a lot of things in hardware that make the emulator not work. If the processor is trying to access the EMIF and it gets stalled, everything will stall, including the debugger. We have tried to improve some of this in newer devices, but it still true that the debugger is not immune to hardware problems.

I wish the debugger had error messages that point to a pin failure or a code problem or a timing issue, but it does not.

Regards,
RandyP

Hi Randy

RandyP said:

goes to a diffrent board than to a microcontroler

This is one of those cases where a typo cannot be repaired by context. I think you meant "then", but "than" also has a valid discriminating meaning here.

[/quote]

 

Yes sorry it was meant to be then.

 

The datasheet tells me what emulation boot is but nothing about how to set it up and use it so not really what I was after.

 

The clock ocilating like that is what it does on the board that works.

 

The fact that the flash programming code works on the board but the other doesent does point towards a EMIF problem because as I dont think the flash programming program is big enough to need the flash and as I mentioned we have changed SDRAM.  Allthough from the datasheets the two RAMs look like they should be swapable with no issues. 

 

Is there any way to tell if a program is using the SDRAM in software or would it just be scoping the CE0 pin (which is going to be dificult)?

 

Thanks

 

Sean

 

 

Greetings,

Does your FLASH device have a RESET pin?  If so, is it connected to the Reset signal as well?

Good Luck,

Sam

Hi
Sam no, no reset pin.

I think i have made some progress. My smaller flash writing program does run
which I belive is because it only uses the internal memory. So I thought it
could be some obscure difference with the SDRAM we changed to (they are from
the same manufacturer ISSI, who say other than the size they are the same). I
wrote the following c code in the working program to test the RAM.

while(1)

{

unsigned int temp = 0xFFFF;

unsigned int count = 0;

unsigned int error = 0;

unsigned int buffer;

temp =
0xFFFFFFFF;

count = 0;

error = 0;

while (count < 0x10000)

{

*((unsigned int *)(0x80000000 | count)) = temp;

count +=
2;

temp -= 4;

}

count = 0;

temp = 0xFFFF;

while (count < 0x10000)

{

buffer =
*((unsigned int *)(0x80000000 | count)) &
0xFFFF;

if(buffer != temp)

error++;

count +=
2;

temp -= 4;

}

if(error)

error = 0;

}

All the reads were errors, so I had one board changed to have the old flash on. I got that back today and it still doesn't work. I have spent a lot of time playing around with register and timing values and got no where. My emif registers in my gel file are as follows

/* EMIF setup */

*(int *)EMIF_GCTL = 0x00003068;

*(int *)EMIF_CE0 = 0xffffbf93; // CE0 SDRAM 0x10528191

*(int *)EMIF_CE1 = 0x02208812; // CE1 Flash 16-bit 0x01208812

*(int *)EMIF_CE2 = 0x22a28a22; // CE2 Daughtercard 32-bit async

*(int *)EMIF_CE3 = 0x22a28a22; // CE3 Daughtercard 32-bit async

*(int *)EMIF_SDRAMTIM = 0x00000578; // SDRAM timing (refresh)

*(int *)EMIF_SDRAMEXT = 0x000a8529; // SDRAM Extension register

*(int *)EMIF_SDRAMCTL = 0x6348F000; // SDRAM control (16 Mb)

With this out of a possible 0x7FFF errors there is about 0x7DF5 this fluxtuates and isnt fixed but is allways 0x7Dxx so some reads allways work but the majority don't. I have investigated this thurther and the working reads dont seem to tie up with any data or address lines being disconnected.

I am really puzzeled with this now any help would be great.

I have tried the above code on my old board where the RAM and DSP are wired identically and it works with no errors.

Thanks

Sean

Greetings,

First make certain that your data cache is disabled for now during your testing.

And not knowing your hardware, I compared your EMIF setup with the original one for the DSK below

    *(int *)EMIF_GCTL     = 0x00000068;
    *(int *)EMIF_CE0      = 0xffffbf33;     // CE0 SDRAM
    *(int *)EMIF_CE1      = 0x02208802;     // CE1 Flash 8-bit
    *(int *)EMIF_CE2      = 0x22a28a22;     // CE2 Daughtercard 32-bit async
    *(int *)EMIF_CE3      = 0x22a28a22;     // CE3 Daughtercard 32-bit async
    *(int *)EMIF_SDRAMCTL = 0x57115000; // SDRAM control (16 Mb)
    *(int *)EMIF_SDRAMTIM = 0x00000578;     // SDRAM timing (refresh)
    *(int *)EMIF_SDRAMEXT = 0x000a8529;     // SDRAM Extension register

and would like you to ascertain that they are all fit to your device choice mixture (which appear to be different from the DSK).

Next, your test code is for a 32 bits unsigned integer space in SDRAM.  It is incrementing the address increment "count" by 2 bytes.  Please clarify that is what you wanted to do.

Last, post your results for a follow up.

Good Luck,

Sam

BTW, I assume your old board design uses a different EMIF setup.  Pls clarify.

Greetings,

It is good to get to the bottom of it.  Please mark the thread resolved.

Good Luck,

Sam