PSoCDeveloper

ImageCraft ICCv7 for M8C Pro Compiler :: RE: "pointer to function" in ISR

Author: hitech
Subject: Re: "pointer to function" in ISR
Posted: Sun Oct 05, 2008 10:03 pm (GMT -8)
Topic Replies: 2

hertnfab wrote:

What means that? I'm working with the PSoC Designer 5.0 and the Image Craft Compiler! I think its a compiler problem...

Actually you are using the HI-TECH C compiler - the error message gives that away.

I suggest you firstly try the latest compiler build available from here:

http://forum.htsoft.com/all/showthreaded.php/Cat/0/Number/69252/an/0/page/0#Post69252

If you still have the problem, either post your question on HI-TECH's forum at http://forum.htsoft.com or email your project to support@htsoft.com and ask for assistance.

Clyde

General :: RE: 4x6 Keypad

Author: aries_ph08
Posted: Sun Oct 05, 2008 9:26 pm (GMT -8)
Topic Replies: 9

@ Blackfin

I did fixing the code for ucColState i change it into 4. then change my declaration into Byte for bKeyIndex. Still i cannot get the results I've wanted.

Code:

ucColState = ((PRT2DR & 0b11110000) >> 4) | ((PRT0DR & 0b00000011) << 4 ) ;

The results is always on the bKeyIndex = 0.
What do you mean on Scoping the pins and see if the column return is as expected.? Please do elaborate on this?
Thanks for the help.

General :: RE: Flash Writing Problems

Author: graaja
Posted: Sun Oct 05, 2008 7:36 pm (GMT -8)
Topic Replies: 5

Paul,

No. I have not had this experience. But, if the flash loses its content, it should definitely be a flash retention issue. This usually happens when the flash is written with insufficient pulse width.

Generally, if the product operates within 0 to 50 degrees, you can calculate the pulsewidth based on a temperature of 25 degrees. But for any more deviation, either the flash retention or the number of write cycles will degrade.

For example, if you had calculated the pulsewidth for 50 degrees and if the actual temperature were 10 degrees (or less), then flash retention may be affected. On the other hand, if you had calculated the pulsewidth for 10 degrees, but are writing at 50 degrees, flash retention would be fine, but the number of erase/write cycles will degrade.

So, in your case, there should be some major deviation in the temperature measurement and / or pulsewidth calculation.
_________________
Regards,
Ganesh

General :: RE: Flash Writing Problems

Author: wrightpc
Posted: Sun Oct 05, 2008 5:37 pm (GMT -8)
Topic Replies: 5

Graaja,

Thanks for your reply. Have you had this happen yourself?

It's actually a custom system as the device has the firmware uploaded remotely (based on the flash appnote).

At the moment we are reading the local temperature and calculating the parameters according to section 3.4 of the TRM. Is there a safe temperature setting that we could use all the time (fixed write parameters)?

I'm going back now to double check that I haven't done something silly.

Paul.

General :: RE: AN2120 RTD & PGA Question

Author: graaja
Posted: Sun Oct 05, 2008 5:31 pm (GMT -8)
Topic Replies: 23

What are the physical voltage levels on the input pins with the 100ohms and 150 ohms resistors. Only if we have these values, we can decide if the problem is external to PSoC or internal.
_________________
Regards,
Ganesh

General :: RE: Flash Writing Problems

Author: graaja
Posted: Sun Oct 05, 2008 5:26 pm (GMT -8)
Topic Replies: 5

Paul,

Which bootloader are you using? If wrong temperature value is used during flash write, this problem may happen.
_________________
Regards,
Ganesh

General :: RE: Flash Writing Problems

Author: wrightpc
Posted: Sun Oct 05, 2008 1:14 pm (GMT -8)
Topic Replies: 5

Thanks for the feedback - I will search the forums for other failures.

We have used over 30,000 CY8C27xxx and CY8C26xxx chips in previous products with only 1 failure. The only difference is that we are not writing the final code from an external programmer, but reflashing itself.

I'm worried that this is something inherent and we can't work around it.

Paul.

General :: RE: Flash Writing Problems

Author: FAA
Posted: Sat Oct 04, 2008 8:48 pm (GMT -8)
Topic Replies: 5

We have been using PSoC for more than 5 years and have sold a small quantity of devices with different chips, mostly CY8C29xxx.

In these years, I have noticed what you mentioned. Not an important quantity, though (Around 100 in 20,000 units), but I was also wondering if it is a chip or a design problem. I am not sure yet.

I have seen the same case in this forum several times.

Maybe you could submit some of your chips to a failure analysis at Cypress. I have not done it, but reading yours and the other posts I guess it would be a good idea.

Regards,

FAA

General :: RE: Reading physical address of pointer to structure

Author: fidelity
Posted: Sat Oct 04, 2008 7:44 pm (GMT -8)
Topic Replies: 2

Thanks FAA,

I got the required!!

Thanks again,
Fidelity

General :: RE: Reading physical address of pointer to structure

Author: FAA
Posted: Sat Oct 04, 2008 3:43 pm (GMT -8)
Topic Replies: 2

Check the ProjectName.mp file in the \ProjectName\output directory.

At the end, there is a symbol table where you can find the address. Then, you can add it manually to the watch window and/or in the .wnp file, if exists.

Hope this helps.

Regards,

FAA

General :: RE: Hi!

Author: GeorgeIoak
Posted: Sat Oct 04, 2008 3:34 pm (GMT -8)
Topic Replies: 1

what are you actually trying to accomplish with your project?

What eval board are you working with or what is your hardware configuration?

If you post what errors(s) you are getting that would help determine what is wrong.

General :: Reading physical address of pointer to structure

Author: fidelity
Subject: Reading physical address of pointer to structure
Posted: Sat Oct 04, 2008 9:40 am (GMT -8)
Topic Replies: 2

Hello all,

I am trying to debug my code, where I am using a pointer to structure. As its not global variable I dont see it in global variable list while debugging. Is there a way to know its physical address in RAM, so that I can add to watch variable list?

Thank you,
Fidelity

General :: RE: Need a pull down with DigBuf

Author: FAA
Posted: Fri Oct 03, 2008 11:15 pm (GMT -8)
Topic Replies: 6

lemmy:

Yes. I tried my own formula and did not work. It is more complicated than I thought and requires more pins.

Attached is a shot in PDF for the configuration of 1 pin, as an example.

I could not find any other way to do it.

Hope it helps.

Regards,

FAA

General :: RE: Need a pull down with DigBuf

Author: lemmy
Posted: Fri Oct 03, 2008 6:16 pm (GMT -8)
Topic Replies: 6

I have tried writing a 0 at the beginning of the program, then compiled again with writing a 1 and the I tried writing nothing and in every case the pin was driven high (not pulled high with a resistance). I will check shadow registers. Thanks.

General :: RE: A quick question about UART TX

Author: GeorgeIoak
Posted: Fri Oct 03, 2008 3:23 pm (GMT -8)
Topic Replies: 1

The Write command does not return until the last byte is sent out. I guess if you wanted to check each byte you could use the PutChar command in combination with checking the register and loop through each byte in your string.