Bootloader versus CCS debugger

Hi,

Not sure if this could be relevant however there is the TRST emulator signal that usually controls device normal or emulator function :

TRST : IEEE standard 1149.1 reset signal for test and emulation logic. TRST,
when high, allows the IEEE standard 1149.1 scan and emulation logic
to take control of the operations of the device. If TRST is not connected
or is driven low, the device operates in its functional mode, and the
IEEE standard 1149.1 signals are ignored. The device will not operate
properly if this reset pin is never asserted low.

If by chance there is a problem with driving this signal  correctly it could cause debug session problems as the emulator needs to drive this signal high to allow it to control the device. if it is low, the bootloader I presume would start searching for devices to boot from as per usual. Just a hunch, but could be worth looking into ...

M MARIN

Brian,

Why do you need to stop the normal boot process to debug your firmware?  I must be missing something.  Can't you wait until boot completes and then download your code?  It seems that if you did that you would simply overwrite the code that was loaded from SPI flash and you would be good to go.

This is very hit or miss approach, but I have used it in the past.  Bring up CCS, but don't connect to the target.  Target is not powered up yet.  For this you should not have a GEL file specified because you don't what CCS to modify the state of the processor.  Then, power up the board and hit Connect in CCS at the same time.  I've never tried this with CCSv4, so don't know if there are any issues.  This worked about half the time.

Regards.

Regarding TRST, it's certainly connected on both revisions of my boards.  Now that I think about it, the Reset problems may be due to circuitry attached to the GPIO pins which backlash the power.  So I guess you could break my question into two parts: How do people deal with the Bootloader and Debugger together, and secondly, is it possible to do this without Reset?

@TommyG: Yes, I am waiting for boot to complete, but I can't seem to connect reliably to download my code.  I expect it to work the same, whether my board is running firmware that I have downloaded and want to alter, or if it is running firmware from the bootloader that I want to override.  For some reason it seems much harder now that I have stored a valid bootloader.  Mostly the problem is that I cannot connect reliably.

I'm fairly certain that I don't have a GEL file.  I haven't used one of those since CCS3.  I try to make sure that my firmware startup code makes all of the appropriate settings instead of relying upon a GEL file.  Is there a quick way in CCSv4 to confirm that I do not have a GEL file?

My firmware does engage both Timers, four channels of DMA and all three McBSP peripherals, so sometimes I wonder if too much is going on for the Debugger to get a word in!

Hi Brian,

I've resolved (to some extent) some of the emulator intermittent connection problems by reducing the clock speed (from the default 35MHz). Depending on your emulator, you could try reducing the clock to the ""legacy jtag 10,723MHz  (or whatever it is)"or even assigning a fixed frequency, say 20MHz instead of the 35MHz limit which is normally the default for the XDS560 types (and similar). How and why this may be due to the flash bein programmed, the mind boggles ...

The custom board I use does have the EEPROM flashed with one code or another, but generally it loads the software on a reset (or when the emulator is not connected to the target), then the emulator takes over when I connect to the target as per usual, so I cannot quite relate to the same downloading problem your experiencing, but I've had the occasional connecting to the target issues.

Regards, M

Thanks, M, I should have mentioned that I have the XDS510, which is limited to the legacy 10.368 MHz frequency.  I tried to ask here what the maximum frequency is for the C5506, but that information is not documented as part of the chip specifications.

In the mean time, I have erased the Flash, so this should no longer be an issue for me.  I also hope to improve the board on my third revision, and perhaps then the Reset will work.  In the past, with my first revision board, I could reset the DSP and even step through the bootloader, so the CCS3 Debugger had full control.  Except for the fact that CCSv4 will sometimes hang waiting to clear breakpoints in my device, I think that some of these issues might be my hardware.

Brian,

Wanted to clear something up that you mentioned about CCSv4:

I'm fairly certain that I don't have a GEL file.  I haven't used one of those since CCS3.  I try to make sure that my firmware startup code makes all of the appropriate settings instead of relying upon a GEL file.  Is there a quick way in CCSv4 to confirm that I do not have a GEL file?

CCSv4 Target Configuration does use GEL files unless you specifically remove them (similar to CCS3.3).  Across the bottom of the window should be 3 tabs.  Click on the Advanced tab.  This should show you an All Connections window.  Click on the C55xx icon and this will open Cpu Properties on the right pane.  The GEL file is specified there.

Also, as far as I know, as long as the CPU is in a valid operating state the emulator will always be able to get control of your device.  I would check the JTAG signals to make sure they are clean and meeting spec.

Regards.

Thank you for the information, Pedro.  I was mostly looking for other people's experience as a benchmark.  Sounds like it's reasonable for me to expect that it should work better than it is now, but that the changes may be up to me and not the tools.

To give a few more details, I am running the C5506 at 108 MHz, but I have Timer0 set to 4 MHz and triggering DMA4 for a 16-bit transfer.  Now that I do the math, this means I have a DMA transfer happening at least once every 27 cycles!  On top of that, Timer1 is running at 1 MHz and directly or indirectly triggering 3 more DMA channels (DMA0, DMA1, DMA2) for 16-bit transfers.  Maybe I am imagining things, but it seems possible that the debugger cannot get in past the DMA, perhaps because I don't have the DMA channels set to stop during debug.  Are there any particular recommendations here?  I see that there is a global FREE setting to control DMA operation during Emulation breakpoints, and I recall turning this on to allow accurate frequency generation even when stopped in the debugger.  Could that be causing trouble?

