C6713 GPIO trouble becomes catastrophic failure - cannot access DSK from CCS

Christian,

Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI.com documents and in the TI Wiki Pages. Be sure to search those for helpful information and to browse for the questions others may have asked on similar topics.

Christian Wright said:

I've been attempting to work with GPIOs and testing my code by applying 3.3V and 0V alternating to GPIO pin 15

My recommendation is to use a 1K resistor between your 3.3V/0V source to prevent current drive problems on the DSP.

Christian Wright said:

I've been using DIP 4 of SW3 to activate the GPIOs.  I read in some forums that this resulted in the endianness being flipped over

"read in some forums" is not very meaningful for us to help understand or dismiss this. It seems unlikely to me that toggling one of the USR DIP switches (device SW1 on the schematic and the board silkscreen lettering) would affect endianness, but it would make sense if you were toggling the configuration DIP (device SW3 on the schematic and the board silkscreen lettering) switch's bit that controls the device endianess [SW3-1].

Christian Wright said:

"Failed Software Reset: Error 0x80000020/-1070  Fatal Error during: Execution, An unknown error prevented the emulator from accessing the processor in a timely fashion."

There was a TI Wiki Pages page I was pointed to once that had some of the emulation error codes. You could try searching for "error codes" (no quotes) on the TI Wiki Pages to see if it is there or not. That table might vary depending on which version of CCS you are using, so that detail would be good to post to us. But there will not be much better information for an unknown error; that is probably the best information you will get.

Christian Wright said:

I would reset the simulator as it suggests and reset the DSK

What involvement is a simulator taking in this? Are you using something like MatLab to run part of the project while also using the DSK? I am confused.

Christian Wright said:

"The GEL function "StartUp()" for the target "C6713 DSK/CPU_1" is still processing.  The function could contain an infinite loop."  But I wasn't using GEL at all in my code, unless it was referenced and buried somewhere in the starter code.

When there is a GEL file attached to your configuration (method varies depending on CCS version), there are some functions that will run automatically. Startup() runs when CCS starts running, OnTargetConnect runs when you connect the emulator logicly through CCS, and other functions run at other points in time. Open your GEL file and look for functions that start with the word On.

Christian Wright said:

Is there any way to restore system defaults or break this error cycle?

Probably by changing what you are doing with the wrong DIP switch, but that may be a rude guess before you have had a chance to apply some of that information, or point us to the forum posts or correct my misstatements.

Christian Wright said:

My senior project is due in less than a week, and this is the last system that has to be installed.

It is always that way, no?

Regards,
RandyP

Thanks so much for responding quickly RandyP,

While I will hurry over to the TI Wiki page and search for error codes, I believe I can clarify several details from my first post which might assist in diagnosing the program.

I agree that the endianness should not have been changed unless I used [SW3-1], but at no time did I move that switch.  In the forum post I was referencing, it appeared that another user had also been given an endianness error when using [SW3-4], though I did not see detailed resolution by the user to that specific issue.  My only purpose in referencing the post was that this symptom might be more recognizable, but I see that it is not.  

So despite moving only [SW3-4], when trying to load my program just before this series of communication issues occurred, the message I received was that my program could not be loaded because it claimed my compiled code did not match the endianness of the target device.  Unfortunately, I can't replicate the error to provide the precise message.  Allow me to also state the fact that I was loading program after program to the DSK with [SW-4] toggled and successfully affecting parameters with GPIO15 before this occurred.  The only changes that I made were to code, specifically I was moving the location of the GPIO configuration code so that the GPIO handle would be available in an interrupt.

Prior to this, the emulator would claim there was a problem (sometime suggesting it might have been a stack overflow) and would have to shut down almost every time I tried to reference the GPIOs using CSL - that is, every time I loaded the program and ran the code on the DSK, I would receive an error requiring a reset of the emulator.  This typically happened in less than one minute of the code running.  On some occasions, program continued to run in the DSK and my audio was being successfully processed post error until I was forced to close CCS to reset.

Referencing my original post, I apologize for using the word "simulator" when I meant that it was the "emulator" I was resetting.  I can see why that would cause confusion.  

I'm looking for details on which version of CCS I'm running, but I can no longer fully enter the software without the DSK running.  The splash screen displays Code Composer Studio v2 before I have to abort, and I'm running it on Windows Vista.  I'll keep trying to get back into the program so that I can determine this information and to look at the automatic functions that you mentioned would begin running.

As I have all of my DIP switches reset to 0 as originally configured, I won't be able to restore system defaults by that method.  May I assume your suggestion of using the DIP switch to restore defaults indicates that there is not another method to apply a "factory reset"?

Is it also possible that the issues I'm encountering are with the emulator and not the DSK?

Thank you,

Christian

Hi RandyP,

I was activating SW3-4 prior to reset and switching it off at different points during my testing procedures.  Since it was not 100% clear to me in the Spectrum Digital docs that the only logical characteristic of the DIP was a pull-down of GPIO pin14, I wanted to see how operation was affected.  My ultimate goal was to use GPIOs 15-8 to transfer a consecutive 8-bit word from a microcontroller and avoid unnecessary bit-manipulation in code, and since my results in debugging mode were not as I expected, I began to consider the possibility that SW3-4 might somehow disable GPIO pin14 - even though that seemed unlikely.  This is the only reason I was toggling SW3-4.

I suspected Vista was a concerning element of our test-lab since we installed it.  The libraries provided to us by our professor were installed following a procedure that required an older version of CCS and Vista or XP.  Since we could only acquire Vista, that's the program we installed on a dedicated laptop for the purpose of developing with the C6713 DSK.  

I have since learned a great deal about the code and libraries that support the C6713, and I am definitely considering using a different laptop and operating system and relinking all of the libraries manually.   Perhaps this will allow me to use the current version of CCS.

Thank you for your recommendations.