Hello,
In a new project i use the LPC1347
this chip has an "internal eeprom" and i can use only the "internal ROM" function to access this memory.
because i dont want to disable the interrupts while reading or writing the EEPROM
i found the external LIB, which can linked to project. LIBEEPROM.a
For a risk analyse i have a problem with the internal and also for the external lib
because i have no source, it belongs the category "SOUP" (Software Of Unknown Provenance)
My Software at time dont use any SOUP, because it is an medical product.
Is there any way to get the Source Code for the LIB ?
Or can i get a description to the EEPROM registers of the Chip, to write my own code ?
I think it is not a secret code to write to EEPROMs, i do that every day
with external eeproms in an other projects.
very thanks for information.
Bernd
Hi Bernd,
As for the local NXP office support offered by Brendon, you can contact me at <firstname>.<lastname>@nxp.com.
Regards,
Rolf
a lot of test are running and i also loocked to the Assembler source:
The Library includes:
EELIB_entry external
EELIB_getVersion external
EELIB_idleHandler external
_EEPROM_init internal only
_EEPROM_write internal only
_EEPROM_read internal only
library creation info: found in the library itself:
GCC: (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 227977] A2aeabi (Cortex-M3)
The Assembler code shows that the first action is to check the function WRITE or READ to eeprom
the order of the compare i think is not so good.
most accesses in EEPROMs is to the READ function, but the first compare ist to the write function
this eats unnecessary time :-)
push {lr}
sub sp,#28
str r0,[sp,#4]
str r1,[sp,#0]
ldr r3,[sp,#4]
ldr r3,[r3,#0]
cmp r3,#61 IAP command EELIB_IAP_COMMAND_EEPROM_WRITE
beq.n entry+34
ldr r3,[sp,#4]
ldr r3,[r3,#0]
cmp r3,#62 IAP command EELIB_IAP_COMMAND_EEPROM_READ
beq.n entry+34
the EELIB_getVersion simply result a constant 3
all the range checks i have tested are well done.
The latest eeprom address in the LPC1347 is 4096-64-1= 4031 adress range 0..4031 decimal
Access greater this address results in a EELIB_IAP_STATUS_DST_ADDR_NOT_MAPPED error
// write ablock of comlete EEPROM size (4032 Bytes)
res = EE_Write(0,&value,4032); // EELIB_IAP_STATUS_CMD_SUCCESS
// try to write 4033 Bytes (one byte to much)
res = EE_Write(0,&value,4033); // EELIB_IAP_STATUS_DST_ADDR_NOT_MAPPED
// write only to the latest eeprom address one byte
res = EE_Write(4031,&value,1); // EELIB_IAP_STATUS_CMD_SUCCESS
// write to the latest eeprom address 2 Bytes: (one byte above)
res = EE_Write(4031,&value,2); // EELIB_IAP_STATUS_DST_ADDR_NOT_MAPPED
// write to an eeprom address outside the address range */
res = EE_Write(4050,&value,1); // EELIB_IAP_STATUS_DST_ADDR_NOT_MAPPED
the eeprom write code i have stepped one by one the complete code and there is nothing
which change any interrupts to slow down the CPU.
the hook function is also tested. In the dead time while eeprom is written, it calls the
void EELIB_idleHandler (void)
i am on the best way to validate the library :-)
Siro
New tests for the libeeprom: write cycle timing and hook functionality
the EEPROM is paged to 64 bytes each, so writes above the page boundary needs more time
one page write need typically 1100 write + 1800 erase = 2900 microsecond as described in the datasheet.
my measeure can confirm that:
New behavior of the hook function was found:
The hook function is called for every page write.
So if you write data only in one page, the hook was called one time
if you write bytes which ovelaps two pages the hook was called two times.
examples:
EE_Write(62,&value,2); time = 2092 µs 2 bytes, all in in the frist page
EE_Write(63,&value,2); time = 5772 µs 2 bytes, first and secound page used
know: in the secound example the hook function was called two times.
so the hook function works very fine, but that was not found in the documention,
or i cant find it.
no of bytes written | time in microscound | EE pages = hook calls |
1 | 2888 | 1 |
2 | 2891 | 1 |
4 | 2893 | 1 |
5 | 2895 | 1 |
10 | 2896 | 1 |
20 | 2905 | 1 |
50 | 2927 | 1 |
64 | 2937 | 1 |
65 | 5821 | 2 |
127 | 5869 | 2 |
128 | 5869 | 2 |
129 | 8752 | 3 |
192 | 8825 | 3 |
193 | 11708 | 4 |
255 | 11765 | 4 |
256 | 11732 | 4 |
257 | 14648 | 5 |
Have a good weekend
Siro
Hello Dmitry,
thanks for your answer.
The LPC Open Library used the internal ROM Code of the Controller
the only documentation is : how to call the functions via IAP calls
but it has no code dokumentation inside this function: iap_entry(command, result);
i know how to use these functions and it works fine with the internal ROM
and also works fine with the linked libeeprom library.
but i looked for the inside code, or registers how it works.
Bernd
Hi Bernd,
The IAP and ISP functions are implemented in ROM, for which NXP does not release source code, sorry.
NXP might be able to help you get through this situation for a medical application that has special requirements - please contact your local NXP office for help with that.
Regards,
Brendon
Thank you for the answer Brendon
I find that very unfortunate, that the ROM code ist not open
What's so mysterious in that code :-)
It's just about the principle, Drivers ROM code must be open
This is my personal opinion.
Maybe i contact NXP or i use external EEPROMs.
Bernd
Hi Bernd,
I can understand you might think that... but actually we have some "special sauce" in there to do with flash memory control and other items, so that's why we don't release it as a general rule.
The point about releasing some aspects related to boot behavior is a valid point, but we try to do that with written explanations.
Best regards
Brendon
Hello,
I have decide to test the library thorougly.
So i can verify the behavior and validate the functionality
The Testobject is the libeeprom-lpc1347.a Version 3
Today i have tested the generell functionality.
Read Write with different sizes and addresses.
Then i build a RAM block copy of the complete eeprom
and fill it with defied values.
This complete block was written to the eeprom.
the ram was cleared and all eeprom reading.
All test are succesfull.
then i have tested the last 64 Bytes of eeprom.
To do that i have programmed a serial terminal to access
to the complete menory.
The last 64 Bytes cant be written.
The read value is always 0x00.
The version number i can also read. result is "3"
Tomorroy i will continue some tests with interrupts etc.
If there is any problem in my tests i will write here.
Bernd