PSoC™ 5, 3 & 1 Forum Discussions

Hello all , 

I want to design a custom pcb with PSOC5LP on it , but I want to eliminate 

The need for an external miniprog3 programmer to program that PSOC5LP (I want to program it through USB connector ) , 

I don't want the 10pin header on my board , 

I have looked how they did that in the evaluation board's (psoc5 059 , psoc4 pioneer kit ) , 

I can see they have another PSOC device that they are calling (kitprog) that is connected to usb data lines , 

And this kitprog PSOC is connected to a target PSOC device with the SWD lines (see attached block diagram ),

I have a couple of questions regarding that :

1.can Any psoc device be used as an KITPROG device ?(I want a small as possible psoc package , psoc5lp only ? )

2.How do you program that initial KITPROG device ? (if I don't have the 10pin header and the miniprog3 )

3.Where is the firmware for this KITPROG device ? ( I can't find anything on this subject, but I guess you must have some kind of firmware in that KITPROG psoc device ) 

Can you share your experience with implementing a kitprog device in your boards ? 

any other lines that you must connect between KITPROG device and TARGET device except SWD lines ? (like reset ? ) 

Thanks 

Eyal Lampel

Hello

Is CYC8Kit059 - PSoC 5LP Prototyping Kit still active?
According to Infineon's website, Infineon has none and neither do their distributors. 

Is it still being made? If so, whn might it be availabel?

If it isn't being made, what might be a good substitute?

What documentation shows how to program a CY8C5888 component, so I might be able to use them instead?

thank you

Hi,

We are using PSoC LP5. In our design, we have a I2C slave component. In the ISR_ExitCallback(), we copy write buffer to a queue, and the queue is processed in main loop.

My questions are:

1. At what timing the I2C ISR routine (ISR_ExitCallback()) can be called? is the I2C ISR routine called at any time(as long as I2C transaction happens) while the main thread is looping?

2. How to synchronize the I2C ISR routine and main loop? Is it ok to disable I2C interrupt in the main loop so when main loop reads data from the queue, I2C ISR routing won't modify the queue at the same time?

Regards,

Winston

The Arm Cortex-M0 microcontroller supports a subset of the instructions provided by the Cortex M3. Presumably these extra instructions provide better performance for some applications.

But does this have any implications for a developer writing C code for either of these devices? Would you write code differently knowing that you were developing for one instruction set rather than the other?

For example, if I knew that my target hardware didn't have a single-cycle multiply instruction, I would use bit-shifting rather than multiplying where possible.

I am writing a complex application with PSoC Creator 4.4. The target MCU is CY8C5868AXI-LP035.

Operation is SysTick timer based, counting off a number of ticks to schedule 'tasks'. The number of ticks is always odd, and most are prime, with the intent being to minimize the number of 'task' running in any 1mS tick.

I have code in place to identify any code that runs longer than expected. The longest 'task' is less than 25mS.

SysTick clearly runs at 1000Hz. I added a hardware marker to my SysTick code so I can measure the execution rate with an oscillocope.

After some (indeterminate, but usually small) number of minutes, the SysTick rate changes from 1000Hz to 255Hz, and stays there. There is nothing in my code that should change any of the clocks.

Text coming out of the UART changes from normal to garbage. It normally runs at 115200Hz, so there is no quarter speed baud rate to test with.

I have traced text down to writing to the UART Tx register, and it looks correct.

I even added code to look at the SysTick values, and up to the point where the clock changes, they look good:

uint32 SysTickReload = CySysTickGetReload();

uint32 SysTickValue = CySysTickGetValue();

sprintf(tstr, " SysTickReload %lu SysTickValue %lu", SysTickReload, SysTickValue);
uart_put_line(tstr);

After the clock changes, I have to use the debugger to look at the numbers. They remain the same as before. For some reason, CySysTickGetValue never goes below 9000d. CySysTickGetReload remains 12000.

Does anyone have any thoughts here?

I had a great time with Cypress products.

Looking at the Cypress datasheet, mechanical drawing of 210 mils 20 pin SSOP for cy8c27243, I am confused.

In the updated Infineon/Cypress datasheet ver.AD from 2012 from Mouser.com, the mechanical dimension are fishy.

It seems to be copied error from previous datasheet versions. Look at the mechanical drawing page 48. The dimensions 7.50/8.10mm on the left side of the drawing are copy of the old Cypress datasheet.

My caliper says 10.44 mm (not 7.50 mm). I have the chips on my table.  And I use the chips for a while.  

Can you rectify and clarify this anomaly?

Thanks

I have an existing design based on a PSOC5LP Cy8C5467 where we have had to change to a Cy8C5667.

This variant of the chip will not start up with a slowly rising power supply.

I am using a precision external 17MHz oscillator module as the system clock source. This oscillator is unstable for 5ms during startup which causes the PSOC to NOT boot. It can be solved with an external reset, but we already have product in the field.

The system will start reliably with the IMO internal oscillator OR with the external clock and the PLL disabled.

Unfortunately, the PSOC provides no safety mechanism for external clock, or the ability to program a higher reset threshold before coming out of initial power-up reset.

Does anyone know how to disable the PLL on startup, then enable it without the clocking wizard messing up all my subclock dividers? (ie I need a system clock of 60MHz, and for the wizard to calcualate my various sub clocks, but start up at 17MHz without the PLL)

eg. Compile with the PLL on, so the wizard correctly sets all my sub clocks, but then 'hack the compiled code' to disable the PLL, then start it after I run

// Enable low-voltage detect
CyVdLvDigitEnable(0, LV_POWER_UP_THRESH);

// Wait till low-voltage condition no longer exists before continuing
while (CyVdRealTimeStatus() & 1) ;