Storing of text data to OTP memory Topic is solved

Technical questions regarding the XTC tools and programming with XMOS.
Post Reply
dotzz
Junior Member
Posts: 5
Joined: Mon Jun 12, 2017 11:47 am

Storing of text data to OTP memory

Post by dotzz »

Hi all!

I want to store some text data with information about my device to OTP memory. How can I do it using XBURN tool? I found just MACs, SN, or executable bins.

Thank you!


View Solution
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

dotzz
Junior Member
Posts: 5
Joined: Mon Jun 12, 2017 11:47 am

Post by dotzz »

mon2 wrote:http://www.xcore.com/viewtopic.php?f=47&t=5155

see the comments from Henk.
Thank you, I saw this topic and actually what I need: "On a more fundamental level: how OTP is used is up to the end-user, i.e., yourself. You can store a serial number in it, mac addresses, a JPG, or other things; a bit like RAM, you decide on the contents. The only constraint is that *if* you boot from OTP, the bootrom expects a boot image at address 0x000 of OTP."

But I really can't understand, if I have for example file info.txt, how can I put it to otp image?. In command-line manual I found only mac/serial/AES keys commands.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Here is an idea but first some disclaimers:

1) have not tested this idea

2) you are working with OTP (one time programmable) memory so be sure to use the file output method for initial debugging before moving to use the OTP region. The file logging method should allow you to emulate as though you are working with the OTP (risk free :)

Review the use of the following xburn api intended for mac serial # use:

https://www.xmos.com/published/otp-boar ... ing-module

Code: Select all

int otp_board_info_get_mac(otp_ports_t &ports, unsigned index, char mac[6])
so this implies that 6 bytes can be R/W (once) from the OTP region. Using a different index value, nothing to stop you from you storing more data into the OTP. You will have to confirm if this method is practical for > 256 bytes of storage. That is, is there an imposed value limit to index?

XBURN details:

https://www.xmos.com/support/tools/docu ... ion=latest
dotzz
Junior Member
Posts: 5
Joined: Mon Jun 12, 2017 11:47 am

Post by dotzz »

mon2 wrote:Here is an idea but first some disclaimers:

1) have not tested this idea

2) you are working with OTP (one time programmable) memory so be sure to use the file output method for initial debugging before moving to use the OTP region. The file logging method should allow you to emulate as though you are working with the OTP (risk free :)

Review the use of the following xburn api intended for mac serial # use:

https://www.xmos.com/published/otp-boar ... ing-module

Code: Select all

int otp_board_info_get_mac(otp_ports_t &ports, unsigned index, char mac[6])
so this implies that 6 bytes can be R/W (once) from the OTP region. Using a different index value, nothing to stop you from you storing more data into the OTP. You will have to confirm if this method is practical for > 256 bytes of storage. That is, is there an imposed value limit to index?

XBURN details:

https://www.xmos.com/support/tools/docu ... ion=latest
I tried, but if I write more than 7 MACs, I've got: xburn: error: more than 7 MAC addresses specified. So, I can store just 42b?
my info file has around 1KB size... No another ways? Regarding to manual we have 8Kb per tile. And it's not possible to write some custom data there?
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

How about coding up a program that will embed your data inside this program -> write to the OTP (again, use an output file with xburn for initial testing) -> then use your program to fetch this data using the ROM (OTP) API ?

Unless you code + data is < 8k, you may have to use an external flash for your boot code and the OTP area for your data storage.

This appears to be the same idea being discussed here:

http://www.xcore.com/viewtopic.php?f=7& ... ata#p12553
dotzz
Junior Member
Posts: 5
Joined: Mon Jun 12, 2017 11:47 am

Post by dotzz »

mon2 wrote:How about coding up a program that will embed your data inside this program -> write to the OTP (again, use an output file with xburn for initial testing) -> then use your program to fetch this data using the ROM (OTP) API ?

Unless you code + data is < 8k, you may have to use an external flash for your boot code and the OTP area for your data storage.

