programmer building pitfalls ?

Questions about programming (not codeing) PSoCs and Encore II as well as freeware programming hardware and software are discussed here. This is also the place to talk about production programming. Programming means loading a HEX file in to the Flash, not, writing your program.

Moderator: ericb

programmer building pitfalls ?

Postby werner on Fri Jan 20, 2006 11:30 am

I'm trying to use PSoCs in a project where all the required software
must be free (gratis) and ideally also should be Free (GPL, or such).
Since all the development tools for PSoCs seem to be based on
Windows, this means that I'll have to build my own tool chain (i.e.,
programmer and assembler for now).

Unfortunately, I'm having quite a bit of trouble already with the
programmer. My first attempt was a bit-banging adapter connected
to the RS-232 port. It sometimes almost works, usually between
midnight and 1 a.m. :-)

Assuming that slow edges and/or noise are the problem, I've built
another one (for debugging - ultimately, I'll want the simple one),
based on a PIC. It uses the reset method and connects directly to
the PSoC, with a 1k pull-down on SDATA (no other resistors or
capacitors). It can send a burst of up to 8 bits every 2 ms (which
also drops XRES), or do some other operation (assert XRES,
read SDATA, etc.) every 1 ms. Pulse width is 1 us or longer.

If section 3.1 of AN2026A is correct (I don't quite trust that
document, see also my posting in the Application Notes forum),
that should work. I've verified that the first eight bits get sent
within < 100 us after dropping XRES.

Unfortunately, all I get is a very silent PSoC, that doesn't even
produce a visible response to READ-ID. The chips I'm using are
the CY8C21323 and the CY8C24223.

So I wonder if there are any other things I have to pay attention
to, e.g., any requirements not clearly mentioned in AN2026A, or
possibly even errors ? What problems did other people building
programmer hard- or software encounter ?

Thanks,
- Werner
werner
The Big Cheese
The Big Cheese
 
Posts: 246
Joined: Fri Jan 20, 2006 10:20 am
Location: Buenos Aires, Argentina

Postby aji_s on Sat Jan 21, 2006 11:32 am

Hi Werner,
there is much information about implementing AN2026,A,B available in this forum.Also some source code portions (including from my own freeware programmer ) are available which can accelerate your development .

A freeware programmer is already available for Macintosh at MacPSoC Programmer by Eric.

If you are using Linux, I can port my freeware programmer if necessary.

AN2026A is correct and most of the problems are already discussed in various posts.Try a search or checkthis topic. If you are using a pic based programmer there is no need to use 1K pulldown on SDATA.I think your problem arises from this.Also check whether HiZ state is implemented correctly.
I think SDATA line can detect logic level correctly only if logic high is almost equal to VDD of PSOC.Use an external regulated power supply.
If you are not using pic timing and logic level can cause problems.

I am also interested to know whether there is any development of linux versions of assembler or compiler in progress at Cypress.
Regards
Ajith
aji_s
Cheese Wheel
Cheese Wheel
 
Posts: 81
Joined: Thu Nov 04, 2004 5:44 pm

Postby werner on Thu Jan 26, 2006 1:56 pm

Hi Aji,

thanks a lot for your reply ! I removed the 1 kOhm pull-down, but all this
seems to yield is a longer time (> 1 us) for SDATA to settle. (What this
really means is probably that the PSoC doesn't even notice I'm trying
to program it.)

My current theory is that there might be some additional timing requirement
that I'm not meeting. In my PIC-based programmer, the PIC just passes bits
around, while all the intelligence is in the PC, so there can be quite significant
delays (I meet Txresinit, of course). Other programmers may never run into
this problem because they're faster. So my plan is to move the entire vectors
into the PIC, and if this works, gradually migrate things back. Even if my
theory is plain wrong, this will at least make things fast enough to let me
examine the entire exchange on me scope, which doesn't have very deep
memory.

Thanks a lot for the pointer to the thread ! So it seems that it's safe to
ignore the additional WAIT-AND-POLL semantics on page 26 ? (It's not
very clear where this would apply anyway, since there is no WAIT-AND-POLL
mnemonic anywhere else in the document, only several places that say in
some way "wait and poll". Anyway, I can try some combinations ...)

aji wrote:I think SDATA line can detect logic level correctly only if logic
high is almost equal to VDD of PSOC.Use an external regulated power supply.
If you are not using pic timing and logic level can cause problems.


Tried that too, without effect :-( By the way, I wonder if it's a very bad
idea to do the programming while the PSoC runs off the SMP. It violates
the minimum voltage requirement, but if I can "almost always" get away
with that and if data retention is at least a few months, that would be
sufficient. (Some of my earlier "almost successful" experiments suggest
that there may indeed be hope.)

- Werner
werner
The Big Cheese
The Big Cheese
 
Posts: 246
Joined: Fri Jan 20, 2006 10:20 am
Location: Buenos Aires, Argentina


Return to Device Programmers

Who is online

Users browsing this forum: No registered users and 0 guests