Hi. It is mandatory for us to include an in-circuit flash programmer on our design using an embedded external CPU. The target device is the CCG3PA CYPD3171 CPU.
This CPU is programmed over SWD.
A few questions:
1) What is the smallest density PSOC that can be used for the Cypress SWD programmer example code? We see the PSoC 5LP (@ $12USD++) that is common to many kits but this specific device is cost prohibitive at this time. Why was this rather expensive CPU selected rather than PSOC4,etc. ? Is it for the higher flash density so it can hold the code to be programmed in an internal array?
2) In studying the CY4532 EVK - how is the CCG3PA CYPD3171 CPU being programmed? Read that the CYPD3171 needs to have a brown out on the VDD rail (as the XRES is not bonded out inside this CPU) but yet the kit (JP6) is shorted to hard +3v3 at all times. So how is the flash inside the CYPD3171 being updated?
Perhaps over CCx lines (and internal bootloader) via the CCG4 CPU (U3)? So in this case, the host Windows PC is spewing out data and/or commands to the USB to UART bridge which then transfer the packets to / from the CCG4 (U3)? Please confirm.
3) Back to the original interest, the generic Cypress SWD programming document reports that a min SWDCLK value of 1.5Mhz is necessary. Why? Only to acquire control of the CPU before a timeout occurs?
The same document also states to reference the datasheet for the target CPU (CYP3171 for us) and believe that the actual datasheet do not impose a min SWDCLK value. Is this correct?
We must decide on the best CPU to create a low cost SWD programmer but also wish to be compliant to the min clock specs.
So the above means that if we can extract the valid CPU ID over SWD - we are in control of the CPU over SWD and ok to lower the SWDCLK for additional commands?
This is to allow us to program a virgin blank CCG3PA at production time but also want this flexibility to allow end users to de-brick the widget without mini-prog3 tools.
I believe that we have clarity on the above but welcome confirmation of our understanding before investing heavy R&D time into this custom programming jig.
Will keep reading...
Ok, so the ACQUIRE phase of the CPU is what demands the 1.5Mhz SWDCLK. The reason being to perform the SWD_LineReset which is:
Standard Arm command to reset the debug port (DAP). It consists of at least 50 clock cycles with data =
1; that is, with the SWDIO asserted HIGH by the programmer. Transaction must be completed by at
least 1 clock with SWDIO asserted LOW.
This sequence synchronizes the programmer and chip; it is the first transaction in the programming flow.
Meeting this timing may be difficult through bit banging so will consider the use of the SPI function to acquire control of the CPU after power cycling the CCG3PA and then proceed to bit bang out the SWD protocol using a slower SWDCLK for our design.