To my surprise I discovered that on the BLE - Pioneer board there is a 1Mbit FRam (Ferro-electric Ram) that can be accessed via I2C..
So I wrote a simple program to prove that it is working as expected - it does.
What makes things a bit more complicated is the opportunity to increase the transfer-rate from 400kByte/s to 1MByte/s.
here is the datasheet for the FRam FM24V10 www.cypress.com/
Attached the Project
In the datasheet for the F-Ram is a (rather strange) method described to switch to a higher speed than 400kbps. I recently found out that this is not needed and that the F-Ram device runs with ths I2C maximum speed of 1Mbps without any additional actions to be taken.
Updated project for Creator 3.1 SP3 attached.
Contains a data-logging mechanism (FIFO) for different record types
Data is stored in FRam of the BLE Pioneer board. Can be adapted to CY8CKIT-044 Pioneer-M kit
We are using FRAM in our application for datalogging. Have you ever encountered memory corruption due to power failure or other interrupts?
Your code contains a line that checks sanity of the memory and if it is corrupted you clear log. Is this a common practice?
Have you ever encountered memory corruption due to power failure or other interrupts? Never! Simply using the low-power interrupt signal to prevent writing to FRam when power is low will be enough. The time to write to FRam is so short and there is no "Erase Row" needed as in an eeprom.
checks sanity of the memory and if it is corrupted When a corrupt (or an empty) FRam is found, there is no need to use any data which still reside in it, so I abandoned all data. This is quite common as long as forensic analyzing is not required.
Only downgrade using FRam are the costs when some more MBs are needed.
I just checked both versions of your project (CY8CKIT-042-BLE kit) with the CY8CKIT-142 module.
The first version "FRam" works (at least the green LED blinks :-)) but the extended version "FRam Logger" does not.
Can you confirm, that it really works (Psoc Creator 4.0) as axpected in your case?
When I debug it, the system goes in an endless loop in file DataLogger.c, line 159
while(FRamRetValue); // Halt on error
FRamRetValue at this point has the non zero value 0x00000008 returned from the function uint32 FRam_Write(void * Data, void * FRamAddress, uint16 Count).
In your first project "FRam" this method returns the same value, but you do not check it. Instead you compare the data written to RAM and read from RAM in memory, unfortunately the memcmp() function you use returns 0 for a match and you take non zero for a success 🙂 so I corrected this line (main.c, 101) to the following code:
if(!memcmp(WriteArray,ReadArray,ArraySize)) LED_Green_Write(LEDON); // Success
else LED_Red_Write(LEDON); // Faillure
Now the red LED blinks, and the data really does not match in memory, ReadArray is still filled with zeros.
Can you find some time to check your example projects and fix it, I have no Idea about the implementation of I2C and exernal memory access and would like to learn from your example "FRamLogger" project. Thx.
I finally figured out, what the problem was with your examples not working as expected on my dev board.
I changed the power jumper from 3.3 V to 5 V at some point in the past because I interface mostly 5V devices in this project.
It seems there is no voltage regulation for the FRAM on the board and the chip simple did not work because its maximum ratings from datasheet were most probably exceeded. Is it possibly a "hardware bug" of the board?
After switching back to 3.3V your examples magically just work 🙂
Glad that you found out that issue. I must admit that I started to find out anything going wrong, but forgot to dig deeper and inform you.