PSoC™ 5, 3 & 1 Forum Discussions
Hello,
I have a problem with the following case and I'm looking for help:
We tried to program the CY8C26643-24AI chip with miniProg3, using ISSP protocol.
The programming configuration in the PSoC programmer were as follows:
Programming mode - Reset;
Verification - Yes;
Auto Detection - Yes;
Protocol - ISSP;
Voltage - 5.0V
Ultimately, we cannot program the device, the device cannot be indentified (nonetheless, we even tried to fiddle with the aforementioned parameters as well- which we think is the right one - in hope for a better outcome. Failed. Naturally.). On the SDAT pin, we experience (by using an oscilloscope) that the PSoC1 sends a signal alternating between 4V and 5V, but only when responding to the programmer. (there are no other parts of the circuit that may cause this) This signal is read as 0xFFFF. Do you have any suggestions what can be the problem?
I've previously read that maybe if the device is configured for I2C comunication, it can sabotage the reprogramming. If this is the case (I've no idea) then what are the proper countermeasures to solve this?
Thanks in advance,
David
Show LessHello!
I need some help or reassurance in the following:
I have implemented a design whose purpose would be to act as a 'man-in-the-middle' in a non-standard paralel bus communication.
I've created a component with Verilog implementation in which the byte-wide databus is bidirectional, therefore I also instantiated 8 BUFOE modules which are connected to the PSOC 5LP bidirectional digital pins. The Data bus is driven by the MASTER on the DATA pins, except when a read cycle is initiated in which case the SLAVE gains control over the DATA bus. The slave drives the DATAO pins.
After building the design with a newly created component, the following warning appeared:
"Warning-1366: Setup time violation found in a path from clock ( Clock_ibus ) to clock ( Clock_ibus )."
(note: my Master Clock is 48MHz)
After opening the STA report, the following was highlighted as the timing violation:
Upon closer inspection I found that the accumulated delay is made up of these steps:
I have attached the Verilog implementation of my component below, but here's a block diagram of the relevant hardware elements:
My assesment of the situation is that the Static Timing Analyser, built in the PSOC Creator, is ignorant about the OE and its inverted pair -OE signals and their effect on the BUFOE components.
In the analysis I can see how the signal originates from my MUX-ed registers, go through the BUFOE, take a U-turn in the iocell (the physical pin, so to speak), go around the BUFOE's fb (feedback) signal, straight into the other BUFOE, another U-turn at the other bi-directional pin, and straight back to my bufreg's input via the din (fb) wire. This whole route is supposed to be completed within a clock cycle + setup/hold times, no wonder the signal propagation delay is a blasted 79+ nanoseconds. In reality, when the OE signal is LOW (-OE is HIGH), the data on dout never reaches the DATA pin. When the OE signal is HIGH and -OE is LOW the data never reaches the DATAO pin.
Knowing how the BUS protocol and my hardware control these signals, I plan to ignore this warning, but use the STA report to calculate reasonable clock frequency (24MHz).
My question would be: Am I right? Can I ignore the STA warnings? If yes, is there any way to make the STA to calculate with the right parameters/constraints(or whatever)? I skimmed through the PSOC Creator User Guide's but found nothing helpful (Directives included...)
Thanks,
David
Show LessHello,
I developed an application that uses the following calls of:
uint8 I2C_MasterWriteBuf(uint8 slaveAddr, uint8 * wrData, uint8 cnt, uint8 mode)
uint8 I2C_MasterReadBuf(uint8 slaveAddr, uint8 * rdData, uint8 cnt, uint8 mode)
In order to read data from FRAM.
It works fine.
Then I integrated FreeRTOS inside this application.
The IIC is a resource that should be used in few tasks.
So I create a counting semaphore in order to implement a critical section:
xSemaphoreTake (..)
I2C_MasterWriteBuf (..)
xSemaphoreGive (..)
The problem:
I created the semaphore with:
SemaphoreHandle_t sem = xSemaphoreCreateCounting(1, 1);
After the semaphore creation, I2C_MasterWriteBuf started to return 2 and not 0.
I did not call to xSemaphoreTake and xSemaphoreGive yet.
What can cause it ?
Thank you,
Zvika
Show LessHello,
We are trying to brig up new PCBA with PSoC 3 CY8C3866LTI-068(48pin) now. When I download project using Miniprog3 and PSoC Creator, it occurred the read memory error as below massage. And then I checked PSoC creator 4.2 and MinProg3 and they are working correctly with on CY8KIT-001. So, I am thinking new PCBA might have problems. Could you tell me what item or circuit I should check?
Error "Unable to acquire target device PSoC 3 CY8C3866LTI-068: Unable to read memory, Debug Enable is not set. Click Port Acquire to reset the chip and enable debug." was received while trying to change the selected target.
Show LessI'm trying to find what the timing is when using the Sequencing Successive Approximation component in 5LP. The important parts are:
1. Time from mux-in to ADC start
2. Length of ADC
3. Time from ADC finish to mux-out.
When looking at the input signal I can see the mux-in and the time it takes to stabilize, then some ringing during mux-out that seems to affect the result. I'm worried the last part of the SAR sampling is taking place during this ringing part as well. We see a 2-4 bit higher value than expected. The ADC inputs capacitance is rather high so a buffer with good driving capability is needed to acheive a stable value fast enough. I'm running the sequencer at 18MHz and testing with NCS20034 as buffer.
Thanks for any input regarding this, Jacob
Show Less
I have a need for more than 20 x 4 LCD characters. Actually the major reason for wanting to use a graphic display is that the neither 20 x 4 or the 16 x 2
LCD's will fit into the display space of the enclosure that I want to use. So I thought to use a graphics LCD that does fit.
Chris D.
Show LessHello all.
-- A little background --
We are having a problem with our product that uses a PSoC 5lp. Here is a little history of our product. We have been using the CY8C5267LTI-LP89 in our product for about 2 years. Since then we have had 5 different board spins. The latest board spin is drawing too much in low power mode, which I believe to be uncovering some "best practices" we were not following. Our previous boards were drawing ~200uA in low power mode ( measured input power. A little high, but not the biggest fish to fry. Started around 80uA and then crept up to 220uA). Our current board starts around 600uA and then creeps up to about 2-3mA. In order to preserve our IP I can not upload a project, or code, but I can provide snippits.
Here is what we do for low power mode ( with respect to the mcu)
- Put all components to sleep
- CyPmSaveClocks()
- CyPmSleep(PM_SLEEP_TIME_NONE, PM_SLEEP_SRC_PICU | PM_SLEEP_SRC_CTW );
Then wake up we
- CyPmRestoreClocks();
- wake up all components
Most of the GPIO is either analog input or digital out (strong drive) I did find ~5 pins that were digital high impedance pins.
Currently the Debug Select is set to SWD + SWV.
I've spent a ton of time debugging this, but here are some key points
- I have verified that MCU is infact going to sleep based on the current spike that I see every second ( based on waking up each cycle of the CTW)
- I have tried setting those 5 digital pins to analog high z during sleep mode, to no change in power consumption.
- I created a blank project and only added 3 pins ( needed to turn off power rails on our board) and tried setting it to sleep. This dropped down to ~80uA and crept up to ~200uA. (Debug Select was set to SWD + SWV)
- I redid step 3, but set Debug Select to GPIO. Power draw was at ~80uA and stayed there ( no creeping for 10 minutes)
- I was not able to set Debug Select to GPIO in our current project. That option is not even there.
I'm leaning towards the power creep being related to the Debug Select. Because of the creep, I can not accurately gauge how much more power this board version is drawing. So it could be that setting those 5 pins to analog high z did in fact help, but because of the creep I am unable to confirm that.
--tldr--
Under what circumstances will GPIO NOT be an option for Debug Select? The only difference (major difference) I can see is that we have a separate bootloader project and our main project has a bootloadable component. What other steps can I take to set the Debug Select to GPIO?
Show LessIt shouldn't be too difficult, but I don't want to reinvent the wheel, if I don't need to.
I don't see any reasonable way to debug PSOC1 SW beyond only simple things. I have the POD but cannot get the proper attachments for CY8C20247s. Am I wrong here?
I am simply trying to create a single capsense sensor on a board that does some processing, counting and display.
I have been using the psoc1 for a long time, the program I have is extensive but I find myself unable to add the new features I would like.
Should I give up on PSOC1 and go with another family like psoc 4?
What is the best way to convert the sw from posc1 to psoc4?
Show LessHi All,
I am currently trying to implement an I2C Slave on my PSoC5LP and I am having a bit of trouble. I have to implement the I2C commands in the fashion of an eeprom, where each address corresponds to a single byte. From some research, using the EZI2C slave is a straightforward way to do this. It even has read and r/w sections and built in sub-addressing. This is the exact memory implementation I am hoping for.
However, my small embedded system needs to be able to trigger functions upon the read and write of certain locations in memory. For example: upon a write to I2C address 0x70, memloc 0x34, it should trigger a stepper motor to step CW if a 0x01 is written to that memloc and CCW if a 0x00 is written. As far as I can tell, there's no way for the EZI2C implementation to tell WHICH addresses were written to or read from only that a read or write did occur. This becomes an issue because simply copying the readbuffer array to a new array and comparing the values wouldn't be good enough. I would need to trigger the stepper motor every time a 0x01 is written even if the previous value was already a 0x01.
I initially tried doing this with the standard I2C component, but sub-addressing with that component seemed very difficult if not impossible.
I am at a loss on the direction to go here and would like appreciate any guidance!
Show Less