That will not work. Debugging needs the two pins. For power saving reasons you should set those to GPIO anyway when the testing phase is over.
There was something I read about SWD where it said that there was a window after the assertion of XRES in which the host debugger had to "wiggle" the SWD pins.
I was just thinking that there might be something that could be done in the PSOC4 where it waits after a reset before taking control of SWDIO as an output.
Of course I don't know exactly how the SWD works - it was just a thought.
About my other question, if PSoC creator has defined a pin as an output of a DAC, how do you redefine this as a GPIO at runtime?
You may set the drive mode of a pin at any time using the appropriate Pin_SetDriveMode() API. Nonetheless to re-route that pin to a different component could be quite(!!!) difficult. Better use a MUX or some other means. Easiest is to do that with pins that do not have a hardware connection. Can you specify what exactly you want to do in a short example project that you upload here?
Another way could be to disable some components that require pins and use that pins for other means until fully tested.
Every pin on the module is being used for something. I would like (not 100% necessary) one more pin to control the backlight of an LCD (on/off control). I have an I2C bus but would rather not add another device just for this function. My 1st choice was the SWDIO.
I do have 3 outputs which go to an 8 input analog multiplexer. This mux is only used every minute or so to scan 8 analog inputs. If one of the mux control signals was also the LCD backlight control it probably wouldn't matter that the display flickered occasionally.
And I have a pushbutton input that is used even less frequently. That could be a good choice to double up on. Yeah, I think I'll work on that approach. Ta.
you can use swd pins as gpio (look at project01.cydwr -> system tab -> debug select: gpio). sure you will be unable to debug your project, but you will be able to reprogram your device via swd.
nb: I used segger debugger to flash the chip and found out, that jlink programming the flash in debug mode, without "chip acquiring" (magic number sending after reset, in short). so, I couldn't reflash the device. then I "built" "4-bucks programmer" and the problem was solved: after "chip acquiring" swd pins are set to swd mode, even when they are dedicated to gpio in the project properties.
Thanks. I thought that might be the case.
Anyway, I've doubled up the use of my pushbutton input as the backlight control output - a little flicker when I read the pushbutton status won't hurt.
as a side note, it might be useful to modify the assignment of the pins reserved for SWD at runtime also to manage different configurations. In our design, for example, we work with both Release and Debug versions, meaning that for every and each build (which includes five projects) each and every .cydwr files must be manually modified before launching the build - which is not only time consuming, but also error prone.
So, let me renew the question: is it possible to assign the debug pins to either GPIO or SWD programmatically at runtime? If the answer is "yes", where should I look at in the documentation?
I also want reassign pin, but no SWD.
I use by same pin for UART RX and the Software USART TX modules (half duplex 485).
Once I can assign the pin to one of the two purposes by set CYDWR table ,but how can I reassign him in runtime by firmware, wish registers to change?
There is a Register TRM for your PSoC. You'll have to dig the information out of that book.
Thank's..It may be very useful if Cypress will add to the PSoC Creator indication about witch registers changed if I change any thing in the graphic user interface..