I do have a reset button on my custom boards, and have used it in the past.  However, now the boards are mounted inside our product case and I don't have easy access.  Also, the CCS Debugger Reset seems to cause problems.  As I alluded to above, my analog power supply is switched on or off via GPIO outputs, in order to meet USB requirements for under 100 mA current draw before configuration.  Unfortunately, my analog power circuit is a little too small for the current draw, it produces heat, and seems to cause Emulator issues whenever it is turned off (possible backrush of current).  I have an improved board design in process, so perhaps I would be able to use Reset without any problems once I clear up that issue.  In fact, that one problem may be the source of all of my emulation troubles.

I still appreciate the feedback on how other people are dealing with the bootloader in combination with emulation and debugging.

Brian,

CCS communicates with the DSP core through JTAG and requests the CPU to read registers, variables, I/O locations, and memory of all open windows (including the disassembly window) . If the DMA is constantly being triggered, this should happen on the background. However, if a window needs to be filled (disassembly, variable, or memory view) and this is also a bank that is used by the DMA, you might have the condition where the DMA's constant access to the memory prevent the CPU from accessing it. If so, you would get an error from the debugger that can't communicate with the device and disconnect. This condition can be readily corrected by setting the FREE bit in the DMA GCR to 0. Thus when the CCS stops execution, the CPU can access the memory and stop DMA transfers. 

On a breakpoint, CCS replaces the current instruction with a TRAP to trigger an emulation interrupt. Until a breakpoint is reached, CCS does not ask any of the windows to be updated unless a refresh command is sent from CCS by right clicking on a variable or a window. Once a breakpoint is reached or a refresh is issued, CCS sends a JTAG command to have the CPU read the necessary information, send it over JTAG, and displayed on the screen.

If there are too many DMA accesses to several banks of memory, you might ease things up by closing those memory or variable windows. In this way, we minimize JTAG's commands to the CPU to read those locations, removing extra load to the memories.

As far a CCS reset, it is a software reset and not a hardware reset. Only portions of the device that allow software reset, will be reset. Thus, it is not the same as a true hardware reset. in many of our devices, a hardware reset will tri-state pins during reset and then set the pin to the reset state after reset. In contrast,  a software reset just sets the state of to its reset condition. In case of GPIOs, the reset state is an input. If your GPIO controls the analog power supply, this pin will probably become an input with reset and not drive a value. Do you have a pull-up or pull-down so you do not have an un-driven input into your analog supply? Also, make sure that I/O supply is the same between GPIO and analog supply input so as not to have the GPIO trying to power the analog circuit if the supply of this circuit is down. C55x I/Os should not be connected to unpowered devices. Otherwise, a path between the I/O supply and the other device is established and the I/O pin will drain current through it. Sort of the I/O powering the other device's I/O supply.

Finally, in my many years at TI, co-workers and I have never had an issue connecting to a device that has bootloaded with CCS and stopping it in the middle.

Thanks for the help, everyone.  I think we can close this one unless someone sees something important below.  I'll reopen things if my new C5506 board revision still has problems.

As for the GEL file, when I look at the Cpu Properties, the "initialization script" is blank.  This leads me to believe that I have no GEL file.  I guess I could check the Bypass button for extra measure...

Thanks for the hints about the variable and memory windows.  I do have a few that I could close.  They're not visible, but I suppose they could still be requesting values.  Usually, it's fairly obvious when the JTAG slows down for a graph or other data-intensive display update.

Regarding Reset, there is a menu option next to Reset Emulator, named CPU Reset, which seemed to work as well as pressing reset on my first board revision.  This option no longer works, and I think the cause is my analog supply (backcurrent).  I only have a problem when the supply turns off, and this is true whether the DSP gets reset or not.  I think we can safely assume that my issue is hardware and not software.

Thanks for the hint about making sure the GPIO supply is the same as the control signals for the attached circuits.  Actually, they're always powered when the DSP is powered, so that meets the GPIO requirements, and all that the GPIO controls is the /SHDN signal which turns on the output.  These are actually just regulators, so perhaps "supply" is a misnomer.  Hmm, since the raw USB voltage feeding the analog regulator is approximately 5V, but the GPIO supply is 3.3V, perhaps I'm making the GPIO pin unhappy, but the regulator should work with any positive logic above 2V.  Perhaps I should start a discussion about this sidebar.

P.S.  I learned the hard way that my GPIO output needs a pull-down.  In my first board revision, I had two analog supplies, but I deleted one of them in my second revision.  Unfortunately, I had not realized that this deleted supply had an internal 6 MΩ pull-down inside the /SHDN circuit that magically made everything work.  As soon as I powered up my second revision, the remaining analog supply kept cycling on and off due to the unknown state of the high-impedance GPIO pin.  So I added a pull-down and all is well (except that I need to upgrade to double the current).

Hi PedroGelabert,

You are right.
Similar problem happens with the  ezDSPc5515. I accidentally loaded a faulty code(probably wrong PLL settings) , and the board stopped connecting to the CCS after bootloading. 

I tried to reset, but the board doesn't have a reset button. I suggest the design team to notice this and add a reset button in the future versions.

Then I managed to connect by corrupting the data lines from the memory chip from reading the boot signature.

Anand,

I have also programmed the PLL wrong, set wrong status registers, or bad EMIF programming values. This usually gets me in trouble connecting to a board. Once I fix those issues, no problem. I have worked around these operator errors by hitting reset on the board and quickly try to connect to the device before it bootloads. Having a reset button is a nice workaround to many issues, not sure why it was not placed on the ezDSP.

Thanks for your feedback. I will pass your suggestion to add a reset button if a board revision is done or on future ezDSP or EVMs.