Pull down pins on "suspend"

Hi,

Are you referring to the JTAG output pins TDI, TRST, TCK and TMS? I know that pulling down TRST would reset the JTAG logic and therefore cause a disconnect between the emulator and the device, therefore an undesired condition of a simple suspend. Similarly, the other pins would probably be held in their previous state to avoid any disruption in the sequence of commands to the JTAG state machine.

Also, devices with multiple cores would certainly require the JTAG communications to continue as before, given that other cores may still be connected and either running, halted, disconnected, etc.

Issuing a reset or a disconnect presumes you expect a disruption in the current core status, therefore I would expect a complete change on the JTAG signals.

Regards,

Rafael

I think it's all the non-JTAG pins that the OP wants to pull down on suspend. It's a feature I've been wondering about myself.

As an example of when this might be useful, consider the Sharp Memory LCD Boosterpack. The display requires external COM inversion at >=1Hz whenever it is enabled. By default the board is configured to accept that signal as a SPI command sequence. When I pause execution the SPI transmissions stop, so there is no COM inversion and the LCD becomes DC biased.

If it were possible to override the state of a GPIO while paused in the debugger, I could pull the display enable line low temporarily. Then the display would automatically go blank while paused, and it wouldn't require COM inversion any more.

Unfortunately I'm not sure that this is a practical idea. Presumably the original GPIO states would need to be restored when resuming or stepping so as not to affect the behaviour of the program. Also the pin state is pretty complex, what with all the different functions available. The debugger would need a lot of target-specific code to handle this feature.

Robert Cowsill said:

If it were possible to override the state of a GPIO while paused in the debugger, I could pull the display enable line low temporarily. Then the display would automatically go blank while paused, and it wouldn't require COM inversion any more.

GEL scripts allow the access to registers on the target. There is a OnHalt() GEL callback which can be used to take action upon a target halt. e.g. the following was placed in a GEL script for a MSP-EXP430FR5969 fitted with a 430BOOST-SHARP96 which clears the DISP signal to the display when halted in the debugger:

// Register addresses copied from msp430fr5969.h / msp430fr5969.cmd 
#define BIT3                   (0x0008)

#define PBOUT_H *(unsigned char *) 0x0223     /* Port B Output */
#define P4OUT                  (PBOUT_H)      /* Port 4 Output */


// When the target is halted clear the DISP signal to the Sharp96 display,
// tp prevent the LCD becoming DC biased while halted in the debugger.
OnHalt()
{
	P4OUT &= ~BIT3;
}

Robert Cowsill said:

Presumably the original GPIO states would need to be restored when resuming or stepping so as not to affect the behaviour of the program

The above example GEL script doesn't restore the GPIO state when resuming or stepping. This is because I haven't worked out if it is possible to get a GEL callback activated when the target is set running.

[One possibility would be to install a GEL hot-menu which restored the GPIO state and then set the target running - but the user would have to remember to use the GEL hot-menu rather than the normal CCS debugger controls.]

Hi Robert,

Thanks for your reply. You have actually understood my problem. In my case i am using the PWM pins to drive solid state switches in a power converter. I cannot use "suspend" because I risk shorting out the power supply if the switch remains on too long. Anyways my question was purely for improving the debugging process of my prototype. I do not mind that much resetting for now.

I will try and follow up on the lead provided by another reply in this thread, suggesting the use of GEL files.

 

Chester Gillon said:

One possibility would be to install a GEL hot-menu which restored the GPIO state and then set the target running - but the user would have to remember to use the GEL hot-menu rather than the normal CCS debugger controls.

The following GEL scripts adds menus which restores state of the DISP signal and then runs the target:

// Register addresses copied from msp430fr5969.h / msp430fr5969.cmd 
#define BIT3                   (0x0008)

#define PBOUT_H *(unsigned char *) 0x0223     /* Port B Output */
#define P4OUT                  (PBOUT_H)      /* Port 4 Output */

// Used to save the state of the DISP signal upon a target halt
int DISP_state_saved = 0;
unsigned char DISP_state;

// When the target is halted clear the DISP signal to the Sharp96 display,
// to prevent the LCD becoming DC biased while halted in the debugger.
OnHalt()
{
	DISP_state = P4OUT & BIT3;
	if (DISP_state != 0)
	{
	    P4OUT &= ~BIT3;
	}
	DISP_state_saved = 1;
}

// Restore the saved state of the DISP signal
RestoreDispState()
{
	if (DISP_state_saved)
	{
		P4OUT |= DISP_state;
	}
}

// Menu items to restore the saved state of the DISP signal and then run the target
menuitem "Restore and Run";

hotmenu AssemblyStepInto()
{
	RestoreDispState();
	GEL_AsmStepInto();
}

hotmenu AssemblyStepOver()
{
	RestoreDispState();
	GEL_AsmStepOver();
}

hotmenu StepReturn()
{
	RestoreDispState();
	GEL_StepOut();
}

hotmenu StepOver()
{
	RestoreDispState();
	GEL_StepOver();
}

hotmenu StepInto()
{
	RestoreDispState();
	GEL_StepInto();
}

hotmenu Resume()
{
	RestoreDispState();
	GEL_Run();
}

This works, but is not ideal since it has created a new menu which has to be used to run the target, rather than being integrated into the existing debugger buttons / keyboard short-cuts.

If you are prepared to modify code in the target then an alternative could be:

1) Only use a GEL OnHalt() callback to disable the DISP signal

2) Make the target regularly set the DISP signal when it is running - so that on resuming the target the target is responsible for re-enabling the DISP signal rather than GEL script.

Fonkwe Edwin said:

In my case i am using the PWM pins to drive solid state switches in a power converter. I cannot use "suspend" because I risk shorting out the power supply if the switch remains on too long.

Are you using a device which supports Real-Time Mode ?

I haven't looking into how much latency the GEL script introduces between the target being halted, and the target registers being written. As explained by the Wiki, Real-Time Mode can avoid the need to suspend the target to read/write memory and peripherals.

I am using a TMS28335 which supports realtime mode. I am not currently at my test bench so I will only try the gel files subsequently.

Thanks.