- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I also have such a demand
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
(Not only) For the right naming: PSoC4 hasn't got any EEProm, there is flash only. There is, as you stated, emulated EEProm which will reside in the flash of the chip. Since the programming of the chip starts with a (complete) erase, all data stored in the emulated EEProm will be lost.
Only way out I see is: using bootloader to re-program your chip with a new application and manage to leave the eeprom-area untouched. Probably someone else may have another solution, I would suggest you to create a "MyCase" (and please keep us informed of the results). To do so, use "Support&Community -> Technical Support -> Create a MyCase" at top of this page.
Happy coding
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Another approach is to write your own bootloader, it's not too hard.
With that bootloader, the first thing you do is READ the protected areas, then ERASE, then PROGRAM flash, then WRITE back the data you saved earlier. - This is what I do with PSoC 5.
BTW, there were serious bugs in the Emulated EEPROM component v1.0 which /should/ have been fixed by Cypress in Creator 3.0 - but these bugs won't apply to PSoC4, but on my PSoC 5 systems using the 'fixed' code I still get flash and bootloader corruption from time to time which I am sure is down to the emulated eeprom component.
OR if your system has an external interface such as RS232 or Ethernet, save the data, re-flash with Cypress tools and then re-load the data as a function of the firmware.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have found when small window occurs clearing browser history,
most of the time, clears up the problem.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You'll have to activate in Internet Explorer the "Compatibility Mode" (or whatever the translation is). Only that will work for IE.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you. Compatibility View did the trick.
I got a reply from MyCase:
Thank you for pointing out this enhancement. But this is not possible with the present PSoC Programmer.
But you can write your own script using PSoC COM library, without having the step to Erase the flash. Now write to the flash PSoC4_ProgramRowFromHex(). And write the flash data from hex file. But we have not tested the same. While doing the same care must be taken care while calculating check sum.
Please let us know if you have any further questions regarding this. Thank you for your suggestion.
So that does not help me at this point in time. I am pressed for time and can't research the COM interface and scripts. Will just have to comment one line in for each board I program.
Currently the only solution is to use a bootloader as stated, which I also don't have time to write .
Thank you,
Errol
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There are projects already written for Bootloader -
http://www.cypress.com/?rID=50230 AN68272
http://www.cypress.com/?rID=83293 AN86526
http://www.cypress.com/?rID=56014 AN73854
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Dana.
I've looked at all the bootloaders, but we will have to write a custom interface for the bootloader component. We run 8 boards on a single half duplex serial line. The protocol is custom with source device and destination device indicated in the packets.
To complicate things more, the PC talks to an HID usb device using it's own packet formats. The HID device must place the end device into bootloader mode, reformat the packets coming from the PC to the serial packet format then sent it on to the end board.
This must also be very robust as the PC, HID board, and end boards all sit inside a safe and the end devices all control the safe motors. Thus if something goes wrong and you loose comms to the wrong board then you must cut into the safe as there is no other means to open it.
This all adds up to a lot of things that can go wrong with the bootloader, and a lot of testing.
Thank you,
Errol
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello!
Datasheet of Emulated EEPROM1.10 says that it can be used when data needs to be preserved across power cycles, and the target device does not have dedicated EEPROM memory. But I don't see a read function in the API. Can anyone write a small code for the following scenario so that the functionality is clear? :Store a variable (uint8) in emulated EEPROM and assign it a value of 10, then on reset:- Read the variable if it is 10 or anything else, change it to 20 and display (character LCD) 20
- Read the variable if it is 20, change it to 30 and display (character LCD) 30
- Read the variable if it is 30, change it to 10 and display (character LCD) 10
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What you want to perform is easily done.
"Reprogramming of the CHIP starts with a complete erase" is true, but it only concerns when you program your project, not when you program a handfull of bytes under the control of your program. So beteen resets and power-downs the values in the eeeprom are saved.
First you need a variable residing in flash (although this might sound weired), so you declare
const uint16 FlashVar = 0u; // will put this into flash memory
Next you need a variable that holds the information to write to eeeprom
uint16 RamVar;
After starting your EEEProm module (do not forget!) you may read and write as
RamVar = FlashVar + 10;
EEEProm_Write((char*)&RamVar, (char*)&FlashVar,sizeof(FlashVar));
As you see there is no explicite eeeprom read.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
is it not possible to access the eprom data (an array for example) if you reprogram the psoc? I have a bootloader aplication
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This -
const uint16 FlashVar = 0u; // will put this into flash memory
Should be changed to this -
code uint16 FlashVar = 0u; // will put this into flash memory
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yeah! Dana is right!
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
... but "const" does work as expected. Address of var is within flash. (PSoC4, GCC)
and "code" is flagged as error.
Dana, seemingly you are not right
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From Keil manual (notice the word "typically") -
In ANSI C, the const type qualifier is used to define and access objects that are constant and that may not be changed. A variable that is declared with const may not be assigned to in the program.
The Cx51 Compiler conforms to the ANSI definition of const objects.
- Variables declared with the const type qualifier alone are stored in the memory area (data, idata, xdata, and so on) associated with their definition.
- Variables you want to locate in ROM must be declared with the code memory type. For example:
code char test[] = "This is a text string";
- Variables declared with const far are stored in the HCONST memory area. This area is typically allocated to ROM memory.
- Finally, the STRING compiler directive specifies where string constants are stored. This directive allows you to place strings in CODE memory, HCONST memory, or in XCONST memory (constant space in XDATA).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Looks like I am in the wrong compiler manual, 8051 PSOC 3 is not
a PSOC 4 ARM, GCC tools.
So is GCC firm on the use of const ?
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So here is a discussion of GCC and cost -
http://www.nongnu.org/avr-libc/user-manual/pgmspace.html
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
replace cost with const in prior post.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content