This appears to be the same idea being discussed here:

http://www.xcore.com/viewtopic.php?f=7& ... ata#p12553
Good idea, thank you.
I made some "dummy" program, like:

int main (void) {
const char text[]=" <here is my text data> ";
return 0;
}

convert it to .bin file and flash it to OTP. Now I able to read my text data from OTP, but I have few questions:
- I guess "boot from OTP" bit was enabled and now chip tries to boot from my "dummy" programm;
- Using this approach I can't use AES bootloader anymore? (because i see, that "dummy" programm was written to 0x00 address);
- when I try to convert .xe to .bin using XBURN, I get "xburn: error: binaries requiring network setup are not supported", helps only manipulations from AN00153:
> xobjdump --split app_test_program.xe
> xobjdump --add 0,0,image_n0c0_2.elf otp_tile_image.xe
> xobjdump --add 0,0,..\src\platform\platform_def.xn otp_tile_image.xe
Is it possible to compile the program without network setup?
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi dotzz. Sorry but no idea the raised questions. Hoping that someone else can assist with details. You may also wish to contact XMOS support for feedback. Still so much for us to learn about these powerful XMOS devices and tools...

On an aside and about the AES bootloader - you are interested in preventing piracy of your widget? In our opinion, just about anything you do will be well protected. Given the complexity of the compiled code, you would have to do very little to prevent cloning. For example, the use of the OTP region along with run time constant checks in your code - the next pirate would have to do quite a bit of homework to reverse engineer the IP before they can clone. Even the use of unique serial numbers and then some hash based on this unique ID (MAC address for example) could lead to results that will demand the pirate have many pots of strong coffee and sleepless nights to copy the product. There are also relatively low cost external devices from Maxim, Atmel and others that over I2C, SPI, etc. you can R/W to this lock / digital key dongle part -> based on the values, branch this way or another in your IP. Best to NOT immediately enter a lock state which will be obvious to the hack reviewing your design. Reminds of a very large company whom we are working with now and this engineer wrote the IP with protection (tons of code to confuse the next engineer to prevent piracy). He recommended that we not proceed to break the code as it is quite complex. Well, in the end, he ends up in a perm loop if the IP was cloned. The fix involves to just null out this perm loop and the code can work again - not a good idea to use in the real world. Still make your IP do something but obviously the wrong execution once the code is deemed to be copied without your special code locks.
dotzz
Junior Member
Posts: 5
Joined: Mon Jun 12, 2017 11:47 am

Post by dotzz »

mon2 wrote:Hi dotzz. Sorry but no idea the raised questions. Hoping that someone else can assist with details. You may also wish to contact XMOS support for feedback. Still so much for us to learn about these powerful XMOS devices and tools...

On an aside and about the AES bootloader - you are interested in preventing piracy of your widget? In our opinion, just about anything you do will be well protected. Given the complexity of the compiled code, you would have to do very little to prevent cloning. For example, the use of the OTP region along with run time constant checks in your code - the next pirate would have to do quite a bit of homework to reverse engineer the IP before they can clone. Even the use of unique serial numbers and then some hash based on this unique ID (MAC address for example) could lead to results that will demand the pirate have many pots of strong coffee and sleepless nights to copy the product. There are also relatively low cost external devices from Maxim, Atmel and others that over I2C, SPI, etc. you can R/W to this lock / digital key dongle part -> based on the values, branch this way or another in your IP. Best to NOT immediately enter a lock state which will be obvious to the hack reviewing your design. Reminds of a very large company whom we are working with now and this engineer wrote the IP with protection (tons of code to confuse the next engineer to prevent piracy). He recommended that we not proceed to break the code as it is quite complex. Well, in the end, he ends up in a perm loop if the IP was cloned. The fix involves to just null out this perm loop and the code can work again - not a good idea to use in the real world. Still make your IP do something but obviously the wrong execution once the code is deemed to be copied without your special code locks.
Anyway, you helped me a lot! Thank you :)
Post Reply